kcrca

Oh, fwiw, this is under 26.3-snapshot-3 since it just came out, but I could go back if needed.

Yes, it’s primarily targeted at vanilla, but I do have some optifine things in it. Is there a known issue wrt optifine here?

I’ve attached two images, the first is vanilla, with a set of armor in diamond trims. For the second, the only change is to use my pack. I believe that’s showing iron, but since I didn’t re-trim them, that would be wrong.

LMK what else I can give you.

Actually I just checked and, afaict, it actually is present in everything else, though it is missing from both blocks/saplings and items/saplings.

I just copied the the poppy.png.mcmeta file to my pack and reloaded it, and the problem did NOT go away.

I also notice that I don’t have any problem I can see with my RGBA stained glass textures, and vanilla doesn’t have mcmeta’s for them.

Ooops, here’s the indexed png file:

Good point about the uploaded file. It’s attached here. You’re right about the partial transparency, it should have stored it that way because the edges are antialiased against transparency, but Photoshop doesn’t do that by default.

I have to admit I sorta wonder why files with partial transparency aren’t strict_cutout by default, but there’s probably something I’m not thinking of. Anyway, I will generate .mcmetas for any file I want partial transparency for. For me it’s just another python script, dunno how people doing it manually will. feel about that :-)

Why would an .mcmeta file be required for an RGBA file but not an indexed color file?

That sounds more like a crowdin problem, in that the data being used for older version is influenced by changes in later versions. Thanks for the answer.

The fix seems incomplete. The armor on a small stand is adult armor, not baby armor, which is what a small stand should have. I’m thinking this comment will re-open this bug, rather than having to file a new one.

can confirm in 1.21.11

can verify in 1.21.11

FWIW, here’s another related log: https://pastee.dev/p/BVg9eVFp

In my case, it looks like a bee was down too low.

To be precise, before following the above commands, do:

1. Set world to “Peaceful”

2. Run the second command above (This may not be necessary)

3. Set the world to “Normal”

4. Run the second command above again

The bee will do nothing.

OK, now I know what was missing: If I set the world to “Peaceful”, run the second command, of course nothing happens. BUT then I set it “Normal” and still nothing happens. I had done that in the world before running into the problem, but didn’t know it was connected.

I am in creative mode. But this also fails for me for non-player entities. For example, if I summon a nearby parched (also in a pen), and run

/data modify entity@n[type=wolf] angry_at set from entity @n[type=parched]

the wolf also fails to get angry. However, if I run get the parched’s UUID and put it into a merge command so I set both at once, as in:

/data merge entity 163ac043-3b47-44be-b643-88aaff94cd0e {angry_at: [I; 577786577, 605832062, -1989529972, 1018961742], anger_end_time: 0}

this works. Which seems more evidence that the problem is that setting the values in different commands doesn’t work. (FWIW, this isn’t a solution because in a function I won’t know the UUID of the entity get angry at in advance, so the only direct way to do this is to use “/data modify … set from …”, which has to be in a separate command.)

Yes, this is the solution I’d suggest as well. I’m asking Mojang to do what you suggest to restore the status quo, because red sand has been allowed for a long time.

I don’t see this in 25w43a.

The golem: 12 100 45

Closest banner: -42 101 -22