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

[DStaal]

1 hour ago, GraczNet said:

I have one more question. So when ExtraplanetaryLaunchpads requires MaterialKits and SpecializedParts then recyclers from that mod are useless right?

EDIT: Nevermind, figured it out myself.

No, actually - the recyclers from EL should produce MK and SP if that's the recipe, IIRC.

[GraczNet]

1 minute ago, DStaal said:

No, actually - the recyclers from EL should produce MK and SP if that's the recipe, IIRC.

In-game it seems like recycler makes scrap metal, and then smelter turns it into metal.

Edited April 19, 2019 by GraczNet

[DStaal]

17 minutes ago, GraczNet said:

In-game it seems like recycler makes scrap metal, and then smelter turns it into metal.

Ah yes, that makes sense.  I see the config for that now as well - if you can think of a better MKS-specific recycle path, I could probably write a recipe file for you.

[GraczNet]

17 minutes ago, DStaal said:

Ah yes, that makes sense.  I see the config for that now as well - if you can think of a better MKS-specific recycle path, I could probably write a recipe file for you.

No I don't want to waste your time, but thank you for that!

[mrstoned]

2 hours ago, panarchist said:

Plugging Pathfinder in the MKS thread (or vice-versa) is kind of like plugging Pepsi in a Coca-Cola ad. ;-)

Regarding comments further up, if I ever learn how to do IVAs, I would totally try to make some for MKS - just because I love IVAs.

And since I am in here being semi-snarky anyway, I'd like to say in all seriousness, thanks, RoverDude for continuing to enhance and support such a great mod - looking forward to seeing what other enhancements you come up with more it. Thanks for sharing it with us, and all the hard work.

While i semi-agree with you that referencing to another mod in a different thread should be avoided, i was only providing an answer regarding to domes as they (currently) are missing from MKS.

Personally i use parts and bits of many different mods as very few of them have all the parts i find interesting.

 

For example, another mod have self-leveling landing legs, while i need to adjust the legs on the cradle in MKS by eye.

Another mod have very good trusses for stationbuilding and matches good with the tundra modules from MKS.

I use GC for pre-made kickstarter bases and EL for building extensions and the compressable welding docking ports from Konstruktion to put it all together.

 

I know RoverDude has put alot of work into this, and i admire this and all other modders who spend their free time maintaining their work as well. 

[DStaal]

26 minutes ago, GraczNet said:

No I don't want to waste your time, but thank you for that!

I did a lot of the work on the current MKS/EL integration patch.  I'm open to ideas to make it better.    (Though I'm not playing with MKS at the moment.)

[GraczNet]

1 minute ago, DStaal said:

I did a lot of the work on the current MKS/EL integration patch.  I'm open to ideas to make it better.    (Though I'm not playing with MKS at the moment.)

Hmm, my idea is to instead of producing Metal from ScrapMetal, smelter should produce MaterialKits and SpecialParts since disassembling ship manually gives MaterialKits, but this is only an idea.

Also sorry for my english.

[RoverDude]

A quick heads up ::)  There will be (offical) 1.7 stuff coming up, mostly in the form of a few PRs and getting that locked down, after which there's going to be a separate pre-release that includes two things:

- Atlas parts (the dome bits!)

- W.O.L.F. Integration (this is the super nifty and new resource management stuff that takes MKS up another level.  Or another way of looking at it, stock KSP is management at the vessel level.  MKS brings in colonies and outposts.  W.O.L.F. adds a layer above that, and deals more with managing multiple colonies with a completely different resource management system at an easier to manage abstraction layer (and gets rid of all of those pesky background processing and interplanetary transport issues).  @DoktorKrogg and I are also working on something special that tacks onto W.O.L.F.   

W.O.L.F. is not an MKS replacement any more than MKS is a replacement for the stock resource system.  Rather, it's a system that layers on top and adds more goodness.

Since it's a massive change both in terms of design and will probably result in people's brains sloshing around a bit (and also have it's share or tweaks, etc.). there will be an opt-in download available for pre-testing   This pre-release will also include all of the Atlas bits as those are ones I also would like to get some feedback on from some of our more enthusiastic and involved players.  

[Brigadier]

1 hour ago, RoverDude said:

A quick heads up ::)  There will be (offical) 1.7 stuff coming up, mostly in the form of a few PRs and getting that locked down, after which there's going to be a separate pre-release that includes two things:

Looking forward to it all despite not having a lot of room in which to slosh stuff around.

[panarchist]

On 4/19/2019 at 2:15 PM, mrstoned said:

While i semi-agree with you that referencing to another mod in a different thread should be avoided, i was only providing an answer regarding to domes as they (currently) are missing from MKS.

Personally i use parts and bits of many different mods as very few of them have all the parts i find interesting.

Hence the ;-)
I likewise use several mods, although I do keep MKS and Pathfinder in separate installs simply because the resource mechanics usually conflict with each other. I don't think I have a game where I'm not using Heisenberg from the WildBlue constellation and Nuclear Rockets from USI. Both modders have put an amazing amount of work into those respective constellations. There has been some good-natured ribbing in both directions in the two threads, though, which is what I was keying off. 

[strudo76]

On 4/18/2019 at 11:29 PM, COL.R.Neville said:

Spoiler

 

@PART[FuelCell*]:AFTER[SQUAD]
{ 
    @MODULE
    {
        OUTPUT_RESOURCE
        {
            ResourceName = Water
            Ratio = #$../INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]]/Ratio$
            @Ratio += #$../INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]]/Ratio$
            @Ratio *= 0.25
            DumpExcess = true            
        }
    }
}

[LOG 2019-04-18 08:44:52.619] Applying update UmbraSpaceIndustries/MKS/Patches/StockTweaks/@PART[FuelCell*]:AFTER[SQUAD] to Squad/Parts/Resources/FuelCell/FuelCell.cfg/PART
[ERR 2019-04-18 08:44:52.619] Error - Cannot parse variable search when inserting new key Ratio = #$../INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]]/Ratio$
[LOG 2019-04-18 08:44:52.619] Applying update UmbraSpaceIndustries/MKS/Patches/StockTweaks/@PART[FuelCell*]:AFTER[SQUAD] to Squad/Parts/Resources/FuelCell/FuelCellArray.cfg/PART
[ERR 2019-04-18 08:44:52.619] Error - Cannot parse variable search when inserting new key Ratio = #$../INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]]/Ratio$

 

anybody run into this before?  is it missing an @ or % for the liquid fuel? 

Are you also using Realism Overhaul? I came here looking for this same information. (Incidentally someone asked the same question almost 2 years ago on page 186, also without a response)

After some investigation, I found RO contains a modification for both FuelCell parts, which includes

Spoiler

		!INPUT_RESOURCE,* {}
		!OUTPUT_RESOURCE,* {}

		INPUT_RESOURCE
		{
			ResourceName = LqdHydrogen
			Ratio = 0.000606231
		}

		INPUT_RESOURCE
		{
			ResourceName = LqdOxygen
			Ratio = 0.0004301955
		}

		OUTPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 4.5
			DumpExcess = True
		}

		OUTPUT_RESOURCE
		{
			ResourceName = Water
			Ratio = 0.0005337
			DumpExcess = True
		}
	}

 

Which means the values this particular patch is looking for (input resources liquidfuel and oxidizer) don't exist in the new definition, and water is already added as an output resource.

You can remove the errors and successfully build a MM.cache file by commenting out that section you have already identified, but it does raise the question of how many other modifications on top of modification the USI configs make to the RO parts. They are both extensive modifications to the game, and it's likely there'll be multiple unexpected changes. Looks like I might have to spend a lot of time in Notepad++ to get these working together, or forego one for the other 

Edited April 22, 2019 by strudo76

[SmileyFace255]

Hi! I startet to play KSP again and now I noticed, that I can't use the flexotube with 1.7 - the rickt-click-menu is broken. I read somewhere, that MKS should work with the new version. The error looks like the problems from KAS before the new 1.3 version.

I tested it al lot - currently after a clean install and some USI-mods + KIS + KAS. Nothing works. Is it a problem of MKS, of the new KAS-Version or my own fault?

EDIT1 image: https://imgur.com/a/VyPMpsK

EDIT2 logfiles: https://www.dropbox.com/sh/07a3emejlemn559/AABOpRnUkqRy2QrOxpv1Tn7ma?dl=0

Edited April 22, 2019 by SmileyFace255

[Terwin]

On 4/19/2019 at 11:53 PM, RoverDude said:

A quick heads up ::)  There will be (offical) 1.7 stuff coming up, mostly in the form of a few PRs and getting that locked down, after which there's going to be a separate pre-release that includes two things:

- Atlas parts (the dome bits!)

- W.O.L.F. Integration (this is the super nifty and new resource management stuff that takes MKS up another level.  Or another way of looking at it, stock KSP is management at the vessel level.  MKS brings in colonies and outposts.  W.O.L.F. adds a layer above that, and deals more with managing multiple colonies with a completely different resource management system at an easier to manage abstraction layer (and gets rid of all of those pesky background processing and interplanetary transport issues).  @DoktorKrogg and I are also working on something special that tacks onto W.O.L.F.   

W.O.L.F. is not an MKS replacement any more than MKS is a replacement for the stock resource system.  Rather, it's a system that layers on top and adds more goodness.

Since it's a massive change both in terms of design and will probably result in people's brains sloshing around a bit (and also have it's share or tweaks, etc.). there will be an opt-in download available for pre-testing   This pre-release will also include all of the Atlas bits as those are ones I also would like to get some feedback on from some of our more enthusiastic and involved players.  

Very cool, I have been watching eagerly for an Atlas/Domes announcement.

Any idea if the beta and/or release is expected to be  in days, weeks or months?

[DStaal]

2 hours ago, SmileyFace255 said:

Hi! I startet to play KSP again and now I noticed, that I can't use the flexotube with 1.7 - the rickt-click-menu is broken. I read somewhere, that MKS should work with the new version. The error looks like the problems from KAS before the new 1.3 version.

I tested it al lot - currently after a clean install and some USI-mods + KIS + KAS. Nothing works. Is it a problem of MKS, of the new KAS-Version or my own fault?

EDIT1 image: https://imgur.com/a/VyPMpsK

EDIT2 logfiles: https://www.dropbox.com/sh/07a3emejlemn559/AABOpRnUkqRy2QrOxpv1Tn7ma?dl=0

Known issue.  The KAS parts those are based on has been removed from the latest version of KAS.

[DoktorKrogg]

4 hours ago, Terwin said:

Very cool, I have been watching eagerly for an Atlas/Domes announcement.

Any idea if the beta and/or release is expected to be  in days, weeks or months?

A pull request for the Atlas parts has been submitted and the models are done. The converters and their recipes have all been setup. We just need to make a second pass over them to iron out all the other fiddly details like mass, cost, attach nodes, names, descriptions, etc.  The converters in the 10m domes worked out to be roughly equivalent to the converters in the Tundra parts in terms of throughput. The big difference is that there are 6 bays instead instead of 2 or 3. The 20m domes also have 6 bays and thus have substantially more throughput per converter. I'm not going to make promises on @RoverDude's behalf but the goal is to put out a beta release for both the Atlas parts and WOLF for KSP 1.7.  Could be days, might be weeks, probably not months. It really just comes down to his schedule. 

Some more notes on the Atlas parts:

• We added some "shortcut" recipes that will allow to do things like make MatKits directly from MetallicOre, Minerals and Substrate, bypassing the intermediate conversion to Metals, Chemicals and Polymers.
• For the first time, we will have swappable, multi-bay USI-LS parts. What this means is that you could have a starter dome that's setup to perform all life support functions (i.e. habitation, recycling, med bay, life support extender, etc.). Then later, when you're ready to grow your colony with additional domes, you could have one dome dedicated to each function. A 20m dome with all 6 bays set to Habitation will provide almost 2,000 kerbal months!
  • Side note: This is the reason we had to change the way converters work. We wouldn't have been able to do this previously.
• The 10m domes will seat 12 kerbals and the 20m domes will seat a whopping 96! Anyone want to make an IVA for the 20m dome...? Anyone? 
• This is all subject to change which is why we're waiting to include it in the beta release we put out for W.O.L.F. We may add bays, remove bays, add recipes, remove recipes, add crew capacity, remove crew capacity... who knows. 

[mrstoned]

On 4/21/2019 at 12:40 AM, panarchist said:

Hence the ;-)

Which i totally missed

[Some random person]

On 4/22/2019 at 12:55 PM, DoktorKrogg said:

A pull request for the Atlas parts has been submitted and the models are done. The converters and their recipes have all been setup. We just need to make a second pass over them to iron out all the other fiddly details like mass, cost, attach nodes, names, descriptions, etc.  The converters in the 10m domes worked out to be roughly equivalent to the converters in the Tundra parts in terms of throughput. The big difference is that there are 6 bays instead instead of 2 or 3. The 20m domes also have 6 bays and thus have substantially more throughput per converter. I'm not going to make promises on @RoverDude's behalf but the goal is to put out a beta release for both the Atlas parts and WOLF for KSP 1.7.  Could be days, might be weeks, probably not months. It really just comes down to his schedule. 

Some more notes on the Atlas parts:

• We added some "shortcut" recipes that will allow to do things like make MatKits directly from MetallicOre, Minerals and Substrate, bypassing the intermediate conversion to Metals, Chemicals and Polymers.
• For the first time, we will have swappable, multi-bay USI-LS parts. What this means is that you could have a starter dome that's setup to perform all life support functions (i.e. habitation, recycling, med bay, life support extender, etc.). Then later, when you're ready to grow your colony with additional domes, you could have one dome dedicated to each function. A 20m dome with all 6 bays set to Habitation will provide almost 2,000 kerbal months!
  • Side note: This is the reason we had to change the way converters work. We wouldn't have been able to do this previously.
• The 10m domes will seat 12 kerbals and the 20m domes will seat a whopping 96! Anyone want to make an IVA for the 20m dome...? Anyone? 
• This is all subject to change which is why we're waiting to include it in the beta release we put out for W.O.L.F. We may add bays, remove bays, add recipes, remove recipes, add crew capacity, remove crew capacity... who knows. 

96 KERBALS? That’s a lot of room for immigrants... or for “kolony growth”

Also all that stuff about converter bays sounds like it'd be a great step for improving the load on a computer's graphics card. Less parts required is always a bonus. Glad to hear about this, since my GPU is seriously bottlenecking my CPU

 

Edited April 24, 2019 by Some random person

[SmileyFace255]

On 4/22/2019 at 7:21 PM, DStaal said:

Known issue.  The KAS parts those are based on has been removed from the latest version of KAS.

Sry, I missed that Flexotubes are our of date. Is there any other possibility to dock vessels on the surface without the pain of the stock docking ports? Scavenging and Power disptribution is nice but a lot of local storages ruin my fps. In fast forward both does not work the way it should even at small bases....

Startet again to expant my outposts... without flexotubes I do not know how....

Edited April 24, 2019 by SmileyFace255

[DStaal]

58 minutes ago, SmileyFace255 said:

Sry, I missed that Flexotubes are our of date. Is there any other possibility to dock vessels on the surface without the pain of the stock docking ports? Scavenging and Power disptribution is nice but a lot of local storages ruin my fps. In fast forward both does not work the way it should even at small bases....

Startet again to expant my outposts... without flexotubes I do not know how....

Konstruction ports with KIS and the Konstruction mod make a pretty good team.  Not quite as easy as pulling the tube from KAS, but you get better looking bases IMHO.

[Terwin]

3 hours ago, SmileyFace255 said:

Startet again to expant my outposts... without flexotubes I do not know how....

I have generally used a core 'seed' base and then used Ground Construction to make new parts that I then attach using KAS.

Before that I used the other construction mod suggested for use with MKS(EPL?) to make parts that I then attached with KAS.

Also, the 1.7 fix to reduce hopping of landed craft(and bases) seems promising to make large single-piece based more feasible without needing to worry about attachment-point creep(where parts spontaneously un-align themselves when you load up the base, even when anchored)

(I have had ground bases with more than half a dozen large hab-wheels and several 3.5m nuclear reactors from time to time, so I am all for large single-piece bases)

 

[alien_wind]

4 hours ago, SmileyFace255 said:

Sry, I missed that Flexotubes are our of date. Is there any other possibility to dock vessels on the surface without the pain of the stock docking ports? Scavenging and Power disptribution is nice but a lot of local storages ruin my fps. In fast forward both does not work the way it should even at small bases....

Startet again to expant my outposts... without flexotubes I do not know how....

if all you need are connection there are kas links and winches
they work fine(no matter how you squeeze a kerbal through one  )

[mrstoned]

I have used Flextubes in place of the MKS flex-o-tubes dependancy on the recently changed KAS pipes.

 

 

 

[infinite_monkey]

On 4/22/2019 at 9:55 PM, DoktorKrogg said:

A pull request for the Atlas parts has been submitted and the models are done. The converters and their recipes have all been setup. We just need to make a second pass over them to iron out all the other fiddly details like mass, cost, attach nodes, names, descriptions, etc.  The converters in the 10m domes worked out to be roughly equivalent to the converters in the Tundra parts in terms of throughput. The big difference is that there are 6 bays instead instead of 2 or 3. The 20m domes also have 6 bays and thus have substantially more throughput per converter. I'm not going to make promises on @RoverDude's behalf but the goal is to put out a beta release for both the Atlas parts and WOLF for KSP 1.7.  Could be days, might be weeks, probably not months. It really just comes down to his schedule. 

Some more notes on the Atlas parts:

• We added some "shortcut" recipes that will allow to do things like make MatKits directly from MetallicOre, Minerals and Substrate, bypassing the intermediate conversion to Metals, Chemicals and Polymers.
• For the first time, we will have swappable, multi-bay USI-LS parts. What this means is that you could have a starter dome that's setup to perform all life support functions (i.e. habitation, recycling, med bay, life support extender, etc.). Then later, when you're ready to grow your colony with additional domes, you could have one dome dedicated to each function. A 20m dome with all 6 bays set to Habitation will provide almost 2,000 kerbal months!
  • Side note: This is the reason we had to change the way converters work. We wouldn't have been able to do this previously.
• The 10m domes will seat 12 kerbals and the 20m domes will seat a whopping 96! Anyone want to make an IVA for the 20m dome...? Anyone? 
• This is all subject to change which is why we're waiting to include it in the beta release we put out for W.O.L.F. We may add bays, remove bays, add recipes, remove recipes, add crew capacity, remove crew capacity... who knows. 

So the Atlas parts will still use the same modules for resource conversion? I was hoping the new system would make better use of parallel threads. As I mentioned before, KSP is painfully slow (5 FPS) for me near MKS bases, but both GPU and CPU are pretty bored. Maybe something else is wrong with my system?

[alien_wind]

 

On 4/20/2019 at 7:53 AM, RoverDude said:

A quick heads up ::)  There will be (offical) 1.7 stuff coming up, mostly in the form of a few PRs and getting that locked down, after which there's going to be a separate pre-release that includes two things:

- Atlas parts (the dome bits!)

- W.O.L.F. Integration (this is the super nifty and new resource management stuff that takes MKS up another level.  Or another way of looking at it, stock KSP is management at the vessel level.  MKS brings in colonies and outposts.  W.O.L.F. adds a layer above that, and deals more with managing multiple colonies with a completely different resource management system at an easier to manage abstraction layer (and gets rid of all of those pesky background processing and interplanetary transport issues).  @DoktorKrogg and I are also working on something special that tacks onto W.O.L.F.   

W.O.L.F. is not an MKS replacement any more than MKS is a replacement for the stock resource system.  Rather, it's a system that layers on top and adds more goodness.

Since it's a massive change both in terms of design and will probably result in people's brains sloshing around a bit (and also have it's share or tweaks, etc.). there will be an opt-in download available for pre-testing   This pre-release will also include all of the Atlas bits as those are ones I also would like to get some feedback on from some of our more enthusiastic and involved players.  

finally part series to reduce part count lag in mega bases!!
after a while my bases just become tundra parts stack of lag.

so happy and great work!!,what you're doing for this game is just amazing.

[DoktorKrogg]

3 hours ago, infinite_monkey said:

So the Atlas parts will still use the same modules for resource conversion?

Yes.

3 hours ago, infinite_monkey said:

I was hoping the new system would make better use of parallel threads. As I mentioned before, KSP is painfully slow (5 FPS) for me near MKS bases, but both GPU and CPU are pretty bored. Maybe something else is wrong with my system?

It's not your system, it's KSP. MKS leans heavily on the stock resource system, so there isn't much we can do to optimize its performance any further. It all comes down to part count in the end. Every light, ladder, docking port, antenna, science experiment, strut, storage container, solar panel, etc. that you add to a base has physics calculations performed on it every frame, for every vessel that's currently in physics range. It's pretty easy for an MKS base to balloon in part count once you add in life support, power, comms, storage, support modules, etc. The reason that MKS brings so many logistics options to the table is to encourage a more distributed approach to colonization where you have small outposts dedicated to a single task and spread far enough apart that they are out of physics range from one another.

The Atlas parts should have a pretty dramatic effect in terms of reducing part counts. In addition to having 2 - 3x more bays compared to Tundra parts (and in the case of the 20m dome, something like 8 - 10x the throughput per bay), the domes also perform the functions of the Pioneer and Workshop parts. So you shouldn't need nearly as many support parts to have a fully functioning MKS base.

And... then there's W.O.L.F. This is the ultimate solution to the performance issues that colonization tends to introduce. It's a completely new resource system that has little to do with the stock resource system. We still use the stock system to determine resource abundance but that's about it. The way that W.O.L.F. works is easier to show than to try to explain but the basic flow is this:

• Scan a biome to see what resources are available and in what quantity.
• Setup a depot in the biome (you'll have the option to spawn a premade, single-part base in the biome if you want something pretty to look at)
• Bring in equipment to harvest and process the resources (land them with a rocket, truck them in with a rover, build them on site, whatever)
  • The equipment will be "absorbed" into the biome/depot (i.e. it will be despawned from the game)
• Setup transport routes to transfer resources between depots... even depots on other planets

There is no temporal component to the W.O.L.F. resource system, meaning we don't have to run any per-frame calculations to determine how much Ore a drill is bringing in or how much Ore a refinery is using and how much LiquidFuel it's producing. You'll do a resource survey, it will come back saying you have something like 200 Ore available in the biome, you land a drill in the biome that can extract 5 Ore and now you have 5 Ore available in your depot to do whatever with. Then you might bring in a refinery that needs 10 Ore and produces 5 LFO. The depot can only supply you with 5 Ore though currently, so you either need to bring in another drill or ship the other 5 Ore in from another depot. The important thing to understand that 1 W.O.L.F. unit is not the same as 1 stock unit. 

There is a part (we're calling it a "hopper") that will allow you pull resources out of W.O.L.F. into the stock resource system. That part will operate just like any other converter does currently (i.e. it will output some quantity per second). This is the only time we introduce any kind of temporal component to W.O.L.F. We still haven't ironed out the exact formula we'll use for that conversion but it will probably be something like 1 W.O.L.F. unit = 10 kg/day. That would put a hopper about on par with a single bay in the 20m dome.

There will not be a way to input resources from the stock system into W.O.L.F. though. The whole idea behind W.O.L.F. is permanence. Once you have a drill setup in a biome to bring in 5 Ore, that 5 Ore is guaranteed for the rest of the game. Once that 5 Ore has been allocated to consumers, it can't be reallocated. So we don't want to introduce dependencies on incoming resources from parts that may explode, get recycled on accident, moved to another biome, etc. The permanence of W.O.L.F. is what makes it so much simpler than the stock resource system and thus so much more scalable.