Minecraftforge: Forge block state ignore textures

Created on 16 Mar 2019  路  13Comments  路  Source: MinecraftForge/MinecraftForge

The following (forge) block state worked fine in 1.12.2:

{
"forge_marker":1,
"defaults":{
"textures":{
"plate":"bigreactors:block/turbine/legacy/housing.plate",
"machine":"bigreactors:block/turbine/legacy/creativesteamgenerator",
"particle":"#machine",
"down":"#machine",
"up":"#machine",
"north":"#machine",
"south":"#machine",
"west":"#machine",
"east":"#machine"
},
"model":"cube"
},
"variants":{
"afstate":{
"disassembled":{
},
"assemblednorth":{
"textures":{
"down":"#plate",
"up":"#plate",
"south":"#plate",
"west":"#plate",
"east":"#plate"
}
},
"assembledsouth":{
"textures":{
"down":"#plate",
"up":"#plate",
"north":"#plate",
"west":"#plate",
"east":"#plate"
}
},
"assembledwest":{
"textures":{
"down":"#plate",
"up":"#plate",
"north":"#plate",
"south":"#plate",
"east":"#plate"
}
},
"assembledeast":{
"textures":{
"down":"#plate",
"up":"#plate",
"north":"#plate",
"south":"#plate",
"west":"#plate"
}
},
"assembledup":{
"textures":{
"down":"#plate",
"north":"#plate",
"south":"#plate",
"west":"#plate",
"east":"#plate"
}
},
"assembleddown":{
"textures":{
"up":"#plate",
"north":"#plate",
"south":"#plate",
"west":"#plate",
"east":"#plate"
}
}
},
"portdirection":{
"outlet":{
},
"inlet":{
}
}
}
}

Now in 1.13.2 (Forge 25.0.84) the default textures block is not applied and the block show up in game with the missing-texture texture. Setting the textures in all the variants has no effect too.

Loading that blockstate give the following warnings from ModelBakery :

Unable to resolve texture reference: #down in minecraft:block/cube
Unable to resolve texture reference: #up in minecraft:block/cube
Unable to resolve texture reference: #north in minecraft:block/cube
Unable to resolve texture reference: #south in minecraft:block/cube
Unable to resolve texture reference: #west in minecraft:block/cube
Unable to resolve texture reference: #east in minecraft:block/cube

Also note that no error is emitted if the texture path is wrong (eg: "blocks" instead of "block")

Z

1.14 Bug

Most helpful comment

Just ran into this problem myself. Hopefully it can fixed because it will save me creating hundreds of JSON files.

All 13 comments

A more complete repro case would be helpful, as is I would have to recreate a lot of your code.

Sure, here you go:

https://github.com/ZeroNoRyouki/forgetest5615

I kept the original (1.12.2) forge block state for the 2 blocks the example add (you can find them in the mics creative tab, sorry no langs) with the exception of modid and directory names

For the "turbinefluidport" block, you can cycle the "afstate" property by clicking on the block. If you sneak, you cycle the "portdirection" property. The same goes for the "turbinecreativesteamgenerator" block but only for the "afstate" property (the other one is fixed for that block)

Also note that those blockstates define an "inventory" variant but that is flagged as an error:


 [Sound Library Loader/INFO] [minecraft/SoundManager]: Sound engine started
 [Client thread/WARN] [minecraft/ModelBakery]: Exception loading blockstate definition: 'forgetest5615:blockstates/turbinefluidport.json' in resourcepack: 'main' for variant: 'inventory': Unknown blockstate property: 'inventory'
 [Client thread/WARN] [minecraft/ModelBakery]: Exception loading blockstate definition: 'forgetest5615:blockstates/turbinecreativesteamgenerator.json' in resourcepack: 'main' for variant: 'inventory': Unknown blockstate property: 'inventory'
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to load model: 'forgetest5615:turbinefluidport#inventory' referenced from: forgetest5615:turbinefluidport#inventory: java.io.FileNotFoundException: forgetest5615:models/item/turbinefluidport.json
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to load model: 'forgetest5615:turbinecreativesteamgenerator#inventory' referenced from: forgetest5615:turbinecreativesteamgenerator#inventory: java.io.FileNotFoundException: forgetest5615:models/item/turbinecreativesteamgenerator.json
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #down in minecraft:block/cube
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #up in minecraft:block/cube
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #north in minecraft:block/cube
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #south in minecraft:block/cube
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #west in minecraft:block/cube
 [Client thread/WARN] [minecraft/ModelBakery]: Unable to resolve texture reference: #east in minecraft:block/cube
 [Client thread/INFO] [minecraft/TextureMap]: Max texture size: 8192

Just as a note: It says FileNotFoundException - I'm pretty sure that's your fault... (Though this exception message isn't the nicest...)

Nop, the exception itself is correct: the file do not exist. And it did not exist in 1.12.2 / 1.11.x / 1.10.x too

It should resolve the "inventory" variant using the forge block state, not by looking for an "external" model for the item

It appears the BlockState loading hooks have not been ported into 1.13, and thus the 'ForgeBlockstate' doesn't exists.
If someone wants to take a look into this that know more about rendering then I do then go for it. I wrote the original permutation hooks, but fry came along behind me and expanded it into a format I don't know anymore.

it seems like BlockStateLoader$ForgeVariant#process is never called and thus the textures never get overwritten. The forgeblockstae itself is there though.

Just ran into this problem myself. Hopefully it can fixed because it will save me creating hundreds of JSON files.

This is still an issue. Currently using forge-1.14.2-26.0.33

This issue appears to still be present as of forge-1.14.3-27.0.25, so I think we should update the tag to 1.14

I'm using a custom json model however, so this might not be the same exact repro as @ZeroNoRyouki & @MrCrayfish . The model refers to #texture which is defined in my BlockState, like in 1.12

{
  "forge_marker": 1,
  "defaults": {
    "model": "placeableitems:bone",
    "textures": {
      "texture": "placeableitems:block/bone"
    }
  },
  "variants": {
    "": [ { } ]
  }
}

However I'm getting the error

[minecraft/ModelBakery]: Unable to resolve texture reference: #texture in placeableitems:block/bone

I have a very basic commit you can have a look at for a minimal example

Using Forge 1.14.3-27.0.60
Additional information
It does not appear that texture overrides due to a variant property are being utilized at all either.

eg:

    "variants": {
        "int_prop": {
            "1": {
                "textures": {
                    "overlay": "harderores:block/ore/overlay_1"
                }
            },
         ...

That overlay texture override never gets used when rendering. Instead only the original texture specified in the model gets rendered. Using the debugger and examining the Forge BlockStateLoader it does correctly parse the JSON and generate the correct variants with the correct textures, correctly identifies "not vanilla compatible" and inserts the correctly constructed object into a list of models that eventually get baked.

As far as I can tell, its not an issue with parsing the JSON, constructing models, or baking those models, but in the game deciding how to render the variant.

The only thing that will cause a change in displayed texture is providing a new model which points to a different texture. If this is intentional on the part of Forge, then it should be noted on the update notes gist: https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a

@tterrag1098 Since we were able to reproduce on the latest version, and in 1.14, would it be possible to update the issue title & tags? Unless you need something more to help reproduce, in which case let me know!

From what I can tell, I think the problem is with the baking process itself. In VariantList.bake(), the textures data is entirely ignored and not passed down to the model that's baked.

Should be fixed as of 28.1.40 / 5e9380ab85c1365dbc4fde262628bc9095f3a294

Was this page helpful?
0 / 5 - 0 ratings