Does just WANTING a space station make lag?

[Padishar]

1 minute ago, pandaman said:

Is this the case, or have I misunderstood some detail?

No, that sounds about right.  However, note that, even with my 1410 part vessel with 24 active ports, it "only" uses about 8% of the CPU so you have to get to serious part numbers before it makes a large difference...

[pandaman]

2 minutes ago, Padishar said:

No, that sounds about right.  However, note that, even with my 1410 part vessel with 24 active ports, it "only" uses about 8% of the CPU so you have to get to serious part numbers before it makes a large difference...

That's very helpful, thanks.  I guess I don't need to worry 'too much' in that case, as long as I don't get too ambitious, but it's good to know the things.

Thanks.

[Archgeek]

14 hours ago, Tw1 said:

Woops, that was poorly worded. I meant within the distance that ports start to attract, but thinking about it, sounds like finding out what those parts are in the first place might make it just as bad or worse than what it’s doing currently. 

 

Though this sounds like an argument for using the shielded docking ports, if they're not active until open. 

Yeah, there's no way to search an area of space -- the game only has the list of parts in the scene, which happens to be the physics bubble.  If it maintained a list of active ports on each vessel, then it could check each vessel's active port list for distance and save a lot of time.

Them and the mk1 and 2 in-line ports, it turns out.

13 hours ago, pandaman said:

OK.  Very interesting stuff.

So... If I understand correctly, shielded docking ports with shields closed and all docking ports that are docked don't cause this issue, but ANY ports that are available to be docked to (even those inside closed bays etc.) have the search performed and so therefore add to the resulting lag.

Is this the case, or have I misunderstood some detail?

That's about right, those and mk1 and 2 in-line docking ports that are currently retracted.  Everything else is scanning the whole part list every physics frame.

[Brownhair2]

On 6/10/2016 at 5:52 AM, 5thHorseman said:

Also, I've noticed that docking ports tend to lag far more than other parts. I've not done a hard analysis, but a 50-part ship with 10 of those parts docking ports makes a bigger hit for me than a 100-part ship.

 

22 hours ago, Archgeek said:

It seems you were quite right, only the animated ports went into the disabled state -- the others were still active regardless of the state of their containers.

Well I guess that explains my Mun base. It's lagging a lot, even though it doesn't seem much bigger than my pre-1.0 space station. But it has more docking ports, so...

[evileye.x]

Someone needs to modify docking ports so the could have 'armed' and 'unarmed'  states, like shielded ones. Or even suggest it to SQUAD? 

[Archgeek]

57 minutes ago, evileye.x said:

Someone needs to modify docking ports so the could have 'armed' and 'unarmed'  states, like shielded ones. Or even suggest it to SQUAD? 

They'd want to include one exception if they were to do that -- you'd want open ports on uncontrolled "debris" (say, reusable propulsion stages you forgot to put a probe core on) to re-arm somehow, and without control on the vessel, you can't quite do that.  However, if we make this state more of a performance option and not an in-universe feature, we can make the exception that any open port targeted by the active vessel becomes armed.

[vger]

On 6/10/2016 at 11:42 AM, Tw1 said:

Woah. That's so inefficient. 

Is there no way it could just check within a certain distance for docking ports? Like maybe having a separate list for docking ports? And/or a simple off switch for a port's "Magnetism"?

Ah... that explains a problem I ran into when ARM first went live. I launched an asteroid 'collector' into orbit. It was nothing but framework, a bunch of claws jutting out in different directions a safe distance from one another, and minimal power/RCS. The idea was that I wanted captured asteroids to all be in one place where they wouldn't slowly drift apart, so I was going to dock them all to this 'station.' I think I had a total of 12 claws on it, and the thing lagged like CRAZY. We're talking a drop from 30 to 1-2 FPS. I tried launching it without the claws and it was fine. So I started adding claws back in one at a time. Even just having two claws caused a noticeable performance hit. This seems horrid for anyone who likes modular assemblies, and that obviously is THE logical way to build a space station, 'mothership,' or base.

There's gotta be an easy way to fix this.

#1. Add a 'power toggle switch' to docking ports. If they're not turned on, they're not looking for something to dock with, and the game just treats them as decorative parts. IMO it shouldn't be possible to "accidentally" dock a craft anyhow.

#2. When the ports are connected, they should stop registering as ports, just in case the game is still wasting resources on them. The connection should be treated as a solid (only taking into account physics stress).

Edited June 12, 2016 by vger

[Padishar]

11 minutes ago, vger said:

Ah... that explains a problem I ran into...

Well, not really, though it is related.  Claws are not docking ports, they use ModuleGrappleNode instead of ModuleDockingNode and they work in a very different way.  Each claw doesn't scan all the parts in the physics bubble though it does do a raycast to detect if they've hit something and this can also be quite slow (especially when there are a lot of parts around).  I believe there was also a specific multi-claw issue in earlier versions that was "fixed" quite a while back.

14 minutes ago, vger said:

There's gotta be an easy way to fix this.

Yes, there is.  As was mentioned earlier in the thread, the best way to fix docking ports would be for the game to maintain a separate list of all the ModuleDockingNode part modules that are currently loaded.  This would hugely reduce the CPU needed.  There isn't a similar way to fix claws as they don't do a scan (well, they do but it's inside the Unity raycast code).

19 minutes ago, vger said:

#1. Add a 'power toggle switch' to docking ports.

While this would be a nice feature to have anyway, it wouldn't do anything to improve the scans done by the ports that are active.

25 minutes ago, vger said:

#2. When the ports are connected, they should stop registering as ports

They already do.  It's only ports that are in the "Ready" state that do the scan.

[Superfluous J]

1 hour ago, Archgeek said:

if we make this state more of a performance option and not an in-universe feature, we can make the exception that any open port targeted by the active vessel becomes armed.

Actually you could go one further and say the only 2 docking ports that are ever enabled are the "control from here" port on your ship and the target on the other ship.

Of course that would screw up multidocking... Which I don't use so I have no real ideas on how to preserve it.

EDIT: Maybe the "control from" port is the only one, and it checks all other ports? If it finds one in range, on your ship or not, it docks to it if able.

Edited June 12, 2016 by 5thHorseman

[Padishar]

1 minute ago, 5thHorseman said:

Actually you could go one further and say the only 2 docking ports that are ever enabled are the "control from here" port on your ship and the target on the other ship.

Of course that would screw up multidocking... Which I don't use so I have no real ideas on how to preserve it.

If the game maintained a list of ports then further optimisations wouldn't be nearly as necessary (though I would like to be able to disable ports).  It's the nested loops of partmodules within parts within vessels that really hurt and these would completely disappear.  Only if you had an extreme number of active ports would there still be any issue...

[max_creative]

Most people's space stations aren't bad. Most stations I've seen are either really small so they don't lag bad, or they have an asteroid or something but you just refuel and don't stay long. 

On the other hand, my stations lag. Bad. But that's what I get when I have four 150 part cruisers docked all at once. That's my fault. 

Over all, stations are either A. So tiny that adding a little stuff doesn't matter. B. So laggy they just aren't really worth it. 

Also, some advice, Don't dock cruisers (or and really big thing) without RCS! that's how most of my stations get destroyed. 

[pandaman]

4 hours ago, evileye.x said:

Someone needs to modify docking ports so the could have 'armed' and 'unarmed'  states, like shielded ones. Or even suggest it to SQUAD? 

Only just read this. 

Earlier today I posted a suggestion to give ports a 'ready' light so we can see easily if they are 'ready to receive'.  Not quite what you requested,  but on similar lines. 

[Shadowmage]

22 hours ago, evileye.x said:

Someone needs to modify docking ports so the could have 'armed' and 'unarmed'  states, like shielded ones. Or even suggest it to SQUAD? 

 

18 hours ago, pandaman said:

Only just read this. 

Earlier today I posted a suggestion to give ports a 'ready' light so we can see easily if they are 'ready to receive'.  Not quite what you requested,  but on similar lines. 

This actually wouldn't be too hard to accomplish I believe.  Create a dummy .mu model that contains a single animated empty transform.  Add that model to the stock docking ports as a second model through MODEL nodes (its just an empty transform, so nothing to render).  Reference the animation from that empty model in the docking port module / stock ModuleAnimateGeneric.  Profit?!?

For someone with a lot of time they could actually create animated models for status lights for each of the stock ports and add those through MODEL nodes, with the animation switching the state of the lights or something.

[fourfa]

edit - missed the answer to my question when I first read through the thread

Edited June 13, 2016 by fourfa

[Padishar]

44 minutes ago, fourfa said:

If a regular docking port is inside a closed cargo bay, does it still count as 'armed' and contribute to lag?

Perhaps try reading the thread, it's only two pages...

[JoeNapalm]

 

Well, that's not TOO terrible for me. Most of my ships use shielded ports...I guess I'll be swapping to those for future stations, as well.

I generally have something attached to the large ports on the stations that are used to make them modular. I can add copulas or something to the rest.

 

-Jn-

[Archgeek]

Interesting solutions proffered here, but I'd say @Padishar's is best.  In fact, I'd go slightly further -- keep an active port list for each craft, and on a physics frame concatenate those lists and set a tristate flag on each to -1 or some other value signifying "unchecked".  Have the first port set itself false, then scan the whole list for positions and calculate ranges as per usual, setting its flag and that of the first port close enough to true if it finds one, else leaving its own flag false.  Then the next port scans the list, skipping the distance calculation for the first, and so on, each skipping any port not unchecked, including itself.

This way, for n active ports we only do the distance calculation for Gaussian sum of n, rather than n^2.  Such that if there are 20 active ports in the scene, we do the distance calculation 210 times instead of 400, less if the magnetism needs to kick in, and if there are 100 ports open on some monstrosity, 550 instead of 1k.

Of course, that little optimisation is dwarfed by the savings of using a port list in the first place -- 100 ports scanning every part in the scene is a lot nastier than 100 ports scanning each other.