Parenting mechanics of the Source engine?

A while back I got into a dispute with some people over the way parenting works in Garry’s Mod. They argued that having a weld constraint on a prop before it was parented would retain that prop’s physics simulation, and for some reason they believed that this would entail significant overhead on the server in larger quantities.

Of course I called BS on this, but they maintained that somehow nocolliding the props instead of welding them would somehow make the physics not simulate at all? Why it would work differently based on the props’ preexisting constraint?

So I ended up doing some research and so far nothing has been mentioned about different constraints causing different parent-entity properties. In fact, there isn’t much of anything on the subject.

From experience I know that prop:Spawn()'ing a child prop will cause some problems, and I also know that creating and parenting a prop without :Spawn()'ing it allows you to use it almost like a networked ClientsideModel, and it behaves as expected, visually staying perfectly relative to its parent. And since it was never spawned, there is no physics object.

I did manage to get this:

from the Valve wiki, and this seems to support my theory that the physics object doesn’t actually exist when you use a tool like Multi-Parent, or else it wouldn’t work at all. And in the code of Multi Parent, indeed the physobject is actually put to sleep, and there doesn’t seem to be any special treatment given to props whether their constraints were weld or nocollide.

Am I missing something? Everything I’ve dug up so far points to there being no real difference between welding and parenting and nocolliding and parenting. Since the physics object seems to be put to sleep in all cases no matter the constraint, I don’t see how welding before parenting would make any significant performance overhead at all, even in large quantities. But here I have very experienced builders (who despite their skill are very stubborn) telling me that I must be retarded for thinking this. Is there something here I’m missing? I honestly would like to know if I’m wrong about this.

The following is my personal opinion on what I believe parenting is and does and may not be actual fact:

Parenting is a technique for detail props on moving objects, and it simply attaches the object clientside which is why it works so smoothly. The server on the other hand doesn’t do anything (usually, physics objects are an exception) apart from mark that it’s parented to this at this point and angle.

It’s not designed for objects with entities which is why in my experience physics is disabled on parented props when you just use Entity:SetParent(Entity). Some parenting tools include a hacky physics fix which partially re-enables physics but it’s very buggy. There also appears to sometimes be a ‘physics’ ghost when you parent an physics entity which is left at the point of parenting until the object is removed serverside, though this may be part of the ‘hacky physics fix’ some tools use - unsure.

The constraints don’t do anything. You can get rid of the “ghost” physboxes, i can tell you how if you need that.

As for physics, the only way to get it to work is the way how Perma-Poly weld did it, which is by merging all physics objects into one using

So based on what you two said, I’m guessing the whether a child prop is nocollided or has any other type of constraint on it, there is absolutely no correlation to additional “stress” on the server? And this physics “ghost” you mention, I think it goes away if you sleep it; at least that’s what I observed from the code of MultiParent.

In other words, it doesn’t matter how you parent it, there will be no observable difference?

The sleep freezes the physics object, it can be still bumped into unless it is nocolided. It doesn’t magically remove it, as far as I know.