Creating and then attaching SpringConstraints using scripts can trip humanoids, glitch out vehicles, and more

Bug Reports Engine Bugs
#1

When using a script to automatically create and attach a SpringConstraint between two parts, the parts can glitch out unexpectedly. I’ve only tested it with one part anchored, although I imagine it would still glitch out if both parts were unanchored. (After all, this isn’t Scrap Mechanic, where attaching a rope to an anchored object causes your crane to become a helicopter, but unanchored objects are fine.)

Once the constraint is attached between the two, it can result in Humanoids tripping, or teleporting far underneath the ground and instantly dying. It can also result in vehicle wheels becoming glitched, and flying off / teleporting underneath the baseplate.

In my first attempt at doing this, waiting for RunService.Heartbeat (but not Stepped, and not more than once) before putting the SpringContraint into the data model seems to lessen, but not nullify, the effect. That workaround doesn’t work in my minimal repro file attached below, but that may be because I’m attaching the spring slightly differently than I did the first time. (Parenting the Attachments directly to the parts, instead of to other parts that are welded to the parts so the parts welded to the parts have the constraints, but the parts with parts welded to them don’t have any extra Attachments inside of them. Just the parts welded to the parts)

I’ve only tested this with springs so far, but it happens even with springs with 0 MaxForce. Additionally, a humanoid continues to just act weird with springs attached, even if the springs aren’t actually doing anything (0 max force).

This bug happened from the first time I attempted this, so I can’t provide a time where it suddenly started happening. This may have been in the PGS solver from the very beginning, or it may have started happening right before I tried it.

Repro: SpringConstraintThingyRepro.rbxl (68.8 KB)

Basically, to experience the full glory of PGS, walk over the amazing spring attachy part or drive the provided vehicle over it.

These springs have MaxForce = 0 and FreeLength = 0.

A member of post approval speculated that this had something to do with the seat and network ownership. It may have something to do with network ownership, since parts simulated on the server don’t seem to glitch out in my very limited testing (dropping a part onto the magic spring part at different angles in Run mode), but I don’t think the seat has anything to do with it. Probably just the network ownership.

Original post: Attaching constraints trips and glitches out vehicles, humanoids and more

4 Likes
[Live] Changes to Motor6D.Transform and Motor.CurrentAngle
#2

could it be perhaps because the engine has allready started running ?

1 Like
#3

(notification: perhaps it may be because the engine already started running? but the post was immediately deleted within seconds)

This might be part of it. You have unanchored parts, that are already being simulated, and suddenly they have constraints, and are part of a new assembly, and the solver freaks out.

This is just an uneducated guess (I’m just a scripter), but it might be similar to what is happening.

#4

especailly perhaps because the positions of the created spring or difforent from the auctal physics positions by the time they are simulated. ?

(also the delete was accidental, and fixed)

1 Like
#5

What do you mean? The spring is created with MaxForce 0, so it shouldn’t affect anything physically… but it does.

1 Like
#6

this is where my knowledge ends in usefulness.
hope my previous statements were helpful in some way.

1 Like
#7

I think I know what this is!

Humanoids have some issues when attached to anchored parts with constraints. They get confused about network ownership (Humanoid checks ownership on the “mechanism” root, the anchored part that has no network owner, instead of the correct “root moving part” root that everything else uses for network ownership).

In that situation everyone simulates the Humanoid in non-authoritative mode only. No owner, no master. Weirdness ensues.

I can’t actually think of a good way to work around this right now.

The good news is I think I just wrote a fix for the underlying issue recently. It has some trade-offs to it so we’ll still need to discuss it more, review it, and write some regression tests for it.

6 Likes
#8

So is the vehicle thing also a result of this, since the Humanoid gets welded to the seat?

#9

Looking at your repro there’s several layers of bugs piled up on top of what I mentioned…

image
image443×531 143 KB 

> print(workspace.ContextLost.PrimaryPart:GetRootPart())
 RightFoot

So the root part of the humanoid isn’t actually HumanoidRootPart. Humanoid physics does not handle this well right now and freaks out. In several places it just assumes it is the assembly root and doesn’t compensate if it’s actually not. That’s another known issue.

The foot being the root flips the direction of the implicit tree relationship for the Motor6Ds. The tree is being built out from the foot, so parent-child relationship up the leg is reversed. Back to normal after the LowerTorso. This (unfortunately) also effectively inverts the interpretation of the animated Motor6D.Transform for that leg… That’s why the knees are bent backwards. I’ve known about this and wanted to fix this for a while, but was on the fence since it’s technically a breaking change. I think this gives me the ammunition I need to pull the trigger on that.

2 Likes
RopeConstraints that are connected to the player and an anchored brick, flip the player's hand upside down
#10

Huh… So what does that mean? Are the Part0/Part1s getting flipped or something? How could the root part cause the animations to go weird?

Sorry for the questions, this is quite intriguing…

#11

Effectively, yeah. It’s basically using Transform:Inverse() instead of Transform normally, so the joint rotation is reversed. Animator attempts to compensate for this, but apparently that’s not working right either.

1 Like
#12

Alright, so my next question is, how come vehicles also get glitched out?

Does this also have to do with network ownership and anchored parts in the assembly?

#13

I don’t know what the issue with the car is yet

It’s definitely changing the root around which could confuse physics replication, but since you’re the network owner I wouldn’t expect anything to be doing anything to make that a problem?

I’ll have to investigate more and ask some of my teammates later.

1 Like
#14

Any updates on this? I want to be able to fling around players with constraints, without the constraints flinging them around!! :stuck_out_tongue:

#15

I’ve submitted a fix for humanoid state replication and have a fix for backwards knees in code review now. Might take a few weeks or up to several months for those to be enabled, but those should help with some of the problems.

Other problems like the Humanoid force controller not correctly handling HumanoidRootPart not being the root in some cases there might take a little longer.

It’s worth testing again once those fixes are enabled though. I’ll reply when they are.

2 Likes
#16

The new beta feature (“Motor6D.Transform Consistency Beta”) seems to have made things a little less extreme and fixed the flinging and flipping problem, but constraints still trip the player (even if it’s, for example, a spring with stiffness 0) so this issue isn’t quite solved yet.

Having a lot of springs attached, even with 0 stiffness, also seems to cause issues with the Humanoid rotating. There’s still a bit of work to be done concerning this issue, but we’re getting there!