ChampionAsh5357

I'm guessing you didn't look at the BeaconScreen code at all. Here's a tidbit: [removed code for BeaconScreen#drawGuiContainerBackgroundLayer - diesieben07] You would just need to adjust the x and y offsets from there.

Add a configurated feature in the biome (probably an OreFeature if generated in clusters) with your own FillerBlockType created using FillerBlockType#create. If you're generating clusters of one, use ReplaceBlockFeature where you only need to provide a blockstate of the target and new state. Remember to call these methods within a DeferredWorkQueue within your FMLCommonSetupEvent as they are not thread-safe.

FluidTags#makeWrapperTag or TagRegistry#func_232937_a_ for a more general case should work. And they are now ITag#INamedTag objects.

AttributeModifierMap$MutableAttribute has three main methods: func_233803_a_ which creates an empty instanceof AttributeModifierMap#MutableInstance, func_233814_a_ which adds an attribute to the map that is initialized to the default value, and func_233815_a_ which adds an attribute to the map that is initialized to the value set. Most of the entity types hold a static method of a map that is stored within GlobalEntityTypeAttributes#field_233833_b_. The default map used seems to be based on the closest parent to the child object in question (ChickenEntity would use the one in MobEntity, EndermanEntity would use the one in MonsterEntity). All changes to the base map or additional attributes are applied using MutableAttribute#func_233815_a_.MutableAttribute#func_233814_a_ only seems to be used if the value is the default or where placeholder value is used (such as in LivingEntity until called by each child). As for registering, forge added the method GlobalEntityTypeAttributes#put which satisfies the requirement of where to initialize the MutableAttribute for each custom EntityType. Since the factory used to spawn the EntityType isn't called until the entity needs to be spawned, it can probably be called within your FMLCommonSetupEvent. I'm pretty sure the method is not thread-safe however, so it is best to set it up within a DeferredWorkQueue.

Since you're using a key to damage the item, I assume you're in creative. If so, the first line of ItemStack#damageItem should answer your question. if (!entityIn.world.isRemote && (!(entityIn instanceof PlayerEntity) || !((PlayerEntity)entityIn).abilities.isCreativeMode))

As the title says, 1.16 introduces a new data generator that creates block/item models for the game. I am wondering if forge is going to continue developing the system they already have or adopt and merge with the new generator implemented.

Try either GuiContainerEvent since it renders the screen after Screen#renderBackground is called.

You can check that with the debug hotkeys. If you want to show us the actual goal you written, it would be easier to find the solution.

Hmm, I wonder where a null value is in this code. Ah, there it is! It's not good if you make the message part of the text field widget null. The object is not nullable and requires a string, empty or not.

That would make sense as the method has an effect on the PlayerRenderer which in turn affects the FirstPersonRenderer. As for a way around this, you would have to update the MatrixStack when your item is held during RenderHandEvent. In that case, you could repurpose the CrossbowItem rendering by canceling the event and rendering the item yourself in the correct location.

Does your item extend CrossbowItem? That class has some special handling within the FirstPersonRenderer. That's probably my best guess as to what is going on.

Read up on capabilities if you want to store information in the chunk I would say. Also, the chunk seems to be unloaded before it is saved, so the data would be cleared before it is written.

It would be nice if you can post the json file of the weapon and include if you made any changes to the first person renderer. If you really want to you could import the model into Blockbench and look at the first person display to see if the issue is in your json file or not.

Your error refers to one with the obfuscated Material#ROCK. Please post the error log response for a more accurate response to your issue since it has nothing to do with dependencies at the moment.

No, I mean the actual source code example. Yes. Usually I wouldn't suggest rewriting code unless it was a standardized or core component of creating modifications for the game. Registering features is one of the things that is required along with a few other mentions.

You might want to read up on registries and look into using DeferredRegister and RegistryObjects. There are plenty of forum posts including both of these if you need some more information.

No, the maps are a static final variable so it should be accessed directly from calling the class. Just follow the example in FlatGenerationSettings. I quote from the source itself "Utility for running code on the main launch thread at the next available opportunity. There is no guaranteed order that work from various mods will be run, but your own work will be run sequentially." Use DeferredWorkQueue#runLater in your FMLCommonSetupEvent to reference and put your feature in the maps. Even if you're modifying preexisting code, you should check all the information regarding whatever you are doing. What I said early refers to the correct way of registering and adding features to biomes. DeferredWorkQueue is a less obvious one unless you have been paying attention to similar threads on the forms or actively keep checking the changelog and source information. A lot of what is in the source code is just a loose template as you say since there are better ways to approach it.

You put your configured feature in the map most likely during the common setup in the DeferredWorkQueue.

My apologies, you might want to try adding it to the following maps in FlatGenerationSettings: FEATURE_STAGES, STRUCTURES, and FEATURE_CONFIGS.

If you're specific to your items only, Blockbench (a modeling software) has a tab called 'Display' that allows you to adjust your items in each camera view. If you're talking about all items, you would need to override RenderHandEvent and adjust the translation, rotation, and scale of the MatrixStack, but this would be in effect for anything in the player hand.

Structures need to be added with Biome#addStructure as well. Also, features need to be registered like any block or item not as some anonymous class. Finally, adding anything to the features or structures of different biomes is not thread safe and should be wrapped in a DeferredWorkQueue. Look at how Minecraft handles structures if you need an example.

You still need to attach the register to your mod event bus.

Just use diamond syntax on any mutable map constructor (e.g. HashMap). Also, with your current system, you should wrap the Block instances in a lazy supplier so that blocks that you can correctly call the instance when first accessed instead of returning null.

Both of the methods you laid out are specifically for the logical client. Read up on sides to better understand what you are looking for. You would need to send the information from the logical server to the logical client at a certain point in time so a packet would work best.

Either give yourself a potion effect when the armor is worn or look at how the potion affects the player and replicate that with your enchantment.