V0idWa1k3r

Define "wrong". I have no idea what this means, sorry.

If using NBTTagList check for it's size, otherwise check each tag for it's existance and the dragon's existance.

Just store the dragon's UUID in the NBT, then you can find said dragon by UUID. As for the cycling - store a byte indicating the position in the list in the NBT and manipulate it. When getting the UUID for the dragon get it based on that byte. Eiher name your tags dragon_0, dragon_1, etc. or store them in an NBTTagList.

Where exactly did you put it into your blockstate? And have your removed your custom transformations from the blockstate file?

Don't call Entity#move, since the item is going to move on it's own each tick based on the motion values it has.Your movement is choppy because the item is moved twice per tick. Apart from that I don't know if there are solutions to the position desync that occurs, especially when collisions happen.

Since you are already using forge blockstates you can just specify the transformation matrix directly in there. You are only specifying the rotation which... I am not even sure if you can specify it like that, don't you have to provide a quaternion? Or at least the angle and the Axes? Or if these are rotations for the axes then why are you rotating 90 degrees around the X one? And as you've discovered the rotation alone isn't enough. In any case forge allows you to specify built-in transformation data, already pre-made for you. In your case the forge:default-block transform would do the trick. You can see an example here.

Don't ever use numerical IDs, they can and will change unpredictably between worlds. Use the MobEffects class.

This is actually kinda tricky but here is the general gist: Create a list of AABB representing the player's body part hitboxes: the head, left leg, right leg, body, right arm, left arm. Using the LivingHurtEvent or whatnot grab the player being hurt and the player initiating the attack. Your attack vector is [attacker.eye] - [victim.eye] + [attacker.forward], or alternatively [attacker.forward] * [attacker.reach_distance]. Either should work but the second variant is preferrable. Transform the attack vector into the AABB space(which is the forward-Z identity space). Basically do it by manually rotating the vector around the Y axis by the degrees between the [victim.forward] and [unitZ] vectors, and then do the same with the victim's pitch(not the head pitch, the body pitch). Or construct a transform matrix and multiply the vector by it, it works too. There are a lot of math papers on the subject that might help you here. Now that you have the attack vector in AABB space simply check which boxes it intersects with - that's your hit bodypart. It may not intersect any though because of the way the game works. You could also implement BB boxes(not Axis-Aligned) and work with them but it's a bit more tricky albeit a better solution. Again, there are a lot of papers on the topic of BBxes, you just need to search for them. Unfortunately Iimplementing moving body parts like the legs and the arms is trickier since their transformations only exist on the client, so you would have to replicate them on the server in the even based on variables like swingProgress, but you might simply be lacking a few values which may or may not be important, then transform the vector to the space of animated body part and check whether it intersects that AABB. You only need to check that one AABB and you don't have to check it again. Do the same for all body parts. That's how I would do it anyway.

The deprecation of methods inside of the Block class (apart from forge-provided ones) mean "Don't call directly but is safe to override". Override Block#shouldSideBeRendered

This is plainly not true. It might have been at some time but I can tell you for certain that it isn't the case at most since 1.8.

This will obviously not work. Why? You can't just extend EntityPlayer and call it good. Why are you using EntityPlayer anyway? renderViewEntity can be anything that is an Entity. Don't use KeyInputEvent, use a TickEvent of some kind. Try a simpler setup. Can you replicate the issue if you just set the renderViewEntity to, say, a mob you punch? Without the rest of the code.

You are seeing a normal behaviour. First of all the Z value IS changing, even in your screenshot it goes from 55 to 56. Secondly imagine how the world generation works in your case. Say you moved 1 chunk in the positive Z direction and the render distance is 10. The game now loads 21 new chunks(x, y) -10, 11 -9, 11 -8, 11 -7, 11 -6, 11 ... As you can see the X is the one changing, not the Z which is logical. You will see the reverse happen if you go in the X direction. No, you wouldn't. You would bitshift to the left by 4. Also in your implementation the yellow flower placed by the generator would immediately pop up and drop itself since it can't stay on top of bedrock.

Class != Instance of said class.

Well, yes, you need to use the instance you want to update the value of.

If the method is public then you don't need reflection. Anyway, as the error clearly states you are passing an object as an instance of the class while the object in question isn't an instance of said class. This is one of reflection's basics. Same here - you are passing a Class as the instance, which will never be the case. https://www.oracle.com/technetwork/articles/java/javareflection-1536171.html

No. Forge only works for the version it was made for.

Also probably don't put your model(or is it a blockstate?) into the textures folder. No, vanilla doesn't even have a textures folder inside of a blockstates folder.

I know you've solved this, but You could use the EntityJoinWorldEvent.

Override Item#getItemUseAction and return whatever action you want it to be, in your case it would be DRINK

Anything below 1.9 is no longer supported on this forum. Update to receive support.

What version of the game are you using?

https://mcforge.readthedocs.io/en/latest/animation/intro/

Well, you do, rarely. You pretty much shouldn't be using it on your own methods though. These are basically somewhat of a proxy(ish) for forge. Client/Server execute side-specific stuff while common executes common code. Note however that they are NOT a proxy, and you shouldn't have a common proxy. But it doesn't matter anyway since you shouldn't get the server like that. Get it from a respective WorldServer instance. Well, kinda. It's not about synchronization, it's about running logic on the server. You still need to notify the clients of the change using the packets though. Minecraft is an obfuscated game, meaning that things like Minecraft.getMinecraft().player.swingArm() are actually ada.b.a.d() in the compiled binary. The ada.b.a.d() nonesense is called NOTCH names and that is how the game looks when you download it from the official website. Not very good for modders, so a group of people decided to deobfuscate the game by manually "translating" this giberrish into human-readable names. It is done in two steps - first the names are translated into still non-human readable but consistent names - func_141242 for example. You don't know what this means and neither do I but this stays consistent between versions which allows for a simple database to be setup. These are called SRG names. Finally these are translated locally on your machine when deobfuscating into human-readable MCP names(like swingArm). When the game launches with forge it runs SRG names, so when mods are compiled a backwards process is applied - the MCP names the mod references turn into SRG names. Thus we come to reflection issues - since reflection searches by name there is an issue since the compiled binary has different names than the one you are running in your dev environment. So forge has helper methods that allow you to pass multiple names to reflect on or in case of the later forge you only need the SRG name. Why SRG? Because it's consistent. MCP names may change as often as each day, but the SRG stay consistent. So yeah, here you go, I guess https://en.wikipedia.org/wiki/Memoization

This looks mostly correct to me. Are you sure the items aren't there? Are you sure that the item is registered at all? Are you sure that the creative tab is correct? And if you are using static initializers - then don't because the item is likely being assigned a null creative tab.

this is still the case. This was never the case. You needed to override Item#getSubItems and manually add new item stacks to the list. Apart from that - you have provided zero code so I can't tell you what you are doing wrong.