[1.12.2] Key binding conflict with ImmersiveCraft when run under Vivecraft
Techjar opened this issue ยท 5 comments
Base information
- Minecraft version: 1.12.2
- Mod version: 2.3.27.353
- Minecraft Forge version: 14.23.5.2854
Hi, I'm one of the Vivecraft developers. We got a weird issue report from a user, and it turns that when both this mod and ImmersiveCraft are installed, SteamVR fails to load the action manifest due to a duplicate action. For context: we take all of the key binding names from the game and pass them to SteamVR so users can bind them however they wish through its interface.
The problem here is you have a binding named key.placeItem
while ImmersiveCraft has a binding named key.placeitem
. While this works fine in normal Minecraft since binding names are handled as case sensitive, SteamVR action names are case insensitive, so this results in a conflict, the action manifest fails to load, and the game crashes later on when it can't read the action states. This can be easily fixed by namespacing your binding names with the modid as is standard practice for most mods, for example you'd use key.draconicevolution.placeItem
instead.
Renaming the offending binding in either mod would fix this issue, however it would be best to properly namespace all of your bindings to prevent any conflicts in the future. I opened a similar issue report on the other mod as well: McJtyMods/ImmersiveCraft#67
The log/crash report isn't useful to you as it happens in Vivecraft code, but I attached it anyways in case you're really curious.
immcraft-draconicevolution-conflict.log
Well documented; thanks for the bug report. I'll pass this along to @brandon3055 and/or submit a pull request to update this.
The only problem I see with updating these is that existing keybinds will break and default to normal when updated, but that's easily fixed on the user's side.
Well documented; thanks for the bug report. I'll pass this along to @brandon3055 and/or submit a pull request to update this.
Thanks! :)
The only problem I see with updating these is that existing keybinds will break and default to normal when updated, but that's easily fixed on the user's side.
Yeah I thought about that, but I think it's a small price to pay to avoid future issues. Honestly I'm surprised Forge doesn't already have some mechanism to enforce namespaced binding names. Surely someone foresaw this kind of problem. Even I did, I just kinda hoped no mod would actually encounter it.