Draco18s

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?

float renderPosX; float renderPosZ; for(int i=0; i<4; i++) { renderPosX = i/2; /* 0 / 2 = 0, 1 / 1 = 0, etc. */ renderPosZ = i%2; /* 0 % 2 = 0, 1 % 2 = 1, etc. */ /*the multiply by some fraction, add in the block's world coordinates*/ /*finally, call the renderer*/ }

Right click -> Source -> Correct Indentation (its magic).

I don't think you understand what your code is doing.

I just realized that 1.8 effectively killed the "Camouflage Block." That is: because the texture code moved into the json file, it is impossible to use a different, arbitrary, block's texture. Or at the very least, it made is incredibly more difficult.

It might help if you registered your event handler class with the event bus, rather than the FMLPreInitializationEvent.