So I am trying to handle gun UX on the client solely, but the problem is that the sound effects that the client hears isn’t heard by other clients. Because of this, I am forced to play the sound in the server which causes a slight delay in between clicking the mouse and playing the sound which is ugly.
Any ideas on how I can do this? I tried using SoundGroups but that doesn’t help at all, and using RemoteEvents may take up way too much bandwidth especially with high rate of fire guns.
Have the server call FireClients to all other clients except the shooting client. Those clients play the sound upon receiving the event. Don’t use the server except to serve as a bridge between other clients.
I assume you are playing the sound in a local script, and so only the player would hear it.
You’d have to use remote events than to play the sound in the server
If you set game.SoundService.RespectFilteringEnabled to false then sounds played locally will replicate to other clients. However, your sound instance must exist on the server to be replicated properly. If you want a sound to play on the client without replication, then you can use the SoundService:PlayLocalSound(soundinstance).
This works, but you can minimize network traffic by using SoundService.RespectFilteringEnabled. This way you don’t need to use remoteevents, and the sounds still replicate.
EDIT:
although this would be quicker and less taxxing, it is insecure and would propably be out of sync with other effects such as muzzle flash, tracers, etc.
Typically not the best idea to touch that unless you’re setting it to true. It was introduced primarily due to sound exploits where clients were capable of crashing servers or inappropriately propagating audio to other clients authoritatively, like network ownership.
I’d do a round trip via remotes, as I suggested prior. The client performs all it’s visual and auditory effects locally and then passed on a message to the server to tell other clients to do the same.
Network traffic wouldn’t be too big an effect, no?
You’re only sending a few bytes of data for a round trip, so realistically no it wouldn’t. This is comparing at least less than 20 bytes to a 60 KB/s maximum.
The question is about the sound instance. If the game is on FE, would they change if an exploiter touched them? Can they create a sound instance and then play it on the client and be heard by other clients?
If a sound instance is created on the client, RespectFilteringEnabled doesn’t have any effect; the instance only exists on the client, thus following standard replication rules imposed by FilteringEnabled.
If the sound already exists on the server at run time, they are capable of playing that sound. Such includes sounds under their character.
Also, I see security issues with RemoteEvents. If from the client I sent a FireServer to some soundManaging script and that soundManaging sent the gun sound to the other clients to play, an exploiter can replace the gun sound with any other sound they want
Or maybe I can have the server script only accept certain assetId’s
using the SoundService.RespectFilteringEnabled property, it runs the risk of people spamming the sounds. If you used RemoteEvents, couldn’t you just spam those in the same way? You could introduce a server cooldown/debounce, but that can be dangerous due to latency.
That’s why you don’t let the client be authoritative about what sound to play. Don’t pass an object, pass a string. This string will be checked to see if matches an existing sound in the gun’s handle and the player actually has the gun.
Typically I don’t create an explicit sound remote because of this. The client shouldn’t be authoritative of what to play. Thus, I couple the playing of the sound with other effects when firing off, say, a gun replication remote.
Ok. For now I’ll do the RemoteEvent roundtrip method as I have to replicate other effects too like particles, flare, etc. Thank you all for contributing to this thread. I know many people will be asking this in the future.
Keep in mind that the method I proposed says to use the server only as a bridge. This also includes any verification checks you might need to make in that time. If you look at my solution raw, yes it’s completely possible to spam the remote which makes either solution pointless.
I don’t know specific implementations so I can’t offer the most concrete of advice, but this is normally where you come prepared with backup plans to counteract spam. This includes custom rate limit solutions, copies of data on the server (ammo) and preventing sending if certain conditions aren’t met, so on.
Server-bound rate limiting doesn’t do much as far as latency goes. The only bottleneck in a round trip solution is the time it takes for the server to receive the request from the shooting client and a client’s machine for how long it takes to receive the event. All server verification should be non-yielding to maximise on how little your environment is taking during a single trip.
I only meant that if the server lags, it could make server debounce out of sync with client debounce which could make some really annoying lag when you try to click but the server falsely thinks your clicking too fast.