ChampionAsh5357

The deprecation refers to calling the method. You should call these methods from BlockState. Overriding is fine.

Advancements are stored on the logical server. The information is specific to the save used based on the uuid of the player. Asking whether or not you could get the advancement on the logical client is pointless since that information can just be obtained by pressing the letter L on your keyboard (by default). If you want to know how, learn about networking and realize there is a ClientAdvancementManager that handles this information for you already and a packet that transfers information.

This seems like an issue of rendering the same widget twice. If you look at the super method for renderButton, you can see that the button is already rendered with the standard textures before calling your own blit to render. Try removing the super method and replacing what's missing inside your own method.

You would just need the position which is already in Item#onItemUse

Create your own sign instance that's expandable instead of relying on extending the source code.

A lot of data is not stored on the client. Since you are not throwing an error, I can assume the ClientWorld is not null on your entity. However, the position of the entity may not be. You can verify this with a breakpoint. If so, you can pass the data using a packet from the server.

The hand renders what's being held in the hand. You would need to render yourself whatever item the player is holding.

For death persisting and changing between dimensions, you should probably read over the forge documentation and look at some implementations (credits to Choonster). As for the data when the player joins, if the data is being reset to zero (assuming your write method is correct), then your error probably comes from incorrectly reading the values back. Another error I can think of has to do with logical sides, but this would have to deal with synchronization issues depending on how you call and read the information given.

After doing a quick look, it has to do with how attributes are stored on itemsstacks. By default, itemstacks have no attributes stored on them. What attributes are determined on an item is based on a method called Item#getAttributeModifiers. This is what ItemStack#getAttributeModifiers defaults to if there are no attributes added on as nbt data. What you are doing adds on an attribute as an nbt tag, causing the program to not default back to Item#getAttributeModifiers but rather execute only what is currently on the item, your only added attribute. For a semi-complex problem, there is a simple solution since this is an item. Just simply add the modifier by overriding Item#getAttributeModifiers in your class and add to the previous multimap by storing the super call of the method.

It can be any number of things based on how little you are showing. I do not know what your constructor is implying or what the gui is for (since you are specifically calling a client version with no server communication e.g. containers). The one thing I do notice is that there is a method in Screen that adds a button for you. Please show your entire class and give context so we may accurately give a more meaningful response specific to your case.

Assuming the water is modeled in a json file, did you set the tintindex to 0? This would apply to any face of an element in the json model.

Send a tile entity update packet to the client.

Take a look at the RecipeManager

First, don't use @OnlyIn. Second, you just pretty much copied the classes without viewing your situation. You already had the tickable sound done. You just need to play, check if playing, and stop it from the SoundHandler in a player tick event.

I don't really have an example. The most I could do is give you classes that use it such as UnderwaterAmbientSoundHandler or BeeSound. You can get an instance of the SoundHandler from Minecraft#getSoundHandler. Then using a player tick event, play the sound if it isn't already playing and item is held. If the sound is already playing, do nothing. Finally, if the item is not held, stop the sound using the methods above. I hope this description can show you some usage of the classes.

Ah okay. So there are multiple ways to do this. One way is to call it using SoundHandler#play but you should store the current instance of the sound playing in a variable. Then using a combination of SoundHandler#play, SoundHandler#isPlaying, and SoundHandler#stop you can manage the sound looping in some sort of tick event I would say. Another way would be attaching it through an ambient sound handler.

Well let me ask a better question. What specifically do you want to use this sound for? If its just a simple request on another entity then using Minecraft#getSoundHandler and playing the sound through there would work. If its for ambiance, you need to access and write to ClientPlayerEntity#ambientSoundHandlers.

You need to add a sound handler to the client player.

My guess is that the jar file didn't obfuscate itself to match what the actual method is (e.g. func_numbers_letter). The command I use is 'gradlew build' which is what I assume is what you are doing. You might need to either try a different version mapping or source version.

Why do you need a registry for it? You just literally call the register method when setting up the common lifecycle.

Remember you can deprecate methods in the core to be removed later to allow backwards compatibility with older versions if the changes affect a wide range of mods you are creating. If you are including the libraries as a standard utility, you are most likely not going to reuse the code in other projects.

I'm guessing you forgot all about EntitySpawnPlacementRegistry from your previous post.

It should appear in the controls menu by default. I just verified this using: public static final KeyBinding TEST = new KeyBinding("key.test", KeyConflictContext.UNIVERSAL, InputMappings.Type.KEYSYM, GLFW.GLFW_KEY_J, "key.categories.test"); private void clientSetup(final FMLClientSetupEvent event) { ClientRegistry.registerKeyBinding(TEST); }

Look at how the method is implemented on the creature. You should see exactly how to get a blockpos from an entity position...

Create a static final instance (could be just final as well) of your keybinding in a global variable and register it using ClientRegistry#registerKeyBinding during FMLClientSetupEvent. You will need to use packets to apply the potion effects.