Jump to content

Feedback wanted on a possible new blockstates JSON format


SuperGeniusZeb

Recommended Posts

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! :D

Colore - The mod that adds monochrome blocks in every color of the rainbow!

http://www.minecraftforge.net/forum/index.php?topic=35149

 

If you're looking to learn how to make mods for 1.9.4, I wrote a helpful article with links to a lot of useful resources for learning Minecraft 1.9.4 modding!

 

http://supergeniuszeb.com/mods/a-helpful-list-of-minecraft-1-9-4-modding-resources/

Link to comment
Share on other sites

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
     }
}

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

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
}

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.)

Colore - The mod that adds monochrome blocks in every color of the rainbow!

http://www.minecraftforge.net/forum/index.php?topic=35149

 

If you're looking to learn how to make mods for 1.9.4, I wrote a helpful article with links to a lot of useful resources for learning Minecraft 1.9.4 modding!

 

http://supergeniuszeb.com/mods/a-helpful-list-of-minecraft-1-9-4-modding-resources/

Link to comment
Share on other sites

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.

Disclaimer:  I been told to keep my opinions to myself, to shut up and that I am spreading lies and misinformation or even that my methods are unorthodox and or too irregular. Here are my suggestions take it or leave it.

Link to comment
Share on other sites

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.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.

Disclaimer:  I been told to keep my opinions to myself, to shut up and that I am spreading lies and misinformation or even that my methods are unorthodox and or too irregular. Here are my suggestions take it or leave it.

Link to comment
Share on other sites

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.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

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.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

The Forge format DOES allow multiple tests.

Please show me how. :P

Colore - The mod that adds monochrome blocks in every color of the rainbow!

http://www.minecraftforge.net/forum/index.php?topic=35149

 

If you're looking to learn how to make mods for 1.9.4, I wrote a helpful article with links to a lot of useful resources for learning Minecraft 1.9.4 modding!

 

http://supergeniuszeb.com/mods/a-helpful-list-of-minecraft-1-9-4-modding-resources/

Link to comment
Share on other sites

The Forge format DOES allow multiple tests.

Please show me how. :P

 

{
    "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

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.