Draco18s

If the container is already detecting any changes to slots and sending those changes to any client, why do my slots not update until I close and reopen the inventory?

1 word: Pathfinding. Vanilla barely supports blocks that have collision greater than 1 block tall (animals would routinely attempt to jump over fences back when they were introduced) as several subsystems all assumed that a block was either passable or not, so when fences were added, there were several problems to overcome. This is why a bounding box cannot exceed 1x1.5x1, anything you're doing that makes it appear larger is only working for a subset of all those systems. If you're making a "custom air block that registers as a full block so nothing can be placed there" then I have this to say: Because that's what you just described.

The code is executed on both sides. On the client side it's used to keep the GUI display accurate. Go ahead and try it, make a basic container, then in the "can be inserted" logic of the slot, pass the info off to the TE, then have the TE discriminate based on worldObj.isRemote. You'll see what I mean. When? Edit: Also, there's the issue of the player picking up an item that was not previously in their inventory after the gui was opened (any item stack dropped by another player or a dispenser/dropper/other item transport).

I'm doing crazy shit with a container, due to this crazy shit, I can only determine whether or not an item can be inserted into any given slot on the server. I cannot in any way perform this calculation on the client without doing massive, massive hacks to the way the client handles worlds or completely subverting the suggested solution to the earlier problem (TEs with null worlds). See this post for previous info. How the hell do I handle this?

Except that no, after mining a block you tell your code to reset: hasBrokenBlock = true; break start; //go back to the beginning and run all the loops again

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" } }