V0idWa1k3r

If you are using java then Minecraft.getMinecraft is a public method that doesn't need reflection to be called. Again, just make a java mod.

What stops you from calling this method from java? Why must you use C++? Just write a normal java mod. Anyway, this is a forge forum. Forge is a modding framework written in java. I don't think you would get support with C++ modding here.

The sneaking speed is just a multiplier over the original player's spead(I think) you should just be able to apply an attribute modifier to the player's speed attribute if they are sneaking with your armour.

Why are you using C++ to write minecraft mods? Don't do that. Use java.

Don't. IHasModel is stupid since every item needs a model and makes you write a lot of unnecessary code. You can literally register the models for all your items in 1 line of code. Don't ever use static initializers. Registry entries must be instantinated in the appropriate registry event. Since you are using BlockTorch as a base you must define the blockstates that the torch might have in your blockstates file. See vanilla torch blockstates file for example.

When the villager GUI is open minecraft sends an additional packet to the client that populates the recipe list. See EntityPlayerMP#displayVillagerTradeGui

Loop through the player list and send the message to each one individually.

This means that you haven't registered a renderer for your entity. You however have shown 0 code so I am unable to tell you more.

You would subscribe to a registry event that fires for the EntityType registry, then register your EntityType into said registry. That's it. Nothing else changed from 1.12 or earlier.

Don't use static intializers. instantinate the registry entries in the appropriate registry event.

ByteBuf isn't magically going to accept any object. As any kind of (de)serialization you need to divide whatever it is you are sending into types that can be written onto a buffer and construct an identical one at the receiving end. Although with a fluidstack you would serialize it to a NBTTagCompound and send that over the network in case a mod stores additional NBT data in the fluid stack.

1.7.10 is no longer supported on this forum. Update to a modern version of minecraft if you want to receive support.

Why are you using 1.10? Update. All resources must be entirely lower-case. You are not specifying a model property in your blockstate file as the log is telling you. No, models != model.

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a Specifically this section

Why did you immediately jump to a static initializer when I said "local variable"? If you don't know what a local variable is then you need to learn basic java. You absolutely, 100% must not do this. Use one of the vanilla fluid materials provided, water or lava. If you need a custom color then use the constructor that takes a MapColor as an argument, or override Block#getMapColor

Since you are registering your fluid in a block registry event use a local variable. What's a material in this context? Could you please elaborate?

I know it seems counter-intuitive but player motion must be changed on the client, the server doesn't actually control it.

You don't need this. Just override Block#hasTileEntity and Block#createTileEntity. You don't need the boolean field in the first place. What makes you think it always returns false? I suspect that you are trying to query it on the client which never has the synced data since you never sync your TE to the client. Don't do this. TextComponentTranslation is a class that exists.

I don't think such an event exists.

I explicitly told you NOT to override the method, but CALL it before rendering the model, yet you decide to override it anyway and not call it

This is the method you need to call to bind the texture and you need to do this before rendering the model

Render#bindEntityTexture

Bind the texture before rendering the entity.