I will give this a shot later and check but I do not have any parts on my car that are set below .01 density so I’m doubtful this alone is the cause.
I can confirm that changing it to disabled does not help the issue.
I suspect that its adaptive stepping not working well with surface hinges. Can you try setting your Workspace::PhysicsSteppingMethod to Fixed and see if that fixes the issue?
We would also strongly recommend replacing your surface hinges to constraints. This will greatly improve stability and even performance as vehicle seat wheels are processed in serial
Constraints require custom coding to make the car drive. Surfacehinges + vehicleseat naturally work on gamepad, mobile, and keyboard without any code needed. Also I’ve tried to reverse engineer how a tank chassis car using surface hinges behaves and I’ve come up short each time trying to replicate its exact behavior with constraint hinges.
Until constraint hinges can have the exact same behavior (drive the same and works out of the box with no need for custom code) there is no reason for me to switch over.
Switching physics stepping to fixed did not fix the issue.
Here is the current settings for transparency:
Today, the bug has worsened. Both with PhysicsStepping set to fixed & with it set to default.
Now the tires are ridiculously unstable.
Further update. The problem does NOT occur when I’m on mobile. As well, another player has reported they are on their PC using keyboard (like me) without issue.
Could this be something to do with me having some form of Beta on my client running things differently?
Mobile footage:
And now it’s back to just a little bumpy at times & every now and then a real large bump.
It’s possible this is related to the density of the ball part wheels.
I set it to a lower value, and the issue starts occurring. If the value is low enough, it’s the exact same behaviour in your most recent video where the wheels go mental.
I set my wheels custom physical properties mass to 1, and the issue no longer occurs. As a test, can you try increasing the mass on the wheels, to see if we’re getting the same behaviour?
I had DecreaseMinimumDensityMode disabled, it didn’t make a difference.
I do have some feelings around the idea this is a mass vs torque issue, meaning either increasing the mass or reducing the torque will settle the car.
My point of contention however is that I hadn’t made any changes to my vehicle for the last 4 weeks and now it’s presenting problems. This tells me a change was made to the physics engine for how these things work and that it should probably be changed back to suit making the cars feel as they always have.
1 Like
Upon further review:
- ~half torque (105 → 65) still glitches
- 1/4 torque (105 → 25) still glitches
- double tire density (5->10) with 105 torque still glitches
- quad tire density (5->20) with 105 torque still glitches
- 35 torque, 20 density tires still glitches
so, I stand corrected, it appears to be collision issues, not torque ratios
this is starting to feel like when the buoyancy update broke cylinder tires back in the day
Added Note: Same thing happens if I replace the wheels with Cylinders…
1 Like
This bug occurs on all 3 (Adaptive, Default, and Fixed) PhysicsSteppingMethod settings.
If I set the network owner of the car to nil
local car = game.Workspace.Cars.GeorgeOfAIITradesCar
car.VehicleSeat:SetNetworkOwner(nil)
The car still gets the bumps a little but not as bad
Here is a video explaining and showing that fact:
I’m having the same issue in my game that also uses surface hinges and the balls as wheels. I tried changing “DecreaseMinimumDensityMode” in workspace to disabled, that did not work. But I changed " PhysicsSteppingMethod" in workspace to fixed and it looks like it resolved the issue for all the cars in my game. Also, I noticed that the issue with the wheels glitching would never or very rarely happen in studio, and it would mostly happen when I was in the actual ROBLOX Player on my PC.
Can confirm that changing the ‘PhysicsSteppingMethod’ to fixed sorts this issue which was happening in my Go-Karting game.
https://gyazo.com/08d7520b5a12b467cf2be17845af4d0d
I can now confirm that Fixed PhysicsSteppingMethod has solved my issue.
I will leave the bug report unsolved, until I’m told that this is intended behavior
To clarify what I mean by "Intended Behavior"
- To use tank chassis cars going forward, I must set PhysicsSteppingMethod to “Fixed”
- To fix all of my places, I must go set PhysicsSteppingMethod to “Fixed”
(Note: Not being able to script it is actually a quite annoying thing that I will now have to go update close to 100 places to have Fixed hard set in them.)
@GeorgeOfAIITrades
We are working on a fix for your case under PhysicsSteppingMethod = Default/Adaptive.
So updating all places won’t be necessary.
(essentially VehicleSeat surface hinge cars will be forced to run at a fixed timestep even if the workspace setting is set to default/adaptive, which solves your issue.)
1 Like
Updpate: the fix is being released at the moment, we will let you know as soon as we get it enabled. (will take a week or two)
1 Like
Couldn’t be waiting for a fix so already went and updated all my places that are necessary to update but glad a fix is being rolled out eventually.
Out of curiosity, is the fixed time step the largest one? (240hz)
1 Like
My question more so is concerning what
this section of the above message exactly means. Not what the “Fixed” Timestepping setting does (I read the DevForum post you linked already)
Yes, us putting the VehicleSeat SurfaceHinge car into “Fixed” means it will always step at 240hz, even if Workspace.PhysicsSteppingMethod = Adaptive, the car itself will still step at 240hz. It will not be able to take advantage of the performance benefits of the lower frequencies.
Eventually the PhysicsSteppingMethod option will be removed, putting all places into “Adaptive” mode. Edge cases like yours will continue to run locked at 240hz.
2 Likes
(post deleted by author)