Level maintainers stopped working
CatsLeftEar opened this issue · 15 comments
Your GTNH Discord Username
Keyla3300
Your Pack Version
stable
Your Server
Epsilon
Java Version
Java 8
Type of Server
None
Your Expectation
Being able to maintain levels of items/fluids
The Reality
Level maintainer gives out an error on all items (i can just order them myself though, in much larger quantities). Error is being shown even for items with already met quantities
Your Proposal
fix
Final Checklist
- I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
- I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
- I have asked other people and they confirm they also have this problem by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
Why closed?
My teammate came and randomly managed to somehow enable those liquids i needed. We still cant maintain eyes of ender, for example, even though we have pattern
i guess issue can be reopened, it just doesnt work properly, need confirmation or info from other players?
Overnight a maintainer with an error broke even more, it lost everything it maintained inside, as well as all textures on the sides
I just added several new items to one of my mainteiners and everything is working fine... (single player world)
It just started working for me too next day, i dont know why was the issue happening for 2 days in a row. Maybe someone will give additional info
to trackdown such things we need a config off by default that allows to display the crash reason of maintainers in server logs
ill leave it as needs confirmation then, if possible please change the config and repost a crash log if obtained
Overnight a maintainer with an error broke even more, it lost everything it maintained inside, as well as all textures on the sides
I believe that this is the same issue:
#18329
I posted some clues for this issue on discord previously, starts from here:
https://discord.com/channels/181078474394566657/401118216228831252/1316354998619213844
And I find some new clues now so I will just post them here.
This is the content of
codechicken.nei.api.GuiInfo.guiHandlers
when I reproduced this bug
[appeng.integration.modules.NEIHelpers.NEIGuiHandler@5001dd81
net.p455w0rd.wirelesscraftingterminal.integration.modules.NEIHelpers.NEIGUIHandler@1c5d5530
thaumicenergistics.common.integration.ModuleNEI$NEIGuiHandler@67a44500
mrtjp.projectred.transportation.GuiChipConfigNeiHandler@4174ea9b
codechicken.nei.NEICreativeGuiHandler@1fc7cae1
codechicken.nei.NEIChestGuiHandler@69c5f8fc
codechicken.nei.NEIDummySlotHandler@2c8c3c81
codechicken.nei.recipe.GuiRecipeCatalyst@4aca3bb9
codechicken.nei.recipe.SearchInputDropHandler@6bfb70c3
codechicken.nei.recipe.FillFluidContainerHandler@2dbf6758
codechicken.nei.recipe.CheatItemHandler@601a3e5a
codechicken.nei.NEIPotionGuiHandler@7b96c613
com.cleanroommc.modularui.integration.nei.ModularUINEIGuiHandler@4b5bdcca
li.cil.oc.integration.nei.GuiHandler@1d08e75e
com.github.vfyjxf.nee.client.GuiEventHandler@216e3891
cofh.plugins.nei.NEIGuiHandler@2cd1e24b
com.glodblock.github.nei.AE2FC_NEIGuiHandler@317a8582]
Among those, there are two handlers might handle Level maintainer's dragNdrop action:
No.1: com.glodblock.github.nei.AE2FC_NEIGuiHandler
No.2: com.github.vfyjxf.nee.client.GuiEventHandler
NEI will iterate the handler list to find a valid handler for dragNdrop action.
If one handler returns true in method 'handleDragNDrop' , the remaining handlers are ignored.
AE2FC_NEIGuiHandler is the correct one.
GuiEventHandler is the wrong one(because it won't update the maintainer's task)
So the whole problem is caused by the incorrect order of guiHandlers.
So I investigate the the addition of guiHandlers and find out that:
AE2FC_NEIGuiHandler is registered in NEI_FC_Config.java
And NEI_FC_Config is loaded in NEIClientConfig.java
NEE's GuiEventHandler is also loaded in this way.
NEIClientConfig.java
public static void bootNEI(World world) {
......
......
NEIClientConfig.pluginsList.parallelStream().forEach(clazz -> {
try {
IConfigureNEI config = (IConfigureNEI) clazz.getConstructor().newInstance();
config.loadConfig();
NEIModContainer.plugins.add(config);
logger.debug("Loaded {}", clazz.getName());
} catch (Throwable e) {
logger.error("Failed to Load {}", clazz.getName(), e);
}
});
Unfortunately, pluginsList is actually a HastSet!
HastSet does not guarantee order of iteration, that's why it's so hard to reproduce -- it depends on the hashCode of the plugin instance.
When NEE's plugin goes before AE2FC's plugin, things are messed up.
So maybe make pluginsList a SortedMap rather than a HastSet, to make the order predictable. That will fix this.
Hope my clues will help!
Thanks for the investigation!
I have marked it as ready for dev even tho I am unsure if this is fixable without "major" code changes.
Thanks for the investigation! I have marked it as ready for dev even tho I am unsure if this is fixable without "major" code changes.
Personal opinion:
The key issue is that level maintainer should not use SlotFluidConvertingFake at all.
Use SlotFake subclass = Allow NEE to set stack without callbacks
Possible solution:
Create a private class that does exactly the same job as SlotFluidConvertingFake, to bypass the check of NEE's handler, so AE2FC's handler will be able to handle the click action whatever the order.
Got the same bug immediately after moving from 2.6.1 to 2.7.2 (never had issues with maintainers before). Seems to be kinda unplayable now, sadge
I'm currently playing on nightly-818 (the build from two days ago) and it seems to be fixed again.
I'm currently playing on nightly-818 (the build from two days ago) and it seems to be fixed again.
Because it depends on the hashcode of gui handlers... it's so random and somehow related to the jar filename?