Prevent part from becoming root

[Nils277]

Hi,

is it possible to prevent that a part becomes root? Be it with a certain setting in the config file or (more likely) with a certain code snippet in a PartModule?

I know that parts that are physicsless or don't have a stack node can't become root, but the part I need, does have stack nodes and is too big (and heavy) to be physicsless.

So, is it possible to do this via code? 

[sarbian]

Nope, as far as I know physicsless is the only way to prevent a part to be root and I don't see a way to go around that.

[Nils277]

@sarbian Thanks for the answer. Well, then i have to live with that.

I must have a look at the API, maybe a PartModule can cause the vessel to change its root when it detects that the part it belongs to is/has become root. But i'm afraid this will have unforseen consequences if at all possible. 

Edited January 15, 2017 by Nils277

[Nils277]

I think there is a way to achieve what i want.

It's not that obvious but there is this member in the AttachRules of the part:

part.attachRules.allowRoot

at least this does seem to prevent the part from becoming root in the VAB/SPH. Still need to verify this in flight though...(especially when two vessels undock and one of the docking ports can become the root of the new vessel)

Edit: Looking even further i found that this can also be done with the 8th paramter of the attachRules field in the config of a part. 

Edited January 15, 2017 by Nils277

[Nils277]

Although i feel bad about triple posting, here's what I found out:

1. It is possible to prevent a part from becoming root in the editor by either using the 8.th flag of the AttachRules or making the part physicsless.
2. Both being physicsless or having the 8.th flag set to 0 does NOT prevent a part from becoming the root in flight. Tested it with a docking port
3. Making a docking port physicsless causes it to spam NREs when attempting to dock.
4. All my attempts to change the root of a vessel caused strange physical behaviour. (Vessel seems to be nearly weightless and always tips over to the same side)

If someone knows how to change the root in flight (or has an idea), please let me know. 

 

[Diazo]

While I'm not sure I can actually help, I'm pretty sure that everything you are seeing comes from the fact that the root part is the "start" of the vessel layout in the data file.

So I presume that when you change the root in flight, there is no more "start point" for building the vessel and while it may render on-screen, a whole bunch of behind the scenes stuff has gone wrong.

Now, Squad obviously has code buried in the game somewhere to handle the changing of root parts, at the very least undocking would require this. If you can hook into that you are good to go, otherwise I'd look at trying to resolve your issue another way.

Trying to reverse engineer everything that goes on and change the root part yourself is just asking to summon the kraken if you miss the tiniest thing. It would also be very prone to breaking any time KSP updated.

D.

Edited January 17, 2017 by Diazo

[Nils277]

You are right, changing the root of a vessel by hand is really prone to cause many errors and i have not yet found any public function in the API that does this automatically, so i may be out of luck. 

Edited January 18, 2017 by Nils277

[Warezcrawler]

On 15/1/2017 at 5:54 PM, Nils277 said:

part.attachRules.allowRoot

On 15/1/2017 at 5:54 PM, Nils277 said:

Looking even further i found that this can also be done with the 8th paramter of the attachRules field in the config of a part. 

Could you please provide an example on how the attachRules look with allowRoot is negative/positive?

 

 

[Nils277]

55 minutes ago, Warezcrawler said:

Could you please provide an example on how the attachRules look with allowRoot is negative/positive?

In the config file:

When the part is allowed to be root:

attachRules = 1,0,1,1,0,1,1,1

when the part should not be root:

attachRules = 1,0,1,1,0,1,1,0

The first five paramters are the well known ones. 
The 6.th and 7.th are allowDock and allowRotate. They are 1 by default, i have left them that way and did not test what they do.
The 8.th parameter is allowRoot. It defaults to 1 where the part is allowed to be root and 0 when it is not allowed.

 

Alternatively in plugin code (in a PartModule)

Part is not allowed to be root:

part.attachRules.allowRoot = false;

or part is not allowed to be root

part.attachRules.allowRoot = true;

 

Edited January 18, 2017 by Nils277

[sarbian]

2 minutes ago, Nils277 said:

Part is not allowed to be root

And as stated earlier in the thread this is only true in the editor.

[Warezcrawler]

31 minutes ago, sarbian said:

And as stated earlier in the thread this is only true in the editor.

Thanks for pointing that out... I had missed that one info in the thread 

I was hoping this could help prevent some root problems with docking/undocking.

Edited January 18, 2017 by Warezcrawler

[Nils277]

1 minute ago, Warezcrawler said:

Thanks for pointing the out... I had missed that one info in the thread 

I was hoping this could help prevent some root problems with docking/undocking.

Unfortunately not...and that is exactly my problem. The partModule i'm writing strictly needs a parent part and would ideally also have a docking port...but undocking causes exactly this part to very often become root.

[Warezcrawler]

Just now, Nils277 said:

Unfortunately not...and that is exactly my problem. The partModule i'm writing strictly needs a parent part and would ideally also have a docking port...but undocking causes exactly this part to very often become root.

Yeah.... I see your point... The karbonite generator (KEG-2500 Karbelectric Generator) really messes things up if it becomes root. It becomes invisible, and physics can misbehave - this was at least a problem back in 1.1 

Docking ports themselves could probably use a prevention of root. Maybe this is actually the problem "Infernal Robotics" had, where combining docking ports and IR was not something you should do....

[Nils277]

Yes, IR needs a parent part for the Joints to work. Also when two ships dock it is possible that the parent part changes, which completely destroys all saved translations and rotations because they are relative to the original parent.

It would be really great when a part that is set to not be the root part in the editor will also not become root in flight. I mean the flag was set for a valid reason and will most likely only affect the vessel in flight and not in the editor

Edited January 18, 2017 by Nils277

[Warezcrawler]

14 minutes ago, Nils277 said:

Yes, IR needs a parent part for the Joints to work. Also when two ships dock it is possible that the parent part changes, which completely destroys all saved translations and rotations because they are relative to the original parent.

It would be really great when a part that is set to not be the root part in the editor will also not become root in flight. I mean the flag was set for a valid reason and will most likely only affect the vessel in flight and not in the editor

Yes.. That, or another setting, like the ninth one, that would set the inflight allowroot setting... Maybe if a request is passed to squad they might incorporate that?!

[Nils277]

I made a bug-report about this behaviour because i think that the allowRoot parameter should apply to all situations: Bug Report

Lets see what come out of this.

Edited January 19, 2017 by Nils277

[linuxgurugamer]

On 1/15/2017 at 11:54 AM, Nils277 said:

I think there is a way to achieve what i want.

It's not that obvious but there is this member in the AttachRules of the part:

part.attachRules.allowRoot

at least this does seem to prevent the part from becoming root in the VAB/SPH. Still need to verify this in flight though...(especially when two vessels undock and one of the docking ports can become the root of the new vessel)

Edit: Looking even further i found that this can also be done with the 8th paramter of the attachRules field in the config of a part. 

Just tried this, it seems that some other modules will override this (probably ModuleCommand, among others)

I ended up using the attachRules as you described in the part