Draco18s

Thought XCW'd updated that recently. Maybe not.

Use this: https://mods.curse.com/mc-mods/minecraft/230541-lookingglass The api to handle the rendering is already built, it's amazing, it works across dimensions...you aren't going to get any better than that.

No no no, not-user-friendly is Blender. It took me 2 hours to move a camera and change the animation speed on an already complete scene. I lost track of the number of times I had to quit and start over.

IntelliJ isn't the only program that does it, I've run into a few others. But every time it's "undo, undo, undo...ok redo...fuck, why did that just delete a line? Oh, stupid keybinds. FINE, I GUESS I'LL RETYPE IT." I don't mind ctrl-shift-z being redo and not ctrl-y, it's the binding something destructive to ctrl-y that irks me. Yeah, just completely fuck with someone who's never used your software before so they can't fix the mistake because they didn't know what your keybinds were, that's just brilliant.

I totally understand the ctrl-z / ctrl-shift-z paradigm, but I hate it due to muscle memory for literally everything else I use having defaults of ctrl-z / ctrl-y

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.