jeffryfisher

As a matter of style, I would replace that sequence of if statements with a simple switch, or even a reference to a static array.

It looks as if you have multiple core mods. Forge does not work well with some core mods, and you'll have trouble finding help here sorting out the conflicts. If you are coding a mod, please create a separate test world in which it is the only mod, and then show us the crash.

Also, I think you should replace "builtin/" with "item/" when referring to items in json.

You have two sets of wall types at the bottom of the blockstates file. Are they doing the same thing? What's the difference between writing "raw" versus writing "type=raw"? Do both sets need to be there, or could they be consolidated? It looks as if you might have solved the inventory texturing inside the blockstates file, but I'm unsure.

So for instance, if the block inside of the state is your block (not guaranteed, even if the method is being called on your block!) then you can decide whether the dragon/wither can or can't destroy it. All other blocks should be handed off to super.

My custom walls are working now. I had item model files left over from mc 1.8, so I gave up trying to teach the blockstates json to do inventory. Here's one of my blockstates files that handles blocks only: { "forge_marker": 1, "variants": { "up" : { "true" : {"submodel": {"wall_up" : {"model": "wall_post" }}}, "false" : {} }, "north" : { "true" : {"submodel": {"wall_north" : {"model": "wall_side", "uvlock": true }}}, "false" : {} }, "east" : { "true" : {"submodel": {"wall_east" : {"model": "wall_side", "uvlock": true, "y": 90 }}}, "false" : {} }, "south" : { "true" : {"submodel": {"wall_south" : {"model": "wall_side", "uvlock": true, "y": 180 }}}, "false" : {} }, "west" : { "true" : {"submodel": {"wall_west" : {"model": "wall_side", "uvlock": true, "y": 270 }}}, "false" : {} }, "skin" : { "0": { "textures": { "wall": "blocks/stonebrick" }}, "1": { "textures": { "wall": "blocks/stonebrick_mossy" }}, "2": { "textures": { "wall": "blocks/stonebrick_cracked" }}, "3": { "textures": { "wall": "blocks/stonebrick_carved" }}, "4": { "textures": { "wall": "blocks/brick" }}, "5": { "textures": { "wall": "blocks/hardened_clay" }}, "6": { "textures": { "wall": "blocks/netherrack" }}, "7": { "textures": { "wall": "blocks/quartz_block_chiseled" }}, "8": { "textures": { "wall": "blocks/obsidian" }}, "9": { "textures": { "wall": "blocks/sandstone_normal" }}, "10": { "textures": { "wall": "blocks/sandstone_carved" }}, "11": { "textures": { "wall": "blocks/stone" }}, "12": { "textures": { "wall": "blocks/stone_granite_smooth" }}, "13": { "textures": { "wall": "blocks/stone_diorite_smooth" }}, "14": { "textures": { "wall": "blocks/stone_andesite_smooth" }}, "15": { "textures": { "wall": "blocks/end_stone" }} } } }

I think that when you use item/generated, you can get rid of all of the display: section (third- and firstperson stuff).

I tried continuing the multipart: { "variants": { "multipart": [ { "when": { "up": "true" }, "apply": { "model": "wall_post" } }, { "when": { "north": "true" }, "apply": { "model": "wall_side", "uvlock": true } }, { "when": { "east": "true" }, "apply": { "model": "wall_side", "y": 90, "uvlock": true } }, { "when": { "south": "true" }, "apply": { "model": "wall_side", "y": 180, "uvlock": true } }, { "when": { "west": "true" }, "apply": { "model": "wall_side", "y": 270, "uvlock": true } }, { "when": { "skin": "0" }, "apply": { "textures": {"wall": "minecraft:blocks/cobblestone"} } }, { "when": { "skin": "1" }, "apply": { "textures": {"wall": "minecraft:blocks/cobblestone_mossy"} } }, { "when": { "skin": "2" }, "apply": { "textures": {"wall": "minecraft:blocks/hay_block_side"} } }, { "when": { "skin": "3" }, "apply": { "textures": {"wall": "minecraft:blocks/prismarine_dark"} } }, { "when": { "skin": "4" }, "apply": { "textures": {"wall": "minecraft:blocks/prismarine_bricks"} } }, { "when": { "skin": "5" }, "apply": { "textures": {"wall": "minecraft:blocks/lapis_block"} } }, { "when": { "skin": "6" }, "apply": { "textures": {"wall": "minecraft:blocks/quartz_ore"} } }, { "when": { "skin": "7" }, "apply": { "textures": {"wall": "minecraft:blocks/quartz_block_lines"} } }, { "when": { "skin": "8" }, "apply": { "textures": {"wall": "minecraft:blocks/iron_block"} } }, { "when": { "skin": "9" }, "apply": { "textures": {"wall": "minecraft:blocks/red_sandstone_normal"} } }, { "when": { "skin": "10" }, "apply": { "textures": {"wall": "minecraft:blocks/red_sandstone_carved"} } }, { "when": { "skin": "11" }, "apply": { "textures": {"wall": "minecraft:blocks/glass"} } }, { "when": { "skin": "12" }, "apply": { "textures": {"wall": "minecraft:blocks/glowstone"} } }, { "when": { "skin": "13" }, "apply": { "textures": {"wall": "minecraft:blocks/sea_lantern"} } }, { "when": { "skin": "14" }, "apply": { "textures": {"wall": "minecraft:blocks/diamond_block"} } }, { "when": { "skin": "15" }, "apply": { "textures": {"wall": "minecraft:blocks/emerald_block"} } } ] } } But I still get only a huge number of MissingVariantException. It's as if the multipart is completely ignored. I checked it with json lint, so syntax is okay. Is there an explanation of multipart out there somewhere? Or, is it the wrong tool to use when separating tesxture assignment from model assignment? PS: If my problem is really different from the OP, let me know so I can start a separate thread.

It's an amazing coincidence that I am also running into a json issue with custom walls today. Maybe we can converge on a solution that works for both of our mods. I took a different approach to the blockstates file, attempting to separate the texture from the other properties in an advanced Forge blockstate file and then copy the multipart json from vanilla. Unfortunately, I get a slew of MissingVariantException, so either I wrote it wrong, or it's not possible to do what I have attempted. What do you think of this blockstates file (is it salvageable?): { "forge_marker": 1, "variants": { "multipart": [ { "when": { "up": "true" }, "apply": { "model": "wall_post" } }, { "when": { "north": "true" }, "apply": { "model": "wall_side", "uvlock": true } }, { "when": { "east": "true" }, "apply": { "model": "wall_side", "y": 90, "uvlock": true } }, { "when": { "south": "true" }, "apply": { "model": "wall_side", "y": 180, "uvlock": true } }, { "when": { "west": "true" }, "apply": { "model": "wall_side", "y": 270, "uvlock": true } } ], "skin": { "0": { "textures": { "wall": "minecraft:blocks/cobblestone" }}, "1": { "textures": { "wall": "minecraft:blocks/cobblestone_mossy" }}, "2": { "textures": { "wall": "minecraft:blocks/hay_block_side" }}, "3": { "textures": { "wall": "minecraft:blocks/prismarine_dark" }}, "4": { "textures": { "wall": "minecraft:blocks/prismarine_bricks" }}, "5": { "textures": { "wall": "minecraft:blocks/lapis_block" }}, "6": { "textures": { "wall": "minecraft:blocks/quartz_ore" }}, "7": { "textures": { "wall": "minecraft:blocks/quartz_block_lines" }}, "8": { "textures": { "wall": "minecraft:blocks/iron_block" }}, "9": { "textures": { "wall": "minecraft:blocks/red_sandstone_normal" }}, "10": { "textures": { "wall": "minecraft:blocks/red_sandstone_carved" }}, "11": { "textures": { "wall": "minecraft:blocks/glass" }}, "12": { "textures": { "wall": "minecraft:blocks/glowstone" }}, "13": { "textures": { "wall": "minecraft:blocks/sea_lantern" }}, "14": { "textures": { "wall": "minecraft:blocks/diamond_block" }}, "15": { "textures": { "wall": "minecraft:blocks/emerald_block" }} } } } Maybe I need to continue the multipart to "apply" each of the skins? would such a solution work for your custom walls also?

If you have any more crashes, don't even mention them when asking for help unless you include the crash log (bracketed by spoiler or code tags).

I think it means that the prefix does not match your mod name. BTW, your mod name should be all lower case (can't check your code at github today because of the DDoS attack).

It's time to get into the debugger with a break at the line where you're detecting that the enchantment has been placed. Then step through/into to see what happens to that stack.

I think your block needs to override the createState method associate itself with those two properties.

switch (world.provider.getDimension()) { case 0: //Overworld In 1.10, the getDimension() method no longer returns -1, 0 1. It now returns an enum. I don't even use it. My example: if (w.provider instanceof WorldProviderHell) { ... You should identify the world provider classes or else switch the enum values.

So you want your item to remain in the crafting grid after you've used it as an ingredient? Look at how a bucket of milk becomes an empty bucket in the cake recipe in vanilla mc.

1) I don't think you need your own class just to add a recipe. That said, your recipe fails because your class is not instantiated and its methods are not called anywhere (as far as I can see). 2) If any of those methods is meant to override an inherited method, then it should be annotated with @Override. This will alert you to any mismatches, visibility barriers etc. This will become even more valuable when your upgrade to a new mc forge version where inherited methods change beneath your feet. 3) It would be nice if you indented your code. It would also be more readable if you bracketed it with "code" tags. I suggest that you edit msg 1.

And see the tutorials section of this site to get started.

If items/blocks are not registered, then all memory of them in a world will be erased whenever and wherever their chunks are loaded. Players who've worked hard for rare items/materials will be irate. Even worse, the block IDs in a world could be scrambled so that chaotic substitutions appear. If you want some kind of automatic update, you need to design it so that absence of a DB connection leads to running with the last known good download.

Now I see 3 different blocks. In your output we see stone versus stone-brick-stairs. In the crash report we see air. Clearly there is some disagreement about what block is at pos. Somewhere in your code, you've made a wrong assumption (or you've invalidated a vanilla code assumption) about whether a variable represents the world as it is. Figure out exactly which variable is providing each of those three blocks. Stop trying to use the wrong one(s) at the wrong time. I suspect the timing of the collapse. While inside a block's method, blocks in the world are being replaced. At some point, the method tries to getActualState, but the call is no longer valid because the block's properties aren't there. Stepping through the scan in the debugger should make it blindingly obvious how the timing of the block changes is causing the mismatch. Unfortunately, I can't step the debugger for you. You need to persevere until you reach that face-palm moment.

So... Which value there was null? You did hover over each, right? When you have located the null element, then you should be able to see where you forgot to set it.

The way the method is commented, and because it is not called by any vanilla code, rotateBlock method in class Block looks like a Forge addition that we can improve. It employs state.cycleProperty. Unfortunately, that method goes through compass directions in haphazard (maybe alphabetical?) order, not in a circle. Because it has an EnumFacing passed to it (indicating axis), I suggest that rotateBlock should call EnumFacing.rotateAround instead. I searched for prior mentions of this issue and didn't see any; I apologize if I didn't look hard enough.

That's the last line the debugger could give me. When you get back to the precipice of the crash, examine the values of all of the objects involved in the offending statement. Figure out how it became possible for a stairs method to be called from inside a stone block. Then fix your logic so that doesn't happen. BTW, You might be able to make the approach less tedious by learning about conditional break points (test for block == stone brick stairs). Draco's suggestion to "step into" (if possible) is another precious debugging tool. PS: Why does the word "core" appear in your console output? Around here, "core" implies "core mod". Forge doesn't play nice with core mods, and threads asking for help with core mods don't fare well in this forum. Just to avoid the 7's itchy trigger finger, you might want to revise the naming of your package structure to avoid the word "core". (And if this really is a core mod, then we're done here)

So when you set a breakpoint at ItemSeeds.java:52 and re-ran in the debugger, what did you find? What's null there, and how could you make it not null before reaching that point?

Don't panic. There are several stages to debugging. After running in Eclipse (or other IDE), you run SP in your local MC (Forge) client. After that, you should try MP between client and dedicated server. At each new stage, things can go wrong there that don't show up earlier. So put on your thinking cap and gather more info. In particular, find the log file (not console output) from your test run. The log will have more warnings than you'll see on the console. The first question is: Did you perfectly match capitalization where it needs to be matched, and did you use all lower case where it must be all lower case? Reason I ask: Running in an IDE in Windows means using a filesystem that is NOT case sensitive. Running a jar in SP means accessing "files" inside a jar that IS case sensitive. Mixed-case errors hidden earlier then appear. The log should show warnings. And again: Don't Panic.

Solved: In the sounds.json file in 1.8, each sound name was automatically prefixed with my domain. In 1.10.2, I need to explicitly include the domain in each name. Adding domains gave me my sounds. New sounds.json file: { "fanPwrUp": {"category": "master","sounds": [{"name": "jrfinventions:fanPwrUp", "stream": false}]}, "fanWhirr": {"category": "master","sounds": [{"name": "jrfinventions:fanWhirr", "stream": false}]}, "fanChoke": {"category": "master","sounds": [{"name": "jrfinventions:fanChoke", "stream": false}]}, "fanPwrDn": {"category": "master","sounds": [{"name": "jrfinventions:fanPwrDn", "stream": false}]} }