Draco18s

Then basically you're doing things backwards. You're trying to learn an entire way of thinking without knowing either the language, the codebase, or the general principles. i.e. you named a method "makeTippedArrow" with the intent to override, but never actually overrode anything and didn't tell your IDE that that was your intent either, so when I asked about it you said "no no, that's actually a method in ItemArrow" which was pretty much false (I had already checked and supplied the actual method name), which meant that (at some point) you intentionally renamed the method, making the assumption (wrongly, due to your lack of OOP knowledge) that the change was meaningless and that because you didn't inform your IDE that it was supposed to override something (using @Override) your IDE couldn't spot the mistake. And the reason we ask that people have some background in programming already is so that we don't have to explain things like "that's not how that works" or that's all we'd be doing. You can go virtually anywhere else to learn Java already, this forum is not a place for it because there's already too many questions available about Minecraft and Forge specifically to handle the increased load of "I don't understand, what's X?"

You still don't have a section of code that causes you to break out of ALL the loops. You have one that breaks an inner loop and one that resets everything. Really you shouldn't make the block burrow all the way down to bedrock the moment its placed. It should do 1 block a tick, maximum, and spend energy for each one. Right now your code is basically set up to spend 100 energy mining an entire chunk (assuming it ever actually exists all the loops).

Do you have any OOP experience?

And this is why you use @Override

And never, ever stop. The method will never return. It will continue trying to do something and never do so, thereby never exiting your statement as far as I can tell.

makeTippedArrow() isn't overriding any method and you are not calling it yourself. Did you mean createArrow() ?

You're right, I missed that. Tablet makes it hard to see, sometimes. Ahh. I found your problem. What happens at y=0 when it can't break blocks?

Chunkx and chunkz aren't the blockpos coordinates of the chunk's 0,0 corner. You need to multiply by 16 to get those.

You need to use technical blocks.

Read the javadoc

What was actually happening (as the stalk property actually changes files) was that it was trying to find [flower_type] within [flower_type,item] due to my bungling of getModelResourceLocation() Thanks for the examples.

With difficulty. A lot of the Elytra's behavior is actually handled elsewhere, so you'd have to go find all references to the Elytra and duplicate that code (I think it's in EntityPlayer and you'd have to put your copy of that code in a player update tick event).

Look for existing usages in vanilla.

Are you registering your item as a colored item? Just because you declared and implemented that interface doesn't mean diddly: nothing calls getColor() .

Please show me how. { "forge_marker": 1, "defaults": { "textures": { "particle": "blocks/log_oak" }, "model": "harderores:axel", "uvlock": true }, "variants": { "normal": [{ }], "inventory": [{ "y": 0 }], "axel_orientation": { "none": { }, "gears": { "model": "harderores:frame" }, "hub": { }, "up": { "x": 270 } }, "facing": { "north": { "y": 0 }, "east": { "y": 90 }, "south": { "y": 180 }, "west": { "y": 270 } } } } Note how the state GEARS,NORTH results in a different model and a given rotation than NONE,WEST does. And it looks like I have the two-rotations you desire, but that's actually false, because UP doesn't pay attention to the facing (I cheated the state system a little: I was able to move the one additional direction I needed into the axel_orientation property rather than needing the extra bit for facing). Edit: You could also use a custom StateMapper to handle things too. Have two different models (one pre-rotated around the X axis) and on that property, load one model or the other, then the other property is free to modify the rotation. I do something like that myself: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/states/StateMapperFlowers.java

And why is this here? protected void arrowHit(EntityLivingBase living,RayTraceResult result) Seriously, use @Override and don't go dickering with things that you souldn't dicker with.

You can't have your cake and eat it too. In order to extend the spec it must add new sections.

Why is this here?

This is what looking at your class hierarchy is good for. protected void arrowHit(EntityLivingBase living)

That....half worked. The item model is 100% spot on, but the block model is broken. Edit: nope, it was me derping with my custom state mapper. The getModelResourceLocation() method was not 100% flexible. It only returned the resource location for a single property, rather than for all properties (except the one it was meant to "ignore"). I still have this though, but it shows up perfectly anyway: [19:06:56] [Client thread/WARN]: Unable to resolve texture due to upward reference: #cross in oreflowers:models/block/item/flower Blockstate: { "forge_marker": 1, "defaults": { "textures": { }, "model": "oreflowers:flower", "uvlock": true }, "variants": { "normal": [{ }], "inventory": [{ }], "flower_type": { "poorjoe": { "textures": { "cross": "oreflowers:items/poorjoe"} }, "horsetail": { "textures": { "cross": "oreflowers:items/horsetail"} }, "vallozia": { "textures": { "cross": "oreflowers:items/vallozia"} }, "flame_lily": { "textures": { "cross": "oreflowers:items/flame_lily"} }, "tansy": { "textures": { "cross": "oreflowers:items/tansy"} }, "hauman": { "textures": { "cross": "oreflowers:items/hauman"} }, "leadplant": { "textures": { "cross": "oreflowers:items/leadplant"} }, "red_amaranth": { "textures": { "cross": "oreflowers:items/red_amaranth"} } }, "item":{ "true":{ "model": "oreflowers:item/flower" }, "false":{} } } } Item model: { "parent": "item/generated", "textures": { "layer0": "#cross", "cross": "oreflowers:items/poorjoe" } }

Settings in Eclipse != Settings in Gradle.

Well of course they all animate. They all use the same model and all get rendered the same way, including keybind check. You make no attempt to distinguish which armor is currently being rendered.

Because you're wrong. Here's the same block using the Forge format: { "forge_marker": 1, "variants": { "normal": { "model": "coarse_dirt" } } } Magic! All those other lines are options. You can set up defaults and override them with variants (or not!). The "defaults:{}" block is actually a way to simplify the format, so rather than having to specify the same thing over and over again, you specify it once.

That is what he wants to avoid, aka the Vanilla Blockstate System. He wants something more like the latter because you can't do this: "connected_down=true": { "y":90 } "connected_east=true": { "x":90 }

/assets.forgecraft/ does not equal /assets/forgecraft/