I'm attempting a custom bounding/collision box which obviously has to be different based on which direction the block is facing. Unfortunately the enumFacing in the block is dealt with through the tileEntity and 'getActualState' method. Which I think is the reason it always outputs 'north'. Any ideas how to fix/go around this besides moving facing to the block.

 

https://github.com/BeardlessBrady/Currency-Mod/blob/30d7853c28bb545448b09ac3a9b723c2064c11e4/src/main/java/gunn/modcurrency/common/blocks/BlockVendor.java

You can simply call getActualState yourself - the getBoundingBox method comes with all the parameters you need.

Right, I thought so too. If I call

EnumFacing facing = state.getActualState(source, pos).getValue(StateHandler.FACING);

in the 'getBoundingBox' method, I get a crash on block place

http://pastebin.com/6hfHwut2

 

Quote

 

java.lang.NullPointerException: Unexpected error

    at gunn.modcurrency.common.blocks.BlockVendor.getActualState(BlockVendor.java:281)

 

 

Yes, theres a nullPointer when it looks for a tile entity. I assumed this was because it gets the collision and bounding box before it places the tile entity, am I wrong?

Debug it and find out.

If that's the case, you're going to need to find a default value to supply.

Is there a way to set or reset the bounding/collision boxes after the block has been placed?

Basically When I rotate it there seems be about a 1 radius between the actual block and the rotation point. When I move the rotation point it just moves the block and the rotation point. I want to move the rotation point on that specific part of the block. Translating also isnt working

Yes! I fixed it, I just did

 

try {
    int face = ((ModTile) source.getTileEntity(pos)).getField(7);

    switch (face) {
        default:
        case 0: return BOUND_BOX_N;
        case 1: return BOUND_BOX_E;
        case 2: return BOUND_BOX_S;
        case 3: return BOUND_BOX_W;
    }
} catch (NullPointerException n) {
    return super.getBoundingBox(state, source, pos);
}

 

That way when it first calls a null exception it will ignore it, then once the tile exists it will fix

How about you check for null instead?

Try...catch is actually pretty CPU intensive.

I tried but apparently you cant check an int == null

I suppose Ill try casting it as an Integer since that can be null

Ya, I think it may be the only way. Even casting the int as an Integer still crashes from nullPointException. Is there a way to check if the tileEntity has be placed yet?

1 hour ago, BeardlessBrady said:

Yes! I fixed it, I just did

 

try {
    int face = ((ModTile) source.getTileEntity(pos)).getField(7);

    switch (face) {
        default:
        case 0: return BOUND_BOX_N;
        case 1: return BOUND_BOX_E;
        case 2: return BOUND_BOX_S;
        case 3: return BOUND_BOX_W;
    }
} catch (NullPointerException n) {
    return super.getBoundingBox(state, source, pos);
}

 

That way when it first calls a null exception it will ignore it, then once the tile exists it will fix

 

TileEntity#getField can't return null. World#getTileEntity is returning null.

 

This is why World#getTileEntity is annotated with @Nullable, you need to account for it returning null. Your IDE should warn you about calling a method on a @Nullable value without checking for null.

Edited February 14, 20178 yr by Choonster

Yes, I actually just got that working, but thanks for the insight!

10 hours ago, BeardlessBrady said:

I tried but apparently you cant check an int == null

What Choonster said.