ChampionAsh5357

You probably shouldn't inject your capability into two locations then. If you look at your PlayerHandler class, you can see that your capability will be injected into this location, calling the class with a bunch of client side only imports.

That's the mistake, never follow a tutorial word for word. Even though you probably just didn't register the DeferredRegister to your mod event bus. I can't see it, you don't have it working, it makes for a great combination of trial and error when this could've been done in a single post. Please post your code next time.

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. 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.

I meant that section within the method in the class. I still don't find it since its called from an entity type. Also, as much as you tell me this is 1.14.4, WorldServer was renamed to ServerWorld and WorldEntitySpawner was moved to a different package in that version making your statement a lie. Just for a bit more research, this line of code was referenced in at latest 1.13.2. There are things known as EntityTypes now. So once again. 1.13.2 is not supported on this forum. Update to at least LTS if you want support on your code.

So you have an entry in EntitySpawnPlacementRegistry and you've added a SpawnListEntry in the biomes to spawn in? I have no idea what this is: It always nice if you can show code and an error log rather than showing us where the error is. I also don't even see where this class is which leads me to believe that this is an outdated version based on the variable names. So, update to at least the LTS 1.15.2 if you want support.

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. 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.

Although there is support for recipes and recipe implementations, there seems to be relatively little when it comes to how its displayed in the recipe book. There are two main classes this occurs in: ClientRecipeBook and RecipeBookCategories. Since RecipeBookCategories is an enum, it can be easily extended upon via IExtensibleEnum. However, ClientRecipeBook is a bit more tricky. There needs to be some references in newRecipeList, getCategory, and func_216769_b. newRecipeList concatenates recipe book categories together. This is because the search categories include all the references from the same type categories (e.g. FURNACE_SEARCH will contain recipes listed in FURNACE_BLOCKS, FURNACE_FOOD, and FURNACE_MISC). This works in association with func_216767_a to put the subcategories into the search one. getCategory associates a specific IRecipeType with a recipe book category. func_216769_b associates a RecipeBookContainer (just an extension of Container) with a list of associated recipe book categories. So there would need to be some sort of mapping that associates an IRecipeType with one or multiple RecipeBookCategories depending on the tab, a RecipeBookContainer with all corresponding RecipeBookCategories, and a search RecipeBookCategories to its subcategories.

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.

Although the docs on this is still outdated (my fault for incorrectly basing a branch, causing a larger delay on it), it still is plenty useful. As you said, capabilities are used to store extra information on TileEntities, Entities, ItemStacks, Worlds, and Chunks. You can attach your capability via a provider or by using the attached method to the class (usually on TileEntity and Entity I believe). Basically, it just stores excess information on the object provided. Now capability data is specifically for the logical server as by default, it is not sent to the client. There are three use cases for this information and how to synchronize efficiently without creating a bottleneck is depending on how or what information you sync. Hopefully this gives you a good starting point. As for examples, I think Choonster made a pretty good one (it doesn't matter that it was for a previous version since the implementation of capabilities have still been the same).

But why? Static variables are nice this time of year. And using deprecated methods is also not a good thing either. Also, what's the question?

First of all, THIS HAS TO RETURN YOUR ARMOR MODEL. Second of all, THIS HAS TO REFERENCE YOUR CUSTOM CLASS. I have definitely said the second one at some point already.

Read this if you want some reference. It'll tell you where the source maps are located. If you want to know why Forge doesn't use them, read this.

You would need to write something that extends this class and reflect it into Minecraft. That's what I was saying originally which would have unintended side effects. You can change the values with reflection fine. But if you reflect the class in for another, then it creates issues.

Ah ok. I misread the code then. I don't really see anything particularly an issue, but I also couldn't pinpoint the information with the code. I should note that you have two listeners pointing towards AttachCapbilityEvent However, there seems to be a lot of information that is just not right. Most of the information is logical server only so you most likely wouldn't detect any "rendering" changes on the logical client. There is no synchronization if I do say which would be fine if you're not retrieve information on the logical client. How did you test that your capability was returning empty? It could just be you were trying to retrieve information that is not stored on a specific side. Of course, with the mess of code, I could just be completely wrong with my assumptions.

Learn the difference between the forge and mod event bus. Hint: LivingHurtEvent is not called on the mod event bus. These two also do the exact same thing.

Not to mention your code is very everywhere and doesn't even store a LazyOptional (why do you call creating a lazy optional EVERY SINGLE TIME), you don't even store the capability you mention. First thing, why in the world are you storing a capability for an ItemStack on an Entity? Second thing, why is there any reference to storing information between these two capabilities. They might have dependent data, but their read and write functions are solely independent. Go look at Choonster's test mod if you want an example.

Unlikely that there will be a tutorial for this, at least one that works well. But one of the greatest tutorials out there is just reading the Minecraft source. So, go do that and take a stab. You'll probably have to decide whether your structure is stored in an nbt file or not as well. You might want to try reading through and creating your own implementation from there. It's probably good that there are no tutorials for somethings at times since it will show how well you can apply your knowledge of Java in the current situation.

First, make a block with container access. If you want the information to be stored within the block, you'll also need a tileentity. From there, you can choose to use the current recipe system or create your own. As for making it reversible, you would need to check its output and get the ingredients used to make it. Since ingredients can be multiple items, you would need to select a random item to return from that list. And if you want to implement a recipe book for it, you'll need some knowledge to get it working semi-smoothly after all that especially with the additional of reversible recipes.

Do it when the capability is first attached to the itemstack.

Once again, learn basic java. Its not a red, its called an error. Second, ITS AN ENUM. Enum objects are separated by comma and ended with a semicolon. Please don't tell me you're trying to follow the tutorial word for word. It's a baseline to understand what's going on and for you to apply your knowledge to it. It's not a giant cheat sheet.

Here is the link to the default blockbench model. It was within resources. And its the hierarchy that's wrong. Each part is separate from one another. This says that the body's rotation supersedes all which is not true. I mention the zombie entity as a good baseline, but you still need to edit it to get a standard model to work from. I would say reconstruct your model from the default provided. All cubes must be in one of these folders. If you want easier transference, you should put all your custom cubes into their own separate folder within the six default ones. Anything within the default model should not be edited besides from the texture.

First of all. What I wrote assumes you have some knowledge of java, items, and sided systems. I wrote a proxy to separate physical client and server code. Since this is my text, I will do my best. Almost but no. You add children to the actual ModelRenderers within BipedModel. rightArm attaches to bipedRightArm and not your body. If some of your ModeRenderers are not attached to a child with a 'biped' in front of it, you're probably doing something wrong and it won't render. Because of the lack of understanding when it came to these things, I attached a Blockbench file in the Github to make it so that you could just remove those renderers afterwards and attach them to the actual ones. It makes the process much easier to handle rather than guessing and creating from scratch. I already explained the issue with the first one. The tutorial assumes you set up a proxy system or somewhere client code can't be accessed by the physical server. As for why none of your things says extends, I made a class that EXTENDS ArmorItem. This should be done to render the armor. I can see that you didn't make a custom item class and opted to use a vanilla one instead.

I thought Forge classes are not obfuscated? And if it still relates back to the original topic then sure.

First point, you should look at Entity::changeDimension (the one with the ITeleporter instance, server side only). Second point, I mean it doesn't help when your noise biome is only one biome. Take a look at OverworldBiomeProvider. That should answer your question.

Well you'll probably need to make a custom VirtualScreen and MainWindow instance and work with how certain information will render within it. You would need to use reflection to edit these values within the client. I highly advise against this however since it will probably create major side effects replacing the it value way too late along with the previous instance still being used in the original calls. It probably wouldn't work at all since most of the information is called in the initialization phase. In my opinion, just create an overlay similar to the debug menu to show your overlay.