Does just WANTING a space station make lag?

[Fireheart318]

So during the second module launch (primary generator, if you're curious), my game became incredibly laggy. It doesn't make any sense. I've even deleted some mods and the problem persisted. I am baffled by what's going on here and none of my mod developing experience is helping!

[Vanamonde]

I assembled a station and Duna mission by docking multiple launches in recent weeks, and had no trouble until my part count got over 200. After that, lag slowly became worse as I added parts, but still much better than previous versions. 

[Fireheart318]

2 minutes ago, Vanamonde said:

I assembled a station and Duna mission by docking multiple launches in recent weeks, and had no trouble until my part count got over 200. After that, lag slowly became worse as I added parts, but still much better than previous versions. 

I've driven rovers with about 200 parts and lagged about as much as this! I have a pretty good starter computer but in total, I probably had around 50 parts in the entire save file once I reached orbit! That's actually a high estimate!

[Tw1]

Yes. They can sense it. 

 

How much lag though? A slight stutter or are you reaching seconds per frame territory?

Also is there debris in the save you could clear out? If it's just an un-precedented amount of parts, perhaps you've just found your computer's limits for this KSP version? 

[Nathair]

Getting to the point in the game where you're thinking about stations suggests that you've done a bunch of preliminary stuff. How many missions do you have ongoing? How many flags, how many satellites, how much (as Tw1 mentioned) debris in orbit or scattered around various moons and planets?

[marcello639]

At what part of launch it started to lag? I have noticed that atmospheric effects create huge lag on high settings.

[Superfluous J]

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.

[pandaman]

45 minutes ago, 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.

Hmm.    If that turns out to be the case I may have to rethink my modular station concept. 

I had noticed on previous versions that some parts seemed to cause more lag than others, the ion engine seemed to be the main culprit, but also that was on my old machine so I put it down to that at the time.

[Jimbodiah]

There is probably a part from one of your mods that is causing a lot of log hits, check to see your debug log (in-game under alt-f12) what is happening.

[Padishar]

20 minutes ago, pandaman said:

Hmm.    If that turns out to be the case I may have to rethink my modular station concept.

No "if" about it, on every physics update every non-acquired docking port searches all the parts within the physics bubble for docking ports until it finds one that is within the activation range.  So the performance impact is at least proportional to the number of docking ports multiplied by the total number of parts in the loaded vessels.  For example, the station in my avatar is 1410 parts of which, 120 are docked ports holding it all together, and 24 are vacant senior ports.  Nearly 9% of the total CPU time is spent in ModuleDockingNode.FixedUpdate (and another 22+% shuffling EC around the Vessel from the 360 solar panels and 42 probe cores).  Eliminating (or greatly reducing) these two parts could increase the framerate by nearly 50%...

20 minutes ago, pandaman said:

I had noticed on previous versions that some parts seemed to cause more lag than others, the ion engine seemed to be the main culprit, but also that was on my old machine so I put it down to that at the time.

The ion engine (when firing) uses a fuel flow mode that involves searching through the whole vessel for fuel tanks both when calculating how much fuel is available (for the fuel gauges) and for actually transferring the fuel.  This uses considerable CPU time and also generates a considerable amount of garbage.

 

Edited June 10, 2016 by Padishar

[JoeNapalm]

 

Docking ports generate lag?

But...but...I love my modular refueling stations with port spam!

I almost never build anything without at least one docking port. I mean, map sats are about it -- everything else can be docked. MUST BE DOCKED!

-Jn-

[Archgeek]

35 minutes ago, Padishar said:

[bunch of useful information]

...

The ion engine (when firing) uses a fuel flow mode that involves searching through the whole vessel for fuel tanks both when calculating how much fuel is available (for the fuel gauges) and for actually transferring the fuel.  This uses considerable CPU time and also generates a considerable amount of garbage.

It's also heck to programatically figure out delta-v for in a staged droptank configuration, isn't it? 

[N_Molson]

Quote

I almost never build anything without at least one docking port. I mean, map sats are about it -- everything else can be docked. MUST BE DOCKED!

Alternatively, there is... the Klaw ! Well, it doesn't allow resources transfer, that's a point. That being said, there must be a hundred of mods around allowing it.

Edited June 10, 2016 by N_Molson

[Tw1]

1 hour ago, Padishar said:

No "if" about it, on every physics update every non-acquired docking port searches all the parts within the physics bubble for docking ports until it finds one that is within the activation range.   

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"?

[Padishar]

16 minutes ago, Tw1 said:

Woah. That's so inefficient.

Well, yes.

16 minutes ago, Tw1 said:

Is there no way it could just check within a certain distance for docking ports?

That's exactly what it is doing, but it looks at all the parts to find docking ports and checks those for distance.

16 minutes ago, Tw1 said:

Like maybe having a separate list for docking ports?

This would be the really important bit.  Having the code maintain a list of all the docking ports within the physics bubble would make the code very much quicker.

16 minutes ago, Tw1 said:

And/or a simple off switch for a port's "Magnetism"?

I assume you mean a way for the player to disable vacant docking ports and then they would only enable the ones they actually want to dock.  Yes, this could be done, and it would make quite a difference when there are a large number of ports,  However, it would still need the list of ports to optimise the scan for the ports you do enable.  The code that checks if a particular port is within range and in a good enough alignment to trigger the magnets is pretty decent, the real killer is having to search the partmodule list of every part of every vessel in physics range just to find the docking ports which would still need to be done to test the "active" flag...

 

Edited June 10, 2016 by Padishar
Inaccurate after re-reading

[Archgeek]

26 minutes ago, Padishar said:

No "if" about it, on every physics update every non-acquired docking port searches all the parts within the physics bubble for docking ports until it finds one that is within the activation range.   

...stupid question -- does the shielded docking port, or ports like it like the mk1 and 2 inline ports, do this search when closed?  What about open ports in closed service modules, cargo bays, or fairings?  If not, this'll change my designs a bit.  I'm thinking shielded ports on construction tugs,  no more jr.s on tugs meant to work with high-part-count ships, and shielded and inline ports as far as they eye can see.

[suicidejunkie]

With KAS, you could also re-cap the regular docking ports until they are needed.

[Padishar]

12 minutes ago, Archgeek said:

...stupid question -- does the shielded docking port, or ports like it like the mk1 and 2 inline ports, do this search when closed?  What about open ports in closed service modules, cargo bays, or fairings?  If not, this'll change my designs a bit.  I'm thinking shielded ports on construction tugs,  no more jr.s on tugs meant to work with high-part-count ships, and shielded and inline ports as far as they eye can see.

I believe that closed shielded ports are in a different state (Disabled rather than Ready) and therefore don't do the search but I don't think them being inside bays, fairings or service modules will affect it.  Basically, any docking port in the Ready state (should be visible in the save file) will do the scan.

[GarrisonChisholm]

3 hours ago, Padishar said:

No "if" about it, on every physics update every non-acquired docking port searches all the parts within the physics bubble for docking ports until it finds one that is within the activation range.  So the performance impact is at least proportional to the number of docking ports multiplied by the total number of parts in the loaded vessels.  For example, the station in my avatar is 1410 parts of which, 120 are docked ports holding it all together, and 24 are vacant senior ports.  Nearly 9% of the total CPU time is spent in ModuleDockingNode.FixedUpdate (and another 22+% shuffling EC around the Vessel from the 360 solar panels and 42 probe cores).  Eliminating (or greatly reducing) these two parts could increase the framerate by nearly 50%...

The ion engine (when firing) uses a fuel flow mode that involves searching through the whole vessel for fuel tanks both when calculating how much fuel is available (for the fuel gauges) and for actually transferring the fuel.  This uses considerable CPU time and also generates a considerable amount of garbage.

 

This is *incredibly* useful information, thank you!  It also explains the greater lag for the deathcraft (I'm sorry, they kill much more surely than fly, so I can't call them aircraft).

[Archgeek]

34 minutes ago, Padishar said:

I believe that closed shielded ports are in a different state (Disabled rather than Ready) and therefore don't do the search but I don't think them being inside bays, fairings or service modules will affect it.  Basically, any docking port in the Ready state (should be visible in the save file) will do the scan.

Hmmm, sounds like I should set up and launch a test rig, then grep the .sfs to find out.  Or would that be in the .craft?  ...I'm likely to be back with results sometime after work.

[Padishar]

8 hours ago, Archgeek said:

Hmmm, sounds like I should set up and launch a test rig, then grep the .sfs to find out.  Or would that be in the .craft?  ...I'm likely to be back with results sometime after work.

Yes, a new save with a single test vessel would be best.  Launch it, quicksave, search the .sfs for ModuleDockingNode and look a couple of lines down for the "state = " line.

[vger]

14 hours ago, Nathair said:

Getting to the point in the game where you're thinking about stations suggests that you've done a bunch of preliminary stuff. How many missions do you have ongoing? How many flags, how many satellites, how much (as Tw1 mentioned) debris in orbit or scattered around various moons and planets?

The game doesn't do complex calculations with craft you're not focused on, does it? Resource usage should be minimal with all except what you're focused on.

[Archgeek]

4 hours ago, Padishar said:

Yes, a new save with a single test vessel would be best.  Launch it, quicksave, search the .sfs for ModuleDockingNode and look a couple of lines down for the "state = " line.

I made a test rig that went shielded port => small service bay with a .jr in it => mk1 inline port => adapter => mk2 cargo bay with a .jr in it => mk2 inline port => adapter => 2.5m service bay with normal docking port in it => adapter => mk3 cargo bay with sr. in it => mk3 mono tank as a bulkhead => mk3 cargo ramp with sr. in it.

Getting the data from the .sfs and figuring out which things were which by cross-referencing the .craft file, I wound up with this:

dockingPortLateral (mk1 inline): Disabled
dockingPort1 (shielded): Disabled
dockingPort3(jr in small service bay): Ready
mk2DockingPort:Disabled
dockingPortLarge(sr in cargo ramp): Ready
dockingPortLarge(sr in mk3 cargo bay): Ready
dockingPort2: (size 1 in 2.5m service bay)Ready
dockingPort3(jr in mk2 cargo bay): Ready
 

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.

[Tw1]

21 hours ago, Padishar said:

Well, yes.

That's exactly what it is doing, but it looks at all the parts to find docking ports and checks those for distance.

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. 

[pandaman]

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?