Minecraftforge: [1.15] Add an empty "wrench" tag

[Da-Technomancer]

Many mods add some sort of "wrench" item for configuration. Currently, mod recognition of each other's wrenches is hit-or-miss.

I suggest adding an empty "wrench" item tag to Forge. The idea being that mods could add their wrenches to Forge's wrench tag, and any mod would have the option of accepting any item in the wrench tag as a valid wrench.

I'm aware that a universal wrench registry was proposed in the past and rejected (#988), but given that the new Tag system is extensively used by vanilla to define properties, it doesn't seem like a stretch to add a single empty json file.

[williewillus]

this doesn't need to be in forge, mods can just agree on which tags that they will use to put their wrenches in, there's no need to have an empty file in forge.

to illustrate the point: many mods add brass. Does forge need to make an empty json file for it, or should mods just agree "we will look in forge:ingots/brass" for brass ingot items? Repeat for every single type of material people have in their mods.

The reasoning is the same.

[gigaherz]

I had this written 7 hours ago, but github was having issues, and then forgot later until I saw willie's message:

If I understand correctly, due to how vanilla code works, adding empty tags is not a good idea. This also extends to using tags to decide if you run some behaviour or not. If you need wrenches for your recipes, you should create the tag yourself, with the wrenches you know about. But do note that, unless I understand the issue wrongly, if none of the mods involved are present and the tag ends up empty, the recipe will accept any item in the crafting slot.

I'm not closing this because I'm not certain that I fully understand the issue that resulted in the "don't use tags for logic" guideline.

[ShetiPhian]

Unless your using wrenches in recipes why not use ToolTypes?

Set the ToolType of a wrench item:
properties.addToolType(ToolType.get("wrench"), _level_)

Check if the item is a wrench:
_itemstack_.getItem().getToolTypes(_itemstack_).contains(ToolType.get("wrench"))

[Alpvax]

I am using a (currently empty) capability for my "wrench", and having all my code handled by the blocks (which is the way you would have to do it with tags). If people start to use tags for the wrench functionality, I will add mine to that tag. As long as the functionality is implemented in the item, tags won't actually work though.
Also, bear in mind that tags are user-editable. Does that make sense for wrenches?
Potentially a better option would be a forge wrench capability, which blocks can check for, and could maybe include the handling.

[KingLemming]

Disagree on the capability. Wrenches can do different things in different contexts. Best way to deal with it is to just have a crossmod way of identifying "wrench," and a cap is overkill for that.

I actually use a tooltype on mine, but I'm amenable to a tag as well.

[gigaherz]

For what it's worth, back in 2015-2016, I proposed using a pair of block/te capabilities: ITweakable and IDismantleable.
The process, under a modernized version of the proposal, would be:

1. The item identifies the capability, and if missing performs default action,
2. If the capability is present, the item calls ITweakable#tweak(world, pos, state, itemstack, player) or IDismantleable#dismantle with the same args, depending on the wrench item preferences or the mode the wrench is set to.
3. The block reacts to the request, and returns an ActionResultType, depending on what it chooses to do. If PASS, the wrench can do its default logic, or PASS itself. Otherwise, the wrench would stop the item use with the same result type the block returned.

[KingLemming]

So that's the thing, as raw interfaces they kinda make more sense, like IPlantable.

If those interfaces were just in Forge and acted as a common reference, great. But the advantage that capabilities afford (dynamic implementation) don't really make sense for this IMO.

Also, my wrench just calls rotate() which is a standard function now. IDismantleable is still something I use internally though.

[Alpvax]

IDismantleable would be a great addition to forge. I'm not sure about itweakable, as some blocks have different tweaks possible for different wrench modes, so you would still have to identify the mode of the item in a common way.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.