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.

Can you confirm if there are any that will likely NOT be removed? Yeah, some of these don't currently work right (and like some of the growth stuff, was likely internal stuff only, didn't act right when you could see it) but some should already work provided you fully use multipart, and some of these are really useful to have.

Redstoners would greatly benefit from being able to use a resource pack that can make disabled hoppers look different (this works) and when command blocks are activated (especially since chain command blocks are a thing, but this might not work). Activated tripwire/ filled jukebox stuff is also useful (I can confirm has_record works perfectly already) and good for aesthetics.

It makes sense to lose:

• bed occupied state: minor aesthetics and likely internal only in a buggy way

• reeds/cactus growth stages: player placed ones are completely screwed up... though this could be fixed by making setting the age to max when the same block is placed over them and set to minimum when the same block is broken over them. Still a minor change, even less useful for cacti since it has collision.

• unused snowy states: since snowy likely never was intended to be added onto dirt

• dispenser/dropper triggered: since they already give signs of activation

• TNT 'explode' state: it doesn't make sense to control entity models through a blockstate... unless this is about the ones that break on-contact, then it's misleading ('volatile' would be a better name) and it makes sense to lose that since you can't get it in default

• doors' 'powered' state: not that useful, and iron doors can't be open and unpowered (or powered and shut) anyways.

So much of it is justified in being thrown out, but the rest I'd hope can stay since they are 'stable' in function as well as useful to a large scope of users.

Not really, the first step is to split out the different blocks. So 'snowy' will be gone of anything that has no custom model right now.

After that and depending on some other things the 'growth stages' will be purged of things that do not have visuals.

Beyond that unknown for now.

will these blockstate issues listed here be fixed by 1.9? or in a 1.9.x version. custom texture packs like mine would work so much better if these worked as we're expecting. (@ hoppers, personally)

I'm not sure what will be waiting for us (users) in 1.10. but it sounds like a major re-write? v2.0 even?

Also, Fancy and Fast versions of leaves. It would make much sense if those would be split in 2 different models, also because any leaf model which is not a perfect 1x1x1 cube will act as an "x ray" block.

Confirmed for 17w47a, 17w47b, 17w48a

Affects 1.13-pre6. Please keep the issue updated.

Since TNT breaking is back in 1.13.1, you should fix the page.

Confirmed for 1.16.1. Ran into this while trying to make a disabled variant for hoppers. Using multipart did not fix the issue.

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.