Nathan Wolf

I am having a similar issue, but it is not failing to delete the file, it just fails to apply the new pack. This seems to be new 1.17 behavior:

File /Users/nathan/Library/Application Support/minecraft/server-resource-packs/ff251496d074136489fa5136c71b99bc8dbd0fd8 had wrong hash (expected 642c3be6698603ee3c0d887ad8386e3d7aa1f7cd, found 73f7dd5236c76b45907932c38f1be8eb8a8ddac9).

Pack application failed: java.lang.RuntimeException: Hash check failure for file /Users/nathan/Library/Application Support/minecraft/server-resource-packs/ff251496d074136489fa5136c71b99bc8dbd0fd8, see log, deleting file /Users/nathan/Library/Application Support/minecraft/server-resource-packs/ff251496d074136489fa5136c71b99bc8dbd0fd8

I will get this every time I update my RP (in-place, same URL different hash).

 
 
The delete does work for me though, so if I immediately re-send the same URL and hash it works. 
 
 
This is not ideal of course (will require plugin functionality to work without the player relogging), and this used to work fine pre-1.17.
 
Thank you for your attention, and I apologize for the insta-edit.
 

You download the script and put it in the root "models" folder of your resource pack and run it with 

php addrpparent.php

It'll edit all your json models to add the "item/custom/lit" parent, if they don't have a parent set already. You can edit the script to use a different parent if you want. But you'll need to have that parent in your rp, if you want to use mine just copy this into item/custom/lit.json

{ 
"__comment": "This is here to fix lighting issues with GUI items in 1.15", "gui_light": "front" 
}

Make sure to back up your RP source first, in case something does wrong.

I had some flat but many 3D, but they all looked dark. It's certainly more noticeable on the 2D ones (I have many that represent icons). Particularly because I already have "dim" versions of all the icons to use when they are disabled.

But the actual 3D models (wands, bows, swords, etc) also looked dark. I don't have any texture-only models, so I guess I never had need to use builtin/generated?

Most of my models did not have a parent, now they share a common parent that currently just has "gui_light: front" on it, but at least now it'll be easier for me to add more common properties if I need to.

In case it's helpful to anyone, you'd probably need to tweak it a bit for your own purposes but here is a script that will recurse through a directory structure and add a parent to any models that don't already have one.

Thank you for the reply- I did not understand that I was meant to have parented all of my models to something specific builtin.

I did end up making a common parent, but that still involves touching all the models so it didn't really help except to maybe future-proof a little. I just wrote a script, so it didn't take me all day 🙂

I can confirm that adding

"gui_light": "front"

to my custom models has resolved the issue in 1.15.2

I hate to be "that guy", but I have a dozen resource packs with hundreds of items in them- why can't this be the default? It's kind of a huge pain for people, I have to imagine I'm not the only one. Why would we want the dim items to be the new default?

Thank you for the fix, but could you please provide a specific example (or a documentation link) for how and where to apply that tag?

Can confirm Aaron's comment on fireworks, could you please add it to the list? I searched for "silent firework" and the search did not catch this issue, I'm guessing it doesn't search comments?

The Silent tag on fireworks is respected server-side, where the launch and flight sounds get sent, but the pop seems to be client-side and ignores the tag.

Thank you, my apologies! I did search first but I guess my query didn't catch the "firework" only mentioned in the comments on the duplicate issue.

Fun new 1.12 side-feature: there must be some kind of key combination for the narrator, because it's constantly turning on for me as a result of this bug.

It really would be nice if this could get fixed.

It'd be nice to get some feedback either way. I don't see this behavior from other Java apps, so I can't imagine how low-level it could be.

If Mojang uses Macs I am a little shocked this doesn't drive them crazy- I know I'd want to nail it down if it were me. So you could be right, that there's some reason it's very hard to fix, that would be both surprising and a little disappointing.

Any possibility for a response from the team? The provided work-around really doesn't help anything, as you can see the numerous examples of how annoying this is. Yes it's "fixable" but not until after you're already frustrated about it. I'd love to say after years of dealing with it I've trained myself to mash command every time I alt-command back to MC, but apparently it's just not sticking in my brain.

Ok, sorry! I will add it there.

I thought that "damaged=true" always excluding unbreakable items, while "damaged=false" does not include them seemed like maybe a bug, but I'll admit this was a bit of a stretch.

Just checking in to say that this bug makes me scream at my computer at least once or twice a day.

I'm guessing the Mac client is not exactly super high-priority now, if it ever was.

I think if any one of the Mojang devs tries to use the game on Mac for just one day, this bug would get fixed. It's truly infuriating for anyone doing MC dev of any kind, since that routinely requires alt-tabbing away, and then back to type a command. 99% of the time you end up having to re-type the whole command, after realizing you just spewed some gibberish into chat. It's maddening!

Sorry! I did search first, but must've missed it. Thank you, I'll be keeping an eye on it 🙂