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

[goldenpsp]

7 minutes ago, MaxPeck said:

So is this taking the place of GC, OSE, or both?

The current functionality already present in the pre-release constellation download takes the place of OSE.  It will be expanded to replace both.

[TheSuMa]

Missed one suggestion in my previous post:

It is more a question than a suggestion and nothing tested on it so far, but what do you @DoktorKrogg think about a multiplier-setting on transport-computer (Only integers, no decimals) before connecting to destination? It was just, if i'm able to fly it once, i would be able to fly it twice.  But when i fly a transport-route from Kerbin to Jool and after reaching destination i notice that payload is too low, i need to wait for next transfer-window to fly again. This would either result in forgetting the current project for a long time or timewrap multiple months.

[RoverDude]

2 hours ago, TheSuMa said:

Can confirm the finding of @MaxPeck, just needed to make sure first no other mod caused the problem (As far as i found out WOLF does not handle the Kerbals in any special way, they just automaticcaly "die" when wessel goes Poof, when Respawn is enabled they get state MIA instead of KIA)

Thanks for the catch!  If you have a PR for this we'd be happy to take it!

2 hours ago, TheSuMa said:

The 3.75m Fuel hopper ratio for reqeip "Liquid Fuel" seems wrong (takes more resources than small version, but same output
=> HopperFuel375.cfg change Ratio = 0.0185185

Same as above, PR would be great

2 hours ago, TheSuMa said:

As far as i can see there is no possibility to add only a CrewMember to depot
=> Not sure about that, but probably there should be a Button "Connect to Depot" on every part that can have crew??

We could add a 'communicator' part that's explicitly for this purpose that you could slap on a capsule, that way we don't clog the part PAW.  Could also be a UI option but that could get confusing if you have a lot of vessels in the area and accidentally WOLF-ize your science base...

2 hours ago, TheSuMa said:

If i havn't missed something i'm not able to see how good a route performs before connecting it to destination depot. Especially in career mode this is a problem as transportcredits are very expensive to get.

The 'route cost' you see there is your cost in TCs - for payload see below

2 hours ago, TheSuMa said:

Kerbal "Resources" are multiplied by experienceLevel (stars), regarding that star-leveling is not linear probably a balancing issue (https://wiki.kerbalspaceprogram.com/wiki/Experience#Levels)

We did stars because of the easy math in WOLF (1 CrewPoint = 1 Star).  A lot of WOLF is about making the calculations incredibly simple.  Also, level 5 Kerbals are exponentially powerful in WOLF since you've probably seen the long chains you need to get stuff to work

2 hours ago, TheSuMa said:

• Refueling during transport increase payload (unrealistic, why should it)
  => Track lowest mass during flight instead readout while connecting to destination
• If a vessel is barely able to reach the destination and arrives completely dry, i can still get a lot of Payload if the craft is heavy enough (unrealistic, where should that payload be stored? With more weight the craft would not have been able to reach destination)
  => Calculate the payload based on resource-mass instead of vessel-mass
• Cost calculation
  1. Refueling during transport reduces cost (unrealistic, the opposite should be the case as more fuel is needed for transport)
  2. Flying with high-efficient fuels (like karborundum) a route will be very cheap because almost no mass is lost. But it should be expensive as the fuel is hard to mine and expensive to buy
     => Calculate the route-cost based on "burned fuel cost" + "vessel dry cost start" - "vessel dry cost end"

Lots of good stuff here.   Refueling to reduce transport cost is by design.  But the issue as you found out is folks loading up on mass at the end.  We're going to be introducing WOLF Kontainers that are used specifically for route setup, so that's the only mass that counts for payload calculation (your loss of ship mass is still used for route cost in TCs).

2 hours ago, TheSuMa said:

Change some methods in code from "private" to "protected virtual", this would make it a lot easier to implement custom Transport-Logic for other modders (This would have saved me some time while testing )

More than happy to do this   and a single PR is totally fine.

1 hour ago, TheSuMa said:

Missed one suggestion in my previous post:

It is more a question than a suggestion and nothing tested on it so far, but what do you @DoktorKrogg think about a multiplier-setting on transport-computer (Only integers, no decimals) before connecting to destination? It was just, if i'm able to fly it once, i would be able to fly it twice.  But when i fly a transport-route from Kerbin to Jool and after reaching destination i notice that payload is too low, i need to wait for next transfer-window to fly again. This would either result in forgetting the current project for a long time or timewrap multiple months.

That one's a toughie.  Part of the reason for making you do all of those journeys to build up your transport network is a balance function.  @DoktorKrogg - thoughts?

 

[TBenz]

2 hours ago, RoverDude said:

 

4 hours ago, TheSuMa said:

Missed one suggestion in my previous post:

It is more a question than a suggestion and nothing tested on it so far, but what do you @DoktorKrogg think about a multiplier-setting on transport-computer (Only integers, no decimals) before connecting to destination? It was just, if i'm able to fly it once, i would be able to fly it twice.  But when i fly a transport-route from Kerbin to Jool and after reaching destination i notice that payload is too low, i need to wait for next transfer-window to fly again. This would either result in forgetting the current project for a long time or timewrap multiple months.

That one's a toughie.  Part of the reason for making you do all of those journeys to build up your transport network is a balance function. 

Here are my thoughts. There's already a decent amount of work in establishing the depots with the necessary supplies to support a transport network. Not to mention designing and testing the transport. 

I don't want to suggest that anything after the first flight is going to be completely routine for every flight, but only the most extreme routes are going to be interesting after 4-5 flights. If someone is setting up a large network of multiple smaller vessels running the same route, it's going to get boring. A case could be made for that being a balancing factor meant to favor a smaller number of larger vessels, but lots of videogame players will grind out boring things if it gives them some benefit. They'll willingly subject themselves to that, and in some cases even have the audacity to blame the designers for designing it in that way (even though they are the ones who chose to play it that way). 

I'm not so sure that balance by tedium is the best approach. I'd vouch for letting a single journey count as a test flight that can be used for multiple duplicate routes.

Also, while I'm here, I'd also like to put support behind having transport routes be more considerate of the fuel burnt. The current system works well enough for LFO, but it breaks down with xenon and modded fuels. And not just in terms of cost, but also availability. Right now all we need is WOLF-ized LFO production to field vessels fueled by xenon, karborundum, or even the crazy FFT fuels. I understand if this is too complex or otherwise beyond the scope of WOLF, and I definitely don't want to suggest you need to worry about supporting all the different mod fuels out there. Just wanted to put my thoughts out there about something I think would be cool to see.

[Plomie]

18 hours ago, RoverDude said:

Or wait a little bit

Maybe @DoktorKrogg has his own hints

 

Are you making your own In situ building part of the mod?  i thought that system was for single parts. Super cool!!!!!!

[Plomie]

Hello roverdude i saw that there where two mks downloads for mks 1.4.10 on github. I downloaded them both to check diffrences and they both have different thing in gamedata the first one has Only usi 000_tools and all the normal stuff. the other has the usi tool and AT utils tools. the first download is UmbraSpaceIndustries/MKS: MKS/OKS Colonization Systems (github.com)

The second is

Releases · UmbraSpaceIndustries/MKS (github.com)

And that could be a problem. 

I didnt reinstall it yet but i dont know wich to download i need, if this is a problem.

3 minutes ago, Plomie said:

Hello roverdude i saw that there where two mks downloads for mks 1.4.10 on github. I downloaded them both to check diffrences and they both have different thing in gamedata the first one has Only usi 000_tools and all the normal stuff. the other has the usi tool and AT utils tools. the first download is UmbraSpaceIndustries/MKS: MKS/OKS Colonization Systems (github.com)

The second is

Releases · UmbraSpaceIndustries/MKS (github.com)

And that could be a problem. 

 

5 minutes ago, Plomie said:

Hello roverdude i saw that there where two mks downloads for mks 1.4.10 on github. I downloaded them both to check diffrences and they both have different thing in gamedata the first one has Only usi 000_tools and all the normal stuff. the other has the usi tool and AT utils tools. the first download is UmbraSpaceIndustries/MKS: MKS/OKS Colonization Systems (github.com)

The second is

Releases · UmbraSpaceIndustries/MKS (github.com)

And that could be a problem. 

I didnt reinstall it yet but i dont know wich to download i need, if this is a problem.

 

please have a look

its a possibly a promblem.  And i dont know wich but in one of those ore both there where no KolonyTools. that can be a problem 

[SpacedInvader]

I'm returning to the game after a couple of years away and have decided to play version 1.10.1 instead of 1.11 because several must-have mods for me are not yet updated to the newer version of the game and because apparently 1.11 is pretty buggy and I'm planning a loooooooooong career (my goal is to have a colony on every rocky body in the system, including OPM and possibly a binary star system if I can find a good one), so I'm trying to keep things running as smooth as possible. That said, it appears there was never a version of MKS specifically built to run on 1.10 so I'm not sure which version to install. Searching this thread has given some indication that the 1.3.0.0 version of MKS worked for the most part on KSP 1.10.1, but there were some issues apparently, and I can't find any reference at all to anyone using 1.4.1 with KSP 1.10.1. As a result, I figured I'd better ask if 1.4.1 is a better option for running on 1.10.1 or if neither is really great?

Thanks

Edited January 8, 2021 by SpacedInvader

[Plomie]

2 minutes ago, SpacedInvader said:

I'm returning to the game after a couple of years away and have decided to play version 1.10.1 instead of 1.11 because several must-have mods for me are not yet updated to the newer version of the game and because apparently 1.11 is pretty buggy and I'm planning a loooooooooong career (my goal is to have a colony on every rocky body in the system, including OPM and possibly a binary star if I can find a good one), so I'm trying to keep things running as smooth as possible. That said, it appears there was never a version of MKS specifically built to run on 1.10 so I'm not sure which version to install. Searching this thread has given some indication that the 1.3.0.0 version of MKS worked for the most part on KSP 1.10.1, but there were some issues apparently, and I can't find any reference at all to anyone using 1.4.1 with KSP 1.10.1. As a result, I figured I'd better ask if 1.4.1 is a better option for running on 1.10.1 or if neither is really great?

Thanks

i dont really know i didnt have mks in 1.10

[SpacedInvader]

5 minutes ago, Plomie said:

i dont really know i didnt have mks in 1.10

[TheSuMa]

 

10 hours ago, RoverDude said:

12 hours ago, TheSuMa said:

As far as i can see there is no possibility to add only a CrewMember to depot

We could add a 'communicator' part that's explicitly for this purpose that you could slap on a capsule, that way we don't clog the part PAW.  Could also be a UI option but that could get confusing if you have a lot of vessels in the area and accidentally WOLF-ize your science base...

Sounds like a good solution to the problem, easy and functional withoud UI cluttering 

10 hours ago, RoverDude said:

12 hours ago, TheSuMa said:

If i havn't missed something i'm not able to see how good a route performs before connecting it to destination depot

The 'route cost' you see there is your cost in TCs - for payload see below

The PrintScreen in my Post was my suggestion, not the current implementation, to clarify and show the problem, another screenshot with both transport-computers side-by-side (Completely dry vessel, so with my payload-calculation not a that good performing route ):

10 hours ago, RoverDude said:

12 hours ago, TheSuMa said:

Kerbal "Resources" are multiplied by experienceLevel (stars), regarding that star-leveling is not linear probably a balancing issue (https://wiki.kerbalspaceprogram.com/wiki/Experience#Levels)

Also, level 5 Kerbals are exponentially powerful in WOLF since you've probably seen the long chains you need to get stuff to work

Sounds legit, was just a tought 

10 hours ago, RoverDude said:

12 hours ago, TheSuMa said:

• Refueling during transport increase payload (unrealistic, why should it)
  => Track lowest mass during flight instead readout while connecting to destination
• If a vessel is barely able to reach the destination and arrives completely dry, i can still get a lot of Payload if the craft is heavy enough (unrealistic, where should that payload be stored? With more weight the craft would not have been able to reach destination)
  => Calculate the payload based on resource-mass instead of vessel-mass
• Cost calculation
  1. Refueling during transport reduces cost (unrealistic, the opposite should be the case as more fuel is needed for transport)
  2. Flying with high-efficient fuels (like karborundum) a route will be very cheap because almost no mass is lost. But it should be expensive as the fuel is hard to mine and expensive to buy
     => Calculate the route-cost based on "burned fuel cost" + "vessel dry cost start" - "vessel dry cost end"

Lots of good stuff here.   Refueling to reduce transport cost is by design.  But the issue as you found out is folks loading up on mass at the end.  We're going to be introducing WOLF Kontainers that are used specifically for route setup, so that's the only mass that counts for payload calculation (your loss of ship mass is still used for route cost in TCs).

• Refueling to reduce transport cost is by design:  Well, ok, accepted.
• But the issue as you found out is folks loading up on mass at the end: This was not my concern, if folks want to cheat i have no problem with that. My concern was that you are in no way able to refuel during transports without cheating.
• We're going to be introducing WOLF Kontainers that are used specifically for route setup: I know, just tought by available resources would be easier to do because otherwise you need to add a lot of parts (different vessel sizes, mk3, ...) to keep the range open for small and large routes

 

10 hours ago, RoverDude said:

12 hours ago, TheSuMa said:

It is more a question than a suggestion and nothing tested on it so far, but what do you @DoktorKrogg think about a multiplier-setting on transport-computer (Only integers, no decimals) before connecting to destination? It was just, if i'm able to fly it once, i would be able to fly it twice.  But when i fly a transport-route from Kerbin to Jool and after reaching destination i notice that payload is too low, i need to wait for next transfer-window to fly again. This would either result in forgetting the current project for a long time or timewrap multiple months.

That one's a toughie.  Part of the reason for making you do all of those journeys to build up your transport network is a balance function.  @DoktorKrogg - thoughts?

As my suggestion is to add it to transport-computer you still need to fly it multiple times if you need more payload later in the game. It is just a multiplier before connecting the computer to destination depot. This way you can only modify the current route and no additional information on routes need to be stored inside WOLF. As noted my main concern was when flying long routes (interplanetary) and you end up with a few less payloads than expected / needed you need to wait / timewrap for next TransferWindow just to fly the exact same transportroute again.

I understand the balancing need to fly the transport routes / build vessels for it and all of that and think it is a good thing. Just tried to solve the edge case for interplanetary transfers

10 hours ago, RoverDude said:

12 hours ago, TheSuMa said:

Change some methods in code from "private" to "protected virtual", this would make it a lot easier to implement custom Transport-Logic for other modders (This would have saved me some time while testing )

More than happy to do this

Thanks

 

10 hours ago, RoverDude said:

and a single PR is totally fine

Will do 

Edited January 8, 2021 by TheSuMa
Remove blanks

[RoverDude]

3 hours ago, Plomie said:

please have a look

its a possibly a promblem.  And i dont know wich but in one of those ore both there where no KolonyTools. that can be a problem 

There is only 1.4.1 - that's the one you should download.  Always download from the releases section, it will clearly note the latest release.

3 hours ago, SpacedInvader said:

I figured I'd better ask if 1.4.1 is a better option for running on 1.10.1 or if neither is really great?

tbh, 1.11 of KSP is fine.   1.4.1 *should* work, but anything beyond that (even pre-releases) are going to break because we're moving to stock inventory, which is a 1.11 thing.

1 hour ago, TheSuMa said:

The PrintScreen in my Post was my suggestion, not the current implementation, to clarify and show the problem, another screenshot with both transport-computers side-by-side (Completely dry vessel, so with my payload-calculation not a that good performing route ):

Yep, let me talk to the other USI Elves since there are a lot of opinions on route repeatability.  I hate to ask, but if you have this already in a PR and want to toss it over in isolation then we can either pull it in, or discuss in that PR thread.   

5 hours ago, TBenz said:

Here are my thoughts. There's already a decent amount of work in establishing the depots with the necessary supplies to support a transport network. Not to mention designing and testing the transport. 

I don't want to suggest that anything after the first flight is going to be completely routine for every flight, but only the most extreme routes are going to be interesting after 4-5 flights. If someone is setting up a large network of multiple smaller vessels running the same route, it's going to get boring. A case could be made for that being a balancing factor meant to favor a smaller number of larger vessels, but lots of videogame players will grind out boring things if it gives them some benefit. They'll willingly subject themselves to that, and in some cases even have the audacity to blame the designers for designing it in that way (even though they are the ones who chose to play it that way). 

I'm not so sure that balance by tedium is the best approach. I'd vouch for letting a single journey count as a test flight that can be used for multiple duplicate routes.

Also, while I'm here, I'd also like to put support behind having transport routes be more considerate of the fuel burnt. The current system works well enough for LFO, but it breaks down with xenon and modded fuels. And not just in terms of cost, but also availability. Right now all we need is WOLF-ized LFO production to field vessels fueled by xenon, karborundum, or even the crazy FFT fuels. I understand if this is too complex or otherwise beyond the scope of WOLF, and I definitely don't want to suggest you need to worry about supporting all the different mod fuels out there. Just wanted to put my thoughts out there about something I think would be cool to see.

WOLF Fuel hoppers support Xenon, LF/O, Mono, LF, Karbonite, and Karborundum.  With the addition of a half dozen new LiquidHydrogen nuclear engines, you'll likely see a patch for that as well.  The nice part is that WOLF numbers are big and chunky, so if anyone wants to do a PR in the Patches folder for additional swap-options to support other fuel types, that's fine!   If you look at the Karbonite patch that comes with WOLF it's a solid blueprint as it covers harvesters, the refinery, the hopper, and lighting up the resource vein.  

4 hours ago, Plomie said:

Are you making your own In situ building part of the mod?  i thought that system was for single parts. Super cool!!!!!!

Orbital ship construction is the first step on that.  Slowly working on the Tier-1 model - it's about halfway done, going to try wrapping it up tonight:

 

[Spaceman.Spiff]

1 hour ago, RoverDude said:

Orbital ship construction

Will this be MKS only, or a standalone?

Edited January 8, 2021 by Spaceman.Spiff
Clarified

[goldenpsp]

5 minutes ago, Spaceman.Spiff said:

Will this be MKS only, or a standalone?

He already stated above it will be part of the Konstruction mod.

[TheSuMa]

Tanks for the reply.

47 minutes ago, RoverDude said:

Yep, let me talk to the other USI Elves since there are a lot of opinions on route repeatability.  I hate to ask, but if you have this already in a PR and want to toss it over in isolation then we can either pull it in, or discuss in that PR thread.

I'll do a second PR then for the repeatability based on the general PR, understand absolutely that this will need a discussion. Not much additional work if i base it on the general PR, just 2 Lines of Code 

The question was anyway more about the other info-only fields ("Payload" and "Credits / Payload"). I hardly miss them in current release (See left part of screenshot). If your good with them i include it in the general PR.

Another small question is the grouping in the Context-Menu. As the field-count increases i'd like it to be grouped, but would it let expand by default. Especially if you have other mods installed that clutter the UI with a lot of fields (like HotSpot) you're always searching for the relevant fields in the context-menu. What do you think about that, should i include the grouping or should i remove it from PR (AFAIK no other USI modules use the grouping currently, so probably for consistancy-reasons...)

1 hour ago, RoverDude said:

Orbital ship construction is the first step on that.  Slowly working on the Tier-1 model - it's about halfway done, going to try wrapping it up tonight:

Wow, looks very nice so far , looking forward seeing the result

[RoverDude]

@TheSuMa - Grouping would be excellent - it's something we should clean up over time.

[TBenz]

5 hours ago, RoverDude said:

WOLF Fuel hoppers support Xenon, LF/O, Mono, LF, Karbonite, and Karborundum.  With the addition of a half dozen new LiquidHydrogen nuclear engines, you'll likely see a patch for that as well.  The nice part is that WOLF numbers are big and chunky, so if anyone wants to do a PR in the Patches folder for additional swap-options to support other fuel types, that's fine!   If you look at the Karbonite patch that comes with WOLF it's a solid blueprint as it covers harvesters, the refinery, the hopper, and lighting up the resource vein.  

Oh for sure. I've definitely been thinking about whipping up some patches for modded fuels on the production to hopper side of things. What I was more getting at was that transfer credits are created with LFO, to cover the fuel aspect, but you can setup routes using vessels that use much more exotic fuel sources without needing any supply chain for that fuel. 

[eberkain]

The deployable science units get combined into a single vessel in the tracking station. It would be cool if all base modules connected by local logistics were combined into a single vessel in the tracking station in the same manner.  

[DoktorKrogg]

1 hour ago, TBenz said:

transfer credits are created with LFO, to cover the fuel aspect, but you can setup routes using vessels that use much more exotic fuel sources without needing any supply chain for that fuel

Solving this problem is non-trivial. It would mean adding a bunch more code to check for the types of fuel used on the vessel, tracking fuel burn, creating multiple types of TransportCredits and determining which ones were used to complete the route (i.e. what if multiple fuels were used along the route?), what to do about stages that are jettisoned along the way (which type of TransportCredit does that cost?), etc. Ultimately this boils down to "is KSP a simulator or a game?" and everyone has their own opinion on that. @RoverDude and I tend to fall on the "it's a game" side of that argument and gravitate more toward approximation vs. ultra-realism because it makes our lives easier and lets us get more stuff out the door in our limited free time. 

If someone wants to make a more realistic transportation system that ties into WOLF, I'd be happy to answer specific implementation questions (by "specific" I mean don't ask me "how do I make a mod?" ). It's already fairly extensible and we're open to accepting PRs like @TheSuMa mentioned to make private methods protected, etc. to improve the extensibility.

18 hours ago, TheSuMa said:

what do you @DoktorKrogg think about a multiplier-setting on transport-computer (Only integers, no decimals) before connecting to destination? It was just, if i'm able to fly it once, i would be able to fly it twice.  But when i fly a transport-route from Kerbin to Jool and after reaching destination i notice that payload is too low, i need to wait for next transfer-window to fly again. This would either result in forgetting the current project for a long time or timewrap multiple months.

I'm not categorically opposed to this idea but I'm also not convinced that it is an essential feature. Ultimately it sounds like you're suggesting an "oops" button but getting your crew capsule back from the Mun full of science only to realize you forgot to put a heat shield on it for re-entry is 2/3 of the "charm" of KSP. Planning and executing a "perfect" mission in KSP after 1,000 poorly planned/executed missions is one of the greatest sources of satisfaction (for me anyway). On the other hand, I'm not a fan of tedium. If I get to a point in my own saves where transport routes are a source of continual boredom, then I'll probably change my tune. I haven't hit that point yet though.

As mentioned previously, we are working on a new way to handle the payload portion of transport routes (i.e. having WOLF cargo crates with a fixed mass that will be used for the payload calculation instead of using the vessel mass at the end of the route). This should make the payload a lot easier to plan and not a guessing game like it is now.

[Kielm]

Hey, 

Thoroughly enjoying the new WOLF content (it's a little bit of a learning curve but that just makes it more fun)!

One minor (possible) bug:

• The small ATLAS harvesters are located in Advanced Construction tech node, but I think they're supposed to be in Colonization (possibly due MM patch referencing @PART[ATLAS_Harvester_sm* - is it case sensitive? )

Also, I tested out an automated remote mining rig on Kerbin with a few inflatable ILMs and an MPU, hoping to dump the mined materials into planetary logistics on Minmus and use them later. Thinking that the planetary logistics are tied to the ILMs, to save weight, I took the MPU out of the craft at the last minute and decided to do all the processing on my formative Minmus base. On landing however, I discovered that planetary logistics (push) is tied to the MPU, not the ILMs. Not a huge problem as I can just relaunch it with the smallest MPU now that I know, but I'm curious about the design decision here.  Would I be cheesing the system a bit if I use an MPU purely to push into planetary logistics? Should the ILMs have Planetary Logistics instead or should the MPU have planetary logistics removed? Is it supposed to be a higher tech (e.g. ATLAS) feature?

Edited January 9, 2021 by Kielm

[RoverDude]

9 minutes ago, Kielm said:

Hey, 

Thoroughly enjoying the new WOLF content (it's a little bit of a learning curve but that just makes it more fun)!

One minor (possible) bug:

• The small ATLAS harvesters are located in Advanced Construction tech node, but I think they're supposed to be in Colonization (possibly due MM patch referencing @PART[ATLAS_Harvester_sm* - is it case sensitive? )

Also, I tested out an automated remote mining rig on Kerbin with a few inflatable ILMs and an MPU, hoping to dump the mined materials into planetary logistics on Minmus and use them later. Thinking that the planetary logistics are tied to the ILMs, to save weight, I took the MPU out of the craft at the last minute and decided to do all the processing on my formative Minmus base. On landing however, I discovered that planetary logistics (push) is tied to the MPU, not the ILMs. Not a huge problem as I can just relaunch it with the smallest MPU now that I know, but I'm curious about the design decision here.  Would I be cheesing the system a bit if I use an MPU purely to push into planetary logistics? Should the ILMs have Planetary Logistics instead or should the MPU have planetary logistics removed? Is it supposed to be a higher tech (e.g. ATLAS) feature?

The idea with the MPUs is they were meant for quick deployables that could pump out missing resources for your main base.  So having an MPU purely for PlanLog is by design

[SpacedInvader]

12 hours ago, RoverDude said:

tbh, 1.11 of KSP is fine.   1.4.1 *should* work, but anything beyond that (even pre-releases) are going to break because we're moving to stock inventory, which is a 1.11 thing.

Hmm, I guess I was led to believe that 1.11 was bad enough that a decent amount of people rolled back to it after the update. That said, it doesn't really do much about the fact that some of my "must have" mods aren't updated yet (specifically Real Fuels and Real Chute) so I guess I'll either have to wait until they are updated to start or make do with 1.10.1. Thanks for the response though.

EDIT: *Aren't updated and apparently disabled until updated

Edited January 9, 2021 by SpacedInvader

[ninthninja05]

Does this mod require life support functionality? I'd rather just build bases without worrying about keeping my kerbals alive.

[RoverDude]

52 minutes ago, ninthninja05 said:

Does this mod require life support functionality? I'd rather just build bases without worrying about keeping my kerbals alive.

Nope.  Not required.  Some of the parts would just be aesthetic but the whole in-situ building play is still there without LS.

[Murdabenne]

On 1/7/2021 at 5:19 PM, DoktorKrogg said:

We are indeed working on a new system for building vessels in-situ and it will live in the Konstruction mod. It will use MatKits and SpecParts along with some new resources (and corresponding converters for them in MKS and hoppers for them in WOLF). The new resources were necessary to account for things like gravioli detectors whose mass is very low but cost is very high. Otherwise you could just dump a crate of MatKits on the runway, pump out a bunch of gravioli detectors and recover the vessel for a substantial profit. A big difference between our system and systems like GC is that vessels will instantly spawn nearby. Our reasoning is that the "build" time is baked into the assembly of the resources themselves. We don't see the simulation of a build process as being "fun" since you can (and most times would) just time warp through that part of the process anyway. It's still in development and all of this is subject to change at any time but that's where things currently stand. 

How will this interact with something time oriented like KCT?

[goldenpsp]

1 hour ago, Murdabenne said:

How will this interact with something time oriented like KCT?

Guessing that unless @RoverDude or @DoktorKrogg actually use KCT, the answer will be unknown.