Blockstates json ignoring default model

[jeffryfisher]

I just can't seem to wrap my head around the rules for the blockstates json file. I have the Forge Blockstates doc open, and I am copying the example almost verbatim, but every permutation I try just ignores any mention of "model" in the default section, resulting in hundreds of model-not-found errors on launch.

 

And yes, I am using JSON-lint to validate my json scripts.

 

My situation is that I have 7 blocks, each of which has the same 16 states. In one state, they use one model. In all other states, they use a different model. My trouble is my various attempts to define the default model shared by the 15 states. Even more frustrating, I can't even define a default model when I leave out the variants completely. Here are some of my attempts, all of which seemed perfectly valid at the time. Every single one of these is valid JSON according to jsonlint.com so why don't they work???

 

First, the example in the Forge doc that I am attempting to adapt:

{
"defaults": {
        "textures": {
            "all": "blocks/dirt"
        },
        "model": "cube_all",
        "uvlock": true
    }
}

 

Testing a default model with no variants:

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/quartz_ore" },
      "model" : "pressure_plate_down"
  }
}

Result: Mega spew of exceptions because the "variants" block is missing. Don't try this at home 

 

Testing a default model with only a "normal" variant:

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/quartz_ore" },
      "model" : "pressure_plate_down"
  },
  "variants": {
      "normal": [{
      }]
  }
}

Result: Missing model warnings for every possible state 0..15

 

Using a default model with one odd-ball variant to replace the model for just one state:

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/hay_block_side" },
      "model" : "pressure_plate_down"
  },
  "variants": {
    "power=0": {"model" : "pressure_plate_up"}
  }
}

Result: Missing model warnings for states 1..15

 

Using an inequality expression in the variants frame (between =0 and >0, I cover every possible state, so why doesn't this work???):

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/grass_top" }
  },
  "variants": {
    "power=0": {"model" : "pressure_plate_up"},
    "power>0": {"model" : "pressure_plate_down"}
  }
}

Result: Missing model warnings for states 1..15

 

My conclusions:

 

1) The documentation for default models is inaccurate or obsolete. How do I set a default model so I need only define the oddball(s) in the variants frame?

 

2) I don't understand how to state an inequality to cover a range of variants. Can anyone provide an example and/or rules?

 

3) This would be so f*kking easier if I were allowed to write my own predicate in Java! Just pass me a state and let me return a class instance that can answer calls to getModel, getTexture etc. I understand that MC wants to "bake" the final images ahead of display, but it should be possible for a block to provide a closed set and a method to choose among the set's entries.

[LexManos]

Inequalities and stuff like that don't work.

You have to specify all your variants. This isn't magic you have to tell it what states your block has.

[jeffryfisher]

OK, I can understand that the inequality won't work. But what about having a model in the default section? How do I get that work? The example shows a model in a defaults section, but I haven't found any way to get any states to use any default model. What is wrong with my model in the defaults section?

 

As for magic, some code is enough aware of the possible states to complain about each and every one of them. What would be really useful is if, on its way to the warning message, that code looked at the default model and used it. Alternatively, when a default model is first read in, populate the block's state map with it. When the variants are read, only replace models in the variants' declared cases, leaving other defaults undisturbed. Either way, one would end up with a table having models for all the states.

[jeffryfisher]

OK, I finally, begrudgingly, under duress, bit the bullet and spewed out five blockstates.json files, each with the same horribly ugly, embarrassingly inelegant, exhaustive variants section. Here's one:

 

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/quartz_ore" }
  },
  "variants": {
      "power=0": { "model": "pressure_plate_up" },
      "power=1": { "model": "pressure_plate_down" },
      "power=2": { "model": "pressure_plate_down" },
      "power=3": { "model": "pressure_plate_down" },
      "power=4": { "model": "pressure_plate_down" },
      "power=5": { "model": "pressure_plate_down" },
      "power=6": { "model": "pressure_plate_down" },
      "power=7": { "model": "pressure_plate_down" },
      "power=8": { "model": "pressure_plate_down" },
      "power=9": { "model": "pressure_plate_down" },
      "power=10": { "model": "pressure_plate_down" },
      "power=11": { "model": "pressure_plate_down" },
      "power=12": { "model": "pressure_plate_down" },
      "power=13": { "model": "pressure_plate_down" },
      "power=14": { "model": "pressure_plate_down" },
      "power=15": { "model": "pressure_plate_down" }
  }
}

 

Ugly yes, but at least it now works. I love Big Brother!

 

No not really... In my heart, I am still plotting revolution. I will live for the day when a default model can fill the gaps among sparse variants. Viva defaults! I'd even be willing to take a swing at the coding such a feature if anyone can point me to the relevant method(s).

[LexManos]

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/quartz_ore" },
      "model": "pressure_plate_down" 
  },
  "variants": {
      "power": { 
          0: {"model": "pressure_plate_up"},
          1: {},
          2: {},
          3: {},
          4: {},
          5: {},
          6: {},
          7: {},
          8: {},
          9: {},
          10: {},
          11: {},
          12: {},
          13: {},
          14: {},
          15: {}
       }
  }
}

Something like that should work, haven't tested it but it's the idea.

1.9 expands things to have predicates which can make this a little better but we'll see when it actually goes live and we see what we can deal with.

Or, if you use POWERED as a unlisted property in getActualState and then filter out the power you can do this:

{
  "forge_marker" : 1,
  "defaults": {
      "textures" : { "texture": "blocks/quartz_ore" },
      "model": "pressure_plate_down" 
  },
  "variants": {
      "powerd": { 
          "true": {},
          "false": {"model": "pressure_plate_up"}
       }
  }
}