He's on version 1.20.1 as of the filming of that clip, and as you can see, his final descent is slow enough that the maximum amount of damage he should have taken was maybe a couple of hearts (if that.) Instead, he lost all ten hearts, and would have lost his hardcore world had he not been holding a totem of undying. This simply cannot be "working as intended." One's speed upon landing should determine damage taken, not anything that happened before slowing down for the final approach.
I've encountered this issue with volume levels, and it appears random, but probably isn't, If I'm right about why this is happening. It's also potentially the reason for all the other reported issues in this thread, but not for the reasons that other people might think. I know this is long, but please bear with me.
I added a sound to my sounds.json that was intended to completely overwrite an existing vanilla sound, and leave others alone:
What I noticed when I tested this sound was that the event would sometimes play the sound at my requested volume, but sometimes play the sound at full volume.
After cranking up the "weight" of that record to 50000 and hearing my requested volume each and every time, I now think I know why this is happening. Please correct me if I'm wrong.
The crux of the issue:
It seems to me that, when Minecraft builds the array of sounds for an event, it includes records from the "lower" pack for the same event, even if they refer to files of exactly the same filename in exactly the same location. What happens then is that, in my example at least, there are now two records for "idle1" in memory, and the game randomly chooses either of the two at runtime (because they both have equal weight.) When it chooses my record, it plays my file at my chosen volume. However, when it chooses the built-in Minecraft record, there is no volume specification, so it plays "idle1" at full volume. But since I've replaced "idle1" with a different .ogg file, Minecraft plays my sound with Minecraft's (hidden) default volume specification (and blasts my eardrums out in the process.) This is probably what has been happening with all the pitch issues as well.
One way for pack creators to resolve this on our end is to use "replace":true on the entire sound event but this destroys the ability to layer resource packs together properly, since every "higher" pack necessarily eliminates all sounds from the same event in "lower" packs, regardless of filename (or location.) In my case, that could mean that hundreds of sounds fail to play, despite having all different names from pack to pack. "replace":true is a nuclear explosion when a pistol would do.
Another way for a pack creator to resolve this is to pepper their sounds.json with massive "weight" quantities, but this means that to be compatible with one-another, every pack would need to have exactly the same weight specifications, or some packs would overtake others. My pack would outweigh yours if I had higher numbers (and vice-versa.)
Neither of the above are good solutions.
A possible solution:
Every .ogg file that can be triggered by a sound event should have one and only one json record in memory that can be chosen randomly by the game. There should never be conflicting json directives in memory. Only the highest-level pack should be the source of truth. All identical records from lower packs should be overwritten by that top-level record (on an individual basis.) We should no longer have to squash entire sound events in potentially multiple packs with "replace":true in order to replace individual sounds, nor should we be required to hack the system by using astronomically high "weight" for everything (which isn't even a guarantee.)
This was the behavior I expected, which is why I went looking on your bug tracker when it did something else.
Thanks for listening. I hope you all have a wonderful day!
"The behavior of the warden appearing when the shrieker is broken is expected." - Jiingy
I am NOT reporting that it shouldn't spawn at all (as you appear to believe.) My report is about timing. I am saying that it shouldn't spawn faster than it does when the shrieker is left intact. I'm not sure why that was unclear from what I wrote, but here's another way of putting it:
It makes no sense that the warden should suddenly appear much more quickly when the shrieker that made the sound is broken. The sound has already been made. The warden should take the exact same amount of time to respond to that shriek no matter what happens to the shrieker that made it. It should be based on the time that the sound first happens, not any other factor.
Shriek begins... 4 seconds later, a warden crawls out of the Earth. No other factors should have any affect on that timing. It shouldn't be able to be stopped, and it shouldn't be able to be accelerated. Once the shriek happens, you should always get a warden, and it should always take exactly the same amount of time to occur. I am reporting that acceleration as a bug, not that the warden appears at all.
Kuoxsr
MC-266399
There is no way that this guy should have popped a totem due to this landing:
https://clips.twitch.tv/GiftedGleamingSkirretOptimizePrime-EaPGokmqUVzAZmAB
He's on version 1.20.1 as of the filming of that clip, and as you can see, his final descent is slow enough that the maximum amount of damage he should have taken was maybe a couple of hearts (if that.) Instead, he lost all ten hearts, and would have lost his hardcore world had he not been holding a totem of undying. This simply cannot be "working as intended." One's speed upon landing should determine damage taken, not anything that happened before slowing down for the final approach.
Affects Version 1.20.2:
I've encountered this issue with volume levels, and it appears random, but probably isn't, If I'm right about why this is happening. It's also potentially the reason for all the other reported issues in this thread, but not for the reasons that other people might think. I know this is long, but please bear with me.
I added a sound to my sounds.json that was intended to completely overwrite an existing vanilla sound, and leave others alone:
{ "entity.villager.ambient": { "sounds": [ {"name":"mob/villager/idle1", "volume":0.1}, "mob/villager/idle2", "mob/villager/idle3" ], "subtitle": "subtitles.entity.villager.ambient" }What I noticed when I tested this sound was that the event would sometimes play the sound at my requested volume, but sometimes play the sound at full volume.
After cranking up the "weight" of that record to 50000 and hearing my requested volume each and every time, I now think I know why this is happening. Please correct me if I'm wrong.
The crux of the issue:
It seems to me that, when Minecraft builds the array of sounds for an event, it includes records from the "lower" pack for the same event, even if they refer to files of exactly the same filename in exactly the same location. What happens then is that, in my example at least, there are now two records for "idle1" in memory, and the game randomly chooses either of the two at runtime (because they both have equal weight.) When it chooses my record, it plays my file at my chosen volume. However, when it chooses the built-in Minecraft record, there is no volume specification, so it plays "idle1" at full volume. But since I've replaced "idle1" with a different .ogg file, Minecraft plays my sound with Minecraft's (hidden) default volume specification (and blasts my eardrums out in the process.) This is probably what has been happening with all the pitch issues as well.
One way for pack creators to resolve this on our end is to use "replace":true on the entire sound event but this destroys the ability to layer resource packs together properly, since every "higher" pack necessarily eliminates all sounds from the same event in "lower" packs, regardless of filename (or location.) In my case, that could mean that hundreds of sounds fail to play, despite having all different names from pack to pack. "replace":true is a nuclear explosion when a pistol would do.
Another way for a pack creator to resolve this is to pepper their sounds.json with massive "weight" quantities, but this means that to be compatible with one-another, every pack would need to have exactly the same weight specifications, or some packs would overtake others. My pack would outweigh yours if I had higher numbers (and vice-versa.)
Neither of the above are good solutions.
A possible solution:
Every .ogg file that can be triggered by a sound event should have one and only one json record in memory that can be chosen randomly by the game. There should never be conflicting json directives in memory. Only the highest-level pack should be the source of truth. All identical records from lower packs should be overwritten by that top-level record (on an individual basis.) We should no longer have to squash entire sound events in potentially multiple packs with "replace":true in order to replace individual sounds, nor should we be required to hack the system by using astronomically high "weight" for everything (which isn't even a guarantee.)
This was the behavior I expected, which is why I went looking on your bug tracker when it did something else.
Thanks for listening. I hope you all have a wonderful day!
Dhranios, ah, I see that you are referring to a different issue. My bad. Perhaps I'll create a new one.
"The behavior of the warden appearing when the shrieker is broken is expected." - Jiingy
I am NOT reporting that it shouldn't spawn at all (as you appear to believe.) My report is about timing. I am saying that it shouldn't spawn faster than it does when the shrieker is left intact. I'm not sure why that was unclear from what I wrote, but here's another way of putting it:
It makes no sense that the warden should suddenly appear much more quickly when the shrieker that made the sound is broken. The sound has already been made. The warden should take the exact same amount of time to respond to that shriek no matter what happens to the shrieker that made it. It should be based on the time that the sound first happens, not any other factor.
Shriek begins... 4 seconds later, a warden crawls out of the Earth. No other factors should have any affect on that timing. It shouldn't be able to be stopped, and it shouldn't be able to be accelerated. Once the shriek happens, you should always get a warden, and it should always take exactly the same amount of time to occur. I am reporting that acceleration as a bug, not that the warden appears at all.
Now is my report clear?