Use of outdated FabricToolTags prevents modded tools from properly working.
skylorbeck opened this issue ยท 10 comments
Describe the bug
So with 1.17, minecraft added it's own version of tools tags, albeit backwards. Minecraft now makes a list of every item that can be broken by a tooltype. In each tool, the tags of blocks that can be broken are listed.
I would suggest using helditem.getMiningSpeedMultiplier()>1.0F
instead of https://github.com/RakSrinaNa/FallingTree/blob/23769d79b0703826e5620c69881d87b73b65fe0b/fabric/src/main/java/fr/raksrinana/fallingtree/fabric/utils/FallingTreeUtils.java#L91
This should allow all custom tools to work as all tool items should extend MiningToolItem, which has this as the override
public float getMiningSpeedMultiplier(ItemStack stack, BlockState state) {
return this.effectiveBlocks.contains(state.getBlock()) ? this.miningSpeed : 1.0F;
}
Minecraft version
1.17.1
Fabric API version
0.37.0+1.17
Mod version
1.17.1-2.12.2
Relevant log output
No response
"Outdated", how is it outdated? I don't really see any reference that it is deprecated or something. Just it is the responsibility of the other mod makers to tag their tools properly.
I would suggest using
helditem.getMiningSpeedMultiplier()>1.0F
Could be an idea too. Have to think if there could be cases where this actually selects more items than it shoud.
I would say it's outdated considering that vanilla has a tag system now and there is a pull for the FAPI to change Fabric Tags to use vanilla tags.
That check should never return anything else, as vanilla will always return 1.0F if the item held doesn't have the tag for the block you are breaking.
You could even use an accessor to look at the list yourself and check if the block the player is breaking is on the tools list.
I looked a bit that PR fast, wouldn't it be "safer" to use the itemStack.isSuitableFor(state)
when the PR is merged ?
I have to say that I didn't follow much this whole change of tags by Mojang with the mineables.
I'll do the getMiningSpeedMultiplier modification in the meantime.
I'll be honest, I didn't know about them either until about an hour before I made this issue post. Someone reported to me that when using my mod with yours, yours stops working. I found that it's because I have the option to disable my additional tools in the cfg, which causes a malformed JSON error in fabric tags because the item referenced isn't loaded, which causes the tags to be null and break your mod. I moved to vanilla tags last night but now they don't work with FT, and here I am.
I hope this didn't come off as demanding you change, and in hindsight I should have made a pull and tried some changes myself.
You could also do !==1.0F if you wanted to include tools that are slower than your hand... If those even exist.
I'll be honest, I didn't know about them either until about an hour before I made this issue post. Someone reported to me that when using my mod with yours, yours stops working. I found that it's because I have the option to disable my additional tools in the cfg, which causes a malformed JSON error in fabric tags because the item referenced isn't loaded, which causes the tags to be null and break your mod. I moved to vanilla tags last night but now they don't work with FT, and here I am.
I hope this didn't come off as demanding you change, and in hindsight I should have made a pull and tried some changes myself.
That's totally fine. If Mojang made some change that goes toward that direction of "the tool dictates what block it likes" then it should be taken into account.
As it is linked to a report you have and investigated a bit the thing, I let you a build here with the modification so you can try to see if it fixes the incompatibility.
https://www.dropbox.com/t/gl3yrVCNSyqkSb4r
As reference: skylorbeck/Sentimentality3#9