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?