CommonLibSF icon indicating copy to clipboard operation
CommonLibSF copied to clipboard

REL::IDs missing when accessed in PostLoad but available in PostPostLoad

Open alandtse opened this issue 2 years ago • 0 comments

The REL ID database may not be ready for mods in PostLoad. But this behavior is random.

As reported on discord: CommonlLibSF mod is now reporting missing IDs that were confirmed in addresslib database. Code had previously worked before SF 1.8.86. Workaround was to load the mod later: "I've changed kPostLoad to kPostDataLoad in my listener that starts everything and now things are ok. "

This was previously seen in fo4 and fixed by testing for actual data instead of an init boolean.

https://github.com/alandtse/CommonLibF4/commit/667490a1f814192209cef27c50cf819f83029496 and prior discord [discussion] (https://discord.com/channels/535508975626747927/541414634117398536/1129919975327535104)

Nukem's thoughts on seeing commonlibf4 commit:

wtf
it should've just used std::call_once and been done with it
but even then, it's not going to be a threading issue and the atomics are irrelevant
which leaves _instance._filename != L""
someone create a repro of this on github and I'll debug it 

Initial analysis of SF code vs fo4: The same older code in iddatabase https://github.com/Starfield-Reverse-Engineering/CommonLibSF/blob/f2ea1300936d90f1baf15980db8c571a104b4eed/CommonLibSF/include/REL/ID.h#L192-L193 but the code looks different in module.h https://github.com/Starfield-Reverse-Engineering/CommonLibSF/blob/f2ea1300936d90f1baf15980db8c571a104b4eed/CommonLibSF/include/REL/Module.h

As no repro case was available, we're just logging the issue for anyone else.

This can be avoided with other workarounds as described here.

alandtse avatar Nov 23 '23 23:11 alandtse