AlmostKube getPreferredItemForTag takes a ResourceLocation, but lots of tags aren't valid resource locations
robertmaxton42 opened this issue ยท 2 comments
Version
1.19.2-0.7.0
Describe the bug!
When trying to look up preferred items in KubeJS using AlmostUnified.getPreferredItemForTag
, the underlying API seems to expect a ResourceLocation
. However, lots of tags -- like forge:ores/{material}
-- aren't valid ResourceLocation
s; in this case the tag has a /
in it. This produces a bunch of net.minecraft.ResourceLocationException
errors and results in the failing of the script.
Crash Report
No response
Log
No response
Additional Context
Yes
Modifications
No response
Did the issue happen in singleplayer or on a server?
Server
Yes, the underlying API uses ResourceLocations
because that's what Minecraft uses to identify tags. Or rather, they use TagKey
but that's also based on ResourceLocation
. You can assume that every tag that exists in Minecraft is a valid ResourceLocation
, otherwise it wouldn't exist in the first place.
forge:ores/{material}
is not a valid ResourceLocation
because that's what we are using in the config to prevent the need to list all variations of all tags with a specific material. The {material}
placeholder is being replaced with each material from the materials section within the config in the unification process.
If the getPreferredItemForTag
function of the KubeJS binding throws an exception for you, it is because you passed an invalid tag to it. It's not because of how the API is implemented. Please join the Discord to resolve your issue in your code. This is not a mod issue.
๐ @robertmaxton42!
Please don't use the issue tracker for support requests.
As stated in our Contribution Guidelines, we use it
exclusively for bug reports and feature requests.
Feel free to join our Discord for help instead.