Is it possible to to have more then 16 different block states. I was thinking about using tileEntities but i'm not sure how i can accomplish the cross over from tileEntity to the blockstate .json. do I have to use a special renderer to accomplish this?
I'd say instead of messing with tile entities just make a new Block, call it Dirt2 for example, make it extend the original if needed and make block states for the second block.
[/p]
[p]@Override
protected BlockState createBlockState() {
// These actually have to be explicitly called as 'new IProperty[]' - cannot simply be listed as arguments
return new ExtendedBlockState(this, new IProperty[] {A_PROPERTY}, new IUnlistedProperty[] {AN_UNLISTED_PROPERTY});
}[/p]
[p]
These unlisted properties will not appear in the JSON file as variants, so it is generally useful for properties that do not have any special render model or texture associated with them. Of course, you can couple it with a tile entity (and I haven't seen any implementation yet NOT coupled with a tile entity) for quite a bit of flexibility, even so far as rendering your block as a different block.
I was just reading about ISmartBlockModel before too, completely overlooked the mention of IExtendedBlockState.
I think it requires a TileEntity to store whatever additional info you want, but it allows you to use that data as block states which is quite nice for readability. There may be some other type of extended block state storage, though, I haven't actually looked into it too much since the blocks I used it with all had tile entities anyway.
I'll look into IExtendedBlockState, but this does seem kind of hacky. I guess it will work better then the TileEntity stuff i was attempting to implement. I think TileEntity is loaded after the get meta call in Block.
I think it requires a TileEntity to store whatever additional info you want, but it allows you to use that data as block states which is quite nice for readability. There may be some other type of extended block state storage, though, I haven't actually looked into it too much since the blocks I used it with all had tile entities anyway.
That's fair enough. We can always return false in canUpdate to get back most of the overhead associated with TileEntities (I think).
I'll look into IExtendedBlockState, but this does seem kind of hacky. I guess it will work better then the TileEntity stuff i was attempting to implement. I think TileEntity is loaded after the get meta call in Block.
Also as coolAlias just suggested, there doesn't seem to be a way to use the extended block states *without* a TileEntity - it's essentially just a wrapper for the standardized block property system. Which is nice and makes it more readable and easier to maintain. You need that extra data to be stored somewhere as it can't physically fit in the metadata nibble that Blocks are given.
That's fair enough. We can always return false in canUpdate to get back most of the overhead associated with TileEntities (I think).
In 1.8, TileEntities do not update by default. You have to specifically implement the IUpdatePlayerListBox interface (which provides only one method: 'update()') for your TileEntity to receive update ticks.
@OP Can you explain why you need 26 block states? I'm familiar with MineSweeper, but I do not understand the approach you are taking. If it were me, I would simply iterate through the world when needed to check the state of other blocks nearby, and only maintain a handful of states (at most, probably just a PropertyBool for discovered or not and another for whether it was marked by the player) for the main blocks.
In 1.8, TileEntities do not update by default. You have to specifically implement the IUpdatePlayerListBox interface (which provides only one method: 'update()') for your TileEntity to receive update ticks.
Interesting, I've not even tried doing a TE in 1.8 yet. That's an odd name, "IUpdatePlayerListBox"... but thanks for the heads up. I think that's great that TE's don't tick by default anymore.
If this mine sweeper game doesn't cover the whole world (i.e. I assume this is limited to some area) the block metadata isn't necessarily the only way to do it. You could just use tile entities (I think that is suggested above), or have some other data structure that can be saved in the world save data NBT.
But also, like CoolAlias asks -- what exactly are the 26 states you need to maintain? It seems to me that in a classic minesweeper you only need to have 9 states since you can have from 0 to 8 neighbors. Or are you making this 3-dimensional so you're looking above and below as well?
it's 3d so yes i'm looking above and below. At the moment I lowered the density to the point where it's highly unlikely for a block to max the 16 possible states.
I guess you could consider the largest number to be "16+" so player would know there could be more. I know that when playing minesweeper, if you knew there was that many potential bombs around, you probably wouldn't take a chance, so whether it is 16, 20, or 26 doesn't make much difference to the gameplay.
I think its fine at the moment and this case is very unlikely to occur in general. I just wanted to look into the possibility of adding more states to the current block. I think i have my answer and will probably review that example code offered up by coolAlias. I'm more interested in adding trophies and what not to the mod.
Is it possible to to have more then 16 different block states. I was thinking about using tileEntities but i'm not sure how i can accomplish the cross over from tileEntity to the blockstate .json. do I have to use a special renderer to accomplish this?
Look at fire, it has almost 100 states and JSONS for all of them
Errr, what? JSON Model <> BlockState lol fire has only 8 different property fields.
You can't have more than 16 BlockStates, you need a TileEntity or your own custom implementation.
You can still use JSON models that are "selected" by data in the TileEntity. Renderer and BlockState are two different things.
I'd say instead of messing with tile entities just make a new Block, call it Dirt2 for example, make it extend the original if needed and make block states for the second block.
There is IExtendedBlockState:
Which you usually use with unlisted properties:
These unlisted properties will not appear in the JSON file as variants, so it is generally useful for properties that do not have any special render model or texture associated with them. Of course, you can couple it with a tile entity (and I haven't seen any implementation yet NOT coupled with a tile entity) for quite a bit of flexibility, even so far as rendering your block as a different block.
See TheGreyGhost's excellent example / tutorial on this subject.
I stand corrected then. Very nice!
I was just reading about ISmartBlockModel before too, completely overlooked the mention of IExtendedBlockState.
I think it requires a TileEntity to store whatever additional info you want, but it allows you to use that data as block states which is quite nice for readability. There may be some other type of extended block state storage, though, I haven't actually looked into it too much since the blocks I used it with all had tile entities anyway.
I'll look into IExtendedBlockState, but this does seem kind of hacky. I guess it will work better then the TileEntity stuff i was attempting to implement. I think TileEntity is loaded after the get meta call in Block.
Here is what i'm working on if your curious. I need 26 states for the number of blocks in the vicinity and an additional state for marking the block.: https://github.com/pollend/mine-sweeper/tree/master
That's fair enough. We can always return false in canUpdate to get back most of the overhead associated with TileEntities (I think).
What makes it seem hacky? Forge is one huge hack
Also as coolAlias just suggested, there doesn't seem to be a way to use the extended block states *without* a TileEntity - it's essentially just a wrapper for the standardized block property system. Which is nice and makes it more readable and easier to maintain. You need that extra data to be stored somewhere as it can't physically fit in the metadata nibble that Blocks are given.
In 1.8, TileEntities do not update by default. You have to specifically implement the IUpdatePlayerListBox interface (which provides only one method: 'update()') for your TileEntity to receive update ticks.
@OP Can you explain why you need 26 block states? I'm familiar with MineSweeper, but I do not understand the approach you are taking. If it were me, I would simply iterate through the world when needed to check the state of other blocks nearby, and only maintain a handful of states (at most, probably just a PropertyBool for discovered or not and another for whether it was marked by the player) for the main blocks.
Interesting, I've not even tried doing a TE in 1.8 yet. That's an odd name, "IUpdatePlayerListBox"... but thanks for the heads up. I think that's great that TE's don't tick by default anymore.
If this mine sweeper game doesn't cover the whole world (i.e. I assume this is limited to some area) the block metadata isn't necessarily the only way to do it. You could just use tile entities (I think that is suggested above), or have some other data structure that can be saved in the world save data NBT.
But also, like CoolAlias asks -- what exactly are the 26 states you need to maintain? It seems to me that in a classic minesweeper you only need to have 9 states since you can have from 0 to 8 neighbors. Or are you making this 3-dimensional so you're looking above and below as well?
it's 3d so yes i'm looking above and below. At the moment I lowered the density to the point where it's highly unlikely for a block to max the 16 possible states.
I guess you could consider the largest number to be "16+" so player would know there could be more. I know that when playing minesweeper, if you knew there was that many potential bombs around, you probably wouldn't take a chance, so whether it is 16, 20, or 26 doesn't make much difference to the gameplay.
I think its fine at the moment and this case is very unlikely to occur in general. I just wanted to look into the possibility of adding more states to the current block. I think i have my answer and will probably review that example code offered up by coolAlias. I'm more interested in adding trophies and what not to the mod.