VehicleSeat Throttle/Steer oscillation on single tap of an input key during frame lag

I’ve recently discovered a bug whereby quickly tapping any of the movement keys (WASD/Arrow keys), while the client is sat in a VehicleSeat and suffering from framerate lag, causes the (depending on the input) Steer, SteerFloat, Throttle, and ThrottleFloat properties to oscillate between the intended value and 0 a seemingly arbitrary number of times before settling back on 0.

This has lead to some issues in my game that I thought were due to the configuration of the constraints making up a vehicle chassis. I’ve had to temporarily move to dealing with user input myself.

I’ve also had a look into the default ControlModule and VehicleController player scripts, however, they appear to be setting these VehicleSeat properties correctly as keys are pressed so it appears to be an issue with the core VehicleSeat implementation itself.

Notably, this issue only occurs when a key is tapped rather than held. Holding a key produces the desired output on the VehicleSeat and does not cause this oscillation problem. A game running smooth at a solid 60 FPS also does not cause this issue.

I have no idea how long this issue has been present as this was only discovered after some constraint changes I made appeared to amplify the issue especially during steering.


I’ve made an un-copylocked place here that is able to show the issue using a single VehicleSeat on a Baseplate and :GetPropertyChangedSignal() hooked up to the properties mentioned above (polling the properties also highlights it). There is also a LocalScript that simulates framerate lag so this issue can be reproduced easily. In my production game, lag is as a result of rendering rather than scripts, regardless, the same issue occurs.

  1. Join the game and sit in the VehicleSeat
  2. Press F9 to view client output
  3. Tap any of the movement keys (WASD/Arrow keys) once
  4. Observe the property changed output oscillate an arbitrary number of times before returning to 0

For example, this is the output from a single tap of the W key:


I am currently experiencing this exact issue. Please let me know if you ever found a solution. Thanks.


I noticed this bug report is 2.5 years old, but alas, it has already been bumped & more or less the issue is occurring. Noticed it coming on over the past weekend or so, hadn’t seen it much before that, although some people have been saying they’ve felt it for more than a week or so.

I’m not so sure that it’s oscillating between the intended value & 0, more so than just going completely haywire. I can tap the throttle once and I’ll see it go -1, 0, 1, 0, -1, 0, -1, 0, -1, 0, 1 etc.

I’ve recorded a video showing the phenomenon in my own game in studio:

In this video, you can see I’m pressing nothing on the keyboard [and have no other sources for input] and yet the vehicleseat is freaking out. After an unspecified amount of time, it stops.

I can also confirm that your repro still works [as in, still shows the bug occurring]


Saw a Roblox update pushed today (had the long loading with updating as the loading prompt)

The issue is still occurring and is quite disruptive to the racing community.


Just inputting a couple times can cause it to act this way. Note there’s no scripts active. Edit: And everything is replicating normally in Workspace. No black magic there. ._.

1 Like

I’ve also experience this in my game and had to implement special code to prevent this.

1 Like

Did you have to make the Steer value on local script? @Quenty

1 Like

Bump this, same is happening for me, Literally just Getpropertychanged for “Steer” and just printing its value, If i input D twice or switch to A really fast it just gets stuck in a forever loop switching from 0 to 1

1 Like

Can confirm this is happening, making some cars practically undriveable so hope it can be fixed soon.

1 Like

I can confirm this is still happening to me as of yesterday. I used OSK to make it more obvious what the issue is.

1 Like

By chance, how did you prevent this?

1 Like

We are 2 weeks deep and it’s still not fixed. Any comment from staff about the potential for a fix would be greatly appreciated as the racing community has grinded events to a halt due to this bug!


I’m also experiencing this issue, it’s becoming quite a problem as I rely on VehicleSeat properties for a lot of my vehicles

1 Like

I have been experiencing this issue for many months.
My solution was to develop a new vehicle seat from scratch.

1 Like

I’ve wasted over four hours into this just to see what this was, and if there was a fix. Let me show you what I did, what I found, and what I concluded. Brace yourself for the wall of text, or scroll down for the TL;DR.

After trying the OP’s original un-copylocked place and doing a lot of testing, I can say that including the OP’s findings (core engine bug, etc,) it happens no matter the framerate. I did everything that the OP did in terms of my own findings. Player Module checking, making sure stuff actually worked as intended with the regular vehicle controller script in the player, etc. Here’s what else I found.

So, in Studio, I copied the value printer and put it in a Server script for when the values update. I also included prints for when the vehicle controller module wants to update the ThrottleFloat, as shown here:

if -self.throttle ~= 0 then
	self.vehicleSeat.ThrottleFloat = -self.throttle
	self.vehicleSeat.ThrottleFloat = 0

(Yes, I programmed it where it forced the Float to be 0 if the throttle was 0. I didn’t want to see -0 in the prints :joy:)
During one of the oscillations, I captured this.
(Line 270 is the first print, Line 276 is the second print.)

The vehicle controller always sets it to 0 when released, which the OP says it does. But from what I can guess, the server doesn’t know that the throttle has been changed and it tries to catch up, which explains the oscillation.

A good thing to note is that the Server saw the throttle change to 1 at 0.197 seconds. At the same time in 0.198 seconds, the Client tried to fix that by setting it to 0. And that’s consistent; in the other oscillation prints, it’s to the millisecond plus or minus another millisecond.

Another thing to note is that assuming similar client/server framerates (60 plus or minus 1), it eventually catches up when the two framerates align like the OP said (to be fair, same in general with lag or without, but let’s focus on 60 frames since it still happens.) However, something else to add on: when I tap a key down again to initiate an oscillation while there’s already one going, it tends to either stop completely or halve/double its frequency.

One final thing: even if the player leaves the seat and when no other script - Server, Client, or Module - is updating the values, they will still oscillate.

I assume this is related to the Throttle and Steer property descriptions, where it says it must be set or it will refresh to 0, but that’s a bit confusing as well. Even when setting the Throttle or Steer in Properties, in simulated Server or Client, it does not refresh back to 0. The bug is part of the core like OP said, but I think it must be part of the C++ engine in specific. I say that because of all of my findings above, alongside the core Lua scripts (which was of interest to me too to check out) having absolutely nothing at all to do with Seats in general… or player movement at all.

I’ve done all that I could to see if there was some fix, even if it was a simple script or a replacement PlayerModule. Alongside what the OP did (which in turn I did), I made the VehicleSeat’s network owner to the client, I tested with a very old bus that I had in my models back in my 2010-2011 era (lol), everything.

i give up, gg roblox

The only two ways I could think of circumventing this bug both require quite a bit of work (subsequently I have not tried these.) You could probably have an input listener on the Client to send data to a Server script (by remote event) so the server can update the values accordingly, or just make something similar to the Endorsed Cars’ chassis or something like A-Chassis, where inputs are put straight to local scripts that update constraints or body movers. Nothing at all in common with the traditional OG Roblox chassis setup. Wonder why.

My assumption is that it has to do with networking thanks to replication and timing, but at this point I really do not know. All I hope is that this could be fixed because it could help a lot with some future projects I want to take on. It’s a bit of a tedious task to try to program stuff around this bug.

TL;DR: It’s a core engine bug like the OP said. The client can set Throttle and Steer with it replicating fine to the server. However, if you do it quick (tap) then the server won’t know it and will try to set itself over and over again. Even if the client taps again afterwards, it could either stop the oscillation, make it slower, or make it even faster. An old bug that never got fixed, so even Roblox themselves moved away from their old chassis in favor of some other overengineered ones, despite the fact that ThrottleFloat and SteerFloat are very good values to read from sometimes when making your own code.

That is, if those values were reliable in the first place.

Disclaimer: All of my findings were done in Studio and Studio only. This could definitely be different in an actual play setting with varying degrees. With that said, take my post and my findings however you will.

(All edits were small and were made to make this post more informative and easier to read.)


Good analysis. I hope this whole thing is brought to the attention of engineers.


Hi everyone! Just following up.

We’ve filed a ticket to our internal database, and we’ll follow up when we have an update for you.

Thanks for the report!


So almost 60 days later and still no word?
I have a lot of Constraint Physics going on in my game so having Steering and Throttle use random values doesn’t work for me.


Are you still running into the issue?
I haven’t felt it’s affects since March 28th.
Things appear to be fixed.


I may have found more to it.
I’ve been using Motor6Ds for steering. Since steering with HingeConstraints were flexing in ‘monster truck’ wheels using Ackerman steering and with the steering hinge offset from the wheel center so it’s more realistic.
Motor6Ds seem to be the cause but I thought maybe the issue was the Steer and Throttle issue making them do that.
Motor6Ds used to work just fine for me, but recently they seem to be lagging. The steering used to work smoothly but now it lags or keeps turning a bit more, at times going to full deflection. When I stop the inputs in my steering script I have the Motor6D make the DesiredAngle equal the CurrentAngle.
I may have traced it to a lag issue with lots of vehicles in the game, as on a blank baseplate it works, but when I have 20 constraint suspension vehicles in game it gets worse.

I was hoping this was the root cause since there was no update on the post. Thanks for letting me know!