TileEntity rendering with json

[Jay Avery]

I've created a multi-block structure - when the item is used, it places four blocks (and when one is destroyed they all break). Each block in the structure stores its state in a TileEntity - one int defining which part of the structure it is, and one int representing the horizontal direction it's facing. I want each part of the structure to have a different json model - not a TE special renderer. Is it possible to do this with the blockstates json file somehow?

[Draco18s]

Yes.  You would just be encoding those values in the block's extended state (which is used pretty much only for rendering).

 

That said, with 4 blocks and 4 horizontal directions, there's no need for a TE at all: 4x4 = 16, which is the maximum amount of data storable in metadata.

[Jay Avery]

Yes.  You would just be encoding those values in the block's extended state (which is used pretty much only for rendering).

 

That said, with 4 blocks and 4 horizontal directions, there's no need for a TE at all: 4x4 = 16, which is the maximum amount of data storable in metadata.

 

Thanks. Yeah I realise that 4x4 will fit in metadata, but I'm going to be using the same method for other larger structures too so I still want to know about it. Can you give any more guidance about how to use the TileEntity for the block's extended state? Or direct me to a tutorial maybe?

[Draco18s]

Here's the only work I've done with extended states.

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/block/BlockSluice.java#L80

 

Mind, all that is for calculating water height (but it's treated like any other unlisted property).  But it doesn't have a json file associated (the model is runtime).  But the principles should be similar.

[Choonster]

You probably don't need unlisted properties (

IUnlistedProperty

) and extended state (

ExtendedBlockState

/

Block#getExtendedState

) here, just regular properties (

IProperty

) and actual state (

Block#getActualState

).

 

Regular properties have a fixed set of values and can be used to determine which model is rendered for the block. Unlisted properties can have any number of values (e.g.

PropertyFloat

will accept any

float

by default) and can't be used to determine which model is rendered for the block, but can be used by the model itself to determine how it's rendered (e.g.

ModelFluid

uses it to determine the height of each corner).

 

I have a pair of blocks that store one value (colour) in the metadata and one or two more values (rotation and face rotation) in the

TileEntity

.

 

You can see them here:

• [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/block/BlockColoredRotatable.java]BlockColoredRotatable[/url]

  (

  Block

  ),

  [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/tileentity/TileEntityColoredRotatable.java]TileEntityColoredRotatable[/url]

  (

  TileEntity

  ), colored_rotatable.json (blockstates file)
   
  

• [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/block/BlockColoredMultiRotatable.java]BlockColoredMultiRotatable[/url]

  (

  Block

  ),

  [url=https://github.com/Choonster/TestMod3/blob/c49a3557e534a765fc0f10338cb617ecbc2df292/src/main/java/choonster/testmod3/tileentity/TileEntityColoredMultiRotatable.java]TileEntityColoredMultiRotatable[/url]

  (

  TileEntity

  ), colored_multi_rotatable.json (blockstates file)
   
  

 

These are single blocks rather than a multi-block structure, but the principle is the same (they use

TileEntity

data to determine the model).

[Draco18s]

Er...yes.

Somewhere along the way I got extended state and actual state mushed together in my head.

Whoops!