WeldConstraint BreakJoints | undefined rewelding

[MrGreystone (Grey)]

Reproduction Steps

1. WeldConstraint between two BaseParts is broken by a :BreakJoints() call to one of the BaseParts

2. Sometime ahead, the WeldConstraint suddenly reenables in some odd occurence, as if triggered by an internal change of state, and dislocated BasePart is reintegrated to the fuselage.
   
   

Expected Behavior

• Class WeldConstraint(s) should not reweld after :BreakJoints() is called on directly related BasePart.

• Class Weld(s) should immediately kick in like WeldConstraint when Model parented to workspace (and model should not fall apart temporarily before then)
  

Actual Behavior


This is occuring actively (5/28/22 and the days prior)
Switching to Weld fixes this, but creates the second problem of the Car “falling apart for a split second before the welds kick in” when parented to workspace (can be included or seperate bug report on demand).

Other documented occurences on the DevForum (2021 and 2020 respectively)

Welds ReWelding after calling Breakjoints()

So basically I have a car crashing game and recently when I crash and call Breakjoint() every once in a while it will re weld the parts to the car and the parts will float in mid air attached to the car. Does any one know a alternative to breakjoints or a fix? [image] This time it made my dads car float

WeldConstraints Randomly re-enabling after BreakJoints call (?)

The cars in my game are held together by WeldConstraints. I just upgraded to the WeldConstraints from the old Welds because they’re easier to use. Problem is, they’re leading to some… …exceedingly odd behavior: When cars crash into each other faster than a certain speed, and explosion is created and BreakJoints is called. For the most part, it works fine. But recently since I switched to WeldConstraints from Welds, cars have been randomly re-welding after getting broken apart. Does a…

Workaround

Plan on using Custom :BreakJoints() implementation that Destroys the WeldConstraint Class, and continue using WeldConstraint Class.

Issue Area: Engine
Issue Type: Other
Impact: Moderate
Frequency: Sometimes
Date First Experienced: 2022-05-24 00:05:00 (-04:00)
Date Last Experienced: 2022-05-28 00:05:00 (-04:00)

[kleptonaut]

Are you still encountering this issue?

[MrGreystone (Grey)]

This and other internal API/Instance issues have been forgone by our team’s custom implementations in detail below:

---

By forgoing:

“Explosion” Instances, which seem to simulate inparrell, not on server, were causing desync ( (the driver player) character see’s their car intact, the other player not, the driver character on the ground).

and implementing a custom gExplosion that uses custom gBreakJoints() instead:

implementing a custom BreakJoints(), gBreakJoints(), which calls getDescendants, identifies all WeldConstraint in the traversal, destroying them. (BreakJoints just disabled the Welds, which reengaged sometimes later, often. *Speculation: Client refutes BreakJoints to its car, reenables its welds, through exclusive authority of NetworkOwnership possession?)

and

No longer used Weld for intended static, rigid joints, WeldConstraint replaced all. (did not fix the problem iirc, but was a first attempt)

---

The problem no longer shows w/ cumulative changes.

I do not have an interest in recreating the old circumstances but I would imagine that a live Server with Explosions OnTouch mines, with Weld-using cars doing 160 studs/second, with the typical NetworkOwnership at play, a driver, a observer will reliably produce our two issues (I realize now)

of:

• explosion mechanism desync (only at high speeds typically)

• mechanism weld reengaging (was at any technical speed)

Blocks CanCollide OnTouch BreakJoints() were also used, and could trigger the weld-reengaging glitch likely, which are used for kill-water ingame, as well as the OP cactus.