Draco18s

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

Why are you doing this? this.getWorld().getMinecraftServer().worldServerForDimension(0) You're asking for the world server for the overworld, your TE might not BE in the overworld.

Well. For one. A GameProfile isn't an EntityPlayer ...

People would still have to download your mod, which would contain the resources. You can make a resource pack and include it with your mod without having to do anything in code.

TBH I think his tutorials are both out-dated and cringe-worthy. Not that they don't work, but that they do a few things that make no sense in the context of teaching new people how to do things and it ends up being very cargo cult-y. And it makes it hard for us on a forum to debug because the poster doesn't actually know which bit they should be posting and we don't know which bit to ask for. We know what piece of code we want to examine but we don't know where they've put it. One example is: @mod class invokes a proxy method proxy invokes a ModBlocks method That method then instantiates each block and registers it (calling yet more proxy methods) The user then posts the block class and says that the model isn't working and there's no error message in the console. So we ask for the main mod class. Then have to ask for the proxy. Then have to ask for the ModBlocks class. And only then can we (through tedious tracing) figure out that they missed a step: their ModBlocks method doesn't actually call anything at all! Or maybe they were forwarding the Forge events through this chain (why!?) and somewhere along the way they wrote preInit(FMLInitializationEvent event) . See how that took three attempts to get the information us (more experienced modders) needed in order to help?

Just for understanding: "builtin" is the "the parent is the stuff that is created via actual javacode." But as that's merely a template with the files being able to specify overrides, the rotation, scale, and suchlike are all handled by the json files. Hence the top-most parent for everything else is "item/generated" as it is a direct child of "builtin/generated" but supplies the necessary default overrides for Minecraft's aesthetic.