Incompatibility with Inventory Profiles Next
Anoaxx opened this issue · 19 comments
This is just a post for someone if you found this incompatibility. Its on IPN and its an issue open there #124 but maybe there is someone that can help.
You cannot under any circumstances assume that your mod initializer has been called in a mixin. Doesn't matter if you're using Forge, Fabric, or BananaLoaderPro.
I still need to know why this happens.
The "fix" is adding a method call to all my mixins just to be sure the mod was initialized. I don't really want to do that.
This mod introduces the unexpected behaviour and I would like to know why should I make all my mixins slower.
Doesn't happen in dev env loading from fabrication repo, with InventoryProfiles
if that somehow helps figure it out
SFort: k (Kind) tags are mutually exclusive. Incompatibility > Not Our Defect.
blackd: I can't read whatever Kotlin magic is going on here to initialize what I assume is a method reference. Your mixins would be slower by one IFNULL insn, which will get optimized out basically instantly. (The log lines mean you're already doing this check, anyhow.) My best reading of what is happening is that a Screen is being initialized by Fabrication code before your mod initializer has been invoked. Fabric Loader randomizes mod load order, so this is fairly likely to happen with any mod that uses screens. Mixins load before mods, and there's no way to know when the first time your mixin will be called relative to mod initialization (i.e. whether it will be before or after) — in Java, I would use a static initializer. In general, Kotlin has an idealized view of the JVM world that doesn't line up as soon as runtime patching comes into play.
Doesn't happen in dev env
Load order is aggressively randomized in dev envs — in prod, it's randomized based on installed mods, so it doesn't change between launches. This may be related.
The code that logs the problem is only executed if the init was not performed. In the normal situation when the mod entry point is executed all the methods that do the checking and logging are swapped with the real counterparts. So there no checks.
All this shit is part of the supporting multiple versions of minecraft and both loaders with minimal differences in code.
Anyway the difference with normal minecraft start is that there is a Screen instance shown (rendered) before my mod entry point is executed.
I guess your does something that cause it. Which probably is a valid case but I prefer to be sure before deciding how to proceed.
may be "This mod introduces the unexpected behaviour" sounds like I blame you. I didn't intend it to sound like that .
It did sound like that, yes.
I'll leave the issue open until a fix is released for visibility.
You cannot under any circumstances assume that your mod initializer has been called in a mixin. Doesn't matter if you're using Forge, Fabric, or BananaLoaderPro.
I know that but I've done a lot of checking before considering the assumption that no Screen instance is rendered before the game main menu. In none of my comments have I even implied that the problem is not caused by my assumption.
I just need to know what caused the assumption not to hold so I know how to fix the problem with minimal impact.
may be "This mod introduces the unexpected behaviour" sounds like I blame you. I didn't intend it to sound like that .
I figured a way to bring the checks down to if null. I guess this will handle all other potential cases where my my assumptions about the start sequence is not true.
I guess you can close this.
If it's less work to change Fabrication to not do this than to make Inventory Profiles Next handle this, then you can open a PR. Keep in mind I'm on soft-hiatus and it could be a while before a release.
I need to fix the possibility of this happening again so I'll fix it.
It did sound like that, yes.
I just think that changing the startup is not a good idea unless you have very good reasons.
I've pinned it down to a rendering of a Screen instance is done before game starts ticking. The vanilla behaviour is the game start to tick and then renders the active Screen instance.
I just think that changing the startup is not a good idea unless you have very good reasons.
Fabrication does not intentionally change how startup works. My best guess as to what is initializing Screen early is the config GUI, but the way that's implemented is not very different from most mod config GUIs.
Whether the game renders or ticks first is not guaranteed. It depends on the framerate.
If it's less work to change Fabrication to not do this than to make Inventory Profiles Next handle this, then you can open a PR. Keep in mind I'm on soft-hiatus and it could be a while before a release.
i test out some more mods and turns out that Tweak My Client and Inspecio don't work with Fabrication either.
Fixed by 64341b4
(so probably fixes Inspecio and Tweak My Client aswell)