ChampionAsh5357

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.

Fun fact: that method is used inside of a different method that encompasses all mobs to see if they can spawn. The method is called MobEntity#canSpawn.

Actually, the problem I described is wrong, so apologies. I missed a single line of code. First, the actual problem is that your global variable of your tile entity is not initialized since you decided to make a local variable in your constructor instead (lines 28 and 34). For your method, my understanding is that you should not mix methods outside the realm of the reference holder with the variables inside. You can, but it might lead to a problem later on when dealing with some client server syncing. I'm not sure, but I just tend to avoid it. Second, calling that method inside your tileentity class is just redundant when you are already literally in your instance of a tileentity. You can literally pass in your tileentity by simply using 'this' instead of passing in two variables you only use once.

You know it tells you your error. Your tile entity is throwing a null value on the server at a specific line in a specific class. I think you should write your get method for the reference holder correctly. You also realize this is completely redundant. Why are you getting the current tile entity in the container from the world rather than passing in the tile entity? These two should tell you exactly how to solve your problem.