2.0.6兼容问题

[ghost]

1.17在2.0.6版本與InventoryProfilesNext 1.1.1還有modmenu2.0.14時無法開啟InventoryProfilesNext的配置界面，但2.0.5可以

[blackd]

Hi,

I'm Inventory Profiles Next author. I got a report about this too. The problem is that MasaGadget will try to use IPN's mod menu entry point before Fabric had a chance to invoke IPN's main entry point. Unfortunately IPN's confing screen is not available before the main mod initialisation have finished.

Also it looks like you are caching the cofig screens instances? If you do that it's probably better to stop since Mod Menu doesn't cache instances and most mods won't expect it.

[plusls]

Hi,

I'm Inventory Profiles Next author. I got a report about this too. The problem is that MasaGadget will try to use IPN's mod menu entry point before Fabric had a chance to invoke IPN's main entry point. Unfortunately IPN's confing screen is not available before the main mod initialisation have finished.

Also it looks like you are caching the cofig screens instances? If you do that it's probably better to stop since Mod Menu doesn't cache instances and most mods won't expect it.

I just cache ConfigScreenFactory, and use configScreenFactory.create(this.parentScreen), and I think configScreenFactory just a lambda function, I just cache a function object

I show many mod use it like

public class ModMenuApiImpl implements ModMenuApi {
    @Override
    public ConfigScreenFactory<?> getModConfigScreenFactory() {

        return (screen) -> {
            GuiConfigs gui = new GuiConfigs();
            gui.setParentGui(screen);
            return gui;
        };
    }
}

[blackd]

This is my implementation:

class ModMenuApiImpl : ModMenuApi {

    override fun getModConfigScreenFactory(): ConfigScreenFactory<ConfigScreen> {
        return ConfigScreenFactory<ConfigScreen> {  
            ConfigScreen(true).apply {
                parent = it
                dumpWidgetTree()
            }
        }
    }
}

It's in kotlin but generally does the same thing. However with how Kotlin works lot's of class loading is done because of this. And since my mod wasn't initialised by fabric at the time you try to acquire the factory, the class initialization fails... Lets say in java the equivalent will be a class having a static {} section that's actually executed during the class loading.

I would say it's better to initialise your cache first time it's needed not during startup.

[plusls]

But I have no time to release new version，you can get it from github action.