[1.12.x] - Modular Kolonization System (MKS)

[goldenpsp]

1 hour ago, Jebs_SY said:

@RoverDude

Hello.   I am playing a highly modded install and the performance is always on the edge. I just figured out, that a huge amount of USI drills (automated industrial stripminers) have a big performance impact.
For a fast LH2 production I build a 300 part vehicle, with around 150 of these drills. Loading this vehicle into the SPH takes 3,5 minutes (on a Core i5-4570 with 24GB RAM) and onto the rundway 5,5 minutes.
Removing the drills, save it, reload it into the SPH takes 3 seconds and onto the runway takes 50 seconds.
I put MKS 52.2 on a KSP 1.3 vanilla and loading a vehicle with 120 of these drills also take 2 minutes.
While the game loads, the logs show "[LOG 20:36:08.734] Found 15 overheatable modules" again and again, like 1 or 2 times per attached drill.
On "Vanilla+MKS" this happens 3 times per second, on my highly modded install it can achieve 0.5-1 per second.
Deleting (for a test) USITools.dll from the highly modded installation, I can load the 300 part vehicle in 25 seconds into the SPH and in 55 seconds onto the runway.

I have the feeling, that for each drill the game iterates over the hole ship/assembly. Or it evaluates the ship (or something) one time per drill. On "vanilla+MKS" this is faster than on my "highly modded". At least that would make sense.

What I wanted to ask, if you have an idea what happens here / where it iterates/evaluates that often and if this is maybe a bug or if this is a needed evaluation?

BR
Jebs

While it sounds legit concerning your troubleshooting I'm banking on some eye rolling about the need for 150 drills...

[Jebs_SY]

23 minutes ago, goldenpsp said:

While it sounds legit concerning your troubleshooting I'm banking on some eye rolling about the need for 150 drills...

Gain 32.000.000 units of LH2 in 15 days until the launch window opens?

[RoverDude]

Well you're probably using the wrong drill... but that aside, if you are saying it's fast with UKS+stock, and slows down when you add mods... you probably have a conflict.  Ampyear is a known one.  Start with that if you use it.  Otherwise, re-add mods till you see the performance take a dump and let us know.

Another known issue was Kopernicus loaded on an install with legacy game settings...  if you use any planet packs, delete your stock settings.cfg and redo them.

[Jebs_SY]

Hello @RoverDude
thx for the answer. I can definitly approve that with AmpYear, but I don't use AmpYear or Kopernicus.
Also, if it cannot be optimized, then it cannot be optimized. I just want to bring the information over, that you maybe can spent some thoughts over it.

Talking from "Vanilla+MKS" (manual installed) from now on. For each (USI) drill on a vehicle USI calculates something.
For example adding 128 drills, when loading the vehicle into the VAB or onto the launchpad you get 128x "Found 12 overheatable modules" in the log files. Which means it seems to do some sort of computational task (which also creates the log entries) 128 times.
So loading this test vehicle with 128 drills takes 45 seconds into the VAB and 60 seconds onto the launchpad. So a test+revert cycle is already 2,5 minutes with "Vanilla+MKS".

(This vehicle has a tank with 8 drills added in 8x symmetry around a center tank)

When having more mods installed (than just vannilla+mks) the time per iteration becomes bigger, cause more stuff must be calculated (I assume). By comparing the timestamps from the log, I can say that for the test vehicle it can do 3 cycles per seconds. My highly modded install can only achieve 0.5-1 cycle per seconds, so the loading times extend by 3-6x. This is clear. But the loading time would be like 128 times faster, if it would work with 1 iteration, than needing 128.

So I didn't wanted to ask, why the iteration times with modded are slower (this is clear to me), but if we really need the 128 iterations? And this is a USI thing.

As I said, if it's not optimizable, it's OK, it's a edge case that one maybe not need often, but I thought it shows that there could be maybe potential for optimization if the iterations per drill could be saved. 

BR
Jebs

 

Edited September 24, 2017 by Jebs_SY

[RoverDude]

It is not a USI thing... it is a stock thing.  And stock is already heavily optimized.  But 128 drills on a craft is just... a bit much. 

[Jebs_SY]

@RoverDude

Thx for explaining. Now I got it. The evaluation/iteration is stock. I made some more tests. The amount of the log messages is the amount of the drills.
But it seems to evaluate this for each ressource converter module placed in a drill. And the MKS one has 12 modules. The stock one (with MKS installed) only has 2 modules.
So 12 modules times 128 drills ends up with much computation/evaluation and this is done by stock KSP.
So in the end the only performance gain is to make the iteration itself faster, by removing mods, as you already said. Cause the amount of iteration is defined by the system (stock KSP).

BR
Jebs

[RoverDude]

Note that that eval only takes place once, and is a necessary one to cache the info.  As I said before... 128 drills is a bit... extreme.

[fatcargo]

Will there ever be a habitation module that can reset homesickness timeout ? I've looked at docs and and haven't found anything.  Also, planets like Laythe that have breathable atmosphere should not cause Kerbals to get homesick. MKS offers so much for good base design and then falls short of actually using all of its potential for making independant permanent bases. Also, this issue is even more exaggerated if using addons with larger or multiple star systems, where time spent in transit alone can exceed homesickness limit - another mod for warp drive could let player shorten the mission time but even that won't delay the inevitable.

[Aelfhe1m]

21 minutes ago, fatcargo said:

Will there ever be a habitation module that can reset homesickness timeout ? I've looked at docs and and haven't found anything.  Also, planets like Laythe that have breathable atmosphere should not cause Kerbals to get homesick. MKS offers so much for good base design and then falls short of actually using all of its potential for making independant permanent bases. Also, this issue is even more exaggerated if using addons with larger or multiple star systems, where time spent in transit alone can exceed homesickness limit - another mod for warp drive could let player shorten the mission time but even that won't delay the inevitable.

https://github.com/UmbraSpaceIndustries/MKS/wiki/Functions-(Med-Bay-and-Colony-Supplies)

[fatcargo]

Duhh .. RTFM ... I really need to look more carefully, thanks and my apologies !

[Wyzard]

50 minutes ago, fatcargo said:

Also, planets like Laythe that have breathable atmosphere should not cause Kerbals to get homesick.

Even if you can walk outside without a spacesuit, your family and friends and entire culture are a million miles away, and it'll be months or years before you'll see them again.  Fresh air doesn't alleviate that.

[fatcargo]

5 minutes ago, Wyzard said:

Even if you can walk outside without a spacesuit, your family and friends and entire culture are a million miles away, and it'll be months or years before you'll see them again.  Fresh air doesn't alleviate that.

Ok i agree on that, though player can choose to pretend they're all one big happy family on a slightly longer road-trip. Though i couldn't imagine myself listening to anyone singing "99 bottles of beer on the wall" for several months, nevermind a year

Edited September 26, 2017 by fatcargo
sausage fingers

[Loren Pechtel]

2 hours ago, Wyzard said:

Even if you can walk outside without a spacesuit, your family and friends and entire culture are a million miles away, and it'll be months or years before you'll see them again.  Fresh air doesn't alleviate that.

A thought here--the number of Kerbals in the base should grant a home bonus.  At least some of your friends are going to be your fellow inhabitants of the base.  I also wonder if the home timer should even apply to Kerbals born on a base.  That's home to them!

Edited September 26, 2017 by Loren Pechtel

[voicey99]

3 hours ago, Loren Pechtel said:

A thought here--the number of Kerbals in the base should grant a home bonus.  At least some of your friends are going to be your fellow inhabitants of the base.  I also wonder if the home timer should even apply to Kerbals born on a base.  That's home to them!

That is implemented, of sorts. If your kolonisation rating >500%, all kerbals with 1yr of habitation time will gain permanent residence. It's also worth noting you can do this without that rating, but permanent hab requires 50yrs of time (1yr if pilot/scout).

[Mrtinb96]

Hey, 

is there a RO patch witch is working in 1.2.2?

[goldenpsp]

2 hours ago, Mrtinb96 said:

Hey, 

is there a RO patch witch is working in 1.2.2?

If there was, it would probably be on the RO side.

[voicey99]

6 hours ago, Mrtinb96 said:

Hey, 

is there a RO patch witch is working in 1.2.2?

There isn't one universal RO patch, but there are patches for several of its component mods. CLS, DRE, RT, TAC-LS and KIS/KAS are all supported and AFAIK no other mods in RO require patches.

[Requia]

Are the inflatable habs/greenhouses (or probably anything else than needs materialkits?) supposed to gain mass after inflation? It seems like a strange design decision since it makes them useless for spacecraft.

[damerell]

1 hour ago, Requia said:

Are the inflatable habs/greenhouses (or probably anything else than needs materialkits?) supposed to gain mass after inflation? It seems like a strange design decision since it makes them useless for spacecraft.

I hope the operation is mass-neutral, since the material kits are consumed.

[Requia]

3 minutes ago, damerell said:

I hope the operation is mass-neutral, since the material kits are consumed.

It is. But the material kits mass many times what the parts used to mass.

Edited September 27, 2017 by Requia

[maja]

35 minutes ago, Requia said:

It is. But the material kits mass many times what the parts used to mass.

It's because you are "fitting interior" of these modules when they're inflating. Material kits represent everything that is needed to fully operate them.

Edited September 27, 2017 by maja

[voicey99]

3 hours ago, Requia said:

It is. But the material kits mass many times what the parts used to mass.

It is entirely mass-neutral. For example, the habring gains 46t (from 5t to 51t) of dry mass when inflated, while at the same time consuming 46,000 materialkits. Each unit of materialkits weighs 1kg, so it consumes 46t of MKTs to add presumably 46t worth of fittings, furniture, structure etc. to the ring.

[RoverDude]

4 hours ago, Requia said:

Are the inflatable habs/greenhouses (or probably anything else than needs materialkits?) supposed to gain mass after inflation? It seems like a strange design decision since it makes them useless for spacecraft.

Yes they are, and it makes perfect sense since it lets you launch and land a much lighter vessel, then kit it out later, either through locally produced resources, scrapping, or shipping stuff in.

3 hours ago, Requia said:

It is. But the material kits mass many times what the parts used to mass.

By design, as noted.  And you can always launch kitted out, but you're going to land in exactly the same place.  And an expandable part vs. a balanced part that does not have the expansion functionality (i.e. Tundra/Duna modules vs. Ranger modules or the big hab ring) will end up with exactly the same amount of required mass to be operational.

[voicey99]

19 minutes ago, RoverDude said:

By design, as noted.  And you can always launch kitted out, but you're going to land in exactly the same place.  And an expandable part vs. a balanced part that does not have the expansion functionality (i.e. Tundra/Duna modules vs. Ranger modules or the big hab ring) will end up with exactly the same amount of required mass to be operational.

It's worth noting that only expandable habitation modules require machinery to run, which means you need to lug that along with you as well.

[RoverDude]

True, though that will likely change (though it is worth noting that the machinery is worked into the mass for balance purposes)