Draco18s

I have no idea if one already exists. Try google.

TL;DR: I don't think you'll ever get this to work. Last I poked around with something similar, the newly spawned water block (the one you have that won't flow) updates, detects it doesn't have a neighbor that is itself, but with a higher amount of liquid, and so it sets itself to air.

Attempt to get an item. If it doesn't exist: do nothing

return blockasphodelplant$enumplanttype == BlockTwoPlant.EnumPlantType.ASPHODELPLANT ? Items.AIR "If the current block's plant type is Asphodel, then return air."

What would happen if you input a block that has no item form (say, a piston head)?

You were creating a standard ItemBlock rather than your custom ItemBlock subclass.

onBlockAdded -> schedule update -> replace self

You know that the tickRate method is called by dick and jack, right? It's completely unused by the outside world. The only thing that calls it is a block itself to call scheduleUpdate() with. The only non-block that references this function is the CommandBlock (to scheduleUpdates on spawned blocks) and BlockFluidFinite to determine how quickly its subclasses should flow (oh wait, its in the Block hierarchy). Even within the Block hierarchy it goes virtually unused! BlockStair only uses it to pass off the call to the block that the stairs are made out of (so, basically nothing) as well as the Tripwire and TripwireHook (which actually do use it, again to scheduleUpdates ). Seriously, put 9999999 in there and tell me if it makes any difference what so ever.

(Which is a "manually overriding each recipe" type solution)

Vanilla might (and probably does) use a custom IStateMapper object to strip some properties from needing to be present in the json file. "It throws an error" is a far cry from "its not needed." If it throws an error either its needed or you did something wrong. Take a look at http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/#forges-blockstates

Where do you actually register your blocks and items? I can't find it in your repo. Found it. https://github.com/saxon564/MoChickens/blob/master/src/main/java/com/saxon564/mochickens/registers/RegisterItems.java#L36 Take a REALLY GOOD LOOK at that line. Tell me where, exactly, you're using ItemFeatherBlock

This is your actual error. Something your Zirconium wand is doing is passing a null item stack (or an ItemStack of null) to ItemHandlerHelper.

Your block has 3 properties: Horizontal Facing (4 values) HALF (2 values) PlantType (1 value) All of this is encodable in 4 bits (you have 8 possible variations: 4 * 2 * 1) Looking at your getMetaFromState method, if the top half of the block is set, the metadata is (8 + Facing). Otherwise it's (plant type). However if we look at your getStateFromMeta method, we check if the metadata is >= 8, if it is, set HALF to true. Otherwise we decompose the other three bits into a Plant Type. These two methods are not inverse of each other. Your getStateFromMeta discards the FACING property entirely. THEN, ON TOP OF THAT, your json file ignores both the plant type and facing value: { "variants": { "half=lower": { "model": "modmt:block/asphodelplant_bottom" }, "half=upper": { "model": "modmt:block/asphodelplant_top" } } } Those are not your only two variants! What about "facing=north,half=upper,variant=asphodelplant"?

There's a pack.mcmeta setting that can force things back to v2 instead of v3. Ignore that for now, you have a file that works, its just the one block that's messed up. Best bet is to take what's shown in the game (what you see that's wrong) and put that into your lang file.

The colon isn't the problem, this is: https://github.com/saxon564/MoChickens/tree/master/src/main/resources/assets/mochickens/lang Your lang file is improperly named. Starting with 1.11, all resources must be all lower case. That is, en_us.lang, not en_US.lang.

This not a full crashlog, this is merely the bit that says "the game crashed." Below it (possibly a ways) will be a description of what occurred.

The error occurs during startup. It has no impact during play.

No.

No.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/OreEventHandler.java#L39 If you remove the recipe, the advancement fails to deserialize, you don't get a chance to remove it.

You have to cast the registry during the Register<IRecipe> event to IForgeRegistryModifiable. Note that straight removing the recipe will cause an error during advancement loading, as the advancement that unlocks the removed recipe will fail to deserialize.

Converting from one form of storage to another* is generally pretty easy. The thing is, you need to essentially uncompress the data from the one format and recompress it into the other format. This doesn't mean that you need to read the data into the world (afterall, the world is just a runtime representation of the data) you just need to put it somewhere. *Assuming that both formats represent the same runtime information, which in this case, they do. You can't convert from mp4 to epub because the information represented by each is completely different.

You have 4 bits of information to work with. You have an ore type enum that contains two values (and inexplicably starts at 1 instead of 0) and a dimension enum that contains 3 values (again, starting with 1 instead of 0). Two times three is six, which means there's enough bits to store the data in metadata. Your type enum can be contained within 1 bit (0 / 1) and the dimension needs two (00 / 01 / 10). Now you just need some bitwise math.

public void onEntityWalk(World worldIn, BlockPos pos, Entity entityIn) { this.modelBlock.onEntityWalk(worldIn, pos, entityIn); } The method just forwards the interaction to the base block (e.g. if you were to make Redstone Ore stairs, this would cause the block to switch from not-glowing to glowing...assuming of course that the Redstone Ore class knows how to handle the block at the given pos not being redstone ore).