The Importance of Tags

[ChampionAsh5357 158]

If you have been a modder prior to 1.13, you would know about a thing called OreDictionary. OreDictionary was the forge way of creating inter-mod compatibility by allowing items to become interchangeable with other items registered under that name. This allowed recipes to use different types of the same item from different mods. This could include things like gems, ingot dust, or such things as gears or sticks.

 

As of 1.13, Minecraft created their own system known as Tags. This version of inter-compatibility is more powerful than OreDictionary. Since Minecraft created the system, it allows users to have a greater interaction with the vanilla source. Tags can also hold an instance of another tag. In a modding standpoint, that also allows programmers to make their systems more dynamic such as having their machine take in a container of water rather than just a specific water bucket. It also removes the need from creating arbitrary reload listeners that could specify a list of items for greater compatibility.

 

Recipes and advancements are the most common scenarios to use tags. Let's say I add in some planks called 'silverwood planks'. Well for starters, I could add the value to 'minecraft:planks' so that my planks can be used to create a crafting table, unlock the craft_planks advancement, or even repair shields. In a more system scenario, let's say I wanted to create a washing machine that would need a water bucket to run. Well instead of specifying a water bucket directly, I could create a tag such as 'forge:containers/water' to say that any container that holds water can be used to run this machine.

 

Now, this does not mean you should go create a tag for every single block, item, or fluid. That would be extremely pointless and time wasting. I'm not going to create a tag called `domain:machines/washer` because I know it won't be used as an input for anything. However, if you are creating a system that you know will be commonly used or adapted in some fashion, you should make it possible to use tags to implement your specific recipe, advancement, system, etc.

 

There are a few limitations to this system that I should review. First, commonalities between recipes. Let's say that my friend and I's mod both have emerald armor in our mod. If we both use 'forge:gems/emerald' to create our armor, then whatever recipe is registered first will be the one outputted (yes, I know I chose an example that would happen with standard emeralds too). This issue results from over-creation of unoriginal ideas. The best way of avoiding this is to be more creative in what you create, but that can be a struggle for almost any modder, including myself. To avoid this issue, if you create an item that you know will be present in many different mods, you should just use your specific item rather than tags. As far as I am aware, there is no way to pick a certain recipe output based on the inputs unless the recipe book contains some voodoo magic.

 

Another limitation is that a tag can only take in a single instance of a specific object. This means no nbt data can be specified for any individual tag. This problem is very minor; however, due to laziness in porting or wanting to use a specific potion or arrow for example (for whatever reason), it seems to be an issue to talk about. To avoid this, don't use nbt data. If your mod still has items stored in nbt data, flatten it and create individual items. Now, of course, if you are trying to create a specific item that uses dynamic data (like a registry) this will probably not be possible. But, there shouldn't be any reason to have a single instance of a ItemStack within a tag. Just update to the current standards and try to avoid storing unnecessary information using nbt.

 

The final limitation I will mention is in regards to naming conventions. There is no real standardized location to know how certain files are organized and whatnot. The default Minecraft and Forge ones are easy enough to implement, but what about something not within those realms? Let's go back to the water bucket example. Although I created it for 'forge:containers/water', what if somebody sees a water bucket and decides it to be 'forge:buckets/water'? Then that commonality between all mods becomes a bit more abstract to reference. The only way around this is to communicate with other creators and view their source. Take a look at how a mod stores a tag information and connect the information to what you want to specifically use. Now, this does not mean that you can't determine that an iron gear should be 'forge:gears/iron' or gold dust should be 'forge:dusts/gold'. Just realize that there are some gray areas when it comes to naming conventions and its better to be prepared than left in the dark. For my above example, I could have 'forge:buckets/water' be a subdirectory of 'forge:containers/water' and this would fix my issue. Since tags are stored in a list, you also don't need to worry about multiple people calling the same object into a specific tag.

 

Tags are extremely important to implement and use within your mods for better compatibility with others and for a more dynamic and expandable response in your systems. If you have been avoiding using tags in your mod, especially if you are one of those people who make rubies or sapphires, go and reference them via 'forge:gems/ruby' and 'forge:gems/sapphire' instead of your specific item. So, make sure you realize the importance of using tags in your code and how to best balance what you have.

 

If you want to learn more about tags and their uses/implementations, Forge does a good explanation of them within the docs. It should hold all the necessary links to get yourself familiarized with tags to implement them in your mod.

[poopoodice 109]

Is it possible to compare two items automatically? For example I have this:

unknownItem.getTags().equals(vanillaItem.getTags())

but it obviously won't work if the unknownItem does not have same tag labelled as vanilla item. Are there any other ways besides hard coding what items tags will be there to be compared?

Edited July 22, 2020 by poopoodice

[ChampionAsh5357 158]

1 hour ago, poopoodice said:

Is it possible to compare two items automatically?

The example you gave gives me a bit of confusion on the question. If you want to see if two items are in a certain tag, you would use Item::isIn on both of them. If you're talking about if two items have the same tags, then the above method would work since Sets and ResourceLocations check accurately with the equals operator I believe.

 

1 hour ago, poopoodice said:

Are there any other ways besides hard coding what items tags will be there to be compared?

If you want to get a list of all currently present tags of a specific type in the game, you can check via TagsClass::getCollection and then iterate through all of them to see which one you want based on the ResourceLocation. However, that approach is just bad altogether. Just reference the tags you specifically need via a static final variable and use appropriately. We define specific tags since we know we will be using them. The only tags that will exist are those that are defined within the data/modid/tags section or by making the wrapper tag and adding it to its specific collection.

 

If I am misunderstanding what you wrote, please let me know.

[poopoodice 109]

54 minutes ago, ChampionAsh5357 said:

Just reference the tags you specifically need via a static final variable and use appropriately. We define specific tags since we know we will be using them.

Sorry for the confusions. For my question, to be more specific I'm trying to check if an item is fit with a certain vanilla item(like modded glass pane/glass pane, modded iron ingots/iron ingots), if it is, it allows players to use modded items to craft rather than using vanilla ones. The problem here is, the recipe I have has lots of items unlike fluid tanks and stuff like that that knows what are they taking. Will I need to mark their tags manually like you've mentioned above?

Thanks for the reply.

[ChampionAsh5357 158]

42 minutes ago, poopoodice said:

. For my question, to be more specific I'm trying to check if an item is fit with a certain vanilla item(like modded glass pane/glass pane, modded iron ingots/iron ingots), if it is, it allows players to use modded items to craft rather than using vanilla ones.

Ah ok. So to answer your question, you would need to put it into a specific tag and then overwrite the vanilla recipe. By default, Forge replaces almost all instances of iron ingot with 'forge:ingots/iron' through their recipe provider. The few that remain are iron block and iron nugget (since they are specific to the block version). So, as long as both items are in the specific tag and the tag is referenced in the recipe, it will take in anything within that tag (which would be your modded item). Do remember though if you plan on using something similar to ForgeRecipeProvider's implementation to replace the item with a tag that you exclude items that would be exclusive to that item set. Else, there will be even more issues with commonalities between recipes.

51 minutes ago, poopoodice said:

The problem here is, the recipe I have has lots of items unlike fluid tanks and stuff like that that knows what are they taking. Will I need to mark their tags manually like you've mentioned above?

Since the items are more abstract, you might not want to use a forge domain for your tags. One of the examples I can point you towards is endermen holdable blocks. This is a tag used to determine if an enderman can hold a certain block. This has a lot of different items that are not related to each other. However, they are for a unique purpose. In your case, if the items you want inputted cannot be condensed to a common group, then it would be best to just use a unique tag specific to your mod rather than a forge tag. And I assume when you say 'mark their tags manually,' you mean create the variable that holds your tag instance. If you would like to use it in your code then yes. If it's only for reference in recipes or advancements, you don't specifically need to. I do it because I use data generators to create tags for me. And you can add to already existing tags without replacing the data within them as long as "replace" remains false in the json file. Hopefully I have answered your question.