Draco18s

The closest you can get is 3 consecutive rotations: "+x, +y, -x" (all rotations 90 degrees). The problem is I don't think the json supports two rotations on the same axis. This is, of course, assuming that all 6 sides are uniquely textured (e.g. a die) and that +z is uniquely different than all sequences of a single rotation on x, y, or both.

You don't have EnderIO's API/source/whatever available for the compiler.

You don't have EnderIO's API/source/whatever available for the compiler.

Or more generally: "Golly gee willackers, what happens if there are no players near it?"

Or more generally: "Golly gee willackers, what happens if there are no players near it?"

nameOfJarTask isn't supposed to be literal. Jesus, whatever was inside releaseJars already was supposed to stay there. "nameOfJarTask" was literally a "foo bar baz."

nameOfJarTask isn't supposed to be literal. Jesus, whatever was inside releaseJars already was supposed to stay there. "nameOfJarTask" was literally a "foo bar baz."

super() only handles the basic TE info. You need to call myStacks.writeToNBT() Or the capability.writeToNTB() I haven't poked 1.9 yet.

super() only handles the basic TE info. You need to call myStacks.writeToNBT() Or the capability.writeToNTB() I haven't poked 1.9 yet.

You never call registerRenderInfo

You never call registerRenderInfo

Line 81

Line 81

Your code: WRONG Correct code: @Instance(Strings.MODID) public static MainRegistry instance; //FORGE DOES IT FOR YOU As for the TE registration, what you have is (essentially) correct.

Your code: WRONG Correct code: @Instance(Strings.MODID) public static MainRegistry instance; //FORGE DOES IT FOR YOU As for the TE registration, what you have is (essentially) correct.

Option 2 is take this: #2: task releaseJars(type: Copy) { from nameOfJarTask //this already exists, do not touch } make it this: #2: task releaseJars(type: Copy) { from incrementBuildNumber from nameOfJarTask }

Option 2 is take this: #2: task releaseJars(type: Copy) { from nameOfJarTask //this already exists, do not touch } make it this: #2: task releaseJars(type: Copy) { from incrementBuildNumber from nameOfJarTask }

For compiling with gradle, just look at the gradle build file and put the jar where the build.gradle file says. For example, mine says: compile files('lib/AppleCore-mc1.7.10-1.1.0.jar') That means that in the folder 'lib' adjecent to build.gradle, have a file called 'AppleCore-mc1.7.10-1.1.0.jar' So put the deobf file you got into lib directory. (If the names don't match exactly, change the build.gradle file).

For compiling with gradle, just look at the gradle build file and put the jar where the build.gradle file says. For example, mine says: compile files('lib/AppleCore-mc1.7.10-1.1.0.jar') That means that in the folder 'lib' adjecent to build.gradle, have a file called 'AppleCore-mc1.7.10-1.1.0.jar' So put the deobf file you got into lib directory. (If the names don't match exactly, change the build.gradle file).

I believe Choonster means make it a field. public class TE extends TileEntity { ItemStackHandler myStacks; } I could be wrong though, but that's how I read it.

I believe Choonster means make it a field. public class TE extends TileEntity { ItemStackHandler myStacks; } I could be wrong though, but that's how I read it.

You could write some kind of "crop manager" class that would be able to use 1 class again. But the way you're doing things now will never work: one of the two will always be null when you run the constructor for the other.

You could write some kind of "crop manager" class that would be able to use 1 class again. But the way you're doing things now will never work: one of the two will always be null when you run the constructor for the other.

No.

No.