Relevant: https://steamcommunity.com/app/218620/discussions/10/371918937287046189/#c371919771763121260

Relevant: https://steamcommunity.com/app/218620/discussions/10/371918937287046189/#c371919771763121260

On the question of why mod_overrides do not work may have something to do with the fact that the bundle format is different to the windows version of the game.

Ah, I see. I'd noticed that the bundles on the Linux version were different from the Windows version as well, but hadn't really thought anything of it being related to the mod_overrides issue.

FWIW, I did some cross-referencing in both binaries, and while the Windows version references the "mod_overrides" string twice in two separate subroutines, there are no such references in the Linux binary. Gonna dig around a bit more.

WRT to the bundle format being different, I may disagree.

The mod_overrides folder is structured such that it represents the internal structure used by the Diesel asset pipeline database to find the assets.
I would guess, based on some function signatures, that the asset database scans this folder, and then loads in the assets in a certain path to replace assets matching that path that are already in the database.

This would be pretty format storage agnostic if that's what they were doing.

One of the issues I suspect to be causing a lot of the functionality deficit on Linux is that (and this is speculation) overkill are using divergent branches for the Windows and Linux builds. This means that there are two effectively separate codebases being used for the two different builds. This would not effect the addition of new content such as Weapons, Maps, etc... because all that data is stored in bundles along with scripts that install them in to the game. If you look in to historic issues, many users were encountering similar issues during Crimefest 2015, such as not receiving voice data and what have you. Additionally, while I'm unsure of the date of its introduction in to the game, but I imagine that if you were to look at the source for the main/options menu, you would find that the "Mods" menu option (for the asset mods folder) is simply not even implemented

I would guess, based on some function signatures, that the asset database scans this folder, and then loads in the assets in a certain path to replace assets matching that path that are already in the database.

That sounds likely, though it appears that the function dsl::MainDB::collect_mod_overrides() isn't being called (nor referenced) anywhere in the Linux binary (I've yet to track down the Windows equivalent so I can't compare it against that atm). Interestingly, mod_overrides-related Lua-facing C closures (such as reload_override_mods) seem to be added in the Linux binary, just like on Windows (assuming I'm reading it right, that is. Refer to dsl::MainDB::add_members()).

One of the issues I suspect to be causing a lot of the functionality deficit on Linux is that (and this is speculation) overkill are using divergent branches for the Windows and Linux builds. This means that there are two effectively separate codebases being used for the two different builds. This would not effect the addition of new content such as Weapons, Maps, etc... because all that data is stored in bundles along with scripts that install them in to the game. If you look in to historic issues, many users were encountering similar issues during Crimefest 2015, such as not receiving voice data and what have you. Additionally, while I'm unsure of the date of its introduction in to the game, but I imagine that if you were to look at the source for the main/options menu, you would find that the "Mods" menu option (for the asset mods folder) is simply not even implemented

Yes, this does appear to be the case - I've had three binaries (U78-Windows, U97.3-Windows, U97.2-Linux) open and noticed that the Linux disassembled output actually resembles U78-Windows' disassembly more than U97.3-Windows' disassembly. Or that might be due to an apparent compiler toolset change (probably in U79), since the function prologues are different and the PDB path is now on a different drive letter (D:\Projects\payday2\trunk\packages\win32\win32\payday2_win32_release.pdb in U78, C:\Projects\payday2\packages\win32\payday2_win32_release.pdb in U97.3). It's a good thing lua_call() is still readily accessible in the Linux binary - the inability to hook it in the Windows binary due to aggressive inlining is a particular pain point for mod stability on Windows. :/

I would guess, based on some function signatures, that the asset database scans this folder, and then loads in the assets in a certain path to replace assets matching that path that are already in the database.

That sounds likely, though it appears that the function dsl::MainDB::collect_mod_overrides() isn't being called (nor referenced) anywhere in the Linux binary (I've yet to track down the Windows equivalent so I can't compare it against that atm). Interestingly, mod_overrides-related Lua-facing C closures (such as reload_override_mods) seem to be added in the Linux binary, just like on Windows (assuming I'm reading it right, that is. Refer to dsl::MainDB::add_members()).

One of the issues I suspect to be causing a lot of the functionality deficit on Linux is that (and this is speculation) overkill are using divergent branches for the Windows and Linux builds. This means that there are two effectively separate codebases being used for the two different builds. This would not effect the addition of new content such as Weapons, Maps, etc... because all that data is stored in bundles along with scripts that install them in to the game. If you look in to historic issues, many users were encountering similar issues during Crimefest 2015, such as not receiving voice data and what have you. Additionally, while I'm unsure of the date of its introduction in to the game, but I imagine that if you were to look at the source for the main/options menu, you would find that the "Mods" menu option (for the asset mods folder) is simply not even implemented

Yes, this does appear to be the case - I've had three binaries (U78-Windows, U97.3-Windows, U97.2-Linux) open and noticed that the Linux disassembled output actually resembles U78-Windows' disassembly more than U97.3-Windows' disassembly. Or that might be due to an apparent compiler toolset change (probably in U79), since the function prologues are different and the PDB path is now on a different drive letter (D:\Projects\payday2\trunk\packages\win32\win32\payday2_win32_release.pdb in U78, C:\Projects\payday2\packages\win32\payday2_win32_release.pdb in U97.3).
It's a good thing lua_call() is still readily accessible in the Linux binary - the inability to hook it in the Windows binary due to aggressive inlining is a particular pain point for mod stability on Windows.  :/

If the drive letter for the PDB has changed, it's more than likely the case that it's an older build. That's some BS if that's the case.

If I worked there, someone would be getting a right proper smacking for that.

Regarding the change in bundle format, the change isn't drastic. It appears to just be some more values in the header and using longs instead of ints for certain addresses in the header of the db and bundle header. I'm curious as to why they changed this, because it doesn't seem necessary, especially considering many of the values changed to longs never go >100. It's a possibility that the format change may be the cause for the mod_override issue, but it's more likely that it is an engine side thing.

RE Older build speculations, I recently had a conversation with the associate producer, who said that this was not the case.

My pet theory at the moment is that the model and texture files themselves have been changed in some way, which would explain the lack of a mod_overrides folder.

My pet theory at the moment is that the model and texture files themselves have been changed in some way, which would explain the lack of a mod_overrides folder.

Nonetheless, I would still imagine that the mod_overrides folder would still be present even if it didn't work with the texture replacements currently available.