Donkey/mule's chest does not become Christmas textured on Christmas
(I know that this is kind of useless to report this on the next day of Christmas...)
Trapped Chests are now Christmas textured.
However, donkey's chest aren't Christmas textured.
Created Issue:
Donkey's chest don't become Christmas textured on Christmas.
(I know that this is kind of useless to report this on the next day of Christmas...)
Trapped Chests are now Christmas textured.
However, donkey's chest aren't Christmas textured.Maybe, WAI
Environment
Probably all
Donkey's chest don't become Christmas textured on Christmas.Donkey's chest does not become Christmas textured on Christmas.
Donkey's chest does not become Christmas textured on Christmas.
relates to
is duplicated by
Donkey/mule's chest does not become Christmas textured on Christmas
relates to
Probably all
Thank you for your report!
We're tracking this issue in MC-94829, so this ticket is being resolved and linked as a duplicate.
That ticket has already been resolved as invalid. Please take a look at the parent ticket (MC-94829) and see if an explanation is provided there in the description of the ticket or in the comments for why this issue is invalid.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
The two chests of a donkey and/or mule cannot be independently retextured from one another, making them always look the same. This is limiting to the player's resource pack creativity and freedom to edit the texture.
Steps to Reproduce:
- Download and apply the following resource pack:
DonkeyMule.zip
- Spawn/Summon a tamed donkey, or mule:
/summon donkey ~ ~ ~ {Tame:1b} /summon mule~ ~ ~ {Tame:1b}
Observed Behavior:
Both chests will look entirely red, despite the player seemingly only modifying one of them in the UV map.
Expected Result:
Only one of the chests would be altered, since that is what the player intended to change. The current behavior is unexpected and not resource pack friendly.
Screenshots/Videos:
Notes:
- Related independent retexture issues:
MC-274254MC-274251MC-274250MC-274249MC-274247MC-274246MC-274197MC-271355 MC-271384 MC-271383 MC-271368 MC-271363 MC-271357 MC-271355 MC-271354 MC-271330 MC-271305 MC-271304 MC-271232 MC-264571 MC-270516 MC-270517 MC-145334 MC-265343 MC-265345 MC-270530 MC-271767 MC-271768 MC-271769 MC-271770 MC-271773 MC-271780 MC-271982 MC-271988 MC-271989 MC-271990 MC-271992 MC-271993 - Also related to MC-94829 MC-270530
The small chest which can be applied to donkeys or mules has two front faces. This is unlike the llama's chest texture, which has a front and a back texture for both chests on the entity model.
While generally issues regarding model faces that cannot normally be seen are resolved as "Won't Fix" due to the minimal gain from fixing the issue, this might be worth fixing due to MC-268985. If the chests were changed to wobble again, the back face may be visible again.
Steps to Reproduce:
- Apply the provided resource pack:
DonkeyChestFront.zip
- See if the back face (which is not modified) is ever used

Observed Behavior:
Only the front face of the chest (which was modified to be red) will be visible, facing outward.

Expected Result:
The back face of the chest would not have a latch on it, but instead would appear as a back face similar to the llama's texture:

Screenshots/Videos:
The donkey's texture currently:




Not a bug.
OK... Why?
Because it's not programmed to behave so.
If you want to have Donkey's chests to look like presents -> Feature request.
I recently added Christmas chests for donkeys/mules/horses in my mod: https://www.curseforge.com/minecraft/mc-mods/better-christmas-chests
and yes I was surprised when I found out the horse textures also have chests even thought they can't be equipped
Can confirm in 23w03a
Confirmed with 1.20.2 and 23w40a
Roy Sajima
"Maybe, WAI"
I don't think we should write these things.
(I have priorities, but just in case.) It may really be "Works As Intended".
Kumasasa
It is not your decision. It is the developer's decision.
In fact, the priority is given to Low. In other words, the developer has acknowledged it as a bug.
Also, please do not ever impersonate [Mod]! (The real ones are green with white text.)
user-f2760
>You're responding to years-old comments
Why? Why not?
>Kumasasa is/was a mod, the priviledges were removed from his account as he's inactive. He's not impersonating .
I don't know anything about that. I knew nothing about Minecraft at that time.
I personally resent it when a non-developer, be it a [Mod] or [Helper], casually says "this is a feature request (in the case of this ticket, it was later reopened and prioritized)" or "this is Works As Intended". (This may be selfishness in the public's mind.)
But I missed the history. My fault on this one.
Now the decision is basically the developer's, but it's kind of inexplicable that [Mod] was making the decision.
There seems to be a bit of a panic. I'm going to go cool off.
The helpers and mods are in direct contact with mojang, they also know the difference between a feature request and a bug well, despite phrasing of the report. While this report threads both sides of the spectrum (inconsistent, bug needs new feature altogether to work) it was only prioritized as issue after reconsidering years later.
The userbase does not respond well to people who have a voice to begin with, it's either hate, or love, no inbetweens. I myself was mod years ago, and followed Mojang's statements to the dot, the response of the community was a witchunt, ridiculing me for numerous reasons, and twisting my words into something completely different. People jump to conclusions that the mods actually have the full say, but they don't, they need to have actual proper reasons to resolve reports, or they will be removed from the team.
Any further discussion regarding this should go to the mojira reddit or discord.
Can confirm in 1.21.4.