Skip to content

(NMUK) - Treeset sort order causes incapability with several mods such as Axiom that spill onto each other. #115

@AthenaAcorn

Description

@AthenaAcorn

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 does new KeyMapping.Category
Image

Axiom does the same
Even though it should be KeyMapping.Category.register() for it to get assigned a sort order

It'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 orders

This 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:

  1. Just Axiom installed - Everything shows up just fine for Axiom
Image
  1. Axiom + NMUK - Two of Axiom's Categories disappeared
Image
  1. WorldEditCUI + NMUK - Everything shows up fine for WorldEditCUI
Image
  1. Axiom + WorldEditCUI - Everything shows up fine for both Axiom and WorldEditCUI
Image
  1. Axiom + WorldEditCUI + NMUK Two of Axiom's Categories disappeared, WorldEditCUI is gone.
Image

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions