How to use metadata effectively?

[vilu]

I'm trying to avoid Tile Entities if it just possible (for performance reasons) and now I got stuck and can't figure this out by myself. I have this block and it has three things that needs to be stored, direction, state (on/off), and size (should be between 0 - 8 ). So how could I fit all this to just one nibble or can I? I've tried to do different bitwise operations and still it just doesn't work.

I'm not so good at bitwise operations so therefore I thought that here is someone how knows better. Let's say there are

flags for those things I mentioned, and if the flags were ones like below I could determinate state from meta by checking if ((meta & stateFlag) == stateFlag), and direction by returning (meta & ~

 

(hex)  (flag)    (bin)

0x2 - North (0010)

0x3 - South (0011)

0x4 - West(0100)

0x5 - East (0101)

 

0x8 - State on (1000)

 

But how can I get size information from meta and what hex values I should use for flags? Please someone who understands bitwise operations better tell me if that's not even possible and if it can be done then how? If the size data (from 0 to 8 ) takes too much space in nibble (as it seems to take) then how many different sizes could be fit there?

[SanAndreaP]

You need to split up your uses:

You need a flag for the state, which means 1 bit goes away.

Then you need to determine which direction it should face, which means 2 bits go away

Left is now 1 bit, so you can't store the size, which should be from 0-8

Means:

state    - 1 bit  - xxx0 or xxx1 (1st bit is used)

direction - 2 bits - x00x, x01x, x10x or x11x (2nd and 3rd bits are used)

size      - 4 bits - 0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000 (no space for that information)

 

If you really don't want to use TileEntities, you need to make multiple blocks, meaning you have to use your metadata efficiently, so that you don't need too much blocks!

I suggest you stick with a size range of 0 to 7, so you have 1 bit left for the state:

state - 1 bit  - xxx0 or xxx1 (1st bit is used)

size  - 3 bits - 000x, 001x, 010x, 011x, 100x, 101x, 110x or 111x

the direction is each a different block, so you have 4 different blocks (like the furnace has 2 blocks for the on/off state)

[vilu]

Thank you for your help =) Maybe I should use Tile Entity after all or modify the block model so that it doesn't need direction meta. I've tried to google information about packing data to just one nibble but it really seems to be impossible.

[TheGreyGhost]

Hi

 

As SanAndreasP said, you can pack multiple data into a single nibble so long as you don't try to cram too much in!

 

If it helps you understand it, you can write all sixteen combinations out

 

META	binary	STATE 	SIZE 	STATE	SIZE
0	0000	0	000	off	tiny
1	0001	0	001	off	little
2	0010	0	010	off	small
3	0011	0	011	off	medium
4	0100	0	100	off	large
5	0101	0	101	off	big
6	0110	0	110	off	huge
7	0111	0	111	off	enormous
8	1000	1	000	on	tiny
9	1001	1	001	on	little
10	1010	1	010	on	small
11	1011	1	011	on	medium
12	1100	1	100	on	large
13	1101	1	101	on	big
14	1110	1	110	on	huge
15	1111	1	111	on	enormous

 

His suggestion on using 4 different blocks is a good one, and it's not hard to do.

 

If there will only ever be a few of your blocks (like chests), then TileEntities are fine.

 

If you might have lots (hundreds or thousands) of your blocks lying around, like trees for example, then use the multiple blocks methods because the TileEntities will probably cause a lot of lag.

 

-TGG

 

[SanAndreaP]

Hi

 

As SanAndreasP said, you can pack multiple data into a single nibble so long as you don't try to cram too much in!

 

If it helps you understand it, you can write all sixteen combinations out

 

META	binary	STATE 	SIZE 	STATE	SIZE
0	0000	0	000	off	tiny
1	0001	0	001	off	little
2	0010	0	010	off	small
3	0011	0	011	off	medium
4	0100	0	100	off	large
5	0101	0	101	off	big
6	0110	0	110	off	huge
7	0111	0	111	off	enormous
8	1000	1	000	on	tiny
9	1001	1	001	on	little
10	1010	1	010	on	small
11	1011	1	011	on	medium
12	1100	1	100	on	large
13	1101	1	101	on	big
14	1110	1	110	on	huge
15	1111	1	111	on	enormous

 

His suggestion on using 4 different blocks is a good one, and it's not hard to do.

 

If there will only ever be a few of your blocks (like chests), then TileEntities are fine.

 

If you might have lots (hundreds or thousands) of your blocks lying around, like trees for example, then use the multiple blocks methods because the TileEntities will probably cause a lot of lag.

 

-TGG

 

Instead of listing all of this, you can also look at the data you wanna put in as single bits, then connect those bits together (like I did), thus much less writing and the logic / result is the same

[coolAlias]

If there will only ever be a few of your blocks (like chests), then TileEntities are fine.

 

If you might have lots (hundreds or thousands) of your blocks lying around, like trees for example, then use the multiple blocks methods because the TileEntities will probably cause a lot of lag.

That's an excellent point that I think many people probably don't think about right away. Thanks for pointing that out!

[Wicked1]

I had a similar situation when doing colored stairs.. I could meta the color, OR the facing,

and I didnt want to TE because a ton of them would be in a chunk or 2 when building a castle / player home town.

I cheesed out and went with vanilla stairs meta for a bunch of colored stairblocks.

(I am using meta subtypes for my ore blocks, and again for some deco blocks,

so I feel a little better about trying not to make a gajllion blocks)

 

Good to hear the reminder about CanUpdate()

will definitely put that to use later... may even rethink my colored stairs configuration with that in mind-

Maybe a couple hundred dataTE wont lag so bad if they get no ticks