Jump to content

Lag-free planetary bases


Darinth

Recommended Posts

So, in my case I'm using the USI suite including life support for most of my resource intensive operations, and I'm trying to gain a better understanding of what causes the atrocious lag and what the most effective methods are for having functional, relatively lag-free bases in KSP.

From what I can tell reading through the forums, and this is supported to-date by my circumstantial evidence in that I can build a 500 part craft with minimal lag, but a 100 part craft doing dozens of conversions brings the engine to it's proverbial knees, is that the resource system in KSP has a lot of issues. And when I say resource system, I'm not referring to memory allocations or anything along those lines, I'm referring to vessel resources (ore, metallic ore, substrate, etc...). So... what are people doing to reduce lag and make their bases functional? Right now, I've got 3 bases on the mun. 2 are automated mining bases and are completely lag-free. My 3rd base is too monolithic, and I know that's a large part of the problem. It handles all of the conversions from base mineable resources all the way up to finished products (material kits, specialized parts, machinery, supplies, colony supplies). The lag is at the point where I can still deal with it, but becomes frustrating over longer periods of time.

So.. the question is... what are the best ways of handling these issues?

I know I need to separate out many of the components of my monolithic base. I'm just curious if anybody has more knowledge about what needs separated and what will result in the performance increases. As an example, I was reading through a post that mentioned part of the problem is that a lot of the resource requests in KSP run in O(n^2) (or possibly worse). If this is the case, it might be a significant benefit to literally just take and have 10 bases that are relatively small in the same area because they're not hurt by that O(n^2) algorithm by keeping their part counts low. But I don't know if there are other issues that might make large numbers of individual bases in the same area problematic.

Also, there are issues (due to using USI:LS) involving needing to put life support parts on all of these crafts (or at least on one craft within 150 meters of a cluster of others, as crafts within that range share at least some life support structures though I'm still not sure if they share colonization modules). This means that in order to fix a lag-problem within a game, I've actually gotta be less efficient than otherwise makes logical sense which is frustrating and so I'll admit I'm trying to balance my frustration over trying to handle lag vs. the frustrating which is going to be caused by adding otherwise unneeded life support systems.

What are other solution to this problem? Am I even on the right track or is there a simple obvious solution that I'm just not seeing to handling the life support requirements while simultaneously managing all of these requirements? If possible, I want explanations as to why things work rather than just 'Do it this way, because reasons'. Feel free to be as technical as needed in the explanation. I'm an extremely competent coder and have worked with game engines a fair bit. I fully understand concepts like big O notation, and am capable of learning nearly any algorithm that I might need.

Link to comment
Share on other sites

On 5/14/2018 at 7:59 AM, Darinth said:

As an example, I was reading through a post that mentioned part of the problem is that a lot of the resource requests in KSP run in O(n^2) (or possibly worse).

Still true in the current KSP versions as far as I know.  Perhaps it is only O(n) or O(n*2)(linear), but it is certainly not anything approaching the O(1) (constant) that it should be.

On 5/14/2018 at 7:59 AM, Darinth said:

If this is the case, it might be a significant benefit to literally just take and have 10 bases that are relatively small in the same area because they're not hurt by that O(n^2) algorithm by keeping their part counts low.

Yes.  This will not only improve the resource calculations, but will -also- help with the physics calculations.  Each separate vessel can process most of its physics in its own thread (e.g multithreading); but a single monolithic base will be mostly limited to a single thread for physics processing (e.g. single threaded).

 

The above mostly applies to stock though.  As soon as you start using USI and its 'local logistics' or whatever its called, you are going to lose much of the benefit of having your base split up.  USI has part-modules that actually look at all of the nearby parts/vessels and also manipulate -their- resources (so O(n^x^2).....).  I haven't done any profiling on it specifically, but I would bet it is 'not good' for performance (at least compared to not doing said calculations).

 

On 5/14/2018 at 7:59 AM, Darinth said:

This means that in order to fix a lag-problem within a game, I've actually gotta be less efficient than otherwise makes logical sense which is frustrating and so I'll admit I'm trying to balance my frustration over trying to handle lag vs. the frustrating which is going to be caused by adding otherwise unneeded life support systems. 

Indeed -- this is one of the major problems I've had with the USI suite of mods, and what has been driving me away from it recently.  The part-count required in order to make a fully functional (self-sustaining) base... results in a base that is un-playably laggy.  Love the meta-game and planning needed... hate the lag.

 

 

In the end -- modders are using the stock resource system in a way that it was never designed to accommodate -- too many resources, too many converters, and too many active parts required on the vessels.  Heck... last I checked you could entirely lag out the game just by using 20-30 stock fuel cells.

Link to comment
Share on other sites

15 hours ago, Shadowmage said:

The above mostly applies to stock though.  As soon as you start using USI and its 'local logistics' or whatever its called, you are going to lose much of the benefit of having your base split up.  USI has part-modules that actually look at all of the nearby parts/vessels and also manipulate -their- resources (so O(n^x^2).....).  I haven't done any profiling on it specifically, but I would bet it is 'not good' for performance (at least compared to not doing said calculations).

This probably isn't as big of a performance issue as you'd expect. Local logistics only kicks in and looks for nearby resources if it runs low on resources. So it should only be doing checks of other nearby vessels on pretty rare occasion.

15 hours ago, Shadowmage said:

Indeed -- this is one of the major problems I've had with the USI suite of mods, and what has been driving me away from it recently.  The part-count required in order to make a fully functional (self-sustaining) base... results in a base that is un-playably laggy.  Love the meta-game and planning needed... hate the lag.

I'm in the same boat. I'm hard pressed to believe it's not resolveable, but there's no good solid information on how to build out bases so you don't end up with horrendous lag.

I'm probably going to sit down in sandbox and drop a whole bunch of smaller, individual converter parts to see if I can get to the same setup as what I have in my career save with less lag. I'll report back what I find once I'm done.

15 hours ago, Shadowmage said:

In the end -- modders are using the stock resource system in a way that it was never designed to accommodate -- too many resources, too many converters, and too many active parts required on the vessels.  Heck... last I checked you could entirely lag out the game just by using 20-30 stock fuel cells.

That actually makes sense. Each fuel cell has storage for electricity and manipulates 3 different resources while it runs. If that's 20 fuel cells. Each one is looking at the electricity stored in all 20 fuel cells (400 checks) plus both the LF and O in each of your storage tanks. That means another 40 checks every physics tick per LFO source. At 30 fuel cells that's 900 checks + 60 per LFO source. Every physics tick. I feel like the resource system needs an overhaul to, unfortunately, be less granular or have some optimization so the individual parts don't have to be checked with as much frequency which is absolutely possible, but it is a good chunk of work to write the code to figure out when checks to individual containers are and aren't needed.

Edited by Darinth
Link to comment
Share on other sites

10 hours ago, Darinth said:

This probably isn't as big of a performance issue as you'd expect. Local logistics only kicks in and looks for nearby resources if it runs low on resources. So it should only be doing checks of other nearby vessels on pretty rare occasion.

Excellent point.  RoverDude has generally done an excellent job on optimizing his logistics code and taking performance into account during design of the gameplay systems.

There should be, in theory, a very real benefit to using a small number (2-4) of moderate part-count vessels in a local area compared to a single monolithic vessel.

10 hours ago, Darinth said:

I feel like the resource system needs an overhaul to, unfortunately, be less granular or have some optimization so the individual parts don't have to be checked with as much frequency which is absolutely possible, but it is a good chunk of work to write the code to figure out when checks to individual containers are and aren't needed. 

It is actually quite a bit better now than it was in some recent previous versions; it was definitely overhauled in one of the post 1.0 releases to remove several inefficiencies and reduce GC load.  At this point there probably isn't too much more that can be done considering the limitations in place from the part-tree based structure and how resources interact with physics via part masses and thermal properties.

 

Curious to see what kind of data your experiments come up with :)

Link to comment
Share on other sites

It's worth also thinking about with MKS that you can do widely separated bases - PL allows you to separate out your bases so that they aren't even all within the same local area.

(I once did a five-base diamond layout to take advantage of both - a single medium base at each corner, and a small logistics center in the middle - with each small base outside of the local logistics of each other, but within local logistics of the center.  Worked fairly well, though lag went high when you went to the center base.)

Link to comment
Share on other sites

So... 40 fuel cells was not enough to lag out my game (with all of them running to keep up with the power demands of me running ridiculous reaction wheels), but I also wasn't able to lag it out by creating a facsimile of my base in the VAB and launching it and turning on all of the machinery. I've been thinking for a couple of days on what could be going on, because I really expected that second test to produce the expected lag and when it didn't was really confused. My facsimile wasn't perfect, and so I may have to painstakingly recreate in the VAB the craft that has been slowly put together in-situ on the mun with KIS. I'm also going to create a larger craft and try to get a count on just how many fuel cells would be needed to start seeing lag. I also realized I didn't actually turn on planetary logistics, and I'm now wondering if that might be what makes the difference. Maybe planetary logistics is actually a much larger issue with base lag.

Will post something back here again when I have some more information. This is, so far, actually really confusing. :(

Link to comment
Share on other sites

  • 3 weeks later...

Wanted to drop by here and state a strong opinion that the lag is not caused by base game resource conversions, at least not alone, nor does it appear to be caused by MKS conversions. I've now created crafts with 288 fuel cells and ran them both in a fresh sandbox and my current 1.4 career. In both of these instances, the lag is measurable but not anywhere near what I see in my Munar base. Both saves lag when the fuel cells are turned on/off. When I load up the craft in sandbox, I run at 58 fps and that drops to about 38 fps when the fuel cells are running to charge up the empty batteries the craft starts with. In my career save, the craft loads up at about 45 fps and drops to about 28 when I turn the cells on. In both of these circumstances, the clock stays green which I believe is an indication of the rate fixedupdates which process the physics are being called. Distinct amounts of lag... but that's with a remarkable 288 fuel cells all running.

My Munar base on the other hand, runs at 20-22 fps and (at best) a frame or two increase when I disable all of the conversions I can find. The clock stays permanently yellow when I'm over there. Still haven't actually recreated a precise reproduction of my Munar base on the launch pad. I guess that'll be the next step. Do that and then begin tweaking different things until I see a substantial gain in fps or fixedupdate rate.

Link to comment
Share on other sites

In my experience, MKS and USI-LS just slow things down, especially when you're in physics range. The only advice I can give is to use fewer larger converters and tanks, especially if you're using reactors or anything else which generates heat. And if you're in a career save, be ruthless in limiting the number of craft that the game has to track. I've actually had saves where I never upgraded the tracking center past level 2 just so the asteroids would never spawn.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...