Merkov

Best tip I can think of is to just start a sandbox game with all of the MKS parts and make a few bases beside the KSC to get a feel for what you need and what does what. It's really unfortunate when you get a piece of a base onto Minmus only to realize that you forgot to put a power coupler on it to receive power from your nearby reactor and now you need to send another mission to remedy that. It's even more unfortunate if it's a Duna mission. Another thing I'm really good at forgetting is to add machinery to parts that need it. Eventually, you can manufacture it on-site, but at the beginning you have to either include it in your parts (which adds a lot of mass/cost) or ship it up separately (still adds a lot of mass and cost, but might be easier to do/you can ship up a bunch of machinery for multiple vessels). The point is, once you do the wrong things in a sandbox game placing things next to the KSC, you'll have a better grasp of how to do the right things in your colonization game. Of course, in KSP, failure is always an option.

Sorry, I didn't meant change Pathfinder's stuff, I meant change KPBS stuff, though I see how that would be problematic, too. I can never wrap my head around how WBI's systems work (I'm sure I just need to sit down and play with it, but I haven't had the time), so let me see if I understand this: It sounds like Pathfinder basically supports USI-LS, but not really MKS. Pathfinder then modifies KPBS to support Pathfinder, and by extension, USI-LS (but not really MKS). Is that about right? I know that Pathfinder has its own part/resource switching interface that is pretty slick, so we definitely don't want to interfere with that (I'm thinking of the Buckboards used by Buffalo/Pathfinder, which I always think of as WBI's Kontainers). So, for example, if Pathfinder adds that switching interface to a resource tank, would your plan then be to clone that resource tank, remove the WBI interface, and add our MKS textures/resources, resulting in there being two tanks, a WBI one and an MKS one? The dangerous rabbit hole I see in front of us is the point where suddenly we're also trying to make a WBI-MKS compatibility pack just to resolve this. Which, don't get me wrong, would be an exceptionally thorough way of solving this, but that's a whole other ball game. Off topic, but back in the UKS 0.44 days, I started trying to use Pathfinder's code switching system (I think they're called "Game Modes"?) to see if I could figure out how to basically turn Pathfinder into a UKS parts pack. That is, remove the WBI modules from parts, add UKS ones. At the time, I could barely even write a MM patch, so it didn't go very well...

So if we're going to balance against the WBI Pathfinder USI-LS values (that was quite the mouthful), does that mean we would have our KPBS USI-LS patches disable themselves when both Pathfinder and USI-LS are present, and we would try to balance the MKS specific (but not USI-LS) stuff against the values that WBI provides? Alternatively, if Pathfinder's support for full MKS is lacking, is it worth seeing if Angel 125 is able to set up his USI-LS support so that it defers to ours when Pathfinder, MKS, USI-LS, AND KPBS are all installed together?

Not a lot of computer skills here, I'm afraid, but I am glad to help where I can. My schedule has me going long stretches of time with no free time followed by long stretches of lots of free time, so I'll try to put the latter to good use. I do think, if this takes off, that we should consider taking over USI-LS integration. Balancing it with any MKS patches is vital, and it sounds like Nils is getting tired of it anyway. I'm guessing also that the number of people running USI-LS and KPBS but not MKS is probably dwarfed by those running all three. With regards to you looking for textures: are you thinking of trying to recreate kontainers in the KPBS container style? I definitely like that idea.

Cool. @DStaal @tsaven @PolecatEZ and anybody else who is interested: does anybody care who opens the thread? Also, I'm assuming Add-On Discussions is the right place for it...?

With regards to mass requirements, it is true that part mass isn't really "balanced" between all KPBS and MKS parts. Just talking without thinking here, but maybe that would mean that any configs we can come up with should also look at whether the mass of any parts ought to change. MKS users are pretty familiar with working with massive parts (either by using insane vessels to deliver them, or building them in-situ) so if KPBS parts became more massive for those users, that might not be a bad thing. That opens up a whole new can of worms which brings me to my next thought: should we start a KPBS-MKS interop thread to keep this one cleaner while those of us who use both mods come up with what we would want any configs to look like? My thinking again is that having a separate thread in say Add-On Discussions or something would let Nils retake control of this thread (sorry...) and also keep the MKS discussions to those of us who use MKS. For that matter, if Nils is okay with it (and doesn't really care what his MKS configs look like) he doesn't even have to be that active in it. Lastly, I would like to thank you Nils for offering to keep any configs we come up with in KPBS itself. I think that's a more user-friendly approach than offering the configs as a separate download.

Oops. Right. I meant SCANsat.

I haven't played a lot with the KPBS tubes, but I seem to recall that they look very similar to the MKS ones. Unless sizes are grossly off, I would imagine something like that would look (and work) great. Incidentally, the very first mod interoperability patch I ever downloaded was one of your UKS-KPBS patches.

That all makes perfect sense, no need to apologise. Honestly, KPBS has enough parts that I think MM patches can make MKS/USI-LS play very nicely with existing KPBS parts, and where there are gaps, we CAN just use MKS parts. Also, I'm sure there are a few of us out here who can help with maintaining those MM patches as MKS evolves. If you don't particularly like MKS, but there are those of us out here who like both KPBS and MKS, then perhaps it makes the most sense for us users to debate which parts need which functions, submit them to you, and then you can use your time to work on the things that you do enjoy. Maybe it's not my place to say this, but I don't think anyone benefits when you're trying to work on things that you aren't enjoying.

Really?

Really? Hmm... I'm not seeing that. Time to hunt for updates, I guess.

Honestly, if Nils were to start making custom parts, I would just as soon want it to be something that meshes nicely with the the MKS multihub. That way, you could hook whatever MKS part you wanted on to whatever KPBS setup you wanted. I mean, this is already possible with KAS ports (or their MKS & KPBS look-alikes) but the KPBS crowd tend to appreciate aesthetics . Although, now that you mention future KPBS-style containers (or should I say kontainers) I could see that being interesting... I do agree with the suggestion earlier that MKSModule is added to most if not all KPBS parts, since this would mean that kerbals inside vessels that contain only KPBS parts and no MKS parts would still count towards the kolonization bonuses provided by MKS.

Oh! That makes sense. Yeah, unfortunately the intention is that altitude is a limitation of the magnetometer, so you'll have to use the narrow band scanner. Incidentally, is it one of the DMagic contracts that's asking you to scan Kerbin for Ore? The reason I'm asking is because I'm pretty sure the DMagic one should wait until you have unlocked the Narrow Band scanner before appearing.

Basically this. Although, I don't think most people have Kerbin in mind when thinking of places from which to mine Ore...

Quick question for you guys: Is there any feedback that I'm not seeing when repainting flat kontainers? Full sized kontainers have different textures which make it easy to tell what you've repainted them to, but flat kontainers only have the one texture. Is there any way to see what you've repainted one to aside from swapping back to the vessel, right click, repeat?

If I recall correctly, Kerbal Academy disables (or used to disable) the stock rescue contracts. You should be able to see if they are enabled or not through the difficulty settings -> Contracts window. If they are disabled, a simple check in the box should re-enable them again. Seems like most of your other issues are also related to Kerbal Academy, so it may be prudent to ask in that thread so the contract pack's author can be alerted.

Hey, I have a quick question: how does Strategia decide if a planet is a gas giant or rocky planet for the purposes of the celestial body strategies? The reason I'm asking is because I have @The White Guardian's fantastic Planet Cyran pack installed, seen here: Strategia very helpfully offered me strategies to land probes in three biomes and plant a flag there. The problem is that Cyran is a gas giant. It has many moons, so it would be perfect for a Cyran IX program (nine moons, unless I'm just awful at counting, which IS possible...). I know that the OPM planets are all recognized as gas giants, so I know it's possible, I just don't know how that's done . Also, I have a bit of a suggestion: is it possible for the Eve and Duna probes/program to boost the funds from milestone gains of their respective moons? Full disclosure, I haven't actually completed either of these yet, so I'm just going off what the strategy says in the Admin building, but from the descriptions it looks like taking either program/probe program boosts gains from Eve/Duna, but lowers the gains from all other celestial bodies, which I take it includes their respective moons? It just seems odd that you would take a strategy that encourages you to send several probes to Duna, but heaven forbid any of them approach Ike. Depending on how you want to balance it, I would suggest either including the moons in the milestone gain boosts for their parent bodies (sort of like with the Jool strategies), or at least exempting them from the milestone penalties. Is this something that can be done? Regardless, I am loving the strategies. They are simply brilliant.

I have a suspicion that it is related to velocity at the time of the unloading. I actually failed to recreate this earlier even though I jettisoned my stage travelling at about the same speed as in my example above. The difference was that my vessel didn't make it to orbit, so it fell back into the atmosphere and the discarded stage stayed loaded longer. I'm guessing it slowed down in the atmosphere, because it recovered just fine.

Okay, I took a fresh download of KSP 1.2.2 plus the latest version of StageRecovery (plus MM and AVC) and made a small vessel that goes to LKO and back. Two boosters are jettisoned at around 12km up and are recovered fine (well, one crashed into the other, but StageRecovery worked) the next stage was jettisoned at the border between the atmosphere and space while the vessel was on a suborbital trajectory (AP of about 80 km) and StageRecovery reports that it was not recovered because it was travelling at ~2140 m/s. It shows there were 3 parachutes on board, but it doesn't look like it tried to use them. The message also does not mention the stage burning up. When I came back down, I jettisoned another stage on a suborbital trajectory. This one is not recovered, but SR reports that it was travelling at ~2250 m/s and it DID burn up. Not a huge issue, since it's easy enough for me to simply assume the second stage might have burned up, but I found it odd that SR doesn't say the second stage burned up, but the third stage did. Again, this is using stock parachutes, not RealChutes, so I can't say if this is related to @Loren Pechtel's issue, but it sounds similar. Here is a link to a Google Drive folder with both the KSP.log and output_log.txt. Let me know if there's anything else I can provide for you.

This sounds amazing.

I've actually had this happen a few times with the latest version of StageRecovery with stock parachute modules. It seems like if the debris is moving faster than 2000 m/s when it's deleted, the parachutes aren't taken into account. I'll try to get a stock + StageRecovery-only log for you tonight. I was using Necrobones' LET parachutes before, but I don't think that's the issue (since StageRecovery used them to recover other debris on the same launch).

Well, I'm glad it worked this time around, though I'm now really curious as to what happened the first time... Active strategies shouldn't be an issue, but I wonder if it's possible if maxing out your total available contracts before selecting the strategy would prevent that contract from appearing in the Mission Control centre. I thought I did this once and the game just let me go over my limit, but I could be remembering incorrectly. I think @nightingale has Strategia set up so that you have one more strategy "slot" than you see. This is done so that you can accept an upgraded version of a current strategy without having to cancel the lower level one. You go over your apparent maximum temporarily while strategia lets you accept the new strategy, then immediately cancels the lower tier one. I thought that there was a similar mechanic used with the special contract generated by celestial body programs, too. Would you mind having a quick read of the last few posts between eddiew and myself? Since you mentioned that you had the same problem, I'm curious as to what you saw when you tried it (i.e., did you have a strategia contract in the Mission Control centre, was the strategy still active even though you got the message saying it was unavailable, etc.). Also, have you tried any other celestial body-based strategies since?

Huh. That would definitely NOT be intended. The strategy should cease to be active (and remain unavailable) once you plant a flag on the target body. Out of curiosity, do you see an active contract in Mission Control from Strategia telling you to plant a flag? Picking the strategy should have automatically created and accepted a "plant a flag" contract with the same rewards and penalties as the strategy. Planting the flag should complete this contract, which then completes the strategy. If that contract is missing, then something's gone wrong.

I actually thought that the mini hab was a replacement for the emergency shelter, and that the latter was going to be deprecated. I'm not sure WHY I thought that, since nobody said that would be the case, but somehow that's what I'd convinced myself.

Not sure if this helps, but I remember when MKS was updated to version 0.44 (or whatever it was...) I was doing a lot of wiki updates, and I created an "obsolete info" page where I basically copied everything I was removing from other pages. At the time, I don't recall seeing any previous archives/pages for obsolete info. I mainly kept the old stuff because I didn't think I should be deciding to just delete things outright. Point is, I'm pretty sure that prior to UKS 0.44 the only wiki pages were the ones with the most up to date info (even if that info was out of date). Unless RoverDude says otherwise, I always thought that he sort of left the wiki to the users to manage, so I would guess that we in this thread can probably make the call to remove the zapped stuff. Personally, my vote would be to get rid of them. I don't think it's feasible to keep wikis for past versions of MKS that are both comprehensive and coherent, and as such I don't think there is any value in keeping fragments of past features.