jeffryfisher

Why would a separate method be needed? Can't a structure include air blocks around and above its solid blocks?

Step through your code (and into calls) in the debugger. See if you notice recursion (if your structure spills into another chunk, then that chunk may generate another structure and so-on).

Have you considered using an array for "blockone" through " blockeightteen"? Either that or using more informative names? The numeric naming is malodorous.

Notice that the TNT block turns into an entity when activated, so you need to look up both the vanilla block and the vanilla entity. The entity does the count-down and exploding (and obeys gravity, much to the dismay of many a careless player who has activated TNT without a supporting block under it.

Usually, when a constructor is protected, it is not the only constructor. What else do you see?

Step through your generate method (and into the methods it calls) using the debugger to see what you are actually doing. Examine local variables to see which block (positions) are being changed to what.

You wrote "item", and I think you wanted "obsidianIngot". Sometimes when pasting from elsewhere, you need to replace identifiers from the origin context with names from your own context (i.e. Use your own variables instead of leaving the names from another program)

If your TE is being replaced when you don't want it replaced, then the logic in your shouldRefresh method is probably faulty (or not being reached, resulting in default behavior, which replaces the TE for every state change). Make sure you have overridden shouldRefresh, and make sure that its logic does replace the TE when it needs to be cleaned up (e.g. when the block class changes) but not when you want to keep your TE during a state change. Step through it in the debugger to watch it work.

Ha! My dark guess (bullet 'C') was right

A) You didn't share enough of the error log (I'm looking for any "caused by" or any "at" that references your code). B) You didn't tell us what you saw in the debugger when you stopped the program on the verge of the exception and examined this.world. C) Searching what I can see of your code, I can't see this.world being set, so I'll assume it isn't. That's your problem until you prove otherwise.

Have you looked at what line 654 is trying to do (I haven't, so I can't tell you). If you can't see how you (or your data) got there from your code, then you should rerun in the debugger. NB: The log also shows core mods. Forge sometimes doesn't play nice with other core mods. Can you first develop and debug your Forge mod apart from those core mods before trying to integrate with them? This would simplify many things (even if the error persists, the logs, warning messages etc will be more familiar to the regulars here).

Instead of a missing variant, I think you have a problem with model name or location. The error could be in JSON or file name or directory structure. Umm... I think models are assumed to be JSON files, so no file extensions in the blockstates file. Has that custom changed since 1.10.2?

That's not stepping using the debugger. You're telling us only the user experience. Set some break points and step through the code so you can see, line by line, what field of what object the itemstack is moving to when you "put it in inventory", and so you can see what field of what object the "wrong" itemstack is coming from when you "take it out" (and follow it all the way into your hand to see that it's not switched).

That block already exists in vanilla Minecraft. It's called "Iron Door". Servers also have a "peaceful" mode in which zombies don't even break wooden doors. You might look at how that's coded in vanilla.

What did you see when you stepped through these actions in the debugger? The data for " taken out of the inventory" should hit you in the face when watched in the debugger.

With each error, learn (and fix) as much as you can from researching general Java questions before coming back here when you get stuck on the peculiarities of Forge. Also learn the Eclipse tool (what it's telling you and what you can explore in it) by searching general Eclipse questions. Before you get here, you should already have walked through source code of all the vanilla classes you're extending and methods you're calling.

"How to do it" depends on other design criteria, such as needing data when chunks are not loaded, and how do chunks affect their neighbors. If each chunk is independent, and if its values are only needed when loaded, then things stay simple. Otherwise things get messy.

If you're dealing with a block type that has variants, then (in theory), each variant could have a different hardness. Therefore, if you want the hardness for a block in the world, you should use pos to fetch the block-state from the world (and if you want the hardness for a block that has already been broken from the world, then you need the prior blockstate from before it was broken).

If you now have more than one Forge setup, then look inside each of them to see if your copied run config is sending files to an old file tree.

markDirty is still around in 1.11.2? I thought we were supposed to change to some other method name about an update, or am I misremembering a different class?

Ya -- Pig is the mob equivalent of a zero somewhere (if you give yourself a mob-spawner block and just plop it in its default state, it will start to spawn pigs). Step through the code in the debugger. Start with the egg to see what Minecraft does when you use one.

Ouch, that's the kiss of death around here. The forum even tells us "... this is not a Java school. You are expected to have basic knowledge of Java before posting here. " Go learn Java (and programming in general, and find some Java references / help elsewhere online or in school or by recruiting a programmer friend ftf.

Then you need to read up on how to structure a mod. You should also search out mods that have full source code at github so you can see examples. For starters, you need a main mod class annotated with "@mod..."

While "type" shouldn't be static, it probably should be final.

Aha -- good disclaimer in a 1.10.2 context thread. @Nomnomab will need to be flexible.