[1.12.2] setBlockToAir(BlockPos) not registering on Client side

[Kekz 1]

I am trying to remove some blocks I placed with

worldIn.setBlockState(new BlockPos(pos.getX() + j, pos.getY() + 1, pos.getZ() + i), Blocks.BEDROCK.getDefaultState());

by using

worldIn.setBlockToAir(new BlockPos(px + j, py + 4, pz + i));

Both the building and removing processes happen in my onItemUse() method of my 2 custom items.

In MazeGenerator.java blocks are placed in the onItemUse() method, and in MazeScapeKey.java they are removed in onItemUse().

The removing process itself happens in a method in MazeGenerator.java

 

This rarely works, as only some of the blocks are removed, while other blocks are still there, but disappear as soon as i right click on them.

Sometimes all the blocks are removed correctly, sometimes only a few.

 

I have tried using worldIn.markBlockRangeForRenderUpdate() after setting all the blocks to air, but that doesn't seem to help.

 

What am I doing wrong? As far as I understand, this behaviour means that the Server has succesfully removed the blocks, but the Client is still rendering them.

How can I ensure that the Client realizes that those blocks are no longer there?

 

My whole code

 

I am grateful for any help,

Edited October 10, 2019 by Kekz
Added minecraft version in title

[diesieben07 6775]

• Why on earth are you using state IDs to compare blocks? Just compare the IBlockState.
• You cannot store data like this in the Item class. There is only one instance of your Item class. If you want to store additional data, it needs to be stored in the ItemStack, either using NBT or capabilities.
  Even worse, in your case you are accessing these fields from both client server without any synchronization. This will lead to strange and hard to diagnose bugs, because your code will execute on both server and client thread.
  Same here.
• Currently you are calling clearLabyrinth on client and server. Blocks must only be modified on the server.

[Kekz 1]

6 minutes ago, diesieben07 said:

• Why on earth are you using state IDs to compare blocks? Just compare the IBlockState.

Ok, thanks for the feedback I'll change that.

 

6 minutes ago, diesieben07 said:

• Currently you are calling clearLabyrinth on client and server. Blocks must only be modified on the server.

Does this mean that I should also call buildLabyrinth only on the server side? because that method is not causing any problems

 

10 minutes ago, diesieben07 said:

• You cannot store data like this in the Item class. There is only one instance of your Item class. If you want to store additional data, it needs to be stored in the ItemStack, either using NBT or capabilities.
• Even worse, in your case you are accessing these fields from both client server without any synchronization. This will lead to strange and hard to diagnose bugs, because your code will execute on both server and client thread.
  Same here.

Thanks I'll look into that

[diesieben07 6775]

1 minute ago, Kekz said:

Does this mean that I should also call buildLabyrinth only on the server side? because that method is not causing any problems

Yes, you need to only place blocks on the server.

[Kekz 1]

I'm sorry, but how can I make sure that I only execute buildLabyrinth and clearLabyrinth on the server side?

I tried putting

if (!worldIn.isRemote) {
	// do building / removing
}

around the whole process in both methods, but that doesn't seem to work.

Building the maze doesn't work too now and clearing it still doesn't clear all blocks correctly as before.

[diesieben07 6775]

Yes, that's how you would usually do it, provided you are in a method which is actually called on both sides.

 

However you first need to fix this:

1 hour ago, diesieben07 said:

You cannot store data like this in the Item class. There is only one instance of your Item class. If you want to store additional data, it needs to be stored in the ItemStack, either using NBT or capabilities.
Even worse, in your case you are accessing these fields from both client server without any synchronization. This will lead to strange and hard to diagnose bugs, because your code will execute on both server and client thread.
Same here.