[Solved] [1.8] Block#setLightLevel not working

[LordMastodon]

So I've got this code:

 

@Override
public boolean onBlockActivated(World world, BlockPos pos, IBlockState state, EntityPlayer player, EnumFacing side, float hitX, float hitY, float hitZ) {
	if (!world.isRemote) {
		inLitUpMode = (Boolean) state.getValue(LIT_UP);

		if(!inLitUpMode) {
			this.setLightLevel(1.0F);
			world.setBlockState(pos, state.withProperty(LIT_UP, true));
		} else {
			this.setLightLevel(0.0F);
			world.setBlockState(pos, state.withProperty(LIT_UP, false));
		}
	}

	return true;
}

 

Which works perfectly fine as far as switching the IBlockState, but

this.setLightLevel

doesn't seem to be doing anything. The model changes, the texture changes, the F3 blockstate display changes, but it doesn't start emitting any light. I really don't want to switch to a two-block system like the furnace because this already works perfectly well, but if you know of any bug with changing the light level like that or something like that, please help. Thanks in advance!

[TheGreyGhost]

Hi

 

Here's an example furnace that works like that (single block instead of two like vanilla)

https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe31_inventory_furnace/Notes.txt

 

The key bits are-

in the TileEntity.update():

	// when the number of burning slots changes, we need to force the block to re-render, otherwise the change in
	//   state will not be visible.  Likewise, we need to force a lighting recalculation.
	// The block update (for renderer) is only required on client side, but the lighting is required on both, since
	//    the client needs it for rendering and the server needs it for crop growth etc
	int numberBurning = numberOfBurningFuelSlots();
	if (cachedNumberOfBurningSlots != numberBurning) {
		cachedNumberOfBurningSlots = numberBurning;
		if (worldObj.isRemote) {
			worldObj.markBlockForUpdate(pos);
		}
		worldObj.checkLightFor(EnumSkyBlock.BLOCK, pos);
	}

and in your block

  @Override
public int getLightValue(IBlockAccess world, BlockPos pos) {
	int lightValue = 0;
	IBlockState blockState = getActualState(getDefaultState(), world, pos);
	int burningSides = (Integer)blockState.getValue(BURNING_SIDES_COUNT);

   	if (burningSides == 0) {
		lightValue = 0;
	} else {
		// linearly interpolate the light value depending on how many slots are burning
		lightValue = ONE_SIDE_LIGHT_VALUE + (int)((FOUR_SIDE_LIGHT_VALUE - ONE_SIDE_LIGHT_VALUE) / (4.0 - 1.0) * burningSides);
	}
	lightValue = MathHelper.clamp_int(lightValue, 0, FOUR_SIDE_LIGHT_VALUE);
	return lightValue;
}

 

-TGG

[ItsAMysteriousYT]

Use setBlockBounds(minX, minY, minZ,maxX,maxY,maxZ)

[LordMastodon]

 

If I do this:

 

if(!inLitUpMode) {
    world.setBlockState(pos, state.withProperty(LIT_UP, true));

    this.setBlockBounds(0.0F, 0.0F, 0.0F, 16.0F, 16.0F, 16.0F);
} else {
    world.setBlockState(pos, state.withProperty(LIT_UP, false));

    this.setBlockBounds(5.0F, 0.0F, 5.0F, 11.0F, 2.0F, 11.0F);
}

 

Than the small block's bounds are the size of a normal block and the full block's bounds are hugely massive. Any idea how that's supposed to work?

[Choonster]

Block bounds are on a scale of 0 to 1. A full block is length 1 on each side.

[Choonster]

Instead of setting the block bounds directly, you should override

Block#setBlockBoundsBasedOnState

and set the bounds there.

Block

is a singleton, so calling

Block#setBlockBounds

modifies the bounds for all occurrences of the block.

setBlockBoundsBasedOnState

should be called before the bounds are queried.

[LordMastodon]

So I'm now using this:

 

this.setBlockBounds(0.315F, 0.005F, 0.315F, 0.685F, 0.125F, 0.685F);

 

Which seems like abhorrent practice to me, due to the exact nature of the numbers, but whatever. That yields this:

 

 

But the bounds look sort of glitchy.

 

Side note: the minY is 0.005F instead of 0.0 because if I left it as 0.0 the bottom would disappear under the ground.

 

EDIT 1

 

Switching to

Block#setBlockBoundsBasedOnState

worked fine, but the bounds still looks sort of odd.