Boolean state not changing

[Branone]

I have encountered two problems, each of which only happen on their own when I attempt to fix the other. My object is an animating fan which is meant to get turned on and off by right-clicking it. The object has a boolean state which is false by default, and when right-clicked it is meant to become true.

 

Problem #1

When the boolean becomes true, it instantly turns back to false for some reason.

 

private boolean isOn = false;

@Override
	public IBlockState getActualState(IBlockState state, IBlockAccess world, BlockPos pos) { 
		actualState = state.withProperty(ON, this.isOn);
		return actualState;
	}

public boolean onBlockActivated(World worldIn, BlockPos pos, IBlockState state, EntityPlayer playerIn, EnumFacing side, float hitX, float hitY, float hitZ) {
		this.isOn = !isOn;
		getActualState(state, worldIn, pos);
		return true;
    }

 

I tried changing the isOn variable to just be set to true in the onBlockActivated method instead of using the !isOn logic, but then I get the other problem. 

 

Problem #2

Animation only works when I place the fan down after it has been turned on. The state changes to 'on' successfully when I right-click it, but the animation of the fan doesn't begin until I put down another fan.

[larsgerrits]

You can't store booleans inside the Block class, you need to store it in metadata/properties.

 

And what is actualState?  And why do you call getActualState in onBlockActivated?

[jeffryfisher]

Realize that there's only one block instance to represent all of the blocks of each block class everywhere in the world. In that respect, all class fields act sort of as if they were static, so those fields had better describe the whole class of blocks. For individual block variation, one must put data into the world. That's why we go through the contortions to use properties translated into and out of metadata (limited to 4-bits, the values 0..15) and tile entities. In essence, Minecraft hoists a feature of the object-oriented language up to its our code level to allow it to super-compress the long-term storage requirement of each block. Coding and storing millions of blocks "normally" would bust bandwidth, RAM, and maybe disks.

Edited February 14, 2017 by jeffryfisher