[2.1.7] mod load path caching problems?

[hgschmie]

This is a change between 2.0 and 2.1.

In a number of my mods, I use a mechanism where I dynamically load files based on the presence of other mods. The relevant code is here: https://github.com/hgschmie/factorio-co ... r-mods.lua

When I install two of my mods that use this mechanism, I get an error at startup that one mod (ltn-train-info) tries to load files from the load path of the other (inventory-sensor-improved):

Screenshot 2026-06-25 at 00.40.13.png (197.93 KiB) Viewed 299 times

This has worked flawlessly under 2.0. Those mods have been "ported" by replacing "factorio version 2.0" with 'factorio version 2.1" and upgrading the mod version in info.json.

How to reproduce:

- disable all mods, keep only the base game
- install https://mods.factorio.com/mod/inventory-sensor-improved
- install https://mods.factorio.com/mod/ltn-train-info (this also installs LogisticTrainNetwork)

get the error at the next restart.

Logfile attached

[justarandomgeek]

in inventory sensor data-updates, you do:

Code: Select all

require('lib.init')
Framework.post_data_updates_stage()

`lib.init` resolves correctly but is already cached from your earlier call in data, so it does nothing, and you discard the returned reference. You then call into the global var Framework, which was last touched by ltn-train-info, and thus has functions from there.

[hgschmie]

in inventory sensor data-updates, you do:

Code: Select all

require('lib.init')
Framework.post_data_updates_stage()

`lib.init` resolves correctly but is already cached from your earlier call in data, so it does nothing, and you discard the returned reference. You then call into the global var Framework, which was last touched by ltn-train-info, and thus has functions from there.

Thank you for looking into this! Why did that work in 2.0?

I (naively obviously) assumed that globals are still "per-mod" (similar to 'storage'). So I guess that is not true.

[justarandomgeek]

in 2.0 the package.loaded cache got reset to an earlier state between each top level data stage file, it appears this is no longer the case and it is now more like normal require caching behavior (the main deviation from upstream behavior now is the use of resolved name rather than requested name for the cache - which is necessary because we're all sharing one VM for data)

[hgschmie]

If you don't want to dig into mods but use a smaller reproducer, use the two attached mods.

[justarandomgeek]

i said this on discord yesterday, but just to have it on the record here in the thread: my conclusion is that require is working as intended and that this was a bug in the mod lua that had merely been hidden by previous quirks of loading that no longer apply, and that the fix is for the mod lua to use the value returned from require, which is linked up correctly, instead of the global variable that gets clobbered.

[hgschmie]

I resolved this and my takeaway is “don’t add a metatable to a global object”.

I moved everything inside my code to be locals and only expose as globals when I require my code in (by returning a function which can return multiple values) and then do

GlobalA, GlobalB = require(‘my-code’)()

Sure, it might be a lurking bug that happened to work in 2.0 but the changes for mod loading in 2.1 are there and they were not documented in the release notes so it bit me.

It’s a practical application of Hyrum’s law after all.