tl;dr
Go to hexed.it, drag&drop your witcher3.exe into it, jump to 0xB95CF6, 0xB96366, 0xB967A6 or 0xB95E56 until at that address the bytes are "C0 00 00 00". In the left panel under 32-bit integer, change the number 192 to 500, press enter, export from the top menu, move the modified executable it downloaded to your bin/x64 directory and start it (keep the original just in case). Image to illustrate:
(will replace with a link to mod once I have made one which automatically applies the fix)
LONG VERSION:
I have found a proper fix for the mod limit issue.
The fix involves changing a hardcoded limit (just a single number) in the executable itself. The actual thing limited by that number seems to be the number of file handles, one of which was used by each bundle, thus causing bundles from mods and DLCs to both cause that limit to be reached, and eventually fail to properly load after the limit was reached. It was limited to 192, which apparently was just about enough for the vanilla game, but will be hit very quickly once you start adding mods.
Fixing it involves just increasing that limit in the executable itself. The position in the executable to modify depends on the specific game version you have (there are around 5 different executables among 1.31-1.32 versions). See the tl;dr above to find the position it is at in your executable. In case none of the addresses apply, you can search for the "BA C0 00 00 00 48 8D 4B" pattern in the hex editor, which should presumably be somewhere between B94000 and B98000.
In the coming week, I will create a DLL that will automatically patch this limit during runtime for various different executables without having to modify the executable itself, but if you want to fix it right away (also I'm not entirely sure when I'll get to it), you can just follow the above guide. Or you can just share patched executables to your pals.
The fix has been tested by a dozen or so people already and it appears that it solves most cases where the game hangs during loading when many mods/DLCs had been installed. Some have reported that it has resolved some delays occurring during gameplay itself too.
I have been asked how I stumbled on this fix (and also how exactly it broke the game), so I quote myself from before:
Note that much of the description above of what the game is doing is just guesses. As I simply followed the trail of explosions, I did not stop to verify exactly what the intermediate parts were doing, so some of the description of what the game was doing might not be technically correct, but it did lead to the correct solution.
Some have also been wondering why this limit was set so low. I guess we might never really know, but my personal guesses are that it might either be related to limits on consoles, or it may have been set arbitrarily during development, to be changed only once it becomes a problem (as it never did for vanilla game, might have been left as initially set).
Enjoy spamming your mod directories now!
Go to hexed.it, drag&drop your witcher3.exe into it, jump to 0xB95CF6, 0xB96366, 0xB967A6 or 0xB95E56 until at that address the bytes are "C0 00 00 00". In the left panel under 32-bit integer, change the number 192 to 500, press enter, export from the top menu, move the modified executable it downloaded to your bin/x64 directory and start it (keep the original just in case). Image to illustrate:
(will replace with a link to mod once I have made one which automatically applies the fix)
LONG VERSION:
I have found a proper fix for the mod limit issue.
The fix involves changing a hardcoded limit (just a single number) in the executable itself. The actual thing limited by that number seems to be the number of file handles, one of which was used by each bundle, thus causing bundles from mods and DLCs to both cause that limit to be reached, and eventually fail to properly load after the limit was reached. It was limited to 192, which apparently was just about enough for the vanilla game, but will be hit very quickly once you start adding mods.
Fixing it involves just increasing that limit in the executable itself. The position in the executable to modify depends on the specific game version you have (there are around 5 different executables among 1.31-1.32 versions). See the tl;dr above to find the position it is at in your executable. In case none of the addresses apply, you can search for the "BA C0 00 00 00 48 8D 4B" pattern in the hex editor, which should presumably be somewhere between B94000 and B98000.
In the coming week, I will create a DLL that will automatically patch this limit during runtime for various different executables without having to modify the executable itself, but if you want to fix it right away (also I'm not entirely sure when I'll get to it), you can just follow the above guide. Or you can just share patched executables to your pals.
The fix has been tested by a dozen or so people already and it appears that it solves most cases where the game hangs during loading when many mods/DLCs had been installed. Some have reported that it has resolved some delays occurring during gameplay itself too.
I have been asked how I stumbled on this fix (and also how exactly it broke the game), so I quote myself from before:
attached a debugger. started out by checking what the game is doing when it is "stuck". it was waiting for all previously started decompression operations to finish successfully. tried to detect which of the decompression operations did not finish successfully, found one which seemed to fail consistently for me. then, compared what happens during its loading when mod limit is not reached, vs when it is. backtracked (started from when it ended in failure) in the loading process until the point at which there was the first difference between the two - that was the point where it was about to scan a bundle to determine its decompressed size. at that location, it checked whether it can even do that by comparing a number that was incrementing with every next bundle to a constant value 192. in case of no mod limit reached, it never reached 192 so the failure was never triggered, in case of mod limit reached, it went above that, so after that was reached, bundles were no longer scanned. if the decompressed size of the bundle was unknown, the decompression task was automatically marked as failure because it didn't know how big of a buffer to allocate.
~5-6 hours of debugging and perhaps like 200-300 times relaunching the game in a debugger
Note that much of the description above of what the game is doing is just guesses. As I simply followed the trail of explosions, I did not stop to verify exactly what the intermediate parts were doing, so some of the description of what the game was doing might not be technically correct, but it did lead to the correct solution.
Some have also been wondering why this limit was set so low. I guess we might never really know, but my personal guesses are that it might either be related to limits on consoles, or it may have been set arbitrarily during development, to be changed only once it becomes a problem (as it never did for vanilla game, might have been left as initially set).
Enjoy spamming your mod directories now!
Last edited: