[1.12.2] Retrive MetaFromState without Directional Meta

[MiKeY_]

Hi, Hopefully this is a simple one,

 

I'm looking to use

Block block = state.getBlock();
return new BlockId( Block.getIdFromBlock( block ), block.getMetaFromState( state ) );

 

When scanning the area around the player for a specific block. When scanning the world I get blocks like a chest with meta:2 because of it's direction, I was wondering if there is a way to either get the meta without the direction of the block or if there is a way to savely figure out when it's directional meta and remove it?

 

Thanks

[aw_wolfe]

Probably better answers out there.

 

But, different blocks could handle direction or facing differently, so I'd say there is no for sure way.  You can iterate through the properties of the blockstate and see if any have a "facing" as most directional block will implement similar to vanilla. Problem is they may convert to and from meta differently.

You'd have to implement a switch for each type of block to strip of facing...but if using other mods, you may not know how they convert to meta and back.

 

I guess, I'd question your problem and see if there is a different solution. Or if you can ignore blocks with facing, What are you trying to find with meta?

[MiKeY_]

25 minutes ago, aw_wolfe said:

Probably better answers out there.

 

But, different blocks could handle direction or facing differently, so I'd say there is no for sure way.  You can iterate through the properties of the blockstate and see if any have a "facing" as most directional block will implement similar to vanilla. Problem is they may convert to and from meta differently.

You'd have to implement a switch for each type of block to strip of facing...but if using other mods, you may not know how they convert to meta and back.

 

I guess, I'd question your problem and see if there is a different solution. Or if you can ignore blocks with facing, What are you trying to find with meta?

I had a funny idea I was trying to do something that wouldn't work out in the long run Thanks for you anwser.

 

27 minutes ago, diesieben07 said:

You should not be using either block IDs nor block metadata.

Yeah, I know... 90% of the codebase is using Id's and I've just not had the heart to rewrite it all. Although the functions arent depercated yet so I'll keep being an awful person until then. I know for block Id's but whats correct thing to be using for metadata? Propreties I'd assume?

[MiKeY_]

9 minutes ago, diesieben07 said:

I can almost guarantee you that this 90% of the codebase is broken. IDs can and will change. I doubt your code handles that. This is not about having the heart. Your code is broken, you should fix it. 

 

The correct thing is to stop thinking about blocks and metadata and start thinking about block states (IBlockState). That is all there will be in 1.13 and that is how you should treat things now. 

Is there any good tutorials / documentation on how to use blockStates. To confirm I have no blocks in my mod, no items, no nothing. It's all code based. Basically you can scan a few blocks around you and allows you to add them to a gui. So I don't need to know how the blockState .json stuff works unless that allows me to understand how blockStates are handled for a selection / detection side of things.

 

( I work on my mod as a very much side project. I can miss mc versions with how little I update / change it. So I stuggle a lot to keep up with the changes in the game and forge )

Edited July 8, 2018 by MiKeY_

[MiKeY_]

7 minutes ago, diesieben07 said:

You will need to give a bit more detail about what you are trying to do.

Say you had a config that contained a few blocks id & metas. Then when you are at your own home in SP you could press a button to highlight those blocks to identify issues with wires or missing blocks or what ever. Kinda like xray but not really. The config is controlled by UI and to add a block you can look at it or hold it in your hand. I can get the state from those two options but how would I store the state in a way that uniquely identifies that block, say it was a chest. Then in my code that gets the state of each blocks in a small radius around you, how I do compare there states to the stored ones. The reason I'm using Id's is because I can store the id: 54 and then get the blocks id and do a

if( Block.getIdFromState() == store.getBlock().id )

 

This an extream simplification of what I am doing but basically I have stored Id's and I need a way of compairing them to the blocks around the player. this works as Id's but if Id's are going I need a way of storing the state to compare that instead of ids. I was only storing meta for edge cases like different wool types.

Edited July 8, 2018 by MiKeY_

[MiKeY_]

39 minutes ago, diesieben07 said:

You cannot store numeric IDs in config files. Numeric IDs change. You have to use textual IDs ("minecraft:stone"). Then for "metadata" you can use a custom format, something like this: "minecraft:stone[variant=granite]". To parse this, you can first use ForgeRegistries.BLOCKS.getValue to obtain the Block and then Block#getDefaultState to obtain that block's default block state. From there you can use IBlockState#getPropertyKeys (stupid name, but that's crowd-sourcing for you) to obtain all properties this block state supports. Each one of them has a name (IProperty#getName()), so you can find the property for each string key in your custom format ("variant" in my example). Then you can use IProperty#parseValue to parse the value ("granite" in my example). Then use IBlockState#withProperty to apply the parsed property-value pair to the block state.

To store an IBlockState in a world-related file (e.g. WorldSavedData, capabilities, etc.) or for sending it over the network you can use Block.getStateId and Block.getStateById, they operate on 16-bit unsigned values. Note that these IDs should only be used in critical places (e.g. networking), as they can change (they should be consistent within a world though, for the time being), which causes problems if you are not careful.

Would I be wrong in thinking that if I was to say, have a much larger range on my selection, that this would be a lot of logic to run on every tick to detect blocks? Although, I think I could do a lot of that logic on the startup of reading the config to resolve the block states that I need to be searching for. My only worry is that I use defaults as examples like Grass and Wool. I'd assume that these wouldn't change between world? Only between instance or would that depend on mods. I'm not a fan of volatile data.

Other than that, Thanks for the info, I'm going to work on refactoring the codebase to use States instead of Id's & Meta.

Edited July 8, 2018 by MiKeY_

[MiKeY_]

Just now, diesieben07 said:

Well, obviously you would not do this text-parsing every time. You would parse the config file once and then have a collection of IBlockState instances (they have the nice property of being immutable).

 

I am not quite sure I follow you here. IDs can change regardless of which blocks are involved.

Yeah thats what I was thinking, Thanks for clarifying.

 

Upon the first time you start the mod it will generate a config and in the original instance it would add id: 3 for grass and add it to the gui. It would do the same for id: 12 meta: 2 for orange wool. I'd assume that if I was to use "minecraft:grass" and "minecraft:wool[varient=orange]" and upon startup resolve that to a stateId. That would work fine for other worlds on the same instances. Or should I be resolving the id's upon world load instead?

[MiKeY_]

4 minutes ago, diesieben07 said:

You are not resolving IDs. You are resolving IBlockState instances. Those are valid for the lifetime of the game launch. 

Thanks for all your help!

[MiKeY_]

3 hours ago, MiKeY_ said:

IProperty#getName()), so you can find the property for each string key in your custom format ("variant" in my example). Then you can use IProperty#parseValue to parse the value ("granite" in my example). Then use IBlockState#withProperty to apply the parsed property-value pair to the block state. 

I'm really struggling with this part.

 

( Warning, prototyping code )
 

String testingBlock = "minecraft:wool[color=yellow]";

BlockResolver blockInfo = new BlockResolver(testingBlock);

Block test = ForgeRegistries.BLOCKS.getValue(new ResourceLocation( blockInfo.getDomain() + ":" + blockInfo.getItemName() ));
assert test != null;
IBlockState state = test.getDefaultState();
for( IProperty prop : state.getPropertyKeys() ) {
  if( prop.getName().equals( blockInfo.getVariationProp() ) ) {
    Optional sd = prop.parseValue( blockInfo.getVariationValue() );
    if( sd.isPresent() ) {
      IBlockState newState = state.withProperty(prop, sd.get().toString());
      System.out.println(Block.getStateId(newState));
    }
  }
}

 

Ignore BlockResolver all it does is parse my block string. I'm going to assume I'm using parseValue wrong or I've completely miss understood. The code as is isn't able to set the property because I get this error

Cannot set property PropertyEnum{name=color, clazz=class net.minecraft.item.EnumDyeColor, values=[white, orange, magenta, lightBlue, yellow, lime, pink, gray, silver, cyan, purple, blue, brown, green, red, black]} to yellow on block minecraft:wool, it is not an allowed value

 

I get what the error is saying so I used this to fix this by using

EnumDyeColor.YELLOW

but of course this isn't a fix. I need this to be dynamic depending on the variation and the prop value

Edited July 8, 2018 by MiKeY_

[MiKeY_]

34 minutes ago, diesieben07 said:

Why are you calling toString on the parsed value? The point is that parseValue parses the value. Do not turn it into a string again. You need to use proper generics:

<T extends Comparable<T>> IBlockState applyPropertyValue(IBlockState state, IProperty<T> property, String rawValue) {
    return property.parseValue(rawValue).transform(v -> state.withProperty(property, v)).or(state);
}

 

Thanks, I just about get that. I should have looked for examples of parseValue is the mc source. By any change is there a way to stop this

[MiKeY_]

27 minutes ago, diesieben07 said:

I can just about make out that you are using raw types (IProperty prop). IProperty takes a type argument, you cannot just leave it out. IntelliJ warns about usage of raw types by default, you should not turn this warning off.

Wholesomely. Thanks for that I've sorted the error. Thanks for the suggestion. I make a point of not turning any warning off and figuring out why it's being pinged. I use a lot of different linters for the other languages I use so I'm pretty used to it.

 

Thanks again, I think I've got it from here... Hopefully