[1.8][SOLVED] Placed block using wrong model json

[Tyron]

I'm at my witts end here. I've been debugging this for 2-3 hours and I bet i'm just missing some comma or space somewhere

 

My custom anvil block renders correctly in the inventory, which means it must have correctly loaded the model json. But when placed it completely ignores my PropertyEnum METALTYPE and just renders with the last item in my enum. Interestingly enough, the second property FACING is working just fine.

 

So, there must be something wrong with either my blockstates json file or by the way it's being loaded I guess.

 

Here is my custom anvil block with METALTYPE=iron once in my hotbar (active item) and then placed on the ground.

 

This is the blockstates json: https://github.com/tyronx/vintagecraft/blob/master/src/main/resources/assets/vintagecraft/blockstates/anvilvc.json

The model json files: https://github.com/tyronx/vintagecraft/tree/master/src/main/resources/assets/vintagecraft/models/block/anvil

BlockAnvilVC.java, correctly setting up the block properties: https://github.com/tyronx/vintagecraft/blob/master/src/main/java/at/tyron/vintagecraft/block/Utility/BlockAnvilVC.java

 

 

The enum is here: https://github.com/tyronx/vintagecraft/blob/master/src/main/java/at/tyron/vintagecraft/WorldProperties/EnumMetal.java

Any anvil I place always renders with metaltype=bismuthbronze

 

- If I rename the model json file "bismuthbronze.json" all the anvil blocks get the missing texture, so it is indeed using only bismuthbronze.json.

- There are no errors logged to console

- Client and Server blockstate is in sync as far as i could see

 

This is really perplexing that in f3 mode it displays iron (or any other of the 15 metals) but renders as bismuthbronze.

 

 

Is there any way I could debug this properly?

 

 

[Ernio]

I don't really know next shit about 1.8 BlockStates (not yet in topic with my progress), but what I know is that block's meta is 4 bytes.

 

4 bytes is 16 variants (as it always was), please do tell - did BlockStates suddenly allowed users to have more variants?

 

PS - yes, this might be offtopic (additional question).

Well, seeing what I see in vanilla .json-s, you can actually have more than 16 variants, could someone post explanation how is it saved in world? I just don't get how they save so much data in so little space.

 

EDIT (to post below)

Ah, yes, obviously. Should have thought about it before asking

[Tyron]

  On 4/26/2015 at 8:03 PM, Ernio said:

I don't really know next shit about 1.8 BlockStates (not yet in topic with my progress), but what I know is that block's meta is 4 bytes.

 

4 bytes is 16 variants (as it always was), please do tell - do BlockStates suddenly allowed users to have more variants?

 

A block can only hold 4 bytes bits when saved (=getMetaFromState), during runtime you can have as many blockstates as you like - you just cant save/load them together with the block. You have to infer the additional info via neighbouring blocks, store it in a tileentity, or some other custom solution.

[Tyron]

It even seems to use the correct texture.  Below code prints the textures I assigned to each metal correctly for both server and client. Hmmmmmmm....

 

There must be some other code in mc other than BlockRendererDispatcher.getModelFromBlockState() that determines the which model json to use

 

@Override
public boolean onBlockActivated(World world, BlockPos pos, IBlockState state, EntityPlayer playerIn, EnumFacing side, float hitX, float hitY, float hitZ) {
	BlockRendererDispatcher brd = Minecraft.getMinecraft().getBlockRendererDispatcher();
	IBakedModel ibm = brd.getModelFromBlockState(world.getBlockState(pos), world, pos);
    	        System.out.println(ibm.getTexture().getIconName());
	return true;
}

[jabelar]

To clarify, the metadata is only 4 bits, not 4 bytes. So 16 possible values.

 

In your getMetaFromState() function you need to figure out a mapping that fits the properties you've got into those 4 bits. If you need more than that you may need to consider creating other blocks that get swapped in, or using a tile entity (which can store NBT) if you don't intend to place a lot of the blocks.

 

In the code for your anvil block, you don't seem to be storing your property. You are only converting the facing property, not the metal property. You have to do proper getMetaFromState() and getStateFromMeta() that handle all the properties.

 

But also you have the issue that you have too many variants, unless you use a tile entity to manage your property values.

 

To explain further -- each Block class is only instantiated once (it is a "singleton" class). So to store information that makes some of the blocks appear or act differently when placed in the world, there is 4 bits of meta data stored per block position. The reason it is only 4 bits is because there are so many blocks in the world that you'd have issue with memory, disk space, or networking with much more data.

 

 

[Tyron]

  On 4/30/2015 at 6:40 PM, jabelar said:

To clarify, the metadata is only 4 bits, not 4 bytes. So 16 possible values.

 

In your getMetaFromState() function you need to figure out a mapping that fits the properties you've got into those 4 bits. If you need more than that you may need to consider creating other blocks that get swapped in, or using a tile entity (which can store NBT) if you don't intend to place a lot of the blocks.

 

In the code for your anvil block, you don't seem to be storing your property. You are only converting the facing property, not the metal property. You have to do proper getMetaFromState() and getStateFromMeta() that handle all the properties.

 

But also you have the issue that you have too many variants, unless you use a tile entity to manage your property values.

 

To explain further -- each Block class is only instantiated once (it is a "singleton" class). So to store information that makes some of the blocks appear or act differently when placed in the world, there is 4 bits of meta data stored per block position. The reason it is only 4 bits is because there are so many blocks in the world that you'd have issue with memory, disk space, or networking with much more data.

 

Thanks for the reply but I'm well aware of the metadata limits. My Anvil is using a tileentity to store the metal type. Only the facing is stored in metadata. You can see that in the coded I posted e.g. in getActualState() in BlockAnvil.java

 

I meant 4 bits, not 4 bytes. It was a typo

[jabelar]

I personally had difficulty getting an enum property to work as well. I just switched to an integer property and it seemed to work better. Sometime I need to go back and figure out the enum properties properly, but although enum is more elegant an int works well too.

 

I'd try to convert the property to an integer and see if you have any different result.

[Tyron]

Thanks for the suggestion jabelar. I did some tweaking and think I just got it working now. I guess probably the culprit was the order in the IProperty Array in createBlockState(). I switched that out (amongst other stuff) and now it seems to work.