PhysicsSteppedMethod behaviour is the same regardless of setting

Initially started as a weakened BodyPosition report, the internal fix to this issue resulted in a second issue:

Both Fixed as well as Adaptive (new default) behaviour now see the same results, which can be clearly seen in parts with BodyPosition in them. Whereas previously Fixed resulted in a constant force to the part, the new Adaptive behaviour sees a more dynamic approach, incorporating other forces and the motion of the part to determine the force.

So both behaviours are expected to be different, yet they’re somehow the same as of ~ November 9th, 2023.
Unfortunately I hadn’t heard back anything about this change and it was never restored (as well as the post being ‘hijacked’ by off-topic responses), hence why I’m filing this new bug report with the issue.

Here’s a second paragraph from May 14th of this year, explaning the issue further:

1 Like

Thanks for the report! I filed a ticket in our internal database and we’ll follow up when we have an update for you.

Looks like there is a lot of history here so I’m going to attempt to summarize the issues you are seeing. Please correct me if I miss any or misunderstand what is going on:

  1. Platforms are no longer “reactive” regardless of PhysicsSteppingMethod and are no longer displaying any “droop” due to their own weight.
  2. The BodyPosition force now “feels” too high, causing the character to become stuck when using a BodyPosition constraint to hold the character in place.
  3. The BodyPosition max force is unpredictable and varies based on movement direction, distance, etc.
  4. The BodyPosition force property appears to be inconsistent, with the same forces leading to different behavior when levitating a block.

For the first two, the problems are interrelated and both are caused by a bug in the original BodyPosition implementation. When computing the force that the BodyPosition should apply in order to reach the target position, the original implementation was using an out-dated velocity which caused it to under-estimate the required force in some cases. As you have seen, the result of this bug is relatively subtle when we are simulating at 240 Hz (which is the timestep we use for our simulation when using the Fixed Stepping method), leading to pretty plausible looking behavior with a little bit of “give” caused by the lagged velocity. For larger timesteps (which can be used when stepping is set to Adaptive), this bug introduces larger behavior changes. As part of addressing this issue, we ultimately fixed this original bug. The fixed implementation is now consistent with every other constraint and is more stable for different values of external forces, gravity and timestep.

For the third issue, I am seeing the direction dependent behavior you report and I think it might relate to the way BodyPosition specifies its MaxForce. The MaxForce is per-component and specified in WorldSpace, meaning the magnitude of the overall force can be larger than any of the specified components if the force is not aligned with one of the World axes. You might try an AlignPosition with the ForceLimitMode set to Magnitude. The resulting force should have a magnitude that is closer to the specified value. For this issue, we may also be seeing a bad interaction between the constraint and the legacy humanoid, so you might want to take a look at the new physics-based character controller and see if that gives more intuitive behavior.

Finally, the last issue looks like a sleep issue to me. It seems like there are some force values that should be sufficient to lift the part but aren’t sufficient to wake it up, causing it to stay stuck. I’ll follow up with members of the team that know this system better to see if there are any improvements we can make.

Let me know if I missed anything or if any of these suggestions work for you. Thanks.

Lot of history indeed, which ultimately has made this issue more complicated than it should have :sweat_smile:
I will try and go over it again:


A lot of my message here summarises what’s happened the first time I addressed the weakened power.
The power was fine before, but around early September 2023 is when I started seeing ‘sinking’ platforms and orbs. When a Humanoid touched it, the part restored its force.

Changing the PhysicsSteppedMethod to Fixed did fix this issue, which I did after RadioGamer informed me about that. This pretty much meant the issue was resolved and BodyPosition worked fine again.
:white_check_mark:


Then an internal fix for this original issue came (which wasn’t needed, because changing to Fixed already solved it)
It updated the Adaptive SteppedMethod, but also caught the Fixed SteppedMethod, resulting in a second bug.

This resulted in all PhysicsSteppedMethods being the same, whereas previously ‘Fixed’ kept the desired behaviour. After, it basically gave Fixed the same behaviour as Adaptive, which removed this slight drop too.

! The slight dip was because my force was intentionally lower. The big drop/sinking was the issue.

And because this slight dip got removed as a result too, this meant that the staff ability broke as a result of a supposed fix.
:x:


So ever since ~November 9th, 2023, both these PhysicsSteppedMethods are the same, which doesn’t make sense when both methods/modes see the same behaviour.

Before the fix it was fine, it allowed the platforms to do what they did before the initial issue, whilst keeping the consistent grabbing force effect of the staff (and other things you can do with it)

The current issue:

  • Fixed PhysicsSteppingMethod is the same as Adaptive. It previously (before ~November 9th 2023) showed the desired behaviour, whereas now it’s the same as Adaptive.

I would love for-

Fixed

to be reset back to how it used to be before ~November 9th, 2023. This would bring back the subtle dip, but not the big drop. And fix the issue !! :smiley:

Adaptive/Default

to see the current behaviour as it is now / no changes


Having the two methods be different again would be amazing!
It’s been a while since, but I can make a video on the topic, if that helps clarify. Perhaps that, or even a call (probably not a general custom) if that makes it easier

Thanks for the summary. The goal of the Adaptive Physics stepping is to give the same behavior as Fixed stepping but at a reduce cost, so we won’t be able to change the behavior for only one of the Stepping methods. I would argue that the new behavior is the correct one. Previously, the BodyPosition would fail to reach its target, regardless of the maximum force, and the error would vary with different values of P and gravity. With the new behavior, we achieve the desired target as long as the force is high enough.

Is the slight dip in your platforms desirable or does this just indicate that the Staff ability will still work? For the platforms, I think we would need to rework things a bit in order to get the exact same behavior as before. You could either programmatically introduce the dip you want to see or you could introduce additional constraints to simulate the appropriate behavior. For the staff ability, I think we should get to the bottom of why the force application seems erratic so you can tune the force appropriately.

Something about this subtle dip (obviously not the big drop) made it feel more alive somehow and had a charm to it, but ultimately it’s applications like the staff that experience this new behaviour to a broken state.

The first part (above the video) of this message explains the behaviour best.
Where the Fixed SteppedMethod used to see a constant range of force, whereas the new changes see different kinds of behaviour below a certain force.

|
Here’s an additional video on it: https://www.youtube.com/watch?v=qpHdHc9IxG0
Place to test the staff: Some Test - 10 Nov.rbxl (73.4 KB)


Would’ve been ideal if the Fixed SteppingMethod became the same it was before ~November 9th, where it kept the subtle dip as well as the desired staff behaviour. Still partly blaming myself for causing this change to the Methods :see_no_evil: , but getting forces surrounding this staff to work again would resolve the current issue and probably bring this thought to rest as well.