Draco18s

Define "not working."

https://github.com/linkisheroic/minestuckarsenal/blob/master/src/main/java/com/natura/minestuckarsenal/item/MinestuckArsenalItems.java#L99-L100 You've made your registration event handler static. Because you are creating a new instance and registering that instance with the event bus, your method needs to be non-static.

Wrong. It should be Biome. Your advice is like saying "when you get a block, you want the variable to be Blocks." Biome is the object, Biomes is where the game holds a reference to each biome.

Don't do that. Register the block, if an ore exists during init, then make it show up in the world, be craftable, whatever. But always always register all blocks and items.

My ItemRawOre is not a block, it is an item. This is so my ores can be subject to Fortune enchantments (among others). 4 is Incorrect. I have one blockstate file. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/harderores/blockstates/orechunks.json Each ore block also has a blockstate file, but the ore items themselves only have 1. The two do not have a relationship with each other. You don't. Here is my block json: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/resources/assets/harderores/blockstates/ore_hardiron.json Here's where I register it: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/OresBase.java#L181 The easy registry is a mess because of the way I want to handle things in my main mod class (as a single function call). But here's a break down of what it does: 1) register and item the block with the game 2) get all valid states for the block and register an item model: https://github.com/Draco18s/ReasonableRealism/blob/1.11.2/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L46-L55 3) That involves calling ModelLoader.setCustomModelResourceLocation for each variant from the block's state: https://github.com/Draco18s/ReasonableRealism/blob/1.11.2/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L162-L169 My 1.12 code makes a hash of that process because it has to cache the object to register and then wait for the ModelRegistryEvent, but it still does just that: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L197-L199

1) You probably can't. For example, lets say I made a mod that I want to have wait for yours to finish, and then do stuff with what your mod does. Now my mod needs to load absolutely-last. 2) You shouldn't do whatever it is your doing when you're doing it. If you need something from another mode, wait until Init. Init is guaranteed to be after block and item registration.

Forge doesn't even maintain the Javadoc, that's all on the MCPBot side. This would be more accurate: http://files.minecraftforge.net/ The last build was 05:37 AM this morning (with a new recommended build that has no changes, 10 minutes later), and the previous build was on the 9th. MCP exports? Those happen daily.

String biome = world.getBiomeForCoordsBody(pos).getBiomeName(); And you do dick with this value. if(Biomes.DESERT != null) This will never be false.

You have to register your variant with the ModelLoader. For example, I have this: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L147 I have my code set up to take an arbitrary property as a variant, I get the metadata value and state information for each subblock, then register it: https://github.com/Draco18s/ReasonableRealism/blob/1.11.2/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java#L162-L169 (The 1.12 code I use is more complicated due to the ModelRegistryEvent nonsense, so I linked the simpler snippet from 1.11)

So, my question here is, "Why wouldn't it be supported in 1.12?" Anyway, take a search on these forums and see what you can dig up. It's come up in the past. No, because it would be out of date in less than a week. All the javadoc you need is in the code itself. And if there ISN'T javadoc on something that means there's NO javadoc at all for it. All the javadoc is handled via MCPBot, the same way human readable names for methods and field names are handled.

I didn't say to make your existing property a property on getActualState I said to use a series of booleans. As in, new properties. Like the Fence.

You don't needed extended states for this, just use getActualState and return whatever booleans you want as separate properties.

That is not "learning Java" that's "taking what you know and utilizing it."

If you can't test Hwyla in dev, create yourself a dummy item that when right-clicked on a block, will query the energy capability from side-null (as that is the side Hwyla uses). Then set a break point in your code and figure out what pathway it takes.

Oh no, the horror of having to use a + and concatenate a string!

No. tooltip.add(TextFormatting.LIGHT_PURPLE + I18n.format("tooltip:oreflowers:indicator"));

Wrong. Tooltip entries are not translated when displayed, you have to do it yourself.

Either use a TextComponentTranslation or translate using I18n.

In order to change the Minecraft code you need to run genpatches for those changes to be reflected. From Forge's git readme:

I probably picked it up from comments like these.

There is nothing wrong with your code. There is no change you can make in your code that will make this error go away.

at com.mraof.minestuck.item.block.ItemBlockLayered.<init>(ItemBlockLayered.java:24) at com.mraof.minestuck.item.MinestuckItems.registerItems(MinestuckItems.java:204) This isn't in the code you supplied. Your code is in com.natura.minestuckarsenal.item

The code you posted should never result in that effect.

Java is to Javascript as Car is to Carpet.

If you want to add buttons to the main menu, you either: a) don't need a GuiScreen because you're modifying an existing one b) are replacing one GuiScreen with another and have initGui