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:
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:
Platforms are no longer âreactiveâ regardless of PhysicsSteppingMethod and are no longer displaying any âdroopâ due to their own weight.
The BodyPosition force now âfeelsâ too high, causing the character to become stuck when using a BodyPosition constraint to hold the character in place.
The BodyPosition max force is unpredictable and varies based on movement direction, distance, etc.
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
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.
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.
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 !!
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.
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 , but getting forces surrounding this staff to work again would resolve the current issue and probably bring this thought to rest as well.
I looked at the place you attached and I think the non-intuitive behavior is due to the way that force limits are applied for the BodyPosition. The BodyPosition force limit is essentially a Box aligned with the World axes and the MaxForce components represent the size in each dimension. This means that the magnitude of the force exerted by BodyPosition can exceed the force specified in each dimension. When the character is walking, the force will be aligned with the movement direction so movements along the coordinate axis will face a lower force from the BodyPosition compared to movements at an angle. Switching to an AlignPosition will give you more options for the force limit specification so hopefully one of those works to your liking. The Magnitude mode approximates a force limit that is independent of the movement direction but because it is an approximation, it may not give a perfectly direction independent result (the approximation seems particularly bad when the constraint is satisfied and the part is at the target position). From your simple reproduction case, the best âfeelingâ result that I got was using the PerAxis force limit with the force specified relative to humanoid attachment. This aligns the force limit with the âwalking forceâ from the humanoid and seems to give pretty consistent direction results.
Then changed the Alignment Mode to âOneAttachmentâ and it did have me stick to a spot, but when trying to resist the force the movement was extremely swaying in a swinging motion.
But upping the force further, the swaying became less free and more closely resembled the current BodyPosition effect with its force seeming to depend on the movement again and not feeling consistent.
As prior to the change of the âFixedâ SteppingMethod (that made the behaviour identical to Adaptive), the force of the BodyPosition was consistent across all movements, similar to a lower walkspeed.
*edit
Itâs also these reactive forces, how now âFixedâ SteppingMethod (for BodyPosition) uses Adaptive & Dynamic behaviour too now, rather than a fixed result.
referring to the video https://youtu.be/Nsz7VRpuJ18 from the post in the original message of this thread
Where 1100 doesnât get the part to float up, but apparently is enough to keep it afloat once itâs at its destination. It previously wasnât reactive like this.
Perhaps thatâs part of whatâs causing the staff forces to also differ depending on the movements and not be consistent ever since the Fixed method became the same as Adaptive. Maybe this helps narrow down the issue
So there are a few things going on but the end conclusion is that we need to switch away from a BodyPosition instance and mimic the old effect with something else. Here is a breakdown of what happened and how it affected the staff effect:
Previously, the formulation for the BodyPosition did not include the effect of external forces, including gravity and the forces used to drive the humanoid. This means that the BodyPosition was unable to counter these forces and would not achieve the desired position. That said, the âerrorâ introduced acted like a spring and the final result was typically close to the target position for most values of P (the spring stiffness) and external force.
As part of the adaptive timestepping work, the error in the BodyPosition became more prominent because the final âerrorâ in the BodyPosition instance is a function of the timestep, meaning larger timesteps would show larger errors. To fix this timestep dependence, the original flaw in BodyPosition was eliminated, allowing the BodyPosition to achieve the target position regardless of the values of P, gravity, timestep or external forces provided the MaxForce is set high enough. This change puts BodyPosition on equal footing with everything else in the Constraint echo system.
For the staff effect, the old, incorrect formulation for BodyPosition ended up giving a relatively nice looking effect where the BodyPosition ended up providing a relatively consistent drag force which ultimately reduced the humanoid Movement speed. With the fixed formulation, the BodyPosition ends up exerting a larger force to counteract the force provided by the humanoid movement, canceling all movement when the MaxForce property is larger than the force provided by the humanoid. This means we get zero movement unless MaxForce is lowered drastically. When the MaxForce is lowered we can get some movement but we start seeing artifacts from the Box force limit enforcement. The AlignPosition workaround I suggested earlier should help with those artifacts; however, it is going to end up having a higher stiffness, dragging the humanoid back as you move further away from the target point.
To get back the old effect, I think you could try one of a few different things:
a) The end result of the BodyPosition is to simply lower the humanoid movement speed so you might want to just set that property directly.
b) If you want to still use a constraint, you have a few options. Because your BodyPosition instance is very overdamped, you could just use a LinearVelocity constraint to directly resist the humanoid velocity. This constraint will consider the humanoid force so you will need to tweak the MaxForce to ensure that it is low enough to not stop the motion completely. This constraint applies its force limit independent of the direction so you should not see the same artifacts that BodyPosition had. Finding the right force value is admittedly tricky. Similarly, you could use a LineForce if youâd prefer a constant force.
c) You can try using a SpringConstraint. This constraint will allow you to set the Damping and Stiffness independently and should allow you to get pretty close to the old BodyPosition behavior. Depending on the values of Stiffness and Damping, you may see some stability problems but you should be able to find values that work.
Let me know if any of that will work for you.
As for the second issue, I believe the issue is sleep. When waking up a part, we need some thresholds to determine if the part should wake up. A large enough force difference should be enough to do it but small changes may be below the threshold causing the part to not wake up and the same force that moves the block when it is awake may not be enough to move it if it has fallen asleep. We have some upcoming improvements coming for that system so I will check if these kinds of issues will be solved by those.
The previous* behaviour was good for practices like this. Fixed steppingmethod differed from Adaptive. It was constant and didnât see these dynamic external force effects. Ever since that ~9th the Fixed method became the same as Adaptive, which is what caused the current issues.
These forces acting the way they do in Adaptive is all good, but thatâs exactly what set Adaptive & Fixed apart; these methods handled it differently. Ever since that change theyâre the same in action. âFixedâ is currently Adaptive in practice, just with another name.
This change allowing BodyPosition to function equally to other constraints seems nice, but does remove these niches that clearly something as AlignPosition doesnât posses. But it again comes down to the seemingly lost discrepancy between these PhysicsSteppedMethods.
If only I didnât report on the initial weakened power bug and knew how changing to Fixed would fix it >_< then fixed had remained the way it was, whilst Adaptive/Default would work with the new âcorrectâ formulation
*before ~November 9th, 2023
I went over and tried the things mentioned
a)
Well, I only brought up the WalkSpeed as that slows the humanoid consistently in all directions, just as how BodyPosition used to work (BodyPosition's power is suddenly less - #14 by milanomaster) regardless of them zigzagging, jumping, or whatever it be that manipulates the force.
âWhy not consider changing their walkspeed instead.â
That was actually my first attempt at creating this effect, but later found that BodyPosition does the same thing, but better.
It dragged/forced you back to the original position, takes into account Y axis changes too and could be modified separately, without messing with another character stat.
thatâs not what this bug is about. The bug and cause is about the fixed steppingmethod having become the same as adaptive (dec ~9th, '23), pretty much right after I got the previous issue with weakened force to work thanks to RadioGamerâs solution of changing to the Fixed method (oct 16th, '23).
I gave it a go anyway and nothing about the manipulated forces themselves is different.
b)
All BodyPosition values were fine, as Iâm assuming the subtle dip (not the big drop) back then played a role too. + The forces were consistent because the âFixedSteppedMethodâ actually differed from the Adaptive one.
I tried the LinearVelocity, but Iâm not quite sure how to apply this to the humanoid. Iâm running a loop to update the force as the player velocity may differ with every move they make. Result is the character shaking back and forth and constantly getting a new point to which they wiggle at. It hard to even tell what the forces are doing here. This might be to do with the way I set the force as the negative of their current, as that should bring them back?
Trying LineForce, I found it does not offer a mode to set the position to where the humanâs pulled back to. Setting one attachment to the staff will be a pull effect. I had to add an additional part with attachment to work as a destination (having the option to also use position coordinates would be easier here)
local part = Instance.new("Part", workspace)
part.Position = target.Position
part.Anchored = true
part.CanCollide = false
part.CanQuery = false
part.Transparency = 1
local att = Instance.new("Attachment", part)
powerGrabEffect = Instance.new("LineForce", currentConnection)
powerGrabEffect.Attachment0 = currentConnection
powerGrabEffect.Attachment1 = att
powerGrabEffect.Magnitude = 18000
This seemed to work, but whenever my character gets off the ground theyâre shot right back to the spot. It also feels more like a rope thatâs pulling you back than the equal force it used to be, which was quite similar to the humanâs own resisting power.
c)
Again had to use an additional part for this one. The resistince power seemed nice too, but the pull was too much of a⌠well âspringâ. Another thing I found was for it to be of reasonable force, the distance I was able to travel became limited. I tried changing its value along with the damping, but to no prevail.
B2 and C donât seem to show differences in force when moving sideways for example, but when trying to cross to the other side, the pulling force really takes over. Same goes for jumping pulling you back immediately. Perhaps B1 (LinearVelocity) doesnât do that if set up properly.
Ah, sleep makes sense as to why the values act this way. Again, all these issues arose ever since the Fixed SteppingMethod became the same as Adaptive. If fixed were to be the same as it was October 16th, '23, all would be fixed
I did catch something about them being inseparable from each other:
But that has me wonder how around that date in October, changing to the Fixed method did see different results (and fixed it until that November). This means they were clearly different from each other, which could not have been possible if one cannot be changed on its own âHow were they different in the first place.â
Thanks for trying my suggestions. Unfortunately, Spring constraint and Line force will require the creation of an additional attachment to work so I can understand how that makes them a bit more annoying to use. The line force should drag you back to the original position if you place the attachment there but it will behave just like a constant force and not something that only counteracts the humanoids current speed. For the LinearVelocity, you can use it as a drag force simply by setting the velocity to zero (I was using Plane mode so that vertical movement was not affected). Configuring the constraint this way will cause it to apply a force up to the max force in order to force the humanoid speed to zero. It wonât provide any âsnap backâ affect so thats probably not a good option if you want that. I think your best bet is to play around with some of the settings on the SpringConstraint. The stiffness and damping of the Spring directly correspond with the P and D parameters for the BodyPosition so you should be able to use the same values you had. The only extra parameter is the free length. You should get similar behavior to the BodyPosition if you set this free length to a small value (I think 0.1 is the minimum).
As for the adaptive vs. fixed stepping, the behavior should always be the same (or at least similar). Adaptive stepping is a performance optimization that allows the physics engine to take larger timesteps when it detects that a part is not accelerating much or that larger timesteps will not reduce the stability of the physics solver. Larger timesteps means we do less work per frame and we free up resources for more physics objects or other systems. This adaptive stepping is a key component of improving the scaling and performance of the game engine. Because Adaptive stepping is meant as a performance optimization, we have designed it to not cause behavior changes. When we see behavior changes, it typically means we have a bug in either the adaptive logic (meaning we are incorrectly taking too large of timestep) or in the case of BodyPosition, we have a formulation that isnât consistent (meaning the final result depends on the timestep we use in the solver). In addition to these theoretical reasons, PhysicsSteppedMethod is also part of a Three phase rollout, which means we intend to eventually make Adaptive the only option and we donât want that change to come with behavior changes. Hopefully this helps.
Ah, thanks for the additional LinearVelocity info
Gave it a further go and found that when jumping I was held stuck in the air.
Then changed the plane axis and the jumping was normal, except when trying to move in mid-air.
When increasing the force it suddenly started showing these reactive forces again to where certain movements resulted in 0 movement and others didnât hold me back much.
And indeed, no slight force that moves you back.
Ahh, perhaps I didnât explain my SpringConstraint findings quite well enough. I was limited as to how far I could move. At some point the spring doesnât extend any further which makes it strange for whenever youâre moving to another side.
I again also noticed the swining again and how certain directions changed/affected the force. By using some movements, I was able to swoop around the part as a pendulum, but then held back significantly more in another direction
The latter also applies to LineForce. I changed the Magnitude to a higher number which yes, slowed the character from moving outwards more, but still saw this easy walk to the other side of the anchor part (which isnât desired)
So in the end none achieve what the BodyPosition did using the Fixed Stepping Method before this method was automatically updated after a change to Adaptiveâs drop bug.
I appreciate the alternative solutions, but unfortunately none seem to suffice to fulfill BodyPositionâs unique functionality.
I suspect that similar to how a Humanoid triggers the platform to a degree where it doesnât drop/give in and acts differently compared to other parts on the platform, the same thing happens with the staff. The MaxForce was 100,000 (X, Z) at first, but now has to be brought down to around 20,000 as 100,000 is suddenly too much force.
The BodyPosition seems stronger and more ferm when it involves a Humanoid now, whereas it gives in more easily with other parts.
Previously it also gave in more easily with Humanoids too - which might be exactly whatâs needed to fix this.
I remember loading up a platform with players and a bomb model back then, which the platform used to slightly struggle with because of the load (and because my values werenât sky high).
When the big drop bug around Septemberâ23 happened, the platform had obviously sunk a few studs because of this bug, but when touched by a Humanoid it restored itself. The rest of the moving when going up with this load was the same.
I believe that bug came from my place using Default steppingmethod, which changed from Fixed being the default to Adaptive being the new default method. Thatâs probably where this big sinking drop came from.
Then, thanks to RadioGamerâs solution, I changed to the Fixed steppingmethod and it was fixed.
There was no more big sinking drop and no more humanoid activation was needed to restore that
So the Fixed method had the platforms keep this subtle dip (because of my lower force values) and still allowed for applications like this power grab effect of the staff.
Then the fix to Adaptive came which made Fixed behave the same as the updated Adaptive.
Which:
Made bodypositioned objects stay much more in place, yet see strange activation behaviour (the sleep?) where values may be enough to keep something afloat, but not enough to move it back up. / Referring to the floating part video
I ran another test placing blocks on a platform. After lowering the blocks mass, the platform went up a bit of the way there. Obviously not all the way as thereâs mass on it.
Strangely enough, when cloning another block on top, the platform went up a tiny bit instead.
It kept doing this until the mass did become high enough and the platform dropped. Removing that last part then brought up the platform, but not as high as it somehow got previously
It also caused platforms to treat humanoids differently compared to random parts.
The mass of those characters far exceeds a few blocks, yet it somehow stays afloat.
Perhaps this is part of why the force in the staff treats a human differently. It maybe exerting much more force against the humanoid?
Using the same D/P and MaxForce as in the TestPlace I sent.
It keeps the ball in place. When the ball mass gets too much however, it does roll down the slope despite the current power onto it. When changing the mass back to a lower number the ball rolls back up very slowly.
Not sure if this ball is of any use, but perhaps it can help.
I canât find anything about a three-phase-rollout
Though with the current missing discrepancy between the Fixed and Adaptive methods I can see why eventually only one option remains - which is practically the same already as a result of my initial thread.
In a post made by staff member Hajimalago, they did however mention as every project was unique.
Both had their place and well, around Octoberâ23 (and earlier that year too) that year it clearly showed how the two functioned differently, both suiting different behaviour and applications.
Whatâs caused the shift in them becoming the exact same in pracice?
As here Fixed worked well and both methods saw different applications each, which allowed for greater user customisation or as Haji stated âevery project is unique and its requirements varyâ.
As ever since they changed the behaviour early November that year, itâs completely removed one of the methods and its usecases. In my case, it be the staff and hovering parts not properly functioning.
Part of it has to do with sleep, which wasnât a thing back then.
And another part is different behaviour for Humanoids: When thereâs a bunch of very heavy characters on the platform it would previously sink, whereas now it does not. When I remove the humanoid instance from these characters however, the platform drops down immediately.
This isnât the desired behaviour. I suspect subtle dip as a result of a lower force back then played a role too (which was good and intentional), but as soon as the big drop bug happened (which could only be ârestoredâ by a humanoid connecting with the part) in the newly defaulted Adaptive, it was changing to the Fixed method that solved it and brought back the desired behaviour and essentially fixed the problem. But then the change to Adaptiveâs behaviour on this big drop also caused Fixedâs behaviour on it to change⌠/ It fixed a bug, but caused a new one.
Similar to the niches these other constraints/forces/movers/velocities/alignments, BodyPosition has its own.
Maybe the current imbalance between forces on/by Humanoids and other parts can help aid in finding a solution to reachieve the previous behaviour which the Fixed Method allowed for.
Even if itâs a checkbox that enables/disables certain forces that may influence movement.
So by checking (or unchecking) it, it would make the platforms and staff power grab effect function as intended again.
Platforms can move without additional activation force
Platforms also allow sinking due to human overload
Forces computed on humanoids are consistent and may disregard manipulative user input (zigzagging, jumping⌠anything that results in different forces)
This should ultimately fix the issue as well as allow for greater variety of customisation.
As Iâm not sure what internally got changed that early November, but Iâm sure part of it can be turned to simulate, mimic or alter behaviour per Instance following Fixedâs physics, whilst continuing Adaptive. Might this be a solution?
, but getting forces surrounding this staff to work again would resolve the current issue and probably bring this thought to rest as well.
