Draco18s

If you have this: Then why do you also have this:

Where do you call new Item()? You have to, somewhere. Maybe it's new Ruby() or whatever, but you MUST be calling new on a class that extends Item SOMEWHERE. If you do not have this line, then you are failing to follow the examples terribly. See this? https://github.com/Cadiboo/Example-Mod/blob/1.12.2/src/main/java/io/github/cadiboo/examplemod/EventSubscriber.java#L95

You set these to null here. So...you're referencing the static fields here. Which are null. Those references are still null. Still null. I don't see where you're actually creating these items. If you are going to use @ObjectHolder to fill them with values, you can't reference these during the RegistryEvent<Item> handler because object holders are not filled until after the registry event.

That is not what the EventSubscriber class does. If you have a problem with something being null (or any other error), you have to include the code and the log so that we can even begin to help you.

https://github.com/MinecraftForge/MinecraftForge/issues/5615

Block drops are handled by loot tables now. Also: This was never the correct way to do this, much less the correct way to drop items when the block is harvested.

Its not MVC (model-view-controller), its data-driven design.

Potions. And the method is called fillItemGroup.

This works for me: { "parent": "minecraft:block/cube_all", "textures": { "all": "minecraft:block/oak_planks" } }

Post your model file

Create 4 separate classes. Subitems are no longer a thing. https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#whats-the-deal-with-metadata

Its a Forge "bug" https://github.com/MinecraftForge/MinecraftForge/issues/5615 Currently you are required to have a concrete texture reference in your model file.

Good fucking luck. There's no way to make crops grow at regular, but slow, intervals. The best I was able to do was to intercept crop growth events, and check nearby crops, and if the neighbors were younger, give them the chance to grow instead.

Two chests next to each other? That's a model thing using neighboring blocks (see: Fences). Also chests are special and magic in terms of their model (because its animated).

You still have to convert from state to meta and back. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/farming/block/BlockTanner.java#L70-L78 (Note that the &1 will not be relevant for you, that is because that block only has 2 effective rotations).

That's not a multiblock structure (e.g. nether portal, snowman). That's just blocks interacting with their neighbors (e.g. hoppers).

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/farming/block/BlockTanner.java#L65-L68

I definitely get The Flattening in making blocks that are actually different blocks separate block instances, however, I have a block that uses a data value in a way that only sorta represents a "different" block. This isn't like "oak fence" vs. "birch fence" or "red wool" vs. "white wool," but that I have ores that have a density property. The higher the density, the more metal resource the block contains and the more that drops when the block is mined (the drops are items like lapis or redstone, not the literal block). The problem is that this property should be retained when mined with Silk Touch (the Edge Case) and I'm trying to figure out what the suggested method of handling this should be: Option 1) the density property is actually-different-blocks (the wool analog approach) Option 2) the density property is metadata when in the world, but drops different Item instances (hybrid approach) Option 3) the density property is left unflattened (uses ItemStack NBT data approach) Eg this is how it looks in the world with different density values (8 of 16 shown):

Your packet does not have a 0-parameter constructor. The game should vomit an error when your packet is sent.

Try hasSolidSide. If that doesn't work, go find the Torch and look for its placement validity check function.

You have to add the capability provider instance. The provider sort of "wraps" around the implementation in order to map the static Type to the nonstatic Instance. I'm honestly not sure how it works either. I'll see what I can do about finishing up my library updates for 1.13 and 1.14 Also, I got that class from Choonster, so: https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/1.13.2/src/main/java/choonster/testmod3/capability/CapabilityProviderSimple.java He also split the capability provider class into two, that one's not serializable, but SerializableCapabilityProvider is.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/capability/CapabilityMechanicalPower.java#L23

More like "mildly annoying." Packets really aren't that bad.

Don't use timer tasks. Use an event handler, subscribe to the world tick event, and count ticks.

Yeah, there might be a reason I mute your posts and typically don't look at them. You haven't posted all of your code, you say "there's an error there" but don't say what the error is, you don't know what SRG names are (that "a method with just a wired bunch of wired numbers"--also you misspelled "weird"--is a method that hasn't gotten a human-readable name from MCP yet).