Repository navigation
[StarMapImmediateLoad] cannot register on KSA 2026.11.10.5801, which removed Mod.PrepareSystems #113
Description
KSA 2026.11.10.5801 no longer has KSA.Mod.PrepareSystems. Mod.LoadSystems, LoadAssetBundles, PrepareSystems and the mod fields that went with them are gone from the decompiled KSA.Mod, and ModLibrary.LoadAll no longer calls mod.PrepareSystems().
StarMap 0.5.2 still looks the method up in RuntimeMod.InitializeMod, in the case StarMapImmediateLoadAttribute: typeof(KSA.Mod).GetMethod(nameof(Mod.PrepareSystems))!. On 5801 this returns null. The null goes to PatchManager.RegisterInstanceVoidPatch and into GetOrCreateMethodPatch, whose dictionary lookup does not accept a null key. ModsLoader.PrepareMods has no try/catch around InitializeMod, so this reads as an exception that leaves StarMapCore's constructor and stops the start of the game, not only the one mod. I read this from the source and have not run it on 5801 yet.
Mods that declare [StarMapImmediateLoad] in the repositories we know: KittenExtensions, gatOS, KSAGEffects, KSAMultiplayer and KSASM. StarMap 0.4.8 patches the same method through ModPatches with a Harmony attribute, so it may fail the same way.
Questions:
- Is there a replacement point in 5801 for "immediately before the systems of this mod are prepared" that
[StarMapImmediateLoad]can use, or should the attribute become a no-op that logs a warning when its target is missing? - Whatever the answer, a missing patch target should skip the one callback and log it. It should not stop the loader.
Activity
Maximilian-Nesslauer commentedon Nov 8, 2026
A second change in 5801 hits
[StarMapAllModsLoaded]:ModLibrary.LoadAllnow has one optional parameter,LoadAll(IContentLoadProgress? progress = null), where it had none in 2026.10.25.5707.RuntimeMod.InitializeMod(caseStarMapAllModsLoadedAttribute) registers a postfix onModLibrary.LoadAlland callsclassMethod.Invoke(modObject, args)with the arguments of the patched method. With one argument, a callback that takes no parameters, which is the documented signature, would throwTargetParameterCountException, and StarMap logs that without stopping the other patches. Then no mod would get its all-mods-loaded callback.I read this from the source and have not run it on 5801 yet. One way to avoid it is to call the callback with no arguments in this case, because the documented signature has none.
Maximilian-Nesslauer commentedon Nov 8, 2026
I ran StarMap 0.5.2 on KSA 2026.11.10.5801 with four mods and can confirm the
LoadAllpart (and only that part).All four mods are found and their
[StarMapAfterGui]callbacks run every frame, so the loader starts and the mods are created. But none of the[StarMapAllModsLoaded]methods ran: each of them writes a log line first, and none of those lines is in the session log. This matches the new optional parameter ofModLibrary.LoadAll, becauseclassMethod.Invoke(modObject, args)gets one argument for a method that takes none. I did not capture the exception text itself, so the cause is still read from the source.None of the four mods declares
[StarMapImmediateLoad], so thePrepareSystemspart of this issue is not exercised by this run.In effect every mod that does its setup in
[StarMapAllModsLoaded]is only half loaded on 5801 with StarMap 0.5.2, with nothing on screen to say so.Maximilian-Nesslauer commentedon Nov 8, 2026
There is a pull request for this: #115. It calls the
[StarMapAllModsLoaded]methods without arguments, hooks[StarMapImmediateLoad]toMod.LoadSettingswhenMod.PrepareSystemsis gone (and only warns when there is neither), and adds theusingthat StarMap needs to build against 5801.