Jump to content

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


RoverDude

Recommended Posts

Just now, Kerminator1000 said:

Do you guys know if Kerbalism Science only config works with MKS? I know that Kerbalism doesn't but I not sure if the removal of all but the science parts would affect it. I asked in the Kerbalism thread too, but they haven't responded yet.

No idea, they would be the right ones to answer.  

Link to comment
Share on other sites

1 minute ago, Kerbals_of_Steel said:

Minor bug report: The ATLAS harvesters only appear in the utility category, not the Kolonization or Manufacturing catagories.

I'm going to try and figure out Github, but no guarantees.

To me it would make more sense for things on only appear in a single category.  That is how all stock parts are. 

Link to comment
Share on other sites

I only see a small portion of the MKS or WOLF components when using the search field. For example if I search for "tundra" I only see the MKS 'Ranger' 2.5m stack adapter. If I search for "atlas" I only see the harvesters.

Is this a KSP problem or have I not installed USI constellation stuff properly?

 

Link to comment
Share on other sites

1 hour ago, JamesonKerbal said:

I only see a small portion of the MKS or WOLF components when using the search field. For example if I search for "tundra" I only see the MKS 'Ranger' 2.5m stack adapter. If I search for "atlas" I only see the harvesters.

Is this a KSP problem or have I not installed USI constellation stuff properly?

 

KSP problem

Link to comment
Share on other sites

So wolf isnt running in the background, but its calculations are consistent?

IE. Back in the day an outpost digging water and throwing it into planetary warehouse would only do so when the vessel was active so you occasionally had to rotate between outposts to ensure the values were updating otherwise eventually the main base pulling resources would run out. 

The way I understand it WOLF now mitigates this by dealing with wolf resources which are consistent? So once WOLF has registered materials being fed into it, the available pool updates and a base elsewhere can make use of that pool and the values wont matter as it will always be consistent? IE 5 units of water available forever ((or something of the like)) and you only need to go back to the extracting infrastructure when adding new industry so it can update its wolf pool? I think I got that correct? 

Edited by Yuri kagarin56
Link to comment
Share on other sites

16 minutes ago, Yuri kagarin56 said:

So wolf isnt running in the background, but its calculations are consistent?

IE. Back in the day an outpost digging water and throwing it into planetary warehouse would only do so when the vessel was active so you occasionally had to rotate between outposts to ensure the values were updating otherwise eventually the main base pulling resources would run out. 

The way I understand it WOLF now mitigates this by dealing with wolf resources which are consistent? So once WOLF has registered materials being fed into it, the available pool updates and a base elsewhere can make use of that pool and the values wont matter as it will always be consistent? IE 5 units of water available forever ((or something of the like)) and you only need to go back to the extracting infrastructure when adding new industry so it can update its wolf pool? I think I got that correct? 

Close.  The only diff being WOLF has no physical infrastructure.  Once infrastructure is added to WOLF it ceases being a vessel, and it's effect is visible from the WOLF UI.

 

Link to comment
Share on other sites

The interface for configuring WOLF modules in the VAB was confusing me so much that I gave up several times. Using the fabricator module as an example, I was working on configuring things to produce material kits as suggested by the WOLF intro I was reading. Looked to me like "machinery => material kits" was talking about converting machinery to material kits, so then I went looking for where to get machinery. I spent a long time fruitlessly trying to get a chain of conversions that was going to work. Gave up and played something else (CIV V) for a while. When I came back I eventually got closer by guessing that my interpretation of the => was backwards and that instead I should start with "material kits => specialized parts" and interpret that as converting specialized parts to material kits. I still couldn't put together anything workable from that interpretation of the =>. Gave up again. When I finally came back I ended up just ignoring the "=> specialized parts" part. Indeed cycling through the various recipes for material kits didn't actually seem to make any difference to what showed up in the WOLF planner. Relying only on the planner and ignoring the various recipes seemed to be the trick. Though that worked, it left me puzzled as to what the various recipes had to do with anything and what the => was supposed to mean.

Link to comment
Share on other sites

1 hour ago, rmaine said:

The interface for configuring WOLF modules in the VAB was confusing me so much that I gave up several times. Using the fabricator module as an example, I was working on configuring things to produce material kits as suggested by the WOLF intro I was reading. Looked to me like "machinery => material kits" was talking about converting machinery to material kits, so then I went looking for where to get machinery. I spent a long time fruitlessly trying to get a chain of conversions that was going to work. Gave up and played something else (CIV V) for a while. When I came back I eventually got closer by guessing that my interpretation of the => was backwards and that instead I should start with "material kits => specialized parts" and interpret that as converting specialized parts to material kits. I still couldn't put together anything workable from that interpretation of the =>. Gave up again. When I finally came back I ended up just ignoring the "=> specialized parts" part. Indeed cycling through the various recipes for material kits didn't actually seem to make any difference to what showed up in the WOLF planner. Relying only on the planner and ignoring the various recipes seemed to be the trick. Though that worked, it left me puzzled as to what the various recipes had to do with anything and what the => was supposed to mean.

It's basically the same as any MKS/USI converter - it's confirming you want to swap from the current recipe to the new one.  

For example, here's a hopper that is currently set to receive dirt (the default).  As I scroll through Next/Prev Manufactured Good, it will change from Dirt=>Something else.  When I find the one I like (in this case, Gypsum) I can confirm by clicking on the Dirt=>Gypsum button that this is in fact what I want to swap the converter to.  

image.png

My screen would now look like this:

image.png

And a launch, like this:

image.png

So in short, cycle through recipes, find the one you like, and swap it in.  Note that some ports support multiple bays so rinse and repeat for each of the bays (they can be the same or different recipes).

Link to comment
Share on other sites

19 minutes ago, The Minmus Derp said:

I have a question that's probably ridiculously late. Why did you drop support for the cool Extraplanetary Launchpads models and make everyone use Ground Construction?

Back at the time @RoverDude and @allista were interested in working together to more tightly integrate the two mods together, while EL wasn't opposed to integration but had no desire to actually work together on tighter integration.

Link to comment
Share on other sites

22 minutes ago, The Minmus Derp said:

I have a question that's probably ridiculously late. Why did you drop support for the cool Extraplanetary Launchpads models and make everyone use Ground Construction?

You're free to use EL - it comes with it's own models.    Or use GC, it's switching from bundled to supported.  Or wait a bit because something else may or may not be happening slowly in the background....

Link to comment
Share on other sites

23 minutes ago, RoverDude said:

It's basically the same as any MKS/USI converter - it's confirming you want to swap from the current recipe to the new one.  

For example, here's a hopper that is currently set to receive dirt (the default).  As I scroll through Next/Prev Manufactured Good, it will change from Dirt=>Something else.  When I find the one I like (in this case, Gypsum) I can confirm by clicking on the Dirt=>Gypsum button that this is in fact what I want to swap the converter to.  

image.png

My screen would now look like this:

image.png

And a launch, like this:

image.png

So in short, cycle through recipes, find the one you like, and swap it in.  Note that some ports support multiple bays so rinse and repeat for each of the bays (they can be the same or different recipes).

Ok. I never would have guessed that. To me it would be a lot clearer without the confirmation step. The next and previous recipe buttons would just change the config without needing an extra button. The extra button and its => notation is what confused it for me. Just showing the current recipe and having buttons for next and previous would then have been obvious. Oh well. Now I understand how to do it anyway, even if I wonder why it's that way.

Link to comment
Share on other sites

Also - one of those heads up things.  The next major release is going to see complete deprecation of KIS/KAS from the USI constellation.  We're moving 100% to the stock system.  Been playing with it (and making a new Packrat rover along the way), and it's been really nice to work with (pic related - ignore the backwards decoupler...)

image.png

Already have a new Konstruction bit added in that will allow working with much larger objects (so you can assemble MKS Ranger bases in-situ), and other stuff in the works to leverage this.

Just now, rmaine said:

Ok. I never would have guessed that. To me it would be a lot clearer without the confirmation step. The next and previous recipe buttons would just change the config without needing an extra button. The extra button and its => notation is what confused it for me. Just showing the current recipe and having buttons for next and previous would then have been obvious. Oh well. Now I understand how to do it anyway, even if I wonder why it's that way.

A multitude of technical reasons :)

Link to comment
Share on other sites

1 minute ago, rmaine said:

Ok. I never would have guessed that. To me it would be a lot clearer without the confirmation step. The next and previous recipe buttons would just change the config without needing an extra button. The extra button and its => notation is what confused it for me. Just showing the current recipe and having buttons for next and previous would then have been obvious. Oh well. Now I understand how to do it anyway, even if I wonder why it's that way.

A big reason it is that way (And I agree it isn't necessarily intuitive) has to do with many parts where you can essentially swap for "free" in the VAB but have some sort of cost (material kits etc) to change in the field.  For example drills can be set in the VAB for what resources they will collect, but if you want to change that in the field you will need stuff to make the switch.  So you need some way to pick what you want and then confirm the switch, and use up the necessary resources.

Link to comment
Share on other sites

1 minute ago, RoverDude said:

Also - one of those heads up things.  The next major release is going to see complete deprecation of KIS/KAS from the USI constellation.  We're moving 100% to the stock system.  Been playing with it (and making a new Packrat rover along the way), and it's been really nice to work with (pic related - ignore the backwards decoupler...)

image.png

Already have a new Konstruction bit added in that will allow working with much larger objects (so you can assemble MKS Ranger bases in-situ), and other stuff in the works to leverage this.

A multitude of technical reasons :)

Ok. I can buy the "multitude of technical reasons"; don't even need more details to understand that there might be such. How about keeping the confirmation button, but removing the "=>" bit so that it just confirms the selection without trying to tell me about what the next recipe might be. After all, it doesn't tell me what the previous one was (which wouldn't be obvious when its the first recipe I'm looking at.)

 

Link to comment
Share on other sites

3 minutes ago, RoverDude said:

Also - one of those heads up things.  The next major release is going to see complete deprecation of KIS/KAS from the USI constellation.  We're moving 100% to the stock system.  Been playing with it (and making a new Packrat rover along the way), and it's been really nice to work with (pic related - ignore the backwards decoupler...)

Cool.  Always have had a soft spot for the packrat, especially how it could be assembled in the field.

I assume KIS/KAS can still be used for other mods that will require it?

What about pipes?  I know most everything is detached these days, however there are some cases where some functionality still benefits from being physically attached.  Maybe this is moot now especially with WOLF etc.   I haven't had the free time yet to load up all the latest stuff.

Link to comment
Share on other sites

Just now, rmaine said:

Ok. I can buy the "multitude of technical reasons"; don't even need more details to understand that there might be such. How about keeping the confirmation button, but removing the "=>" bit so that it just confirms the selection without trying to tell me about what the next recipe might be. After all, it doesn't tell me what the previous one was (which wouldn't be obvious when its the first recipe I'm looking at.)

 

It's telling you what you are about to convert to, not the next recipe.  Sorry, no real interest in changing that GUI at this time. 

1 minute ago, goldenpsp said:

Cool.  Always have had a soft spot for the packrat, especially how it could be assembled in the field.

I assume KIS/KAS can still be used for other mods that will require it?

What about pipes?  I know most everything is detached these days, however there are some cases where some functionality still benefits from being physically attached.  Maybe this is moot now especially with WOLF etc.   I haven't had the free time yet to load up all the latest stuff.

I have no idea where KIS/KAS are going to land tbh, just removing one more dependency out of the chain.  Re the pipes, they will probably be moved to legacy at some point since connected bases really aren't a required thing between local logistics and WOLF.

Link to comment
Share on other sites

4 minutes ago, RoverDude said:

I have no idea where KIS/KAS are going to land tbh, just removing one more dependency out of the chain.  Re the pipes, they will probably be moved to legacy at some point since connected bases really aren't a required thing between local logistics and WOLF.

One less dependency is always a win.  

Link to comment
Share on other sites

4 hours ago, rmaine said:

The interface for configuring WOLF modules in the VAB was confusing me so much that I gave up several times. Using the fabricator module as an example, I was working on configuring things to produce material kits as suggested by the WOLF intro I was reading. Looked to me like "machinery => material kits" was talking about converting machinery to material kits

I'll make sure to add this in the walkthrough since I remember it being a pain for me to learn the hard way as well :D

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...