tutorial:blockstate
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
tutorial:blockstate [2019/07/25 16:56] – fudge | tutorial:blockstate [2021/07/23 18:02] – Fixed typos fireblast | ||
---|---|---|---|
Line 3: | Line 3: | ||
This makes it impossible to change a specific block' | This makes it impossible to change a specific block' | ||
as every other block of that type will be affected! | as every other block of that type will be affected! | ||
- | But, what if I **do** want to give a singular block state, so it can change based on some condition? | + | But, what if you //do// want to give a singular block state, so it can change based on some condition? |
This is what '' | This is what '' | ||
- | Say we wanted a block to have a hardness of '' | + | Say we wanted a block that can summon lightning, but only when charged up. |
- | it would become harder and gain a hardness of '' | + | |
- | First we define the boolean property of the block - whether or not it is hard: | + | First we define the boolean property of the block - whether or not it is charged (careful not to import the wrong BooleanProperty!): |
<code java> | <code java> | ||
public class MyBlock extends Block { | public class MyBlock extends Block { | ||
- | public static final BooleanProperty | + | public static final BooleanProperty |
} | } | ||
</ | </ | ||
- | Then we need to register the property | + | Then we need to register the properties of the block by overriding '' |
<code java> | <code java> | ||
public class MyBlock extends Block { | public class MyBlock extends Block { | ||
- | ... | + | [...] |
@Override | @Override | ||
- | protected void appendProperties(StateFactory.Builder< | + | protected void appendProperties(StateManager.Builder< |
- | | + | |
} | } | ||
| | ||
} | } | ||
</ | </ | ||
- | Then we need to set the default state of our property in the block constructor: | + | Then we need to set the default state of our property in the block constructor |
<code java> | <code java> | ||
public class MyBlock extends Block { | public class MyBlock extends Block { | ||
- | ... | + | [...] |
public MyBlock(Settings settings) { | public MyBlock(Settings settings) { | ||
super(settings); | super(settings); | ||
- | setDefaultState(getStateFactory().getDefaultState().with(MyBlockIsHard, false)); | + | setDefaultState(getStateManager().getDefaultState().with(CHARGED, false)); |
} | } | ||
| | ||
} | } | ||
</ | </ | ||
- | + | Now, we need to be able to charge the block, through the '' | |
- | Now, to set the property | + | |
<code java> | <code java> | ||
public class MyBlock extends Block { | public class MyBlock extends Block { | ||
- | ... | + | [...] |
@Override | @Override | ||
- | public | + | public |
- | world.setBlockState(pos, | + | player.playSound(SoundEvents.BLOCK_RESPAWN_ANCHOR_CHARGE, |
- | return | + | world.setBlockState(pos, |
+ | return | ||
} | } | ||
} | } | ||
</ | </ | ||
- | And to use the property we call '' | + | |
+ | And Finally, | ||
<code java> | <code java> | ||
public class MyBlock extends Block { | public class MyBlock extends Block { | ||
- | ... | + | |
- | | + | |
@Override | @Override | ||
- | public | + | public |
- | | + | |
- | if(isHard) return 2.0f; | + | //Summoning the Lighting Bolt at the block |
- | | + | LightningEntity lightningEntity = (LightningEntity) EntityType.LIGHTNING_BOLT.create(world); |
+ | | ||
+ | world.spawnEntity(lightningEntity); | ||
+ | | ||
+ | |||
+ | world.setBlockState(pos, | ||
+ | super.onSteppedOn(world, | ||
} | } | ||
} | } | ||
</ | </ | ||
+ | ==== Adding models for your blockstates ==== | ||
+ | |||
+ | You can also make the texture and model of your block change based on the state. This is done through a JSON file called a Blockstate JSON. All blocks need a blockstate JSON, whether they have multiple states or not, but the contents of the JSON can be as simple or complex as you like. If you want to change the textures of your block based on the state, you //will// need multiple models. | ||
+ | |||
+ | Let's say you register an instance of '' | ||
+ | |||
+ | <code JavaScript resources/ | ||
+ | { | ||
+ | " | ||
+ | "": | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Let's break this simple example down. There are a couple important parts to this JSON: | ||
+ | |||
+ | - The ''" | ||
+ | - A variant named ''""'' | ||
+ | - The object assigned to the ''""'' | ||
+ | - The ''" | ||
+ | |||
+ | If you want to have different models for each blockstate, you should add multiple variants. For the same '' | ||
+ | |||
+ | <code JavaScript resources/ | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | In this JSON, there are two variants, one for each possibility of the '' | ||
+ | |||
+ | Variants are based on possible permutations of the properties added to your block. A property can be totally ignored in the blockstate JSON if you want, like in the first blockstate JSON where we ignored the '' | ||
+ | |||
+ | This is only a simple introduction to blockstate JSONs. All of the tricks you can do with blockstate and model JSONs are documented on the [[https:// | ||
+ | ==== A note about performance ==== | ||
+ | Every possible state of a block is registered at the start of the game. This means that if you have 14 boolean properties, the block has 2^14 = 16384 different states and 2^14 states are registered. For this reason blocks should not contain too many blockstate properties. Rather, blockstates should be mostly reserved for visuals, and [[tutorial: |
tutorial/blockstate.txt · Last modified: 2024/07/04 16:30 by mineblock11