werwolf969

You're welcome! My install.xml from rdo version, without weapons.ymt, catalog.sp and shopitems.meta. My bad, sorry. You can open install.xml from my archive and copy lines under the Item_Textures to your standard install.xml of WhyEm DLC. Filereplacement blocks that have three .ytd files in their filepath. Tommorow (my TZ) I will add install.xml for standard variant to my message with link, thank you for pointing this out to me.

Other mods have the same textures, I only re-created the install.xml file for each one listed, so LML replaces full files in memory instead of streaming them in chunks, as streaming is one of the main causes for the problems we discuss in this thread. You can download these mods from Nexus, as I don't think it's appropriate to re-upload the full mod archive. However, here are the install.xml files for each of the mods listed in my post. You need to rearrange the files a bit in these folders, just look at the install.xml and if there is a *folder name*/modded.filename in <FilePath></FilePath> node, then you need to place the modded file in the *folder name*, and if it's just *modded.filename*, you need to just place it in the mod name folder next to install.xml. For example, Complete Horse Overhaul keeps its files in the lml/stream folder, so you need to move the textures (.ytd files) in the "Complete Horse Overhaul/Textures" folder, and the config files (.ymt files) just in the "Complete Horse Overhaul" folder next to the install.xml, and replace the install.xml with the one attached to this message. RemadeInstallxmlforUpscales.7z

Sure, you will just lose a few added by WhyEm engravings. In the WhyEm menu for gunsmith customization, there will only be default ones instead of modified ones. Thank you for your warm words and feedback! But all credits must go to WhyEm, as he is the author of this cool mod. I'm just repacking a few assets with proper technique.

swatches_gunsmith.ytd is little icons for engravings and gun parts colour when you customize your gun in gunsmith menu other two are engravings and stock engravings textures. WhyEm DLC added some. You can merge this files with yours. You're welcome! Also, for me, only one mod causes broken spawns, and it's "Weapons Textures Upscale" by WickedHorseMan. Even after scaling down, compressing, and proper loading with LML, this mod's textures break the game logic. I guess it's because the textures have too much quality per pixel, so the game engine can't process them when other upscaled mods are loaded. For now, I have these upscaled textures, and the game works perfectly. Blackwater Terrain Textures Overhaul CharactersOverhaul (remade install.xml) Complete Horse Overhaul (remade install.xml) Terrain Textures Overhaul Upscaled Animals AIO (remade install.xml) Upscaled Documents (remade install.xml) Upscaled Fires (remade install.xml) Upscaled Journal (remade install.xml) Upscaled Signs & Posters (remade install.xml) Upscaled Vegetation WhyEm_DLC (compressed and remade install.xml) alongside with other asi scripts and config editing mods.

Okay, here's my take on compressing WhyEm DLC textures. Also, I re-made install.xml with few files that could be replaced instead of streaming them. UPDATE: Since I got explicit prohibition to share my edit from WhyEm, I removed download link. It is what it is, I guess. I attaching to this message two install.xml files with names for obvious variant you use. But other than that I could not help, sorry. install.xml_rdo install.xml_standard

I reviewed potential possibilities to do so. Unfortunately, neither RedM nor CodeX provide any CLI or API for interacting with them. I tried to create an AutoHotKey script, but there are too many variables that can change during the process, so it is just faster to do everything by hand at this point. It's a very tedious process. I agree, but if you can process 200 files in one day, you will finish in 10 days. Just be patient and perseverant. Good luck! Also, if you use my previous script for conversion, please check the colours and details of the textures. They will be worse than the original. You can correct the colours in Paint.NET or use my other script, at the moment I haven't found any differences between the original and compressed textures if conversion done with it.

Hi. I'm still experimenting with different BC formats for different texture mods. I concluded that BC7 is best for ab textures, BC1 is best for nm, and BC3 works well for other materials (m, ma, mb, etc.) or two-colour textures. If you use BC1 for detailed textures with a source format of B8G8R8A8_UNORM (an uncompressed A8R8G8B8 format), some colors or details, like near-white or black seams on clothes, might be lost during conversion. Also, I've downscaled some mods, like WickedHorseMan's animals packs and weapon packs, so that they don't have textures larger than 2048 x 2028 pixels. I wrote a more complex PS script so the process of downscaling and conversion can be fully automated. Here's the link if you or anyone else wants to use it or tweak it for their own purposes: https://pastebin.com/Zufj5xeP Ensure that the texconv.exe and nvtt_export.exe folders are added to the system path before launching.

It makes perfect sense, since many tests were conducted with gameconfig.xml and systemsettings.ymt. If you increase limits for different resource pools in gameconfig too much, the game will crash. The maximum limits for stable game operation in these files do not solve the problem, because there are still not enough resources in game engine for all the desired streamed assets from mods not broke game logic partially. Also, trains spawns only within the specific player's radius, as do trolleys. In a perfectly working game, your train will have at least 10 people in each cart, and trolleys too. The issue is not in the peds spawning , but in the overall spawning of entities, since when the game engine is overloaded, it will not spawn any trains for you, not just people in them. This is also true for birds and other animals at different spawning points, and for peds on trolleys since trolleys always spawn. What I am trying to investigate is whether splitting texture dictionaries into smaller sizes and editing metadata files for texture references would help with streaming issues and overall engine overload. In GTA V, you could do this trick due to problems with textures not rendering correctly on models when you exceed the limit of 16MB per texture dictionary. If this is true, then we could avoid the steps of compressing textures and simply split them, which is way faster than other manipulations with textures.

This will not work because the problem is not in a broken script in the game that doesn't spawn entities, and you can't fix it by modifying some files. It's the game engine itself that limits the number of entities that can be shown. If you try to force the spawn of some entities, then the game engine will despatch some elsewhere and this part will break. If you overload the game engine, it can't apply some of its internal "save mechanisms", and the game will simply crash. You can even crash the game by installing too many upscaled and bloated texture mods and loading the game in a dense area, like Saint Denis, to trigger this behavior.

Another problem with texture mods is that some of them are just unreasonably bloated with textures that don't make sense. For example, the textures from WickedHorseMan's mods often have not only no compression, but also huge sizes that are not necessary. For instance, the 4096x4096-sized texture for animal teeth in his mammal packs. There's no way to tell the difference between a 512x512 and a 1024x1024 size texture for animal teeth in the game. Yet, we have one that's 16 times bigger than the vanilla archive. The same goes for his material upscales. There's no reason to upscale a material texture to 2048x2048. You can never see the difference in the game when it's applied. Even after repacking, his mods have a size of 10 GB, while the same original data has a size of 300 MB. So, many mods could not only be optimized by reducing their size through texture compression and mod installation manipulation, but they could also be optimized overall with reasonable texture sizes for each type of texture in the dictionary. I hope the authors will either update their mods or give permission for the community to optimize them and upload them with credit to the original work. Otherwise, we'll be stuck choosing between a single character overhaul mod or dozens of scripts and quality of life mods. That's a sad reality.

I managed to fully repack the Complete Horse Overhaul mod, using recommended baseline texture compression methods, and remade the install.xml file so that mod data was not streamed but rather replaced in memory. In an already broken save file where no trains spawned and horses partially did not get streamed textures, this helped to load mod data correctly. I wrote to the author asking him to update his mod on Nexus with information about the issue. Hope he will respond. Thanks to all the information from this incredible community, we can create guideline to ensure that mods are optimised and will probably cause fewer issues when used simultaneously. My 2c: 1. Avoid using stream folder inside LML This along cause many issues and in all guides for modding previous games for this engine this folder considered only for testing purposes, not for usage by published mods. Issues came from data being loaded in chunks, rather then fully placed in memory, so streaming process with many files in stream folder cause game engine allocate way more resources for this process only and stop process game logic, that considered not essential for overall game process by game engine. 2. Use compression methods for textures. This technology exists for a reason. All game textures use Block Compression methods, so the game engine is optimized to work with them. This applies to APIs (DirectX or Vulkan) regardless. Recommendations for different BC methods for each texture type: Albedo (ab) - BC1_UNORM_SRGB or BC1_UNORM Materials (m, ma, mb, ct, eg) - B3_UNORM Normal maps (nm) - BC1_UNORM This is how textures are packed in game archives. There is no noticeable difference in quality between BC7 and BC1 textures, so there is no reason to stress the game engine with heavy texture files or create potential game logic errors. 3. Pack mods well for usage with LML LML is a wonderful tool that gives us the opportunity to modify game files using different methods. However, with many mods, there is a need to optimally configure the install.xml file. We should avoid streaming files as much as possible and instead replace them in memory. To do this, we must use the following code structure: <Resource name=""> <FileReplacement> <GamePath></GamePath> <FilePath></FilePath> </FileReplacement> </Resource> With this structure, we ensure that files we are modifying will be replaced in memory upon loading, so the game engine processes them from memory instead of streaming them partially from your drive during the game in chunks. Personally, I think that any replaced file should be replaced directly by this method, regardless of whether it is a texture dictionary, a configuration, or any other type. However, texture dictionary files (YTD) must definitely be replaced using this method, since it greatly helps with the game engine's data overflow problem. As for the replacement folder, it's simply about overall mod management consistency. Therefore, place your files in your mod folder and not to the "replace" folder in LML. I don't know if we can somehow avoid streaming newer added files that are not in the game archives. With the actions above, we are at least moving away from running out of the game engine's resource pool. The game engine still has limited internal resources. By following these guidelines, we try to fit in as much additional modded content as possible. However, there is no guarantee that we won't cause the game engine to overload with data again. So, choose your mods carefully and spread the word about optimisation in the modding community. Let's hope that one day, all the cool mods will be intact, with all the recommendations the community has found, and we will play an awesome game with hundreds of GB of mods!

Hi all. As Vincemeister55 and others have already mentioned, we can re-compress textures using optimal and native compression methods for the Rage engine without any noticeable loss in quality, freeing up some resources in the game engine, so it can give them for game logic again instead of drawing fancy graphics. However, with large texture mods with many files, such as WhyEM DLC and EEE, it can be very tedious to manually open each DDS file and re-save it using the proper BC method. Therefore, I have created a basic PowerShell script that utilizes the MS tool called Texconv.exe (https://github.com/microsoft/DirectXTex). The script will re-code DDS files in a specified path and subfolders, and output the results to a different folder while preserving the source folder structure. You must edit the paths for Texconv.exe and the source and output folders in the script before running it. Link to script with comments: https://pastebin.com/9fAcGUCi Unfortunately, I cannot automate the export and import of DDS files from and to YTDs, so you will need to prepare a workspace yourself before running the script. For example, the folder structure could be: Somefolder texconv.exe lml Modname *folder with texturedictionaryfilename.ytd* *DDS textures from this ytd* ouput_folder_for_script The script itself checks for input in DDS format and skips any texture files that do not have a B8G8R8A8_UNORM header. I chose this format only because all the large textures from big mods that I use personally are in this format. This is the most resource-intensive format for the engine, and this check is done to not process correctly compressed textures from YTDs. Also, the script will compress material textures to BC3_UNORM and other textures to BC1_UNORM. As for exporting DDS from YTD and packing them back, as specified by Vincemeister55 and others: To extract DDS textures from YTDs - use OpenIV To pack DDS textures back into YTDs - use RDR2 Texture Toolkit (and RedM, as required) OR Simply use CodeX (patreon supporters access only). Feel free to edit the script to your liking.