LameLefty

0.19 - purchase; orbited; docked; landed/returned from Mün, including visiting a Münar anomaly completely by accident; also landed/returned from Minmus and Duna/Ike. 0.22 - landed probes on Gilly and Eve; probe flyby of Moho; landed "colony" on Eve; visited/returned from Jool system including Laythe landing; landed/returned from Dres; 0.23 - probe landing on Eeloo 0.23.5 - Established a Laythe colony; finally visited KSC2, Armstrong Memorial; and some of the anomalies of the Jool system.

"Easy"? It looks like you're doing 197 m/s. That's 383 knots - no aircraft tire in existence can handle that kind of speed. Even if the image is blurred and it's only 107 m/s, that's still WELL above any kind of sane V1 speed for a real-world aircraft.

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.