Recently I made a vehicle chassis with the help of some other members of this forum. I’m pretty satisfied with the way it turned out, however there’s one problem left to solve that I can’t seem to figure out.
When you are driving the vehicle, there seems to be latency when you’re steering. You may notice this if you use a test server with the file below, but I think it’s especially noticeable on full servers.
If you have a solution for this issue, please respond below. Feel free to use the chassis in your own projects if you want.
Seems to be as simple as the input being handled on the server.
This is easy to reproduce by simulating a high ping.
How to add lag to studio
This shows 300 ms of latency, which is bad, but still, many of your users will have to deal with this.
I looked at your script and it seems like everything interesting is in VehicleHandler. Much of the logic in your while true do loop will need to be moved to a local script.
Audio has to be handled by the server, but the client should fire a RemoteEvent to start/stop sounds. I think you can change the pitch on the sounds client-side for the fast feedback, but I’d suggest still sending updates to the server via a RemoteEvent so other players hear the right pitch.
Lights should turn on/off via a RemoteEvent.
Logic related to setting the constraints can remain on the client. Make sure the client has physical ownership of the truck.
Actually, unless you have set SoundService.RespectFilteringEnabled to true, the sounds (and all changes related to them) played on the client will replicate to the server.
I think you can also do this by enabling network simulator in the test tab. This means that the latency will only effect the test you have it enabled for, rather than all tests.
I would suggest you try and cut down on the amount of client-server communication by doing most things unrelated to logic on the client.
For example, if you use a remote event to play a sound on a high latency network, there will be a delay proportional to your latency.
So, for the best experience to the player, move as much as you can to as close as you can to input handling.
Only playback replicates, changes do not. Audio can be handled either on the server or the client. Either way, this is fairly irrelevant - it depends on what OP’s comfortable with or what their current environment looks like. I would like to assume RespectFilteringEnabled is being used because enough sound exploits can go around with it off.
Okay thank you for the correction on the modifications idea.
However, I have to disagree with you on this:
I think it’s pretty much safe to leave this off, because the exploiter has no way of playing their own sounds.
If an exploiter creates a new sound object, it appears on the client so the server can’t play it.
If they modify one of your sounds, once again, it won’t replicate so only they will hear it,
If they play one of your sounds, it’s fine because those sounds were meant to be there.
So, I think it’s pretty much safe to leave that property off unless you really want to play local sounds (which can be done anyway using the soundservice api), or have sounds that are a critical part of the game and an exploiter could ruin it by playing them.
“I would like to assume” refers to an assumption OP’s production environment making use of the property, it’s not a statement you’re supposed to agree or disagree with.
On the other hand, the commentary provided is something that warrants commentary.
It’s really not. Refer back to my statement saying that with this property off, sound playback can replicate. It’s as easy as spamming the play method on sounds to produce a crash or unintended audio effects. Relevant exploit report which a former engineer replied that RespectFilteringEnabled was designed to combat against said playback exploits. It’s not just good for combating exploiters either; it has various production uses.
The server can’t see it*
That doesn’t matter. Sounds that already exist in the DataModel can be fetched and played. Exploits aren’t limited to creation, they can also utilise existing items to their advantage.
Or you can just play them from a LocalScript with RespectFilteringEnabled on without the unnecessary trouble of needing to set sound listeners and such every time you want to play a sound locally with that API. It doesn’t fix the initial problem either - sound playback will still replicate if an exploiter decides to call play across sounds. You also need to account for other sounds if your game is “sound heavy”.
Please DM me if you have any further questions, commentary or responses about this. Sound playback is off-topic from the OP, we’re derailing this thread a bit.
