[1.10.2][IBlockState][SOLVED] getStateFromMeta is deprecated. What should I use?

[Starless]

Block.getMetaFromState

is still good, but what should I use instead of

Block.getStateFromMeta

?

[shadowfacts]

Nothing, use that. Mojang is using the

@Deprecated

annotation to mean that nobody should be using it unless they're overriding it or they absolutely have to.

[Starless]

That's the question. I need to convert from metadata to IBlockState right? because the

Block

class implementation returns

this.getDefaultState()

completely ignoring the metadata parameter.

[imadnsn]

Shouldn't the easier way be by

block.getDefaultState.withProperty(IProperty, value)

?

[Choonster]

Shouldn't the easier way be by

block.getDefaultState.withProperty(IProperty, value)

?

 

You need to override

Block#getMetaFromState

and

Block#getStateFromMeta

to allow your block to be serialised/deserialised correctly. You generally shouldn't be calling these methods yourself.

 

When setting a block in the world, you do need to use

IBlockState#withProperty

to set each property to the appropriate value.

[imadnsn]

I know that in the block class it

Block#getMetaFromState

and

Block#getStateFromMeta

but I mean if you want to make a BlockState like you make a new ItemStack from somewhere else in the code, can't you use

IBlockState#withProperty

?

[Starless]

You need to override

Block#getMetaFromState

and

Block#getStateFromMeta

to allow your block to be serialised/deserialised correctly. You generally shouldn't be calling these methods yourself.

 

When setting a block in the world, you do need to use

IBlockState#withProperty

to set each property to the appropriate value.

 

That's what I wanted to know. But why is it marked as deprecated if we still need to override it?

 

My block has metadata that needs to be calculated based on its neighbors: it searches for an inventory around it and sets the metadata appropriately what methods exactly do I need to override to get this done? Just

onBlockPlaced

and

onBlockAdded

?

[Choonster]

That's what I wanted to know. But why is it marked as deprecated if we still need to override it?

Nothing, use that. Mojang is using the

@Deprecated

annotation to mean that nobody should be using it unless they're overriding it or they absolutely have to.

 

My block has metadata that needs to be calculated based on its neighbors: it searches for an inventory around it and sets the metadata appropriately what methods exactly do I need to override to get this done? Just

onBlockPlaced

and

onBlockAdded

?

If the initial state is only based on the neighbouring blocks, you only need to override

Block#onBlockAdded

. This is called whenever the

Block

is added to the world, regardless of whether it was done by a player or something else.

 

Are you sure you want to store this information in the metadata and not just calculate it in

Block#getActualState

?

[Starless]

Are you sure you want to store this information in the metadata and not just calculate it in

Block#getActualState

?

 

I don't know...

getActualState

would be more accurate and cleaner since I wouldn't need to deal with neighbors changing in my TileEntity, but do you think it's worth the overhead?

[Choonster]

Are you sure you want to store this information in the metadata and not just calculate it in

Block#getActualState

?

 

I don't know...

getActualState

would be more accurate and cleaner since I wouldn't need to deal with neighbors changing in my TileEntity, but do you think it's worth the overhead?

 

How expensive is the check? If you're just calling

ICapabilityProvider#hasCapability

for each neighbouring

TileEntity

, it shouldn't be all that expensive.

[Starless]

How expensive is the check? If you're just calling

ICapabilityProvider#hasCapability

for each neighbouring

TileEntity

, it shouldn't be all that expensive.

 

It's because you didn't see my design. My

TileEntity

doesn't update every tick. It has a tick counter. So updating the metadata only when the tick counter reaches 0 is far cheaper than the alternative.

[jeffryfisher]

... why is it marked as deprecated if we still need to override it?

If I understand earlier comments correctly, Mojang is sometimes using the "deprecated" annotation as a poor-man's abstract method qualifier. In other words, it indicates a need to override so that it will never be called naked. Maybe there was some language rule preventing Mojang from using the abstract qualifier.

[LexManos]

Yes, @Dprecated in the MC codebase can be taken as:

Modders should NEVER CALL this. But as we have not moved away from it, modders MAY need to IMPLEMENT this.

Mojang is working on cleaning up their code base a lot. So things are in flux just like every major project out there.

The annotations are a guide.

 

Seriously it's not a hard concept.

Are you calling a deprecated function? STOP

Are you implementing a deprecated function? Fine, just be weary it may change in future MC versions. {Just like everything else}

 

Remember Minecraft IS NOT a full fledged professional modder facing API. It's a decompiled internal hack of a client.

 

I seriously can't understand how people can't grasp this simple concept, we get FAR to many of these 'but the method is deprecated!' posts... -.-

 

The same thing goes for things WE in Forge deprecate. Like non-stack sensitive versions of Item functions.

You could still IMPLEMENT them and they would work fine{Because we are forced to be compatbile with vanilla}. But you should always CALL the non-deprecated form.

The only difference between Mojang's @Deprecated and ours is that we can add comments directing you to the new stuff. Mojang can't as comments don't survive the compiling process.