Parts connected to other assembly by any given constraint become AssemblyRootParts

I have a part that’s welded to the character. It’s massless, has a RootPriority of -127, and is unanchored. Despite all these measures, it becomes the AssemblyRootPart of the character Assembly whenever it’s Rope is Enabled.

I see no mention of this behavior under the Constraints docs, nor in the graph shown in the Assemblies docs, and thankfully not.

Expected behavior

I expect objects bearing constraints to be treated no differently than those not bearing constraints in assembly tree sorting. In my video the toolmainpart should never be the AssemblyRootPart, as the character’s HumanoidRootPart is clearly a better candidate.

2 Likes

Hey! Can you upload a placefile including the problematic character/part? I’d like to have a look into this.

Unfortunately this is expected behavior for the current spanning tree implementation which chooses AssemblyRootParts…

We don’t document this comprehensively because it is obscure and confusing, but in addition to the tree within an assembly, there is a “Mechanism” tree of Assemblies. All mechanisms have a root assembly and a root part. Unfortunately the mechanism tree and the assembly tree are all one singular multi-layer tree. The trees of parts within an assembly are always sub-trees within the mechanism tree in the current implementation.

(The network identity of the root part of the mechanism root assembly or the first moving assembly connected to the mechanism root gets used as the network identity of a network ownership unit.)

Because of this, if a part is the only part within an assembly that is is connected to the mechanism root assembly (or other assembly closer to the mechanism root), then that part must become the root of its assembly or the part tree might not still be a subtree of the mechanism tree…

This chart here omits this really hard to describe rule that “highest priority part with the most direct connection to a more root assembly within the mechanism”

Anchored parts must be mechanism roots, and the pull of that rope’s connections to an anchored mechanism root overrides all other rules…

As a workaround you can try adding a second, much longer, invisible rope between the HumanoidRootPart and the part you are connecting to. The spanning tree will prefer that assembly connection over the connection to the lower priority part and keep HumanoidRootPart as the root. Give the system a better alternative.

We’re hoping to change this in a WIP rewrite of this spanning tree system. In the next version the choice of assembly roots should not be influenced by external connections between assemblies. No ETA on that, but for now I hope this helps.

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.