[solved] Just looking for an idea to implement tent block.

[tomtomtom09]

Im currently rewriting/improving my camping mod.

 

Main goal is to use less blocks as possible.

 

It's not a lot more code to add different tent variation just don't like using lots of block ids

 

Problem I have is my old mod used 90 different blocks just for tents:

*i do have block states on all tents to check the direction placed so tents are placed in all directions.

Tent version with torches, makes tents easy to craft on first night.

-10 small tent with torches/bed.

-10 medium tent with torches/bed.

10 large tent with torches/bed.

Tent version with lanterns.

-10 small tent with lanterns/bed.

-10 medium tent with lanterns/bed.

10 large tent with lanterns/bed.

Empty tent with nothing inside.

-10 small tent.

-10 medium tent.

10 large tent

 

Im just wondering is it possible to add more block states to a block with different outcomes when right clicked or maybe a simpler alternative?

[Choonster]

You could store some of this data in a

TileEntity

, you can still access it in the blockstates file if you create properties for the various data types and override

Block#getActualState

to set them from the

TileEntity

.

 

I have some examples of this here:

• Coloured Rotatable Block:

  Block

  ,

  TileEntity

  , blockstates file - Stores the colour in the metadata and the facing in the

  TileEntity

  
  

• Coloured Multi Rotatable Block:

  Block

  ,

  TileEntity

  , blockstates file - Stores the colour in the metadata and the facing and face rotation in the

  TileEntity

 

In your case, you could probably have the following properties:

• Facing - An

  EnumFacing

  , probably limited to horizontals.
  

• Size - An enum with three values: Small, Medium, Large.
  
• Lighting - An enum with three values: None, Lanterns, Torches.
  
• Variant - An enum with ten values (whatever the ten variants are).
  
• Has Bed - A boolean. Only include this if having a bed is independent of the lighting.

 

If the facing is limited to horizontals, you can store it in two bits of metadata; leaving two bits (four possible values) to store the size or lighting. You can store the rest in the

TileEntity

.

[tomtomtom09]

Thank you for the helping

 

didn't think about storing block data inside a TileEntity.

 

Should look something like this once finished:

Facing - 4 values n/e/s/w: stored in TileEntity.

Size - 3 values : s/m/l. stored in block class

Equipment - 3 values : empty/torch/lantern. stored in block class

Fabric Type - 10 values. stored in block class

 

Should be fun playing around with properties

 

 

 

 

[Choonster]

Metadata is limited to 4 bits, 16 possible combinations of values.

 

To store multiple values in metadata, you need to use bitwise operations to put values in or get values out of each bit. Each bit can only be used for a single value.

 

10 possible values for Fabric Type will require all 4 bits of metadata to store (the highest value is 9, which is 1001 in binary), leaving no room for any other values.

[tomtomtom09]

My bad though properties had increased the limit for some reason .

 

My mad ramblings 

 

Always been unsure with using meta data so I properly will be wrong in a minute , I've never used multiple values in metadata before.

 

so each bit can hold 4 combinations of a single value.

 

This is my thinking:

2 bits to store 8 fabric variation.

1 bit for the size.

1 bit for equipment.

Then store the block rotation in the tile entity.

[Choonster]

A bit is either 1 or 0.

 

2 values per bit with 4 bits is 16 (2^4) possible permutations.

[Draco18s]

Honestly, store the rotation in metadata, then store the rest in the TE.

 

(2 bits for fabric, BTW, is 4 colors)

[tomtomtom09]

Thank you Choonster

 

After few hours got type/facing working

 

[/img]