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

[RoverDude]

(Usual reminder that I take pull requests ;))

[DStaal]

Just now, RoverDude said:

(Usual reminder that I take pull requests ;))

I know, I know...

(And I've thought of doing one for three of the classes I've written - they're renames of the three base classes.  They don't get any of the colonization bonuses or extra skills - but are good for the early game and for more routine missions, or for missions where the special skills don't come into play.)

[sstabeler]

um, is there any reason why you can't just use the base classes?

 

edit- to clarify, for those missions.

Edited January 19, 2018 by sstabeler
clarification

[DStaal]

54 minutes ago, sstabeler said:

um, is there any reason why you can't just use the base classes?

 

edit- to clarify, for those missions.

Nope, not really.    The idea for these would be that - like the other MKS classes - they'd be cheaper than the full-powered main three classes.  So, especially early-game it'd be cheaper to have two 'Daredevils' than two pilots, for instance, and you'd have the same amount of control.  Of course, later in the game those Daredevils can't do much more than pilot a ship around, and you need to make sure they have habitation that you wouldn't need to worry about with a pilot.

I just find it interesting to balance into the game.

[jd284]

5 hours ago, LastStarDust said:

I don't remember if engineers have to be in the same vessel as the drills for them to receive the efficiency bonus. If you know, you would spare me half an hour to make experiments to find out. thank you

Yes, they have to be on the vessel. Doesn't have to be engineers though, miners also improve the drill efficiency.

[LastStarDust]

35 minutes ago, jd284 said:

Yes, they have to be on the vessel. Doesn't have to be engineers though, miners also improve the drill efficiency.

So if they are in a vessel in the same physical range (but not the same), is the bonus not received? So if I am at the boundary of 3 biomes to maximize resource availability and I set up 3 different mining rigs, would I theoretically need three kerbals, one on each of vessel?

[Araym]

 

12 hours ago, sstabeler said:

Because the colonist mod has pretty much been integrated- Kolonist is the "jack of all trades" MKS kerbal.

If you want to allow kerbals to become veterans, then Earn Your Stripes allows you to- just set it so that a kerbal gets veteran status after a single flight and you functionally have new veteran kerbals.

"Colonist", from the stand alone mod, are some sort of mash-up of the stock 3 professions...
"Kolonist" from MKS actually are some sort of "generic booster job" for MKS function only...
VERY DIFFERENT in functions.

I exposed the exact issues shared here to RoverDude attention to LinuxGuruGamer too, with I shared some thoughts:

... the exact same problem was that both here in MKS and in TRP-hire, the "job" selection was "hardcoded", as it was the original hiring mod.
This implies a series of issues, up to now:
1- both mod are mutually exclusive, as MKS let show ONLY the "harcoded" traits from MKS, and TRP-hire only the 3, standard, stock ones, but basically being the same.
2- both exclude the possibility to add "customized" traits and let them function in the hiring screen. That is not equal to not be possible to be used, but just a long process: hire a kerbal, with any trait available, then change the persistent file on the save to change the "job" of the new hired kerbal. Basically negating the sense to have a mod that make possible to select the job trait in game

10 hours ago, sstabeler said:

yes but:

1. Stock doesn't allow you to customise the kerbals you recruit- it gives you a list of applicants. That simplifies the code.

2. That's one of the reasons why you'd need to rewrite a surprising amount of code- it'd probably be simplest to start from scratch in coding the recruitment screen, which would take a lot of work. for MKS, it makes little sense. However, either a restructured TRP-Hire, or a new mod that was essentially a Community Kerbal Recruitment Pack, along the lines of the CRP or CTT that MKS could make itself compatible with fairly simply, could make far more sense.

Linux got the ideas and started to work on a way to make the hiring screen "open coded" to eventually accept "any" traits that the hiring mod could detect in game, being stock, custom or from any present and future mod. If this new iteration of the hiring mod by Linux will work, it could become a sort of "CustomizableComunityTraitHiring System" that could be available not only for MKS, but also for "any" modder that wants to add "new job" beside stock or, like here, MKS+stock only, coupled with the already available "ComunityTraitIcons" mod that add just only icons for the kerbals traits, mostly used, for now, only by "Portrait Stats" mod...

10 hours ago, RoverDude said:

(Usual reminder that I take pull requests ;))

If I could, I will more than happy to "code" the new ideas...
... sadly I'm just half capable to drawing, in fact I noticed the issues in both MKS and TRP-Hire just meanwhile I was creating a complete pack of suits for all the traits available on "ComunityTraitIcons" (so stock, yours, and from the "Colonist!" mod) but I was puzzled by the impossibility to spawn the "Colonist", if using your MKS, or even ALL the customized traits (yours included), if using TRP-hire.

Dunno if @linuxgurugamer will succede (as I shared some message with him) to make a version "open coded", but if it will work could be eventually be useful for anyone willing to create new traits and also use a nicer modded hiring screen than the stock one. Probably useful for your MKS mod too

 

Edited January 20, 2018 by Araym

[RoverDude]

I saw he did some updates, but bear in mind I also do a lot of additional customization related specifically to the MKS sub-traits that do not exist nor would necessarily be practical in TRP-Hire.  

[jd284]

16 hours ago, LastStarDust said:

So if they are in a vessel in the same physical range (but not the same), is the bonus not received? So if I am at the boundary of 3 biomes to maximize resource availability and I set up 3 different mining rigs, would I theoretically need three kerbals, one on each of vessel?

Yes.

However, if you have USI-LS the life support is shared between vessels, so you only need one setup for recyclers and habitats and such. But efficiency bonuses are per vessel only.

[Crimor]

For some reason tundra parts aren't patched by remotetech, copying the "MKS_*" MM patch and making it say "Tundra_*" instead fixes the local control.

[AlonzoTG]

I'm having a perfectly awful time with this mod... I'm not talking about how the mod has an appropriately designed KIS integration patch AND redundant KIS modules hard-coded into the ranger parts... I'm talking about how you have this bizarre relationship with Extraplanetary launchpads... On the one hand you seem to love the mod and integrate tightly with it... On the other hand you hate everything about EL and (thankfully not automatically anymore) trashing all it's parts... After shipping a K&K EL rig to the mun, I discover that you had found a way to trash the nice, simple, clear, comprehensible materials flow from raw materials, to refined materials, to manufactured parts, to usable hardware with your own incomprehensible garbage.. I mean I've been scouring wikis, reading manuals, and reading through input output lists for days and I can't figure out which end is up... I mean in real life you are constrained to about 86 or so stable elements and maybe two or three noteworthy isotopes of a handful of them. Here you have a tangled mess where things that shouldn't have anything to do with each other are convertable, You tangle up Input/output resources with equipment requirements, not part requirements but internal equipment requirements, with wear modeling. Short of spending all day making a spreadsheet and drawing it out on paper it's incomprehensible.  You have two or three different pathways for each resource, NOT THE ONE DEFINED IN THE UNMOLESTED EL MOD NOT THAT ONE!!! I mean you have enough clout these days to do anything any way you want... Why not just say EL is it's own thing, other mods use it, the player expects it to behave a certain way, I'm going to leave it alone and do my own thing... but NOOO... As it is, I'm getting ready to yank MKS from my game. Some of your other stuff is brilliant, like the collapsing docking ports, and I haven't found any ways it's molesting the rest of my modpack yet so that stays for now. Unfortunately, the game does not behave well when you yank parts and that mun colony with Val and crew is going to go poof if I don't do anything... I'm using a linux trick to share ships between saves so I used a rover I first flew in 2014 to help build the base... 

[DStaal]

48 minutes ago, AlonzoTG said:

I'm having a perfectly awful time with this mod... I'm not talking about how the mod has an appropriately designed KIS integration patch AND redundant KIS modules hard-coded into the ranger parts... I'm talking about how you have this bizarre relationship with Extraplanetary launchpads... On the one hand you seem to love the mod and integrate tightly with it... On the other hand you hate everything about EL and (thankfully not automatically anymore) trashing all it's parts... After shipping a K&K EL rig to the mun, I discover that you had found a way to trash the nice, simple, clear, comprehensible materials flow from raw materials, to refined materials, to manufactured parts, to usable hardware with your own incomprehensible garbage.. I mean I've been scouring wikis, reading manuals, and reading through input output lists for days and I can't figure out which end is up... I mean in real life you are constrained to about 86 or so stable elements and maybe two or three noteworthy isotopes of a handful of them. Here you have a tangled mess where things that shouldn't have anything to do with each other are convertable, You tangle up Input/output resources with equipment requirements, not part requirements but internal equipment requirements, with wear modeling. Short of spending all day making a spreadsheet and drawing it out on paper it's incomprehensible.  You have two or three different pathways for each resource, NOT THE ONE DEFINED IN THE UNMOLESTED EL MOD NOT THAT ONE!!! I mean you have enough clout these days to do anything any way you want... Why not just say EL is it's own thing, other mods use it, the player expects it to behave a certain way, I'm going to leave it alone and do my own thing... but NOOO... As it is, I'm getting ready to yank MKS from my game. Some of your other stuff is brilliant, like the collapsing docking ports, and I haven't found any ways it's molesting the rest of my modpack yet so that stays for now. Unfortunately, the game does not behave well when you yank parts and that mun colony with Val and crew is going to go poof if I don't do anything... I'm using a linux trick to share ships between saves so I used a rover I first flew in 2014 to help build the base... 

You know, you could be a bit polite about it.  I mean, there is a reason: It integrates the same resource chain as everything *else* MKS does.  So you don't have to be hauling around extra tanks and converters for one supply path to build things when the *other* way to build things uses the same supply path as inflating and repairing things.  You could also notice that MKS has been doing this for *years* and it's been a standard part of MKS for all that time.  The way it does it is even built into EL, and part of the official support - taniwha has even mentioned he's surprised more mods haven't made use of it.

Or you could take a bit of attention and notice that the patch to do this is written as a stand-alone patch, easily removed, and in fact is supporting PatchManager to make removal easier.

Remove this file, and be happy: GameData/UmbraSpaceIndustries/MKS/Patches/PatchManager/ActiveMMPatches/MKS_EL_Resources.cfg

[RoverDude]

16 hours ago, Crimor said:

For some reason tundra parts aren't patched by remotetech, copying the "MKS_*" MM patch and making it say "Tundra_*" instead fixes the local control.

Probably an out of date patch - a PR would be appreciated, or at least flag the issue on Github so it does not get lost in the shuffle

58 minutes ago, AlonzoTG said:

<incoherent ranting and babbling>

Honestly, I stopped reading about a third of the way in.  Go find another mod please.

Also, thanks @DStaal 

 

Edited January 23, 2018 by RoverDude

[Danilo Coelho]

Haters gonna hate. Keep the good work Roverdude!

[Araym]

On 20/1/2018 at 2:00 PM, RoverDude said:

I saw he did some updates, but bear in mind I also do a lot of additional customization related specifically to the MKS sub-traits that do not exist nor would necessarily be practical in TRP-Hire.  

In my ignorance on coding, I'm surelly not willing to seems like "someone above" that only goes for ranting.
I'm more for the costructive approach about integration of interesting features that does not exclude between themselves:
- I could guess that your "KolonyTool.dll" handles the hiring function, but that also you, in meantime, added in some function linked to the deep core of the "added professions" that are unique to your mod...
- TRP-hire is working only on the hiring part, obviously lacking of any added fuction by you...

... but both, for an user's point of view (at least on the Hiring Screen at KSC) they are conflicting, and up to now BOTH (TRP-hire up to now) did not allow any "extra trait" aside those hardcoded in the mod themselves.
The necessity of much of your hardcoded difference, I could suppose, are bound to the necessity on your side to handle A LOT of more traits than handled by the original KSI-hiring that make the root of both, plus any function you have found necessary to integrate, but now that the "hiring part" is expanded on TRP-hire to an "open code" that search for "any" traits in the game, could not be simpler for ALL leave the "hiring part" to a single, comunity driven base (let's say the TRP-hiring code), and let you focus only on a "plug-in dll" that goes only for the "extra" fuction that are not immediately connected to the hiring part but just used by your MKS to work as intended?

Basically it will avoid a series of issues that were common upon now, but someway corrected by the latest TRP-hire mod:
- allowing ANY modder to eventually create his own traits (whatever they then could do in game, bundled to stock-ish behaviours or, like yours, to "advanced fuctions" specified by an added plug-in), and enjoying the "modified" hiring scene: TRP-hire now allow it, but conflicts with your, hard coded, KolonyTool.dll as by now...
- you can ditch the mantaining of the hiring part only, just mantaining the plug-in in MKS to the level to have shared planetary resource, long range energy transmission and all the above multiple function it surelly has, meanwhile the root of the stock problem (ability to hyiring different traits than pilot, engineer and scientist) could be simplified by bounding TRP-hire, because differently by "someone ranting above" I really like the MKS idea of A LOT of professions (i'm in this days drawing a FULL set of suits based on kerbals' MKS professions beside the stock ones... pointless of doing so if I'm not on the "like" side about your mod) but in the meantime I found it now bottlenecking any other modder to do, in the future, the same with added/more professional traits for our kerbal...

Hoping that you can look at the above idea not because "you bound a bad hiring system" (or "mantained it wrong"), but as cheering for "keep up on YOUR interesting fuctionalities for MKS, but now without the burden to have adopted an (old) expanded hiring mod that in the latest mantained version has expanded the limits of hardcoded traits"

Hoping that you can look at this constructively and not as something likely above, and not looking at (amybe) weird englishe grammar error (that surelly there will be) as it's not my native language

[RoverDude]

Hey @Araym, more a case that I have some additional deep functionality and custom difficulty settings.  I've requested a PR for additional trait support (which I then need to peek at and see how it impacts the other settings), so it's not quite as cut and dry.  And of course the golden rule on MKS that I take no hard dependencies on repos where I am not a collaborator (burnt too many times on dependencies that failed to update in time...).

[Araym]

I'm not willing to analize your decision about "self-sustaining dependencies" (maintaining it on your own to not have fail collaborators... I found it someway "sane", inany case) but as (for the "hiring section" only) could you just start a discussion with @linuxgurugamerjust to keep, anyway, THAT "open to new trait hiring function" as a stand alone dll?

Or by forking it for future MKS update FROM the now open-coded for other custom traits hiring by TRP-hire (added ability to hire not only "badass" kerbals, but also new "orange-veterans" ones; the name of the future hired kerbal - changeable just by exiting and re-entering the hiring screen, if not of user's liking; the display of the icon associated at the trait, mostly from PortraitStats or any mod that is interfaced to it; the NEW ability -root of my questioning here- to be open to "any" trait found in game), rather than still using the "outdated, hardcoded" original base from KSI-hire???

As staded, being a "dumbass" on coding, I could just hope for you and eventually @linuxgurugamer to find a way to "integrate" in a singular, common, hiring system on the behalf of everyone, rather than two almost identical, but conflicting ones (parted both from the same KSI-hire root)

On the actual side of an user, I have not a big problem: even conflicting, I could cope with a clustered hiring screen.

I could hire any Kerbal, custom it (name, stats, bein badass and/or veteran), assign to him a "random" profession, THEN cfg-edit the peristence file of that kerbal to your MKS traits (or the way around, usin YOUR hiring system, than add "any other" job I could have added in my game), but basically it defies the purpose of a  GUI, in game, that could theoretically do already that...

Edited January 23, 2018 by Araym

[maja]

Hi @RoverDude  I can't find Karbonite thread, only Karbonite+, so I'm writing here. Just heads up, that I checked develop branch of the Karbonite on the github and files from  this issue #255  are still there. It's messing with a tech tree and saves, because the same names of parts leads to duplications (a lot of them) in the tech tree. Based on this issue @JadeOfMaar knows probably more about which file must stay and which is marked for deletion.

Edited January 24, 2018 by maja

[Puckpuck]

Hi, 

Been using this mod for a while now and totally love it! Has extended my gameplay immensely, I would have probably stopped playing along time ago if it wasn't for mks! 

Just wondering if someone could give a brief explanation of how the new orbital logistics works? Does it requires specialised parts separate from the local/planetary logistics parts? 

[Urses]

33 minutes ago, Puckpuck said:

Just wondering if someone could give a brief explanation of how the new orbital logistics works? Does it requires specialised parts separate from the local/planetary logistics parts? 

You only need a logistic module on both conterparts and containers for ressources you will trade.

Than you can go to OL and send the ressources for cash and time.

Edited January 24, 2018 by Urses

[Puckpuck]

8 minutes ago, Urses said:

You only need a logistic module on both conterparts and containers for ressources you will trade.

Than you can go to OL and send the ressources for cash and time.

Thanks, Sounds nice and simple! So you don't need any kind of command module nearby like you do for extending the range of local logistics? Do you need pilots/quartermaster in the logistics modules at both ends? 

[Urses]

2 hours ago, Puckpuck said:

Thanks, Sounds nice and simple! So you don't need any kind of command module nearby like you do for extending the range of local logistics? Do you need pilots/quartermaster in the logistics modules at both ends? 

As i tried the constelation prebuild, a manned module was not needed for OL, but i think in end state you have to mann the logistics modules. 

[voicey99]

6 minutes ago, Urses said:

As i tried the constelation prebuild, a manned module was not needed for OL, but i think in end state you have to mann the logistics modules. 

Note that I believe you have to visit all your bases for it to update and make them appear on the OL list.

[Kaa253]

16 hours ago, Puckpuck said:

Thanks, Sounds nice and simple!

It is and I support it to stay simple or at least have an option to keep it simple going forwards.
My main problem with MKS is it is really really enjoyable, indispensable and ...

17 hours ago, Puckpuck said:

extended my gameplay immensely

... but unfortunately leads to a large number of parts within physics range which bring my game time clock down to a slow motion crawl.

[Puckpuck]

1 hour ago, Kaa253 said:

..... but unfortunately leads to a large number of parts within physics range which bring my game time clock down to a slow motion crawl.

I can relate to this. The first time I played through with MKS I built an enormous 'do everything' base which absolutely killed my frame rate everytime I went near it to the point of making it almost unplayable...

However since getting the hang of how planetry logistics work and utilising colony supplies (which I'd pretty much ignored before) I now tend to have multiple small, specialised bases spread out. Seems to be working quite well so far! Transport between the bases for maintenance/repair can be a bit annoying and time consuming but I think that's more down to my lack of ability at building good, efficient transports!