-
Notifications
You must be signed in to change notification settings - Fork 19
Description
Mod Version: nmuk-1.2.2+mc1.21.9 (As well as 1.2.3+mc1.21.9)
MC Version: Fabric 1.21.11-0.18.5
Description:
When both NMUK and Axiom are installed, most of Axiom's key bind categories do not appear. This bug also seems to affect at least WorldEditCUI, but only when Axiom and NMUK are installed in conjunction. Issue may also additionally tie with options,nmuk.txt
I will try to summarize what the Axiom developer, Moulberry, said to the best of my abilities. Though I do worry I will not make them sound as gracious and patient as they had been during the troubleshooting we went through.
Though perhaps quoting Moulberry would be simpler since they have a better grasp on the situation.
Quoting Moulberry:
NMUK causes entries with the same sort order to disappear
Both WorldEditCUI and Axiom are registering their keybinds in a way where they end up not being part of the sort list
That's why they all appear at the top
See how worldeditcui doesnew KeyMapping.Category
Axiom does the same
Even though it should beKeyMapping.Category.register()for it to get assigned a sort orderIt's not even fully NMUK's fault
Mojang's KeyMapping#compareTo function considers two keymappings to be the same if they have different categories but identical sort ordersThis code here adds the KeyMappings into a TreeSet, causing the 'duplicate' keybinds to disappear (assuming that the compareTo is used for equality?)
So it is specifically this line of NMUK causing them to disappear: https://github.com/Siphalor/amecs/blob/cross-version/nmuk/src/main/java/de/siphalor/nmuk/impl/mixin/MixinGameOptions.java#L166
end quote
The line in WorldEditCUI Moulberry referenced in that quote can be found here.
It appears from the explanation in the quote and outside of it is that that due to both mods inserting themselves into the same order spot, it is running into a issue within Minecraft itself that is only being uncovered by NMUK. It is also why only one Axiom category is showing up since they are each inserting themselves into the same spot.
Moulberry directed me to test some additional stuff. Deleting options.nmuk.txt will restore access to the key binds as they should for the initial launch after deletion. But as soon as to close and relaunch the client it will once again break since the file is recreated. The file itself is never seen to contain any information. But the deletion of the file fixing things lead them to find the exact line in NMUK since the line is in a section that only runs if the option.nmuk.txt file exists.
Moulberry also ended with this recommendation
The fix in NMUK is sorting a list instead of relying on a TreeSet to order it with the unintended side-effect of deleting keybinds
In these screenshots, the only mods that are ever present are NMUK, Axiom, WorldEditCUI, WorldEdit (dependency), Fabric API, and Cloth Config.
Screenshots:
- Just Axiom installed - Everything shows up just fine for Axiom
- Axiom + NMUK - Two of Axiom's Categories disappeared
- WorldEditCUI + NMUK - Everything shows up fine for WorldEditCUI
- Axiom + WorldEditCUI - Everything shows up fine for both Axiom and WorldEditCUI
- Axiom + WorldEditCUI + NMUK Two of Axiom's Categories disappeared, WorldEditCUI is gone.

