[1.8] Couple of questions about block states

[jabelar]

Okay, I'm finally getting around to updating my 1.7.10 mods to 1.8.  I am pretty good at using the IDE to fix any errors created by the changes, but in the case of blocks I've got a couple questions.  I've looked at a number of tutorials, but haven't quite figured out a couple things.

 

If I want to add a block in the world, we use the setBlockState() method, right?  But that method doesn't actually take a block type parameter but rather just an IBlockState parameter so the actual block placed will come from the IBlockState?  So if I'm trying to create a new block, it means that I should retrieve  the default state of the block and pass that into setBlockState()?

 

So something like this would be correct and sufficient to create a block one position above?

worldObj.setBlockState(pos.add(0, 1, 0), MagicBeans.blockMagicBeanStalk.getDefaultState());

 

Next, I have a question about getBaseState(): Is getBaseState() just the current state? (The term "base" is a bit confusing.)

 

Next, I have a block that had custom metadata.  So I assume that has to be converted to state properties.  Is this the proper steps for setting this up?

1. Create a property, possibly enumerated.  Something like: public static final PropertyInteger AGE = PropertyInteger.create("age", 0, 7);

2. Everywhere I used to set metadata with notify, I just have to do something like: setDefaultState(blockState.getBaseState().withProperty(AGE, Integer.valueOf(5)));

3. Everywhere I used to get metadata, I just have to use something like: blockState.getBaseState().getValue(AGE);

 

I guess the property can be static and final because in Minecraft there is actually only one instance of each block and that is mapped into the positions and states within the world?

[jabelar]

getBaseState (in BlockState class) is just the initial value for getDefaultState (which is modifiable via setDefaultState, where as getBaseState always returns the same).

 

Okay, so I'm still a bit confused then.  Is default state the one I should be setting when I want to change "meta data"?  If so, then they are badly named -- "default" doesn't seem like it should be "current".

 

Basically, when should I use each of the following:

- setBlockState() versus setDefaultState()?

- getBaseState() versus getDefaultState()?

 

 

[jabelar]

- getBaseState() versus getDefaultState()?

Use getDefaultState.

 

Sorry, I meant to ask: getBlockState() versus getDefaultState()?

 

Looking through the code, I think some of my confusion is that some of these are World functions, some are Block functions, and some are IBlockState functions.  getBlockState() is a block function, but setBlockState() is a world function, and getBaseState() is an IBlockState function.

 

I guess I'll study the vanilla code further to see if I can really understand proper practice.  I think:

In custom block class:

- create a final static property to represent the metadata.

- in constructor of block use setDefaultState().

- make methods for getMetaFromState() and getStateFromMeta() using the property

- if you want to access metadata within the block code, do something like: getMetaFromState(parWorld.getBlockState(parBlockPos))

In main class:

- instantiate the block once.  you don't need to set default value if you have that in the block contructor

In other classes:

- if you have world instance, use the getBlockState(parBlockPos) method to get the state.

- If you want to test what kind of block is in the position, use the state.getBlock() method.

- If you want to test the metadata of the block in the position, use the state.getValue() method.  Alternatively, use the block's getMetaFromState() method.

 

[Anon10W1z]

Do not use metadata, same way as you don't use BlockIDs anymore.

What about ItemStacks? For example, if I click a block with my item, it will put it with metadata in my inventory.

[jabelar]

Do not use metadata, same way as you don't use BlockIDs anymore.

 

I understand that for new mods I would do it in a 1.8-based way.  But it seems that upgrading a metadata-based mod would be easier using the getMetaFromState() and getStateFromMeta() functions.

 

My specific problem is that I have a custom structure scheme and the way I had it in 1.7.10 was that I have a text file for the structure and it includes the blocks and their metadata value.  So I think the easiest would be to still read that metadata and get it converted to state, although I guess I'm not confident that the metadata values are even mapped the same.

 

I will have to embark on a serious conversion effort if I change the code to have the state saved in the text file.  In fact, I'm not quite sure how to do that since for each type of block there may be different properties that have to be looked up.  In other words, with metadata in 1.7.10 there was a consistent way for every block to get/set the metadata, but with the change to states I think there is a lot more involved.

 

So I guess I'm looking for a shortcut to do the following -- I have 1.7.10 custom text file holding blocks and associated metadata values.  I'd like to read that into 1.8 and place blocks based on that info.  Ideally, I'd like to use the same text file as I did in 1.7.10.

[jabelar]

My specific problem is that I have a custom structure scheme and the way I had it in 1.7.10 was that I have a text file for the structure and it includes the blocks and their metadata value.  So I think the easiest would be to still read that metadata and get it converted to state, although I guess I'm not confident that the metadata values are even mapped the same.

For backwards compatibility the metadata is mapped the same. And yes, for storage using the metadata is perfectly fine.

So I guess I'm looking for a shortcut to do the following -- I have 1.7.10 custom text file holding blocks and associated metadata values.  I'd like to read that into 1.8 and place blocks based on that info.  Ideally, I'd like to use the same text file as I did in 1.7.10.

Keep it the same. Metadata for storage is fine, that's what it's there for.

 

Thanks, I was hoping I could keep using it that way.