[1.9][UNSOLVED] Custom stairs blockstate .json not working w. upside-down stairs

[SuperGeniusZeb]

So I've been converting all my blocks to use the Forge blockstate .json format instead of the vanilla one, and changing my item models so that most block model jsons are unnecessary, allowing me to reduce the total number of .json files in my mod, which is pretty much entirely comprised of basic-shaped blocks (full cubes, slabs, stairs, fences, etc.) It has gone great so far up until this point. I'm currently trying to create a blockstates .json for my custom stairs using the Forge format. (In the example here its the "stairs_of_red_normal"... keep in mind that unlike my previous examples in my mod, the shade "normal" is not metadata here but just part of the name as the stairs metadata didn't have enough room for my "shade" property I used on my other blocks.)

 

I've created 2 model .jsons, "cube_quarter_horizontal" & "cube_eighth", which are basically equivalent to the top half of an outer stairs and the top half of a straight stairs respectively. I'm using these with the vanilla "half_slab" model to try and contruct the proper stairs shape using the forge blockstates .json format.

 

The stairs work perfectly for bottom half stairs, but for top half (upside-down) stairs, the models are the same as their top half counterparts (though the block itself changes). Interestingly, it looks like an east-facing stairs is the exception to the rule, as it DOES rotate the model 180 degrees when it is placed upside-down.

 

Looking at the .json, "east" is the only value of "facing" that does not have a y rotation specified (remember that y is left-right in block .jsons and x is up-down), so I have a feeling that there is a limit to the number of rotations you can apply to a model or submodel in the Forge blockstates format. Is this the case? Can I not rotate the entire model in more than one axis? Is this a limitation of Forge blockstates, vanilla, or is it a bug? Is there anyway around this? Logically, I would think that the .json I've created should work. Any ideas?

 

blockstates/stairs_of_red_normal.json (Forge blockstates .json)

{
"forge_marker": 1,
"defaults": {
	"textures": {
		"bottom": "colore:blocks/block_of_red_normal",
		"top": "colore:blocks/block_of_red_normal",
		"side": "colore:blocks/block_of_red_normal"
	},
	"model": "half_slab"
},
"variants": {
	"facing": {
		"east": {
		},
		"south": {
			"y": 90
		},
		"west": {
			"y": 180
		},
		"north": {
			"y": 270
		}
	},
	"shape": {
		"straight": {
			"submodel": {
				"quarter": { "model": "colore:cube_quarter_horizontal" }
			}
		},
		"outer_right": {
			"submodel": {
				"eighth": { "model": "colore:cube_eighth" }
			}
		},
		"outer_left": {
			"submodel": {
				"eighth": { "model": "colore:cube_eighth", "y": 270 }
			}
		},
		"inner_right": {
			"submodel": {
				"quarter": { "model": "colore:cube_quarter_horizontal" },
				"eighth": { "model": "colore:cube_eighth" , "y": 90 }
			}
		},
		"inner_left": {
			"submodel": {
				"quarter": { "model": "colore:cube_quarter_horizontal" },
				"eighth": { "model": "colore:cube_eighth", "y": 180 }
			}
		}
	},
	"half": {
		"bottom": {

		},
		"top": {
			"x": 180
		}
	}
}
}

 

models/block/cube_eighth.json (block model which is literally the vanilla outer_stairs model with the bottom slab shape removed and is used in outer & inner stairs shapes)

{
    "elements": [
        {   "from": [ 8, 8, 8 ],
            "to": [ 16, 16, 16 ],
            "faces": {
                "down":  { "uv": [ 8, 0, 16,  8 ], "texture": "#bottom", "cullface": "down" },
                "up":    { "uv": [ 8, 8, 16, 16 ], "texture": "#top", "cullface": "up" },
                "north": { "uv": [ 0, 0,  8,  8 ], "texture": "#side" },
                "south": { "uv": [ 8, 0, 16,  8 ], "texture": "#side", "cullface": "south" },
                "west":  { "uv": [ 8, 0, 16,  8 ], "texture": "#side" },
                "east":  { "uv": [ 0, 0,  8,  8 ], "texture": "#side", "cullface": "east" }
            }
        }
    ]
}

 

models/block/cube_quarter_horizontal.json (cube_eighth extended in the z direction and used for straight and inner stairs shapes)

{
    "elements": [
        {   "from": [ 8, 8, 0 ],
            "to": [ 16, 16, 16 ],
            "faces": {
                "down":  { "uv": [ 8, 0, 16,  8 ], "texture": "#bottom", "cullface": "down" },
                "up":    { "uv": [ 8, 8, 16, 16 ], "texture": "#top", "cullface": "up" },
                "north": { "uv": [ 0, 0,  8,  8 ], "texture": "#side" },
                "south": { "uv": [ 8, 0, 16,  8 ], "texture": "#side", "cullface": "south" },
                "west":  { "uv": [ 8, 0, 16,  8 ], "texture": "#side" },
                "east":  { "uv": [ 0, 0,  8,  8 ], "texture": "#side", "cullface": "east" }
            }
        }
    ]
}

[jeffryfisher]

Interestingly, it looks like an east-facing stairs is the exception to the rule, as it DOES rotate the model 180 degrees when it is placed upside-down.

When you rotate an asymmetric model 180 around z or x axis to turn stairs upside-down, then you will change one facing in the process (x-axis flips N-S; z flips E-W). If you have trouble visualizing this in your head, then get something wedge-shaped that you can turn in your hands.

 

Looking at the .json, "east" is the only value of "facing" that does not have an y rotation specified

Then for this particular model, the default facing is east (the rotation zero need not be written into the json file).

 

remember that y is left-right in block .jsons and x is up-down

Are you sure? I thought Y was vertical, hence rotating around it to face E-S-W-N. Don't confuse the axis of rotation with the faces around it. Get that wedge in your hands and start playing with it to see what I mean.

 

I have a feeling that there is a limit to the number of rotations you can apply to a model or submodel in the Forge blockstates format. Is this the case?

I think so: You may apply X, Y & Z rotations. That's 3 axes. You should never need more.

[SuperGeniusZeb]

Interestingly, it looks like an east-facing stairs is the exception to the rule, as it DOES rotate the model 180 degrees when it is placed upside-down.

When you rotate an asymmetric model 180 around z or x axis to turn stairs upside-down, then you will change one facing in the process (x-axis flips N-S; z flips E-W). If you have trouble visualizing this in your head, then get something wedge-shaped that you can turn in your hands.

 

Looking at the .json, "east" is the only value of "facing" that does not have an y rotation specified

Then for this particular model, the default facing is east (the rotation zero need not be written into the json file).

 

remember that y is left-right in block .jsons and x is up-down

Are you sure? I thought Y was vertical, hence rotating around it to face E-S-W-N. Don't confuse the axis of rotation with the faces around it. Get that wedge in your hands and start playing with it to see what I mean.

 

I have a feeling that there is a limit to the number of rotations you can apply to a model or submodel in the Forge blockstates format. Is this the case?

I think so: You may apply X, Y & Z rotations. That's 3 axes. You should never need more.

Whoops. Yeah, you're right about the axis. And I know the zero rotation didn't need to be written, but strangely enough, when I specify it to be zero, the east-facing stairs stops being an anomaly. But the thing about the x rotation is that it isn't even being applied at all. As in the upside-down stairs look identical to right-side-up stairs of the same "facing" and "shape" values. If I remove the y rotations, the x rotations suddenly work, but (of course) the stairs model will only face one direction.

 

So while yes, the models would look wrong if they were simply rotated 180 degrees in the x axis, that's not my problem because the models aren't getting rotated in the x axis at all. It's like it won't let me rotate the entire model in more than one axis at a time, so I can only have either y-rotation or x-rotation, but not both. Is this intended behavior, is it a bug, or am I missing something in my .json?

[jeffryfisher]

Because you're using submodels, I can't help any further. I just don't know how those pieces will be put together. Most of my experience is with 1.8 anyway, and I suspect that the json processing is still evolving.

 

In 1.8, I could use the Forge advanced json to separate modeling from texturing, but I could not use it to separate the different aspects of modeling. In other words, I could not use one property to choose a model, and then use a different property to set its rotation. All of the modeling had to be set together (model name, rotations, uv-lock...). I wasn't forced into a complete Cartesian product, but I did end up writing more tedious lines than I had expected.

 

[SuperGeniusZeb]

Because you're using submodels, I can't help any further. I just don't know how those pieces will be put together. Most of my experience is with 1.8 anyway, and I suspect that the json processing is still evolving.

 

In 1.8, I could use the Forge advanced json to separate modeling from texturing, but I could not use it to separate the different aspects of modeling. In other words, I could not use one property to choose a model, and then use a different property to set its rotation. All of the modeling had to be set together (model name, rotations, uv-lock...). I wasn't forced into a complete Cartesian product, but I did end up writing more tedious lines than I had expected.

 

Hmmm... it looks like I'm stuck then, unless someone else has an answer or the format gets updated. I guess I'll have to go back to the vanilla format. One more question, though. Is it possible to have define what happens if 2 or more properties are true in the Forge blockstates format? (As in ' "shade=true,half=false,north=true,shape=straight":{} ' like in the vanilla format or something like that.) Because I haven't found any examples where you can define what happens with more than one condition at a time, and I feel like that may be one advantage of the vanilla format that should be added to Forge's format if it doesn't already exist. If that's possible in the Forge format, I'll be able to still do what I want to do, albeit in a more lengthy way and using the vanilla stairs models instead of constructing models from submodels.