voicey99

Oops, meant perma tourist bug. It's been cropping up a couple of times lately so it's still around.

Does this include a fix for the permanent hab bug? Editing the persistence is getting irritating. (P.S. I'll be away for a week)

I tested out your change, and it works just fine. The Big Bad Evil Dev should merge it in a day or two. I think the reason it was showing up as an agri module is because I think the base tundra model might use the agri part as a default skin and the agri sticker as a base sticker, in which case it might need to be specified before it can be replaced with another side label.

It's easy-ish© . Go on GH and click the "fork" button at the top right of the page-this will clone the repository to your account. Now go into your forked repo and click through the files until you find Tundra_Workshop250.cfg. Now click edit (at the top right of the box containing the config) and make the changes you made to your version of the cfg file (or delete the lot and copypaste your modified cfg in), and click "commit changes" at the bottom (adding optional title and description). Then, go into the main MKS repo and open a new pull request-after clicking "compare across forks", select your fork ("[YOURNAME]/MKS") from the "head fork" dropdown, "BobPalmer/MKS" from the "base fork" and "DEVELOP" from the "base". Now it will create a PR to add any changes ("commits") you've made in your fork into the main dev repo. RD will review your PR before he adds it so if you made a mistake it won't break anything.

Make a PR for that on GitHub to make it easier for RD if you want it to be speedily added.

Actually, I found why the dusts weren't working-they only show up on bodies with atmospheres (why non-atmospheric bodies have dust colours defined I don't know). As such, my extended config works perfectly-if anyone wants to use it, it's here.

Well, it's not funny. It broke everything, and cost me several hours of progress from having to revert to a backup. The change was most certainly not cosmetic, as every single mod that relied on planet names broke and brought the rest of the save down with it.

Run into a major bug with OPM-all Kerbol-orbiting bodies (including Kerbol itself, but not Kerbin) get renamed to numerical IDs on installing OPM which, of course, breaks a lot of stuff as everything that relies on them no longer has a name to refer to-for example, my Strategia contract to send probes to Eve failed because Eve has been renamed to "58979". Moho is now "92653", Duna is "32384", Dres is "62643", Jool is "38327", Sarnus is "95028", Urlum is "84197", Neidon is "16939" and Plock is unaffected presumably since it orbits the SB barycenter. I even hard-reinstalled KSP and all mods in GameData, to no avail. Here's the logs.

I already have the cfg extension written out with all the values in decimal RGB-I'll test it out as soon as I get a gamebreaking planet-renaming bug fixed as last time I tried it it didn't work, though that was before it got updated.

Loading up KSP one time, and on load several mods start spewing errors at me from all angles. Strategia announces that all of the body programs are now invalid due to the planets no longer existing. Scatterer and CustomAsteroids are throwing NREs like confetti. My previously 96% reputation is now -284. And then KSP crashes and takes my entire PC down with it. On looking into the logs and the trackstation, all bodies (including Kerbol) have been renamed to numbers-for example, Jool is now "38327"-what just happened? My modlist is contained at the start of the logs (16:51:56.133, under "folders and files in GameData"), which are from another (later, but with all the same issues) instance that was closed before it could crash, since I have no desire to sit around for 20 minutes to wait for my desktop to become responsive again.

How would you do that? I tried doing that for OPM bodies, but it didn't work (neither adding them into the main cfg or adding a separate cfg to the main OPM folder). Does it require a MM patch (and, if so, what would it look like)?

Yes it is. Just take a look at what I was having to deal with (I would upload that to imgur but I can't get past the damn captcha). Even if dancing bases are cool.

Considering your base is only connected by flexotubes, it would probably be easier to disassemble it and haul it in two pieces with the skycrane (with a klaw or KAS) to the near side of the Mun (assuming you are producing fuel in situ).

There's a Ranger Pioneer module now? Anyway, are you sure your base isn't in the comm shadow of whatever body its on at the time of training? As for "Construction", its just a hidden resource shipped along with inflatable parts to reduce their mass until you expend an equivalent amount of materialkits to expand them (which I assume removes the Construction resource and its negative mass contribution).

The main Karbonite thread got lost in the Great Forums Derp of January 2017, RD still hasn't got round to making a new one (or the general USI thread, as he said he would a month or two back) as the MKS thread has become the de facto Karbonite thread by now. Concerning documentation, there isn't really an awful lot to say about Karbonite, You mine Karbonite, You burn Ka in engines, generators etc. or convert it into other stuff. End of, really.

I'm looking to add CollisionFX biome dust FX to the various bodies from OPM and I have all* the decRGB values for the colouring in this cfg file, but I'm not sure how to actually apply them to OPM. Does this require an MM patch and, if so, how would this be laid out? *Except Wal and Polta, their biomes are not currently functional.

They don't have the maintenance module, meaning you can't do that. And adding it would be of limited use, since it would also pull from the ones you had already loaded up.

But it is more of a pain to transport (unless you cheese it by using a CCd fuel tank). I'm also not sure how you're supposed to load it into the ship.

I haven't visited it in a year or two, and everything seems good. I do send in a shuttle to bring a shipment of REX back home and do a crew rotation once in a while, but that's it-I'm currently focused on the manned Duna mission and the various probes en route to the outer planets (the only time I have ever considered using ion engines, since its either take decades to get there or put your foot down and quarter it at the cost of a couple of KMS of DV, and only ions have that kind of expendable DV).

Good thing my base largely runs itself these days, since I try to avoid it bc of the lag. Still, as long as everything else stays above 20fps (which it does), being able to use planet packs is still worth the lag (for me, anyway).

I get 25fps in the KSC screen (and 100fps in the TS) with 16gb mem, a decent gfx card and a pretty good processor-what should it be w/o Kopernicus (since I've kinda forgotten what it is not to use a planet pack)?

I do recall seeing somewhere that Kopernicus is more of a hack than anything, and the options for optimisation are probably quite limited.

Actually, since i use OPM I could try removing that (after backing up ofc) and see if the framerate on Boogie Base nudges above 3-4fps. I'm not going to remove it, since the lag is a worthy price for access to the OPM system, but it would be interesting to see if that's the root cause.

I don't think ether are better, both single structures and scattered compounds make my PC run like a toaster. My best guess would be local logistics and scavenging, since (for me) the lag wall only really kicks in <150m away from the base (which also happens to be the scavenging range).

Looks like there's still a gremlin to work out in the OSE compat, then. Log it on the git.