Draco18s

Are you doing it on both the server and the client, or only the server?

My guess would be FreddyCraft as the installed-mod-at-fault.

Oh geeze. I feel like an idiot

Yes, I know about event.Phase public void tickStart(TickEvent.WorldTickEvent event) { if(event.phase == TickEvent.Phase.END) { //code here runs three times per tick. } } Not sure what else I need to check for.

Yeah, don't screw with that value. I'm actually using it right now and I expect it to go above 23999 in order to provide seasonal shifts.

My guess would be "yes."

Because those items are defined at runtime. Look at Item.java

As I said, depends on what you're doing. For me, /etc is where I keep the mcmod.info files for each of my submods (I could have called it /fluff if I wanted to). build.properties is supposed to be for each submod's version number (but for whatever reason gradle complained it couldn't find the variables, so they got shoved into the build.gradle file).

The build.gradle file. Which is why I dislike the project setup for Forge Gradle. Changing from one mod to another either requires that I duplicate a large portion of common files or moving around a bunch of stuff. And makes setting up a git repo annoying, because almost ever subfolder other than /src doesn't need to be on git. Also most of the files there too other than build.gradle... Highlighted stuff is part of the project and should be on GitHub. Everything underlined in blue is technically part of the project, but should not be on GitHub (you may or may not have build.properties or an /etc or /lib directory, depending on your needs). (And Lars pointed out that I missed a directory, ha!) Go to the mod. Click "fork." Or click "edit" on a file and GitHub will automagically fork it for you and drop you right into the edit window. You can also clone-to-desktop.

You're using vanilla's BlockStates and not using the same model definitions.

Man, I keep reading this thread and thinking "Why coffee?"

Or that, yes. But really one of the other two would be better (BlockContainer does the hasTileEntity for you, the interface makes sure you're providing all of the necessary functions, etc.)

I had no idea, that's awesome.

It's called a for-loop. for(x -10 to 10) { for(y -10 to 10) { for(z -10 to 10) { BlockPos pos = new BlockPos(x,y,z) } } } Pseudocode, of course.

www.github.com

And oh yeah, the block's .json model file.

Need to see your main mod file, too.

Forge isn't going to insert the kinds of data you need. You're on your own here.

You need another folder in there.

public class BlockTable extends Block { *Cough* You might want to implement ITileEntityProvider or extend BlockContainer.

Enjoy looking into the abyss that is ASM.

ItemStack myItemStack = newItem.copy();

No idea what sth means. Anyway, the UUID only works for online servers. As I recently discovered. Entity IDs will work, only so long as you don't care about the value not being consistent (i.e. survive a save/load cycle).

BlockPos.x ?

Item.getItemFromBlock?