LameLefty

This past week, having completed my current 0.90 Tech Tree and just sort of messing around, I started a new Sandbox save and installed RoverDude's suite of Umbra Space Industries mods. Yesterday and today I've been building a big surface base on Minmus.

Rebelgamer is correct. KSP for OS X is only 32-bit. Use the x86 version of the mod.

Read up 3 posts from yours (#36).

I love this mod! Here's what I put together for my own game style ... I took the suits from Pentence's Biosuits pack (loved the overall design) but I wanted something more colorful, like the "spacesuits" you'd see in old 1950's golden- and silver-age paperback and pulp covers. So I did a simple colorize in a bunch of primary colors. After experimenting and seeing how they looked on the Mun and Minmus, I decided on these three. They are assigned by crew class: Gold for Pilots, red for Engineers, blue for Scientists, and a gold visor added by tweaking the reflectivity coefficients in the @defaults.cfg file.

I have 35 files in my /TextureReplacer/Heads folder, gathered from a couple different packs. All told, those total 27.5 megabytes.

It doesn't matter - with or without mods at startup isn't what I'm talking about. I'm talking about the total usage of the KSP process on my system after it's been running for a couple hours. It formerly maxed out just under 3.5 GB and could be stable there for hours until a stray memory leak caused a crash.That has changed with 0.90 for me.

I don't think that makes sense, actually. The KSP process itself used to consume 3.4-ish gigabytes easily, sometimes for an extended period, before crashing. Now when I have crashes, the process is a generally frozen and using no more than 2.9 gigabytes.

For my on-the-record guess, I'm going with either "Valentina" for stock female Kerbals, or "Vesuvius" for particle-effect procedural volcanoes on Kerbin, Moho, and maybe one or more Joolian moons.

What's worse is that as of 0.90, KSP is actually more sensitive to memory and crashes much earlier for me than it used to. In prior versions back to 0.19, I could skate up to that 3.4 - 3.5 gigabyte edge, and sometimes right along side of it for hours, before crashing. With 0.90, I've yet to see my KSP session get beyond 2.95 gigabytes before a crash-to-desktop. This is on OS X 10.10, just as a reference point.

Um, no. You've seen some animations and stuff for public consumption. Real work is done with dedicated simulation software like MATLAB and, for spacecraft operations, control and display, STK (Satellite Toolkit). These are aerospace-industry standard tools that have been developed over decades. Don't get me wrong - KSP is fantastic for armchair astronauts and what Sarbian and a handful of others have done with MechJeb is nothing short of amazing. But it's not the real-world.

Serbian's post, that you quoted above in post #8902, tells you exactly how to put one satellite 120º behind another. Do that twice and you'll have three satellites each 120º apart around Kerbin.

What are you actually trying to accomplish? A constellation of satellites in the same orbital plane? Orbital rendezvous?

You misspelled "Hohmann Transfer" ... No, not really. As described above, a resonant orbit is simply one that has an orbital period that is a ratio of another. A Hohmann transfer is meant to get your craft from its current orbit to intercept a target in a different orbit in the most efficient manner.

Or you could just ignore my repeated suggestion to simply make a specific exclusion of the full file path to exclude.

Again, just create a .cfg for RealChutes with the explicit folder structure to exclude. It doesn't matter where the icons are, so long as you define it.

My, my ... so polite you are! Actually, the PITA part isn't where you put the .cfg files (like MM .cfg files, they'll work anywhere in /GameData) - the PITA part is having to do it in the first place, since there's no consistency where mods store each icon file. Since you've already got to dive into each mod's folder structure to determine where the assets are that you want to exclude, I've personally found it easier just to create my little file right there while I'm looking at the folder path to exclude. YMMV.

Took me a little while to figure out again (thanks to the help of a couple polite posters), but you need to stick little .cfg files listing the exclusions into the folders where the Toolbar icons are kept. It's not hard, but it's a PITA to do for many different mods.

I play KSP on an early '11 MacBook Pro. My dedicated GPU has only 256MB of VRAM and I can play just fine with half-res textures and 4X anti-aliasing. Now, to be sure, I don't fly 350-part battleships and build giant bases, but it's perfectly playable, even with fun stuff like TextureReplacer's new reflective visors on EVA. In the past I've played with clouds and stuff from EnvironmentalVisual Enhancements, though I'm not doing that currently. Yeah, I'm sure it'd look a lot better with a newer system but it works, looks just fine, and I have fun. That's enough for me at the moment.

No matter what you pick it'll be a compromise that won't get you 100% coverage of all bodies, for all instruments. If you WANT that, you're simply going to have to vary your orbit from time to time to get the missed areas. Kind of like in the real world.

I have an FNG named Merdock. That makes me laugh. (cue A-Team theme music)

Ditto. In the interest of role-playing my own game, and in attempting to reconcile my personal aesthetics of "fun" and "authenticity," I try to design my lifters to drop the first stage will still on a negative-perigee trajectory, or one with a perigee of under about 10 km. That said, the first thing I do with a new save is turn the debris slider down to 50 ... My game lags when it's tracking too many spent stages, stack separators and dead early probes/satellites. Also, I just noticed the other day after a KSP crash-to-desktop that my Tracking Station now shows 0 debris being tracked. I don't remember setting that to zero. Must be a new glitch in my save.

The sensors all have a different FOV (field of view). That is, they see a different width of the ground beneath them. Plus each body you're scanning is a different size. For those reasons, you can't use the same orbital height for different instruments and different planets/moons and expect to get the same coverage for all the instruments. Vary your orbital height. If you've got the poles covered well already, change your orbital inclination to 70º - 85º and get better coverage over the mid-latitudes. Etc. There is no "one size fits all" solution to orbital mapping coverage for every instrument and every planetary body/moon.

I think there are some mods that give navigational info on EVA.

This is actually an interesting question. I'm at the point in my game where I previously would start building bases and building long-term resource extraction vessels and refineries to orbit moons like Minmus, Gilly and Ike ... However, now with Career Mode considerations, I have to worry about money to pay for all this. So far I'm not in danger of going broke (still have over 5M in Funds in the bank) but with each large craft I launch costing upwards of 300K, I make a serious dent with the opening of each new planetary launch window. I hate having to take penny-ante satellite launch missions, or absurdities like "Build a new 11-kerbal station into a newly-discovered Class D asteroid and put it into orbit around Bop." Are you freaking kidding me? That mission will cost nearly a million to capture the asteroid, launch the station, and then send it to Jool system ... And the payoff will barely cover the cost when it finally pays off 2+ years later. So what's the end-game here for a completed Tech Tree? I don't know but in my case, if/when I go broke in my current save, I'm gonna open up my persistence file and add about a billion Funds and stop worrying about it.