ChampionAsh5357

I was trying to achieve at the time making Effects completely invisible to the player. This means no particle effects or GUI notifications of how much time you have remaining regardless of what Effect it was. Apologies for such a late response. For some reason I never realized this was replied.

{ ... "result": { "item": "your_item", "nbt": { //Your nbt tag goes here. } } }

You're creating a recipe. You're making it in a json file. You need it on the output. The json object is called "nbt".

I'm confused because there are three questions I could ask: Are you changing the shape of your block? Are you trying to write to a tile entity? Are you trying to sync a tile entity to the client?

There's a bunch of good tutorials (especially one on custom dimensions) from McJty that might be able to help.

Personally, I'm not a big fan of the way you programmed it. You're implementing IRecipeType on a class (which makes no sense), not creating a serializer, and just not registering it anywhere. So, let's break it down. All recipes that hook into IRecipe have three things: - A class that implements IRecipe<T> (most likely T will be RecipeWrapper if you are using IItemHandler over IInventory which YOU SHOULD BE) - A class that extends ForgeRegistryEntry<IRecipeSerializer<V>> and implements IRecipeSerialier<V> (V is your class that extends IRecipe<T>) - A variable holding your IRecipeType<V> (statically initialized through IRecipeType#register should be fine). Let's start with IRecipeType. This just basically holds a string that will create a new map entry within RecipeManager for any recipe with that specific type. The string held within the registry should be your mod id appended with whatever you are going to call it. Next, let's go into IRecipe. All IRecipes should have a constructor that takes in a ResourceLocation, a String group (if you are going to use the RecipeBook), an Ingredient (NBTIngredient if you want to use NBT data), and ItemStack output. Note, it doesn't have to be an ingredient or itemstack, that's just the case most people use it for. Then we have the methods: - matches: checks to see if your recipe matches with the ones stored (will use Ingredient#test) - getRecipeOutput: the output of your recipe with no information provided beforehand (will be your result) - getCraftingResult: the output of your recipe with context (will be your result followed by ItemStack#copy) - canFit: checks to see if your recipe can fit in the required space - getId: the ResourceLocation of your recipe - getType: the IRecipeType your recipe should be stored in - getSerializer: the IRecipeSerializer used to read and write your recipe. Then we have the IRecipeSerializer. This will be registered within your code via RegistryEvent or DeferredRegister. This has three main methods: - read: reads the data from a JsonObject and returns an instance of your recipe (json file stored in datapack) - read: reads the data from a PacketBuffer and returns an instance of your recipe (server/client packet sending) - write: reads the data from your instance to a packet buffer (server/client packet sending) These methods can be observed in all recipe classes (e.g. ShapedRecipe, AbstractCookingRecipe, SingleItemRecipe) Once you start to create your json files (same place as all the other recipes), the type is handled by what the IRecipeSerializer is registered under (modid:object_name). And that's basically it. Hope this helps. If you want an example, I wrote a basic recipe and serializer for blenders a while back.

Please create your own post with your code, error logs (if any), and examples if you need more to explain your point.

Forge added an NBT tag (called "nbt" obviously) to outputs as they return an ItemStack and not a simple ingredient. The format is the same as any other nbt tag out in the wilderness of the Minecraft files.

Learn about features, and then structures. IglooStructure and IglooPieces are a good basic introduction to creating structures with nbt data.

Would you like to show us your code so we can actually diagnose the problem with little to no guesswork?

Please use object holder to "hold" the block and item instances when registering or use deferred register if you're going to statically initialize anything. What you have written for custom blocks is just wrong.

First of all, use a data generator. Second of all, your ruby_ore file is not a json file.

Check out your other post:

Since you are using a texture, almost everything within PlayerRenderer is worthless to you. You could literally just replicate SkeletonRenderer or some other BipedRenderer and be fine with it. As for PlayerModel, it depends on what you are trying to do with it. If you are using any of the overlay layer on the skin, you probably will need to use PlayerModel. Else, you can just get away with BipedModel and going from there.

As far as I know, you would need to send a packet. The method is called once on the server and once on the client so you would need to do data synchronization. Most likely, have the number determined on the server and send the number to all entities tracking the entity and itself on the client.

LivingEntity#setActiveHand

Since I don't feel like typing out how entity attributes are handled again, read this:

Entity#func_230279_az_. Please specify the class next time.

net.minecraft.client.renderer.entity.model.* And yes, they do exist.

You need to learn some more Java. Forge does provide an easy access to reflection via ObfuscationReflectionHelper. Note: you will need to locate the unmapped names of all the fields you would like to modify.

Update your workspace to version 32.0.40 at least. It fixes the issue of FMLServerAboutToStartEvent being fired too late on an integrated server.

harvestLevel and harvestTool still need to be reevaluated. Until then, they will not work.

You would need to call Block$Properties#sound and pass in a SoundType. If you want to use custom sounds, you would need to create your own SoundType using the constructor.

Deprecation of randomTick and tick have nothing to do with overriding the methods. The deprecation is for usage. When calling those methods, you should call them through BlockState rather than through Block. As for why it won't work, you probably didn't add tickRandomly() to your block's properties. Deprecated methods will still work regardless.

You would need to modify fuseTime and explosionRadius within CreeperEntity using reflection.