[1.10.2] [UNSOLVED] Block EnumFacing crash

[jeffryfisher]

after looking more deeply into the code, it's not real recursion

 

Ahhh... I feel less crazy now. And, being non-recursive means we can worry less about designing properly re-entrant code. The error is elsewhere.

 

Can't imagine what could go so wrong with just checking all neighbour blocks (which get stored in the list) for side solid and getting there block state and block pos to do so.

 

I can. If you call a method on a block that is not yet (or no longer) in the world, and it assumes it can find its own state by looking at world and pos, then it can get into trouble (e.g. stairs trying to get a facing from a pos that is air in the world).

 

What do you mean by debugging method?

 

Add a method temporarily just to help with debugging. Detect block versus blockstate mismatches in several places, and have all detections call your temp helper method. Have that method write to the console, and put a breakpoint inside of it to stop the program and let you analyze what's causing the mismatch (and where).

 

 

[Bektor]

Add a method temporarily just to help with debugging. Detect block versus blockstate mismatches in several places, and have all detections call your temp helper method. Have that method write to the console, and put a breakpoint inside of it to stop the program and let you analyze what's causing the mismatch (and where).

Ah, ok.

 

So would this be correct? And how to find out from where the mismatch comes and what's causing it then? (never did such stuff before, so more or less lost, only did debugging before when npe's or arrayoutofboundsexceptions occur, so quite easy stuff (atleast it got never complicated in my tools))

    private void temp(BlockPos pos, IBlockState state) {
    	System.out.println("pos: " + pos.getX() + "," + pos.getY() + ","+ pos.getZ() + " || state: " + state);
    }

    @Override
    public boolean isHorizontalSupport(IBlockAccess worldIn, BlockPos pos, IBlockState state, EnumFacing facing) {
        BlockPos otherPos = pos.offset(facing); // go 1 in the negative direction from the facing
        IBlockState otherState = worldIn.getBlockState(otherPos);
        temp(otherPos, otherState);
        if(otherState.getBlock().isAir(otherState, worldIn, otherPos) 
                || !otherState.getBlock().isSideSolid(otherState, worldIn, otherPos, facing.getOpposite())) // check opposite direction
            return false;
        
        // Both blocks, the one in the facing direction and this one needs to have solid sides
        if(!state.getBlock().isSideSolid(otherState, worldIn, pos, facing))
            return false;
        
        return true;
    }

[jeffryfisher]

how to find out from where the mismatch comes and what's causing it then?

 

Look at the call stack when you hit the breakpoint in your temp method. In Eclipse, you could prowl around the call stack to inspect local variables in the involved methods to see what is happening in each. It should become obvious how a stair block ended up looking for its property at a pos that contains an air block in the world.

 

 

[Bektor]

Ok, I debugged now a bit, after I was the last few days ill, and it's kind of tricky to get something out of it:

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 511,5,-676 || state: minecraft:stone_brick_stairs[facing=east,half=top,shape=straight]

That's the last line the debugger could give me. It showed just something about BlockStone in the this field, I clicked next, and crash... and I think in the moment where I clicked next it gave me this line.

EDIT: Exactly what I thought: It shows this message:

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 509,2,-679 || state: minecraft:dirt[snowy=false,variant=dirt]

When you click then on "Resume" in eclipse it crashes... Just a ms before the crash log is posted it posts this message on the console, then the crash and then nothing.

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 511,5,-676 || state: minecraft:stone_brick_stairs[facing=east,half=top,shape=straight]

Even all variables in the variable field are gone then.

So I don't think that will bring me anyway further in fixing the problem.

[Draco18s]

You should try using Step Into rather than Step Over

[trollworkout]

I thought I saw something where you had

"facing=north,  someproperty=value".

with  a space right after comma. I exaggerated to emphasize. Not sure if I saw that correctly.

 

I'm pretty sure all properties need to be butted against one another

"property=value,property2=value2" and anything like "property = value" will not work properly.

 

 

Sometimes it may be something silly in json like you may be missing proper spaces or tabs etc. Since part of the modding is creating a resource pack for your mod.

 

[jeffryfisher]

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 511,5,-676 || state: minecraft:stone_brick_stairs[facing=east,half=top,shape=straight]

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)

 

 

[Bektor]

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 511,5,-676 || state: minecraft:stone_brick_stairs[facing=east,half=top,shape=straight]

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)

 

 

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 511,5,-676 || state: minecraft:stone_brick_stairs[facing=east,half=top,shape=straight]

The word core there is part of a package name. I just created a few packages called core, so that it's clear that all base classes are in there, for example in the blocks package is a core package and in it are all base classes for block which do some stuff so that in the actual block I don't have duplicated code.

 

The only thing I could think of is this line:

state = state.getBlock().getActualState(state, worldIn, pos);

But this is only called in the doCollapse method which is inside the block. And this method get's only called in the updateTick method. And because this is called in my block there is no way a stairs block can be in there.

And I can't see anything where something from the stairs block is called. There isn't even the world stairs in my code.

 

EDIT: With this conditional breakpoint

otherState == Blocks.STONE_BRICK_STAIRS.getBlockState();

in the temp method it directly crashes.

 

Last two lines of syso before crash:

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 509,2,-679 || state: primevalforest:stone[stone=andesite] || otherState: minecraft:dirt[snowy=false,variant=dirt]

[server thread/INFO] [sTDOUT]: [minecraftplaye.primevalforest.common.blocks.core.BlockCollapse:temp:190]: pos: 511,5,-676 || state: primevalforest:stone[stone=andesite] || otherState: minecraft:stone_brick_stairs[facing=east,half=top,shape=straight]

state

is the state which was given from updateTick to doCollapse where it was set with

getActualState

and

otherState

is the state which is the

scanState

in the

hasSupport

method.

 

While this is the crash log when using the conditional breakpoint;

 

[server thread/ERROR]: Encountered an unexpected exception
net.minecraft.util.ReportedException: Exception while ticking a block
at net.minecraft.server.MinecraftServer.updateTimeLightAndEntities(MinecraftServer.java:778) ~[MinecraftServer.class:?]
at net.minecraft.server.MinecraftServer.tick(MinecraftServer.java:687) ~[MinecraftServer.class:?]
at net.minecraft.server.integrated.IntegratedServer.tick(IntegratedServer.java:156) ~[integratedServer.class:?]
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:536) [MinecraftServer.class:?]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_102]
Caused by: java.lang.IllegalArgumentException: Cannot get property PropertyDirection{name=facing, clazz=class net.minecraft.util.EnumFacing, values=[north, south, west, east]} as it does not exist in BlockStateContainer{block=minecraft:air, properties=[]}
at net.minecraft.block.state.BlockStateContainer$StateImplementation.getValue(BlockStateContainer.java:196) ~[blockStateContainer$StateImplementation.class:?]
at net.minecraft.block.BlockStairs.getStairsShape(BlockStairs.java:470) ~[blockStairs.class:?]
at net.minecraft.block.BlockStairs.getActualState(BlockStairs.java:465) ~[blockStairs.class:?]
at net.minecraft.block.Block.isSideSolid(Block.java:1224) ~[block.class:?]
at minecraftplaye.primevalforest.common.blocks.core.BlockCollapse.hasSupport(BlockCollapse.java:141) ~[blockCollapse.class:?]
at minecraftplaye.primevalforest.common.blocks.core.BlockCollapse.doCollapse(BlockCollapse.java:59) ~[blockCollapse.class:?]
at minecraftplaye.primevalforest.common.blocks.core.BlockCollapse.updateTick(BlockCollapse.java:50) ~[blockCollapse.class:?]
at net.minecraft.world.WorldServer.tickUpdates(WorldServer.java:775) ~[WorldServer.class:?]
at net.minecraft.world.WorldServer.tick(WorldServer.java:226) ~[WorldServer.class:?]
at net.minecraft.server.MinecraftServer.updateTimeLightAndEntities(MinecraftServer.java:772) ~[MinecraftServer.class:?]
... 4 more

 

 

And that's what it looks like in the hasSupport method:

 

        while(toScan.peek() != null) {
            scanPos = (BlockPos) toScan.poll();
            scanState = worldIn.getBlockState(scanPos);
            scanned.add(scanPos);
            temp(scanPos, state, scanState);

 

[Draco18s]

The word core there is part of a package name. I just created a few packages called core, so that it's clear that all base classes are in there, for example in the blocks package is a core package and in it are all base classes for block which do some stuff so that in the actual block I don't have duplicated code.

 

You should rename that to "lib" or "library."

[jeffryfisher]

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.