More options to inventory detection of Equipment Requirement Tag
Aproxia-dev opened this issue ยท 3 comments
Mod loader
NeoForge
Minecraft version
1.20.1
Mod version
5.2.2
Modloader version
47.1.106
Modpack info
tested separately
[IMPORTANT] If bug:
- I have confirmed this bug is reproducible on a minimal setup, not a modpack with many other mods.
[IMPORTANT] If bug: The latest.log file, not the crash report
No response
Issue description
I feel like the user should have more options in regards to how the equipment requirement is detected instead of it being a couple of hardcoded values. Options like checking the entire inventory, curio slots and all armor slots, would make it incredibly useful for modpack developers, but with how things seem to be currently, as far as I understand from reading the code, the mod only checks for the helmet slot and both hands, which feels very limiting.
This is some extra reasoning so you can see where I'm coming from if needed
I am currently working on a modpack, it is a fork of Raspberry Flavoured. I really like how it extends and innovates upon survival, and one of the things it does is that it locks WAILA-like functionality behind a spyglass using a mod called Useful Spyglass. However, the mod is extremely limiting and lacks a lot of features one would expect.
This is why I started digging for a similar feature inside of Jade, and clearly, Equipment Requirement Tags are almost exactly what I need, except for the fact that it only checks the three slots already mentioned. This approach does not work in this use case, as the modpack also uses Spyglass Improvements for easy access to the spyglass, and that slot does not get checked.
One might argue that this is not a valid solution, as that leaves the overlay on even when you're not using the spyglass, but for one, I don't think Jade is obtrusive enough for that to be a problem, and for two, adding the option of showing Jade only when you're looking through a spyglass might be easier to code in, it sure sounds like it to me, but it also sounds a lot more limiting and constraining, which is why I prefer the idea of the original solution I suggested.
Disclaimer: I do not know how writing Minecraft mods actually works on a deeper level. I am simply making educated guesses from my past experiences of coding in various languages (none of which is Java or Kotlin) and the occasional Minecraft mod code dwelling.
