Draco18s

What? This is literally nonsense. "Two instances of the class" and "two threads" are completely and utterly different concepts.

Your folder name is ítems it should be items.

There's also a SIDE parameter. CLIENT and SERVER. You need to pick one.

You're storing all that data in your TE somewhere, right? Grab that data from inside your TESR render call, and build a series of quads for each "bit"

Calculate your data, then render your calculations.

This is disgusting. Do not do this. JSON is a serialization format, you are dealing with runtime data, use runtime storage techniques. Don't serialize the data, then deserialize it back into memory, that's fucking retarded. On top of that, you're trying to make one JSON file handled an arbitrary number of different model results by overwriting the file every time you need to render. This is a massive fucking mess.

Well you're trying to get/set a FACING property, but your block does not declare a FACING property in its BlockStateContainer (this is what the error is saying, at least...along with the block being null, what the hell?). Looking over your code... Your BlockEnum class declares how to handle the creation of the BlockStateContainer for the enum via the realStateContainer field, but your BlockMenhir class gives no fucks about this field and declares its own BlockStateContainer as only having a FACING property. You've done something terrifyingly wrong, and I can't quite figure out what.

Wait what? You want to render a JSON model, but that that JSON model changes during runtime, so you don't want the IBakedModel created from that JSON file. Why the hell is that JSON model dynamic?

Some mod-based examples: https://github.com/Draco18s/ReasonableRealism/tree/1.12.1/src/main/resources/assets/harderores/advancements

Fair enough. I was hesitant in my assessment as I had to scratch my head over what the possible pros and cons were. I suppose, "It's....not? great?" might've better expressed that. *Shrug* Thanks for the reading material, though.

My point was it won't crash. Whether or not it's a good idea or bad idea to create an empty array (vs. using the zero parameter version vs. creating the array yourself) I don't know what's best. All I was countering was the comment that "oh, there's your problem, you're creating an empty array!" No, no that is not your problem.

This is what pushMatrix and popMatrix do. GLStateManager.pushMatrix(); GlStateManager.rotate(angle, 1, 1, 1); //Rotating everything renderBody(te, x, y, z, partialTicks, destroyStage); //render the thing GLStateManager.popMatrix(); //undo to the last pushMatrix

No, that is correct.

You call this from common code: This calls: This calls which is a class located at Oops, that's client side only. Server has crashed.

And where do you call this code from?

What?

No modder, bad cookie. It should be done in the main mod class. The concept of a "common proxy" does not make sense. The whole point of @SidedProxy is to abstract over client specific and server specific behavior, the opposite of "common". Common code should go in your main mod class.

https://docs.oracle.com/javase/7/docs/api/java/util/List.html toArray(new Item[0]) is fine. It's...not great, but it won't fail.

You need to think about this in a single-threaded fashion. You want the game to do other stuff while you keep the mouse button held down which means you need to not use an infinite loop.

while(gs.keyBindAttack.isKeyDown()) { Congrats, the game is now frozen until you let go.

Yes you can. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/util/AdvancementUtils.java#L79

Yes, I agree. But even so I still see people doing this wrong. Like I said, I've seen people pass their item reference to their block (heck I once saw someone do both: item ref to the block and the block ref to the item!). Literally every time I see a thread with the word "crop" or "seeds" in the title I know what the problem is, and it's this problem. The registry events have (somehow) not made this common issue go away.

This issue is only ever a problem "when someone is creating crops" (90%+). Usually it's someone passing an item to a block constructor, but only about 60-40. I'd write it as... "Do not pass items to block constructors, if passing blocks to items, insure blocks are initialized first. This is a very common issue when making crops and seeds. Use the debugger to verify your references are not null." Or "When passing block and item references to constructors, insure correct order of operations. Use the debugger to verify your references are not null. Blocks should be initialized before items."

@diesieben07 We should have this problem in the common problems list. I vaguely recall trying to ping you about it before.