#Compatibility issue with NMUK - Missing Entries In Key Binds Menu

1 messages · Page 1 of 1 (latest)

granite needleBOT
#

@lapis narwhal uploaded a log, Axiom Version: 5.3.0
Environment: Windows 10, Fabric 1.21.11-0.18.5
Mode: Key binds screen

Description:
There seems to be an issue when ever NMUK (No More Useless Keys) mod is installed in conjunction with Axiom. Axiom's Capabilities and Builter Tools key binds disappear from the key bind list. This appears to affect some unrelated mods as well. (WorldEditCUI is a prime example as its entire category disappears)

What I expected to happen was:
All available key binds to be visible.

What actually happened was:
Axiom's Secondary key bind categories disappear. Any other mods, such as WorldEditCUI who are also affected by this bug get their key binds wiped/unset.

Steps to Reproduce:
1. Install Axiom
2. Install NMUK
3. Launch
4. Navigate to the Key Binds menu
5. Axiom's Secondary key bind categories are not available.

Can you recreate the bug?
Yes

This was discovered after I had figured out that the key binds for WorldEditCUI no longer worked. This kind of incompatible behavior has not been seen with any other mods and NMUK, thus I suspect it is an issue with Axiom itself cascading and affecting beyond itself and onto other mods' key binds.

Attachments:

Errors do not appear to show up in the log. It has been attached as a precaution however. The period it covered was the client starting, moving to the key binds screen, and then closing out the client.

Screenshot 1: Without NMUK
Screenshot 2: With NMUK

  • Fabric 0.18.5 on 1.21.11 using 4 mods
Modrinth
No More Useless Keys - NMUK - Minecraft Mod

Allows you to add alternative key combinations to every key binding!

low pawn
#

I'm a amecs user and didn't knew this one

#

But amecs always worked fine

lapis narwhal
#

This seems to be specific to Axiom x NMUK. Amecs without NMUK shows the key binds just fine with Axiom.

#

And I have just noticed that the screenshots did not get uploaded by the bot.

2026-03-28_13.59.45.png 2026-03-28_13.59.10.png
viscid reef
#

If its breaking other mods too then why would this be an Axiom bug

lapis narwhal
#

because without axiom nmuk runs just fine.

#

This issue does not occur with any other mod combinations I've seen and it is quite odd for a dedicated key bind mod would run into issues.

There is something between Axiom and NMUK specifically that is an issue that then spills out onto other mods key binds. And due to how Axiom seems to be the catalyst for it to then spill out onto other mods, it leads to axiom being a key factor

viscid reef
#

so the worldeditcui keybinds are only missing when axiom is also installed?

lapis narwhal
#

Many of Axiom's own keybinds are also missing

viscid reef
#

axiom isn't even doing anything weird with keybinds, its just using fabric's key binding system

lapis narwhal
#

In the screenshot you can see the other two categories for axiom key binds are also missing

viscid reef
#

it looks like its specifically the ones with spaces in their name

viscid reef
lapis narwhal
#

The answer is yes, but it isn't just WorldEditCUI but also many of Axiom's own.

And after checking other mods after you mentioned spaces in them, Spaces do not appear to be a factor. for an example JEI's categories shows up fine

image.png
viscid reef
#

I want to see the worldeditcui keybinds showing without Axiom, and then disappearing with Axiom

lapis narwhal
#

Ah, sure, just a moment.

viscid reef
#

Either way there is a zero percent chance it has anything directly to do with Axiom

lapis narwhal
#

that's with just axiom turned off, CUI shows up just fine.

#

One additional thing of note is that WorldEditCui shows up directly under Axiom's key binds in the menu. So when they disappear it gets taken out as well.

viscid reef
#

You seem to be under the impression that Axiom is making it's own keybinds disappear

#

Obviously it's a bug with NMUK

lapis narwhal
#

I am not assuming that. I'm assuming there is a compatibility issue between Axiom and NMUK that is causing an error to crop up that does not crop up with any other mod from what I've seen.

And when that bug triggers it has a cascade effect, one that does not output an error.

viscid reef
#

You keep installing a different set of mods in your screenshots

#

Now you have a search bar

#

You need to actually take a screenshot with specifically axiom+nmuk+worldeditcui and then compare it to specifically nmuk+worldeditcui

lapis narwhal
#

Alright.
Screenshot 1: Axiom+NMUK+WorldEditCUI (And WorldEdit as it is a dependency)
Screenshot 2: NMUK+WorldEditCUI
Screenshot 3: Axiom+NMUK
Screenshot 4: Just Axiom

Does that work?

2026-03-28_20.47.58.png 2026-03-28_20.48.44.png 2026-03-28_20.49.20.png 2026-03-28_20.49.48.png
#

Outside of Cloth Config and Fabric API, those were the only mods installed/cycled during the screenshots

viscid reef
#

Yes that's good

#

Can you try installing Flashback instead of Axiom and see if that makes worldeditcui disappear as well

lapis narwhal
#

It does not disappear, CUI is at the top of the list as it should. Flashback does show up at the bottom of the key bind list instead of the top unlike Axiom.

viscid reef
#

Can you try deleting .minecraft/options.txt and then running with Axiom+NMUK+WorldEditCUI

lapis narwhal
#

Done.

Findings:

On launch the options do show up as normal.

However, closing and relaunching the client the issue comes back, displaying only Axiom's first category shows up while it's secondary and WorldEditCUI no longer show up.

Screenshot 1: Initial launch after deleting Options.
Screenshot 2: Relaunched

Additional note, incase it is a question, the gui size change was for screenshot purposes, it will do it without changing any options. If all you do with the initial launch is simply click quit without going into any menu it will still occur.

2026-03-28_21.05.14.png 2026-03-28_21.06.00.png
viscid reef
#

Oh nmuk stores their config data in a separate file called options.nmuk.txt so you might have to delete that as well

lapis narwhal
#

Also option.nmuk was deleted for it as well.

viscid reef
#

If you keep options.txt and only delete options.nmuk.txt does that fix it?

#

and vice-versa

lapis narwhal
#

Deleting just options.nmuk.txt will temporarily fix it. So now I am more inclined to lean towards NMUK.

What does seem odd is the file is always empty, but that is an issue for them and not for you.

I suppose here is where I apologize for taking up your time.

It did feel like there may had been something such as an enclosement error, though perhaps not literally of such. Which is why I had felt it was with Axiom. But it is most likely not at this juncture.

So again, sorry for taking up your time with this bit of troubleshooting.

viscid reef
#

(the code runs even if the file is empty, but the code doesn't run if the file doesn't exist)

#

Unfortunately it's still not clear to me why this would cause them to disappear

lapis narwhal
#

I will be sure to add that to the report once I can gather the thoughts for it.

If a silver lining, this session has provided enough for NMUK/Amecs devs to poke around with.

viscid reef
#

The options.nmuk.txt was definitely empty after you deleted it, right?

lapis narwhal
#

It was empty, I had found it odd that it was showing 0kb in size so I had opened it to check.

viscid reef
#

It might have something to do with the ordering

#

Because NMUK manipulates the key bindings when the game's options are loaded

#

But Axiom registers its keybinds when the mod is initialized

#

Not sure which comes first

#

Mojang also changed the way categories work recently so I suspect that probably has something to do with it too

viscid reef
#

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.png
#

Axiom does the same

#

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

lapis narwhal
#

Okay, that makes a bit of sense what is going on then.

viscid reef
#

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

viscid reef
#

I can of course make Axiom register a sort order, but that won't mean that WorldEditCUI won't break with other mods alongside NMUK

lapis narwhal
#

Right.

What I may need to do is open a second issue but for CUI specific to point out that it may have an issue with key bind manager mods as seen with NMUK currently, and to update to the better register

But it does not seem to be an issue with other key binding mods out there, such as Controlling and Multi Key Bindings (just checked). So NMUK should be made able to handle these conflicts as well.

viscid reef
#

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

#

Maybe the deleting was intentional to combat some other edge case? Not sure

lapis narwhal
#

Would it be okay if I quote what you said in the ticket for a few things? Primarily the portions involving how both Axiom and WorldEditCUI are using the same way of registering, and TreeSet? I found you had a better and simpler way of explaining it than I could cook up.

viscid reef
#

Yes that's fine

lapis narwhal