-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Catch async usage of playsound #10021
Conversation
Do we also need catchers for the adventure sound methods? Should be added to the adventure patch if so. |
ee36bd3
to
d312602
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. This was expanded to catch any use of World#playSound off the main thread as none of the 3 methods are thread-safe. It does more specific checks for Server#playSound methods as there are some cases where the use is thread-safe.
In my opinion this is a bad idea, .playSound is just sending a packet, same as .spawnParticle people will use it async. If the world random is screaming use the multithreaded random, why does world random even matter when playing a sound |
Very much not true on World and Server. On The "world random" aspect is just one part of this. If a sound isn't provided a seed, a seed must be generated from the world's random instance which is a thread-unsafe instance. As to your second post, I'm not sure what you are "wat"ing? THat diff is just changing some hunk line numbers and index hashes. EDIT: Feel free to ping me in the discord if you want to discuss this further ( |
It appears the line lighning.isSilent = isSilent was removed, I could be mistaken though. |
Since paper now blocks async location-based sound plays (PaperMC/Paper#10021), I decided to use my own system.
This causes the world random to scream due to multi-thread acces