Feedback wanted on a possible new blockstates JSON format

[SuperGeniusZeb]

In my previous topic, I discovered that the Forge blockstates format still doesn't support models like stairs, mainly due to the fact that multiple-condition-tests are not possible. (They're possible in the vanilla format.) See my previous topic here: http://www.minecraftforge.net/forum/index.php?topic=43581.0

 

And so, I decided to try and fix the problem with a new blockstates format. Here is my first draft/concept:

 

{ //This format is intended to be capable of everything the current format is capable of, as well as what the vanilla format can currently do that the Forge format cannot
    "forge_marker": 2,
    "defaults": { //Required (as opposed to optional in the current Forge format) because "variants" system does not force every possible combination of values to be defined
	"model": "mymod:model1",
	"textures": {
		"texture1": "mymod:block/texture_name",
		"texture2": "mymod:block/another_texture",
		"a_submodel_texture": "mymod:block/default_texture_for_a_submodel_if_present"
	},
	"uvlock": false
},
    "variants": [ //Optional
	{
		"conditions": { //Allows for checking multiple conditions, which is necessary for things like STAIRS to be possible without using the vanilla format
			"property1": "this_value", //value can be string, int, or bool, depending on the property's type
			"property2": "this_other_value"
		},
		"model": "mymod:model2", //replaces default model
		"textures": {
			"texture1": "mymod:block/texture_name",
			"texture2": "mymod:block/another_texture"
		},
		"x": 90
	},
	{ //Condition-sets are tested and variations are applied in sequence/order, so the sets defined last have highest priority and can override previous values
		"conditions": {
			"property1": "this_value",
			"property3": true
		},
		"submodel": "mymod:model2", //is added to existing model, like in current Forge blockstate format
		"textures": {
			"example_texture_param": "mymod:block/texture_name"
		},
		"y": 180,
		"uvlock": true
	},
	{ //Since this condition/model-set is defined last, and can override anything set by the previous sets, like the main model's x-rotation'
		"conditions": {
			"property4": "another_value"
		},
		"submodel": { //Demonstration of multiple submodels
			"a_submodel_name": {
				"model": "mymod:the_model_used_by_the_submodel",
				"x": 180
			}
		},
		"textures": {
			"texture2": "mymod:block/placeholder_texture_name",
			"submodel_texture:": "mymod:block/texture_used_by_submodel"
		},
		"x": 270,
		"uvlock": true
	}
]
}

 

I am almost certain I've made some mistake or overlooked something important (and even if I haven't, I'd like to make sure), so that's why I'm posting it here to get some feedback. What do you think should be improved/changed? Would this be possible to actually implement into Forge, or is there some internal code limitation I'm not aware of? Please let me know what you think so I can revise this conceptual format as needed.

 

My goal was to make a format that does everything the current Forge blockstates format does, as well as everything the vanilla format is capable of that the Forge format is not. I've based this format off of the current Forge blockstates format, which you can see in the official Forge docs, as well as the vanilla format, which you can see an example of by looking through the vanilla assets and opening the stairs and fence blockstate files, which give examples of the "variants" & "multipart" system that vanilla uses in its blockstates format.

 

Thank you ahead of time for your help & feedback!

[Animefan8888]

Ok quick question when you say "multiple-condition-tests are not possible" do you mean you can't do this

"connected_down=true,connected_east=true,connected_north=true,connected_south=true,connected_up=true,connected_west=true":{
	"model": "cube_all"
},

or like this

"connected_down=true": {
     "connected_up=true": {
          // Do stuff
     }
}

[Draco18s]

Ok quick question when you say "multiple-condition-tests are not possible" do you mean you can't do this

"connected_down=true,connected_east=true,connected_north=true,connected_south=true,connected_up=true,connected_west=true":{
	"model": "cube_all"
},

 

That is what he wants to avoid, aka the Vanilla Blockstate System.

He wants something more like the latter because you can't do this:

 

"connected_down=true": {
"y":90
}
"connected_east=true": {
"x":90
}

[SuperGeniusZeb]

Ok quick question when you say "multiple-condition-tests are not possible" do you mean you can't do this

"connected_down=true,connected_east=true,connected_north=true,connected_south=true,connected_up=true,connected_west=true":{
	"model": "cube_all"
},

or like this

"connected_down=true": {
     "connected_up=true": {
          // Do stuff
     }
}

Well, you can't do either, so I guess the answer to your question is... yes? Your first example resembles the vanilla format, but that format is rather difficult-to-read/messy-looking, hence my use of a "conditions" group to make things more structured and organized. I'm not sure its the best solution to the problem, though. The problem with the current Forge blockstates format is that you can't have a model/texture applied based on if 2 or more conditions are true. Changes can only be applied on a single-condition basis. This is where the vanilla format has an advantage over the Forge format. (Though the way it handles it is somewhat clunky.)

[trollworkout]

IMHO I don't like the current forge-model spec 1 blockstate AND model. Is confusing as heck. I understand it's usefulness and I have debated using it a couple of time but I always o back to vanilla json specs. Choonster is been kind enough to educate people but I don't think everyone fully understands everything about forge blockstate.

 

This spec 2 seems quite alien as well and quite confusing as 1 was. Just being honest.

 

For ex here is Vanilla MC coarse dirt

 

blockstate

{
    "variants": {
        "normal": { "model": "coarse_dirt" }
    }
}

 

model

{
    "parent": "block/cube_all",
    "textures": {
        "all": "blocks/coarse_dirt"
    }
}

 

Here is same block as forge 1 spec 

{
    "forge_marker": 1,
    "defaults": {
        "textures": {
            "all": "blocks/coarse_dirt"
        },
        "model": "cube_all",
        "uvlock": true
    },
    "variants": {
        "normal": [{

        }]
    }
}

 

Why so complicated?

 

 

I suggest making forge spec 2 a supplement of vanilla blockstate instead of it's whole new thing. 

 

For ex say I wanan render same block above on the translucent layer

 

{
    "variants": {
        "normal": { "model": "coarse_dirt", "translucent" : 1 }
    }
}

 

The idea is the forge's own blockstate/json simply adds stuff to vanilla specs and by default every forge json would work vanilla + forge extensions so you would not need forge_marker.

 

 

Also you can in fact combine them hierarchically like forge would do like for ex both of those could be 

{
    "variants": {
        "normal": { 
          "parent": "block/cube_all",
          "textures": {
             "all": "blocks/coarse_dirt" 
          }, 
          "translucent" : 1 
       }
    }
}

 

Or may be even "layer" : "translucent"

 

the point is everything forge has to offer can be added on top of current MC json spec rather than have it be it's own thing it's whole new thing.

[Draco18s]

Here is same block as forge 1 spec 

{
    "forge_marker": 1,
    "defaults": {
        "textures": {
            "all": "blocks/coarse_dirt"
        },
        "model": "cube_all",
        "uvlock": true
    },
    "variants": {
        "normal": [{

        }]
    }
}

 

Why so complicated?

 

Because you're wrong.  Here's the same block using the Forge format:

 

{
    "forge_marker": 1,
    "variants": {
        "normal": { "model": "coarse_dirt" }
    }
}

 

Magic!

 

All those other lines are options.  You can set up defaults and override them with variants (or not!).  The "defaults:{}" block is actually a way to simplify the format, so rather than having to specify the same thing over and over again, you specify it once.

[trollworkout]

More proof of what I said forge spec is confusing.

 

Forge model should be an extension of vanilla json specs and not add it's own blocks. They seem extra and confusing.

 

I'd rather see all that extra functionality as as properties on blocks that already exist.

 

That's my humble opinion. I appreciate the work everyone has done here so mind you this is just my humble opinion as a user.

[Draco18s]

Forge model should be an extension of vanilla json specs and not add it's own blocks.

 

You can't have your cake and eat it too.  In order to extend the spec it must add new sections.

[jeffryfisher]

The Forge format DOES allow multiple tests. What it doesn't enable is disjoint rotations (one property setting x, and another property setting y). That's a vanilla limitation: Rotation is an atomic (indivisible) value having an x and a y value (zero if you don't specify).

 

Maybe someday Forge can improve on the vanilla rotation array, but I'm not holding my breath.

[SuperGeniusZeb]

The Forge format DOES allow multiple tests.

Please show me how.

[Draco18s]

The Forge format DOES allow multiple tests.

Please show me how.

 

{
    "forge_marker": 1,
    "defaults": {
        "textures": {
            "particle": "blocks/log_oak"
        },
        "model": "harderores:axel",
        "uvlock": true
    },
    "variants": {
        "normal": [{ }],
        "inventory": [{
            "y": 0
        }],
        "axel_orientation": {
            "none": { },
            "gears": {
                "model": "harderores:frame"
            },
            "hub": { },
            "up": {
                "x": 270
            }
        },
        "facing": {
            "north": {
                "y": 0
            },
            "east": {
                "y": 90
            },
            "south": {
                "y": 180
            },
            "west": {
                "y": 270
            }
        }
    }
}

 

Note how the state GEARS,NORTH results in a different model and a given rotation than NONE,WEST does.

And it looks like I have the two-rotations you desire, but that's actually false, because UP doesn't pay attention to the facing (I cheated the state system a little: I was able to move the one additional direction I needed into the axel_orientation property rather than needing the extra bit for facing).

 

Edit:

You could also use a custom StateMapper to handle things too.  Have two different models (one pre-rotated around the X axis) and on that property, load one model or the other, then the other property is free to modify the rotation.

I do something like that myself:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/flowers/states/StateMapperFlowers.java