Some block states not available in model files (variant format only)

Also beds don't have the 'occupied' state (they do in the f3 menu but not in block state files).

Please add:

• tripwire: needs "powered" state (this is essential to replicate the original string movement of tripwire)

• dispenser and dropper: needs "triggered" state

• hopper: needs 'enabled' state

Recommendation for implementation:

Allow these missing states to not be looked for by the system in blockstate files and be used (I tried this by adding the 'occupied' state and 'has_record' and it doesn't work) but also allow the system to choose the closest available blockstate combo.

For example, if no 'occupied' state exists in a blockstate file, a bed foot would use "facing=north,part=foot". If you wanted a non-directional model, you could remove the 'facing' state and just have the state "part=foot" and all of the directions would fall back on that.

Further changes:
Blockstate files still need to be condensed, as they don't match their in-world usage. For example: wool, carpet, stained glass, stained clay all have dedicated blockstate files with "normal" variants rather than general files defining color variants.

Kinda fixed in 15w31a? Tested in 15w31c, but only with Jukebox.

While blockstate files are probably still hardcoded, the multipart feature isn't hardcoded, so I suspected it might fix it. Indeed it did, I used

{
    "multipart": [
        {"when": { "has_record": "false" }, "apply": { "model": "jukebox"}},
        {"when": { "has_record": "true" }, "apply": { "model": "jukebox_has_record"}}
    ]
}

For jukebox's blockstate file and it did indeed use the model I made for it that has a separate top texture. Success!

I'm not sure if the others are working through this method as well... some more testing might be in order to see what works and what doesn't (not too worried, but stuff like the TNT explosion state might be hardcoded on the backend, too), but I still

I tried doing it for the dispenser but it seems the "triggered" state is never enabled (another bug?).

For the hopper, after much tinkering I got it to work, but only after completely removing variants altogether and just using multi-part. So in that respect I'd assume the bug is somewhat fixed, but in another it seems variants are hardcoded to silently override unused states even if you explicitly give them multipart models... which increases the amount of work you'll have to do (requiring completely changing the hopper over to multipart even though it is a very good candidate for a disabled model part like a metal cover) so is kinda defeating the point of multipart.

Even if traditional variants aren't fixed to allow for setting these "unused" states, the overriding even when they are specified via multipart needs to be fixed. Too bad there isn't a "partially fixed" status.

Confirmed for 15w46a

Since much of these states are going to be gone in 1.10, this is not going to be changed now. I think you can use the properties through the multipart system, but expect some of them to simply disappear in the future.

Reiterating the fact that TNT's explode state is present again in the latest version. Testing is needed to see if it actually does respond to model changes.

hoppers' different states work as intended, however "Disabled" is not properly synced to the client, see MC-70127 and this is likely what is happening with droppers and dispensers too, as well as possibly sugarcane and cactus.

Bed has been fixed since 1.13; the metadata issue is gone due to metadata being gone.

Cannot reproduce in 1.19.4 for any of the block states mentioned. Using the following resource pack:

the only buggy states are hoppers, dispensers, droppers, sugar cane and cacti, which require right clicking to be updated. That issue is MC-70127 (which should probably be reopened since it was closed pre-Flattening and there's a Mojang comment alluding to the flattening resolving this in a way that never ended up happening).

I'm also unable to reproduce using the resource pack provided.