[41.78.16 - Steam] [SP] Mod load order apparently not enforced or not documented enough

[kingxerjsaeg]

Background: There's a misbehaving mod (Braven's Auto Engineering) that doesn't play nice with controllers (redefines ISInventoryPaneContextMenu.createMenu and wraps around it, only storing the original in a mod/file-toplevel-local reference, but fails to return the menu reference despite calling it, so it errors out on ISInventoryPane.lua:1399 because the menu var declared in ISInventoryPane.lua:1393 is still nil from the redefinition in the mod and not returning a reference) so I'm trying to make a "Two part" mod fix that should:

1. Lload the first part before Braven's does,
2. Store the original reference to ISInventoryPaneContextMenu.createMenu (using a custom global table as a namespace for it, not to clutter the environment with a loose global function)
3. Let Braven's load and do its stuff
4. Load the second part afterwards, which redefines Braven's redefinition to the proper functionality and (attempts to) get the original reference stored in the first part for the wrapping.

Now, this order is, as far as I've read, what should be going on, but it's not. I made a local clone of Braven's mod for testing and added print()'s to that and mine, to track execution. And here is the relevant bit from console.txt:

• ZAUE is Braven's local copy (I thought maybe the alphabetical order of the name had something to do with it, but apparently not, lol)
• ZomboidData is my cachedir= and -Duser.home=

LOG  : Lua         , 1718159395515> Loading: F:/ZomboidData/Workshop/ZAUE/Contents/mods/BravensAutoEngineering/media/lua/client/BB_AE_Client.lua
LOG  : Lua         , 1718159395516> Loading: F:/ZomboidData/Workshop/ZAUE/Contents/mods/BravensAutoEngineering/media/lua/client/BB_AE_Main.lua -- the offending file >:v
LOG  : General     , 1718159395528> bb stored function -- print after Braven's mod stored the method
LOG  : General     , 1718159395528> closure 0x848664251 -- this is the original method's tostring reference
LOG  : General     , 1718159395528> bb changed function -- print after Braven's mod redefined the function
LOG  : General     , 1718159395528> closure 0x1547910277 -- this is the redefinition's tostring reference
LOG  : Lua         , 1718159395528> Loading: F:/ZomboidData/Workshop/ZAUE/Contents/mods/BravensAutoEngineering/media/lua/client/BB_AE_MenuFunctions.lua
LOG  : Lua         , 1718159395530> Loading: F:/ZomboidData/Workshop/ZAUE/Contents/mods/BravensAutoEngineering/media/lua/client/BB_AE_Profession.lua
LOG  : Lua         , 1718159395530> Loading: F:/ZomboidData/Workshop/ZAUE/Contents/mods/BravensAutoEngineering/media/lua/client/BB_AE_TimedAction.lua
LOG  : Lua         , 1718159395531> Loading: F:/ZomboidData/Workshop/ZAUE/Contents/mods/BravensAutoEngineering/media/lua/client/BB_AE_Vehicle.lua
LOG  : Lua         , 1718159395532> Loading: F:/ZomboidData/Workshop/Fix Joypad for Braven's Auto Engineering Before/Contents/mods/Fix_Joypad_BB_Auto_Engineering_Before/media/lua/client/FJBBAE1.lua -- this is the Part 1 of my mod. As per config, it should load before Braven's.
LOG  : General     , 1718159395532> created new context menu function --- this is where I create the namespace and store the "original" reference to the method
LOG  : General     , 1718159395532> table 0x504668826 -- this is the namespace table tostring print
LOG  : General     , 1718159395533> closure 0x1547910277 -- this is the "original" method's reference, but since it's loading after Braven's, it just gets the redefinition (notice the identical reference id's) so it's already "poisoned" at definition. If it was loading first as it should, it should (AFAIK) print "closure 0x848664251"
LOG  : Lua         , 1718159395533> Loading: F:/ZomboidData/Workshop/Fix Joypad for Braven's Auto Engineering After/Contents/mods/Fix_Joypad_BB_Auto_Engineering_After/media/lua/client/FJBBAE2.lua -- this is the second part of my mod
LOG  : General     , 1718159395533> logging changed BB funct
LOG  : General     , 1718159395533> closure 0x1547910277 -- same old same old
LOG  : General     , 1718159395533> created new context menu function -- created the proper redefinition
LOG  : General     , 1718159395533> table 0x504668826 -- from my table
LOG  : General     , 1718159395533> closure 0x1547910277 -- with Braven's redefinition unfortunately
LOG  : General     , 1718159395534> logging redefined funct
LOG  : General     , 1718159395534> closure 0x807925977 -- my meaningless redefinition's reference u_u

 

Maybe the above is meaningless and it actually loads in order despite logging them exactly like this every single time.

The mods.txt from that last run (yes, I thought alphab order made a difference, hence AAAAAA...):
 

VERSION = 1,

mods
{
    mod = ModManager,
    mod = ModManagerServer,
    mod = modoptions,
    mod = AAAAAFix_Joypad_BB_Auto_Engineering_Before,
    mod = BB_Utils,
    mod = BB_Auto_Engineering_FF,
    mod = Fix_Joypad_BB_Auto_Engineering_After,
}

maps
{
}

 

As you can already see, the only mods in that save are the ones that allow to supposedly set and enforce mod load order. defaults.txt in cachedir\mods is identical, IYWK.

So, it's apparently so far (things I've tried):

• Nothing to do with where the mods are loaded from (cachedir \Workshop or \mods, vs steamapps\workshop\content)
• Nothing to do with being client or shared (worth a shot)
• Nothing to do with alphanum in directory or mod ID
• Nothing to do with gamemode (ie.: Sandbox vs Apocalypse)
• Nothing to do with the "subscription/enabling order" (I specifically disabled *all* mods and resubbed to those in the list, in that order, also changed the ID of the local copy of Braven's mod so it would be considered a completely different one from the steamo workshop one)
• (Confoundingly) Nothing to do with the order in the save's mods.txt or the global defaults.txt. I even set my mods to load all before Braven's and the logs are the same.

The only thing I've not tried is running it in a server, because the constantly re-loading of fresh new environment is too cumbersome. But if there *is* something that respects the mod load order, surely it's not *just* the server.ini, right?

 

So, is there anything I've missed from the little I've been able to glean from the wiki and google on mod load order (pretty much "Yeah, that's probably your issue with x and y mods" comments)? Is there another configuration I should look at tweaking that the mod managers ignore? Is there something intrinsic to the mod loading algorithm that I should look into and work with/around?

 

Q&A (might be relevant, idk):

• Could you just not use the mod until it's fixed?
  • Yes, I could, but I don't want to. And the fix for the mod in question has been posted in said mod's bug reports since Feb 13, 2023. The mod was updated on Feb 26, 2024, and the issue persists, so I'm not holding my breath for that.
• Why are you bothering with this?
  • I've seen at least two people report something about this mod, but my guess everyone wanting to use this mod and a controller is getting hit by this, that's something I think needs fixing; which is also the reason I'm trying to make a new thing working around someone else's code instead of just making a fixed local copy for myself. Also, who knows, I may be willing to open more of the modding can of worms' lid in the future, and this issue here seems like a fundamental thing to me to address/understand.
• What if the mod gets fixed in the meantime? Will you drop this issue?
  • Unlikely. It's not working as to my knowledge it should and, I want to know why/how.

 

[For directing people here if they happen to google the error:]

 -----------------------------------------
STACK TRACE
-----------------------------------------
function: doContextOnJoypadSelected -- file: ISInventoryPane.lua line # 1399 | Vanilla
function: onJoypadDown -- file: ISInventoryPage.lua line # 674 | Vanilla
function: onPressButton -- file: JoyPadSetup.lua line # 345 | Vanilla
function: update -- file: JoyPadSetup.lua line # 779 | Vanilla
function: onJoypadRenderTick -- file: JoyPadSetup.lua line # 796 | Vanilla

attempted index of non-table
creating new sourcewindow: ProjectZomboid/media/lua/client/ISUI/ISInventoryPane.lua