Confusion about VoxelShapes and BlockStates in 1.15.1

[Jipthechip]

In 1.15.1, the methods that work with VoxelShapes (i.e. getShape(), getCollisionShape()) are deprecated in the Block class, but aren't deprecated in the BlockState class. This change seems relatively new and I can't find any information about this on mcforge.readthedocs.io or anywhere else. There's also no documentation in the code itself saying why the methods are deprecated.

 

I assume this means that you're supposed to override those methods in the BlockState class instead, but does this mean that for every Block, if I want to add VoxelShapes I need to make a new class that extends BlockState and then insert an instance of that class into the StateContainer of the Block? That doesn't sound right, and I'm really confused.

Edited April 15, 2020 by Jipthechip

[Draco18s]

42 minutes ago, Jipthechip said:

In 1.15.1, the methods that work with VoxelShapes (i.e. getShape(), getCollisionShape()) are deprecated in the Block class, but aren't deprecated in the BlockState class. This change seems relatively new and I can't find any information about this on mcforge.readthedocs.io or anywhere else. There's also no documentation in the code itself saying why the methods are deprecated.

Mojang marked them as deprecated. Deprecated means "do not call this function." They aren't deprecated in the BlockState class because you're supposed to call the methods in the blockstate class. I'm sure if you searched the forums you'd find a dozen threads about this. Its been like this since IBlockState was introduced (1.10ish)

 

44 minutes ago, Jipthechip said:

I assume this means that you're supposed to override those methods in the BlockState class instead, but does this mean that for every Block, if I want to add VoxelShapes I need to make a new class that extends BlockState and then insert an instance of that class into the StateContainer of the Block? That doesn't sound right, and I'm really confused.

No.

I'm not sure what you're trying to do, but no. That would be Wrong.

[TheGreyGhost]

Hi

Mojang means

"Call the corresponding BlockState function, don't call the Block function".

 

 

It doesn't mean

"you must not override this method when you extend the Block class".

 

Basically you can ignore the @deprecated, it's just an advice that there might be a better way. In this case (extending the block class), there is no better way.

 

-TGG

 

 

 

[Jipthechip]

1 hour ago, Draco18s said:

Mojang marked them as deprecated. Deprecated means "do not call this function." They aren't deprecated in the BlockState class because you're supposed to call the methods in the blockstate class. I'm sure if you searched the forums you'd find a dozen threads about this. Its been like this since IBlockState was introduced (1.10ish)

 

No.

I'm not sure what you're trying to do, but no. That would be Wrong.

 

17 minutes ago, TheGreyGhost said:

Hi

Mojang means

"Call the corresponding BlockState function, don't call the Block function".

 

 

It doesn't mean

"you must not override this method when you extend the Block class".

 

Basically you can ignore the @deprecated, it's just an advice that there might be a better way. In this case (extending the block class), there is no better way.

 

-TGG

 

 

 

Ah ok, I think I understand now. I should've looked more closely at the getShape() function of the BlockState class because it actually just calls the getShape() of the Block ?.

 

I mean, this whole structure doesn't really make sense because you have a non-deprecated function that all it does is call a deprecated function, and said function is necessary if you want your block to have a shape... I'm lost as to what sort of advice Mojang is trying to give here by making this deprecated. 

[TheGreyGhost]

Hi

Yeah it's a bit weird.  It helps to know the history- originally there was just the Block class with those methods, and you had to pass  a 4-bit 'metadata' to most functions.  Then Mojang added BlockStates which was more-or-less Block plus metadata.  So they put a 'deprecated' onto the Block functions to say "don't call these Block functions any more, call the BlockStates instead".  Not really what @deprecated is intended for, but then again Minecraft isn't an API by any stretch of the imagination either.

 

Just ignore it is what I usually do... if it breaks next version update, I'll fix it along with the other 50 things that got broken

 

-TGG

[Draco18s]

10 hours ago, Jipthechip said:

I mean, this whole structure doesn't really make sense because you have a non-deprecated function that all it does is call a deprecated function, and said function is necessary

Its because calling the deprecated version looks like this:

world.getBlockState(pos).getBlock().getShape(world.getBlockState(pos),pos)

Notice how getBlockState is called twice?

Now, this is how you call the BlockState version:

world.getBlockState(pos).getShape(pos)

Edited April 15, 2020 by Draco18s

[Jipthechip]

2 hours ago, Draco18s said:

Its because calling the deprecated version looks like this:

world.getBlockState(pos).getBlock().getShape(world.getBlockState(pos),pos)

Notice how getBlockState is called twice?

Now, this is how you call the BlockState version:

world.getBlockState(pos).getShape(pos)

Oh so it's just for the sake of convenience then. Still, it's so weird how Mojang decided to do this.

[Draco18s]

Its not. Its because metadata was limited to 16 values (4 bits) and relied on Magic Numbers. Blockstates are contextual. But blocks, in order to handle their functionality, need to know what their own state is. So the state needs to be passed in (just like how metadata was passed in). The "problem" is that one shouldn't be interacting with the block directly when querying the state of the world, as then you lose that contextual information. You don't want to know what the voxel shape of a block is, you want to know what the voxel shape of a blockstate is.

[Jipthechip]

6 hours ago, Draco18s said:

Its not. Its because metadata was limited to 16 values (4 bits) and relied on Magic Numbers. Blockstates are contextual. But blocks, in order to handle their functionality, need to know what their own state is. So the state needs to be passed in (just like how metadata was passed in). The "problem" is that one shouldn't be interacting with the block directly when querying the state of the world, as then you lose that contextual information. You don't want to know what the voxel shape of a block is, you want to know what the voxel shape of a blockstate is.

That's the very thing that confused me in the first place. When I saw that Block#getShape() was deprecated and BlockState#getShape() wasn't, I assumed exactly what you said in the last sentence, that VoxelShape information should be received from the BlockState rather than the Block.

 

It's easy to just override Block#getShape() and have a switch-case or something that checks the BlockState and then returns the corresponding VoxelShape. It seems most people are doing it this way and Mojang does too, because it's own BlockState#getShape() method just calls Block#getShape(), and does pass in the contextual information. And that's what returns the VoxelShape.

 

But if the concept is that you should be getting the VoxelShape of the BlockState rather than the Block, shouldn't you be keeping all VoxelShape information in the BlockState rather than the Block? You can do this simply by doing everything you do in Block#getShape() in BlockState#getShape(), but Mojang doesn't do this, and that's what doesn't make sense to me.

[Draco18s]

5 minutes ago, Jipthechip said:

But if the concept is that you should be getting the VoxelShape of the BlockState rather than the Block, shouldn't you be keeping all VoxelShape information in the BlockState rather than the Block?

No, because that's not what BlockState does.