Non-working JSON

[Koward]

Hi.

 

I'm trying to make a slab model, and I'm getting upward references exception. But I really don't see where I put the cart before the horse.

The block has two properties, enum "variant" and boolean "snowy".

 

Blockstate JSON : https://hastebin.com/netecubaji.json

Model JSON : https://hastebin.com/zucijeqari.json

Log of a run : https://hastebin.com/ebavohanip.md

Screenshot ingame : http://i.imgur.com/jQzShNq.png

 

Note I only get errors for #side, but no textures are displayed at all.

[Choonster]

You need to use Forge's blockstates format to specify textures in the blockstates file, you're using the vanilla format.

 

There's also not much point in extending a model with elements (e.g.

minecraft:block/half_slab

) if your model has its own elements, the parent's elements will be overwritten.

 

Using Forge's blockstates format or a vanilla model that specifies all of the textures should resolve the "Unable to resolve texture due to upward reference" errors.

[Koward]

Can we even specify combinations with the Forge format ? My snowy variant don't always apply the same textures when true, it depends of the variant used.

All I have ever seen is

{
    "forge_marker": 1,
    "defaults": {
    },
    "variants": {
        "my_boolean_property": {
            "true": {
            },
            "false": {
            }
        },
        "my_enum_property": {
            "a": {
            },
            "b": {
            },
            "c": {
            }
        }
    }
}

I would need to get the boolean property inside each of enum options. Is it supported ?

This is not obvious by the doc http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/ .

The way the vanilla formats are described at http://minecraft.gamepedia.com/Model looks much more complete and reliable.

[Draco18s]

If you mean "bool=true,enum=a":{ texture{ ... } } (and only in this case) then no, you can't.  Not with the Forge method.

[Koward]

The multipart format don't see to support textures unfortunately. Does that mean I'll have to make 3*2 models (+1 for the parent) ?

[Draco18s]

You could either do separate models for one of the properties (if that'd work, it might not depending on what you're doing) or you could use the vanilla variant format.

[Choonster]

Forge's blockstates format does allow fully-specified variants, i.e. variants that specify a value for multiple properties. These can still define textures like other variants.

 

You can see an example of this here. All the variants are fully-specified and one defines a unique texture.

[Draco18s]

Forge's blockstates format does allow fully-specified variants, i.e. variants that specify a value for multiple properties. These can still define textures like other variants.

 

I consider that to be the vanilla syntax. While the forge format supports it, it is still the vanilla syntax.

[Koward]

Forge's blockstates format does allow fully-specified variants, i.e. variants that specify a value for multiple properties. These can still define textures like other variants.

That's amazing.

I consider that to be the vanilla syntax. While the forge format supports it, it is still the vanilla syntax.

Still, the ability of setting just some different textures at the blockstate level is great, that reduce the number of files quite a lot.

My problems are solved, thanks a lot guys.

[Draco18s]

Still, the ability of setting just some different textures at the blockstate level is great, that reduce the number of files quite a lot.

My problems are solved, thanks a lot guys.

 

Or in some cases, makes things a lot more complicated.

For example, I had this:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/oreflowers/blockstates/oreflowers1.json

And I wanted to add a property called "tall" which would indicate that the plant was 2 blocks high and if "tall" was true, use a different texture (for the lower half).  Except that not all of my plants were "valid" if tall was true (incidentally it applies to like four to six things out of about 36, but as which four weren't discovered/created at the same time, it wasn't going to be easy to refactor other code to migrate those four to their own block).  So I was either going to have to use the vanilla syntax 16 2-prop entries per file across 4 files; with another 2 files having 2 entries) or find another way to handle it.

 

I ended up using a custom state mapper to map the "tall" state so that it pointed at a different resource file:

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/oreflowers/blockstates/oreflowers1_tall.json

[Koward]

I'd like to reup this thread. In the end I have never managed to do what Choonster did in his mirror_plane.json.

The json is here : http://pastebin.com/8PRtt1YD

The log is here : http://pastebin.com/mPGEPdLs

 

As you can see, the variants can't be found. The items freak out too.

 

When using vanilla variants that points to separate models, everything works, but it takes a lot of short json files.

[Choonster]

That's strange. I can't see any obvious problems with your blockstates file, so I'm not sure why the variants aren't being found. You could try setting some breakpoints in the model loading code to see if you notice anything going wrong.

 

Could you create a Git repository for your mod (if you haven't already done so) and link it here? I'll try to do some debugging and find the source of the issue.

[Koward]

That's strange. I can't see any obvious problems with your blockstates file, so I'm not sure why the variants aren't being found. You could try setting some breakpoints in the model loading code to see if you notice anything going wrong.

 

Could you create a Git repository for your mod (if you haven't already done so) and link it here? I'll try to do some debugging and find the source of the issue.

 

I have a Github repository here : https://github.com/Koward/BetterWithMods/commits/ground

(It's a fork, I'm only contributor)

After the commit 817a the models don't work (Forge format). Before that it works using multiple models and vanilla format.

 

I really wonder how something like that can happen. I don't use any special state mapper.

[Choonster]

Forge's blockstates format assumes that all non-array values of "variants" are objects with at least one property. The "snowy=false,variant=dirt" variant is an object without any properties, so the deserialiser (ForgeBlockStateV1.Deserializer#deserialize) calls Iterator#next on the object's entry set iterator and causes a NoSuchElementException to be thrown. To fix this, add a property to the variant (even a dummy value not used by the format will work).

 

Forge's blockstates format also assumes that any object values of "variants" with an object as their first value aren't fully-defined variants. All of the variants in your blockstates file that specify custom textures have an object as their first value, so the deserialiser condenses them together instead of treating them as fully-defined variants. To fix this, add a property before the "textures" property in each of the variants (again, dummy values will work here).

 

These assumptions aren't really documented anywhere (except a comment in the deserialiser mentioning the second) and I didn't know about them before this.

 

Both the Forge and Vanilla blockstates formats expect models to be specified in the format "[domain]:[path]", which will be converted to assets/[domain]/models/block/[path].json. You have an extra block/ prefix for the default model.
 
You can see these fixes applied to your blockstates file here.

Edited May 3, 2017 by Choonster
Fixed formatting errors caused by forum migration. Fixed typo.

[Koward]

I would never have been able to find this, thank you.

I have a new bug with the grass slab whose color is not correct anymore, but I'm sure that's not as tricky as the previous issue.

EDIT : fixed by setting the model at the variant level (each time setting block/half_slab). So no dummy needed anymore. Maybe that's why the format requires it ?