1.16.5 - Setting block states for block with entity. Server vs. client confusion, probably.

[kitescandal]

Hi! New here, so hopefully this is the right place to ask. I'm having trouble finding resources that explain server-client communication with regards to block states, which I think is the problem I'm having. I'm trying to create a block that is temporarily turned into an entity and then back into a block. The block isn't meant to be immediately removed - the entity and the block should coexist for a small period of time, but there should only be one entity for a particular block. The problem I'm having is that the block doesn't recognize that it's already created an entity, and creates a large number in a row. I'm trying to use the "TRIGGERED" block state to prevent this from happening, but this doesn't seem to be the correct way of doing it, as the block state doesn't seem to get set on the server side and then gets reverted on the client side. (I think.) Here's the relevant code from the custom block class:

 

public static final BooleanProperty TRIGGERED = BlockStateProperties.TRIGGERED;

public FallingStone(AbstractBlock.Properties properties) {
	super(properties);
	this.registerDefaultState(this.stateDefinition.any().setValue(TRIGGERED, false));
}

protected void createBlockStateDefinition(StateContainer.Builder<Block, BlockState> builder) {
	builder.add(TRIGGERED);
}

public void entityInside(BlockState blockState, World world, BlockPos blockPos, Entity entity)
{
	if(blockState.getValue(TRIGGERED) == false)
	{
		world.setBlock(blockPos, blockState.setValue(TRIGGERED, true), 3); // Not sure what the 3 does, honestly. Some kind of flags?
		
		FallingStoneEntity fallingStoneEntity = new FallingStoneEntity(world,
				(double)blockPos.getX() + 0.5D, (double)blockPos.getY(), (double)blockPos.getZ() + 0.5D, blockState);
		world.addFreshEntity(fallingStoneEntity);
	}
}

 

Any help would be much appreciated. (Also, the name "FallingStone" is a misnomer... I know I could just extend FallingBlock to do that.)

[Draco18s]

Ok, so, this is really quite simple.

The client is a lying, cheating, bastard. Do nothing on the client that the server needs to know about. Only send user input actions (not results) to the server. The server controls all.

Block states are automatically communicated to the client when they change (unless the update flag says not to).

As for why there are two entities:
The same reason you have two java processes. One on the server (the server controls all) and one on the client (for how else would it be rendered?).

Edited February 5, 2022 by Draco18s

[kitescandal]

Oh, alright, that works a little differently than I'd imagined. That's very helpful!

I added a lot of logging and was able to figure out where the problem was... It turned out that entityInside() was properly setting the block state on the server. But there was an onPlace() function that I stupidly neglected to include in my post, which was getting triggered by setBlock() and immediately reverting the block state back. It didn't occur to me that setting the block state with setBlock() would trigger onPlace (which I didn't even need to begin with). Not very smart of me...

Thank you for your help!