Directional Blocks w/ Blockstates

[PhoxLogic]

I am fairly inexperienced with modding, having only created simple item/tool/block/armor mods with very minimal amounts of content in them. Recently, I've been trying to take some of those old mods and improve them, adding more interesting items and advanced things such as tileEntities while also porting them to more recent Minecraft versions (1.10.2 to be specific). However, I am fairly new to the BlockState and property-based metadata features introduced in 1.8. I am trying to use them to create a block which is rotated based on which direction you are facing when it is placed, as the block in question will eventually become a machine block. I want to figure out exactly how to implement directional properties before coding something that advanced. Here's the code I currently have for the block (with the package reference and imports taken out because they aren't important and I would imagine they're obvious to experienced Forge programmers):
 

public class BlockInfuser extends BlockBase {
	public BlockInfuser() {
		super(Material.ROCK, "infuser");
		this.setDefaultState(this.blockState.getBaseState().withProperty(FACING, EnumFacing.NORTH));
	}
	
	public static final PropertyDirection FACING = PropertyDirection.create("facing", EnumFacing.Plane.HORIZONTAL);
	
	@Override
	protected BlockStateContainer createBlockState() {
		return new BlockStateContainer(this, new IProperty[] { FACING });
	}
	
	@Override
	public IBlockState getStateFromMeta(int meta) {
		return getDefaultState().withProperty(FACING, meta == 0 ? EnumFacing.SOUTH : EnumFacing.EAST);
	}
	
	@Override
	public int getMetaFromState(IBlockState state) {
		EnumFacing facing = (EnumFacing) state.getValue(FACING);
		return facing.getHorizontalIndex();
	}
}

 

One thing worth noting is I'm aware that the setDefaultState action isn't in a particularly great location in terms of priority and I plan to change it.
As for the actual issue I have... I have an extension of PropertyDirection created, but in its current state it does nothing. I suspect that it's incomplete, and I'm missing several lines of code. The issue is, I haven't figured out exactly what that is yet. I've been looking online, and while I've seen plenty of things which have helped me (that's how I got this far in the first place)... Nothing I've seen has demonstrated how to use them. What I do know is that there are two actions, getBlockState and setBlockState, and that somehow I need to use these to achieve the effect I desire. But, I don't know exactly how to declare them. Would I use an Override identifier and declare it with some sort of constructor and body much like the other implementations? Or am I missing a much bigger picture?

[Draco18s]

What do you mean "it does nothing"?

2 minutes ago, PhoxLogic said:

What I do know is that there are two actions, getBlockState and setBlockState, and that somehow I need to use these to achieve the effect I desire. But, I don't know exactly how to declare them.

Do you remember world.setBlockWithMetadata()?

That's what setBlockState does (only there's no longer a "metadataless" version; setBlock).

[PhoxLogic]

28 minutes ago, Draco18s said:

What do you mean "it does nothing"?

What I mean is, the block I have won't actually update its direction/place a block with the correct metadata like I thought it would. The code doesn't throw any errors or anything, the game runs fine, and the block registers properly. But, the blockstate JSON file I made for it still doesn't seem to read any facing: <direction> values because, from what I can tell, I don't have anything to actually set them. Thus, the result is a block with the infamous checkerboard texture and a default facing value (in this case, south). I have attached a picture of what it looks like in-game, with the debug screen open to show the facing:south metadata. Again, the only thing here I'm trying to figure out is how to properly use setBlockState. From what I've gathered, you would use it with world interaction events in this case, correct?

And, no, I don't remember setBlockWithMetadata(). But judging by the name of it and its no-meta partner setBlock, I can probably guess what it does. I think I see at least part of what's wrong with how I'm approaching this now, in fact. What I thought of setBlockState was that it only updated the metadata/properties. Didn't realize it essentially places a whole new block. ...That's what you're saying it does, right? If so, would that mean I basically just take the block as soon as it's placed in the world and replace it with that same type of block using updated property values based on what cardinal direction the player is facing?

 

Either way, there's another thing on my mind about it... I wonder if there's an error in the JSON file along with the incomplete property implementation I have in my code. I had a working JSON blockstate and model file before, with the only problem being it always faced north. Once I replaced the "normal" variant with the cardinal directions, the checkerboarding texture began showing up again, much the same way that it does when Forge can't find a model file/the model file has errors. But, the default cardinal direction changed from north to south on the block, which means it's definitely at least defining a default value. And with that being the case... Wouldn't it at least display the correct south-facing variant if all was well with the JSON code?

[Alexiy]

Are your json files' names lowercase?

[Draco18s]

11 hours ago, PhoxLogic said:

What I mean is, the block I have won't actually update its direction/place a block with the correct metadata like I thought it would.

You want your block to place down with the facing based on which direction the player is looking?

 

Go look at BlockFurnace to see how that block does it. Just adding the facing state value doesn't magically make the block place down with a specific state. Ladders are horizontal blocks too, and those face a direction based on what block they're placed on.

 

11 hours ago, PhoxLogic said:

And, no, I don't remember setBlockWithMetadata()

....what versions have you modded for before?

 

11 hours ago, PhoxLogic said:

Didn't realize it essentially places a whole new block. ...That's what you're saying it does, right?

Yes, but no, but yes, but no.

If the block at the position is already the block being placed, then all that changes is the state (the metadata). If not, then it becomes that block too.

11 hours ago, PhoxLogic said:

I wonder if there's an error in the JSON file along with the incomplete property implementation I have in my code.

There is not. If there was, the game would complain about it. Or maybe there is, because your block is still a black and purple cube, but I can tell that this is not the problem you're concerned about at the moment.

[PhoxLogic]

1) That's... actually a really good idea. Thank you.
2) Failed attempt at 1.6 due to errors/issues with my workspace setup (that's when I was really green), basic 1.7.10 mods which never got more complicated than adding ores to worldgen, and my most recent attempts being this.
3) Okay, that makes sense.
4) Yeah that's not what I'm concerned about right now. I've worked with JSON models enough to know how to troubleshoot those, I'll cross that bridge when I actually get to it.

[PhoxLogic]

UPDATE: It works! By implementing logic very similar to the furnace code, the block now faces the correct directions! It was actually a lot easier than I thought it was going to be, I was definitely overthinking the problem. However, now it is time to iron out the JSON errors, for even though the metadata is correct... I've still got the checkerboard model & texture. Thank you for helping with this, I appreciate it.

QUICK EDIT: The JSON file was easy to fix. Only thing wrong with it was I put quotes around the y rotation values. The block works exactly as intended now.

Edited December 2, 2017 by PhoxLogic
Fixed another error I was discussing

[PhoxLogic]

Okay, I spoke too soon. Now there's a new issue. It's small, but still a problem. Everything works as intended... until I log out of the world. Once I log back in, any block not facing South will be reset to face East. My guess is that I missed something I'm required to do on one of the sided proxies? I'll start looking around on the web and within the code to see if I can find whatever it is I missed.

Edited December 3, 2017 by PhoxLogic

[Draco18s]

	@Override
	public IBlockState getStateFromMeta(int meta) {
		return getDefaultState().withProperty(FACING, meta == 0 ? EnumFacing.SOUTH : EnumFacing.EAST);
	}

 

What happens when the FACING value (when saved, via getMetaFromState) was NORTH?

[PhoxLogic]

If the FACING value is NORTH, it will still default to EAST when I log out and log back in. Only values that keep their rotation are SOUTH and EAST (the latter of which I have a hard time verifying properly because both NORTH and WEST default to EAST - are all 3 trying to do that with EAST not seeming to change simply because that's what it already was, or is it just the other two?)

[PhoxLogic]

Okay, I think I see what was wrong. I misused the ternary operator. Simple logical error.

[Draco18s]

Sigh.

 

EnumFacing.getHorizontal(meta)

[PhoxLogic]

EnumFacing.getHorizontal(meta)

Oh, are you saying to completely remove the ternary operator and replace it with that? That does make sense. Although, I was actually able to get the block working using nested ternary operators. A sloppy way to do it, I know, but it definitely worked. I'll give that other line a try though, I'm sure it's much simpler. It'd certainly look a lot cleaner.

[Draco18s]

7 hours ago, PhoxLogic said:

Oh, are you saying to completely remove the ternary operator and replace it with that?

Yes. Because the ternary operation for 4 linear values (that map neatly to an index) is...

8 hours ago, PhoxLogic said:

sloppy

Oh you said it before I did.