Draco18s

OpenGL calls.

You're both in the wrong section (you want Support and Bug Reports, this is the programming forum) and 1.7.10 is no longer supported and you have coremods installed and should talk to the core mod authors first.

Better idea: prefix all your NBT keys with your mod ID

That makes no sense.

public class BlockTestStem extends BlockStem { public BlockTestStem(Block crop) { super(crop); } } Worked for me, what's the problem?

Pretty much.

return BlockRenderLayer.CUTOUT_MIPPED; Cutout means that the alpha transparency is either 0 or 1. You want BlockRenderLayer.TRANSPARENT;

You need two blocks and a seed. One block is the crop (the stem) and the other is the melon. When the stem is fully grown (and not attached to a melon) and it grows, it picks a random side that is clear and places the melon there.

[14:35:26] [Server thread/INFO] [sTDOUT]: NBT Energy: 60 [14:36:31] [Client thread/INFO]: [CHAT] Charge is 0 SE

I didn't ask about the item model. I asked about the block model. Does the "lit" version have a different model?

So question: The values that got reset. Were those client side values or server side? Have you tried printing out the results of the readFromNBT? That is: System.out.println("It tried to read from NBT"); System.out.println("NBT Energy: "+ compound.getInteger("Energy"));

Do you have two different blocks? Are they both registered? Do they have different models?

Mod IDs are all lower case.

Show: - Your blockstate file - Any model files

How can you tell? Also, don't use ITileEntityProvider. Override the hasTileEntity and getTileEntity methods that are in the Block class.

The reason it isn't syncing when the data changes likely has to do with your writeToNbtSync methods not sending the data due to an incorrect assumption on which data is important. getUpdatePacket and getUpdateTag are called at different times, I forget which is which, but one is called when the TE is first sent to the client (either when the client logs in, or when the chunk is first loaded and sent to the client). The other is called after that, when the TE data changes and the client needs to know about it.

I don't know. Your writeToNbtSync method is weird and I don't know why you have it at all.

You don't need to send packets to update TEs. Vanilla does that automatically. It's what onDataPacket and handleUpdateTag are for.

If it hangs, that sounds like an infinite loop.

if(type != NBTType.SAVE_BLOCK){ super.writeToNBT(compound); } You do know that a TE has to call super.writeToNBT() to be properly saved to disk, right?

$10 says you registered a block using GameRegistry.Register(Block) and didn't also register an ItemBlock. Ergo your block does not have an item form, cannot be held, does not show in the Creative inventory, and cannot be given.

I don't understand how this helps me. This is how one adds dependencies to outside mods. I'm looking for getting the dependency for the API Dude. Both of those mod references are my own mods. HardLib contains my API.

MCAnimator is shit. Don't use it. And by "shit" I mean that it isn't thread safe. I tried using it once and no matter what I did, the game would eventually crash with a ConcurrentModificationException.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/OresBase.java#L83