werwolf969

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.