Deadweasel

Seconded! Very sexy!

"Lands" being a massive understatement.

Oh crap, Steam. Yeah, you have to remember that Steam deals primarily with games that require installation of some sort. It's a rare thing when a game doesn't require installation and yet is mature enough to be considered ready for distribution, so you get oddities like this. Also, Steam would catch nothing but hell from the userbase if it were capable of stepping outside its own "playpen" without specific user intervention. That's the behavior of an application looking to plop some nasties on your root or %SYSTEM% directories. :S There are still a few MS tools that never quite got the point, and never grew up into a useful thing, like UAC (*shudder*). Surprisingly though, they did take some hints and figure out some real good ones, Drive indexing is lots better, DEP is pretty solid (never ran into a conflict with it, for my part), and MSE is excellent.

Good call-out, but you should never disable Data Execution Prevention. In Windows 7, it's a good safety net, and it does work if you're not messing around with its mojo. The thing to remember with Win7 is that its default install locations are sacred, and not meant for the user to just dump their own stuff there whenever. In short, if a program doesn't require installation to run, then DON'T DROP IT IN PROGRAM FILES, for dog's sake! Only installed programs go in there, and no program at all should be running from any of the Documents directories. Just plop the sucker in the root of C:, or any folder on another drive, if you have more.

Yeah, seems like the card in that machine really isn't happy to be playing that game at all. IIRC, you only had 64MB of physical RAM on that card, with more being offered via memory sharing. That doesn't say good things about the card's probable capability for 3D applications. Sorry, I wish I had some miracle cure to offer, but it seems like you're running right at the very edge of that system's performance envelope. There is, however, some tweaking you can try! Go check out Razer Game Booster (yes, *that* Razer). You can set it up so that when you launch KSP through it, it kills unnecessary processes and effects to free up as much performance as possible. Here's what I usually set when gaming: Turn off transparency and window animation effects Turn off drive indexing Turn off all system tray applications, except for basic services like sound control panel, antivirus and mouse drivers Disable just about every other non-critical app and service that Game Booster recommends The nice thing about GB is that if you set all this up to trigger when you launch the game from it, when you exit the game again, it re-loads/enables everything you had it set to kill. Maybe that will help you scratch a few more frames out of that old nag of a machine of yours.

You taunted the angry dynamite monkey. -or the Kraken, one of the two.

Hahaha I know that urge!

Whoa nice! Try using Fraps, it shows a frame counter on the game screen while it's running. Oh, and incidentally, I didn't make the source skin for these. The one I posted is little more than a color shifted version of the stock red one, converted to jpg. Basically I just want to be sure I'm not taking kudos for any part of the design of these things; I'm just here to help spread the love.

Whoa whoa WHOA! Slow down man! Give me some time to save up for the 24 core system before you start suggesting things like that!!! /pretty please?

I did notice my video card fan making some music down there, and I think I have an idea why. You notice how the lights can glare through surfaces and bounce off others? Now, consider some of the ships we make, especially SSTOs, that feature clipped parts, and more specifically scads of merged air intakes. Now, considering how the game doesn't always fully occlude light as we think it should, how much effort do you think is going into re-calculating the lighting for each and every component that's within the area of where the game thinks the light should be visible? HSTAC-02 Whiteraven uses SIX intakes, all merged into the same space that would normally be occupied by only two: That has got to be playing havoc with the game engine, having to re-calculate the lighting for every surface within range of every light, each time they go on and off again. Even if you don't have a bunch of merged parts, or even if you're not using clipping at all, the fact of the matter is that each time one of those lights blinks, multiple surfaces have to be checked for range, and then lighting effects applied to each according to position relative to the light, and then again when the light turns off. Multiply that by however many lights you have mounted on a craft. Minecraft suffers similar issues if you mess around with enough lights in a large enough area, but Minecraft hoses the CPU, whereas KSP chews more on the GPU, potentially resulting in the situation we're seeing here. Here's a thought: what happens if you have the lights mounted, but DO NOT use any flashing or interval mode? What if you just turn them all solid on or off? Is the video card fan still pushed to new heights of musical frenzy in that case?

There's a ship back there somewhere, right? That right there is the main reason I'm not too motivated to mess with Mechjeb O_o

Not if it's thinking- ... Oh god, run.

There is an easy way to test that. Move the texture file out from one of the part folders, and plop a jpg version of it in there. Here, use this one: See if that makes a difference. I'm honestly not entirely convinced that it will. EDIT: not sure if the minimum/maximumDrag are really an issue. The game seems to accept the values without question (no load errors in the log). Could this possibly be an appropriate time to use "if it ain't broke..."?

Thanks! I had lots of fun building this bugger, even though it's a bit "cheaty". It's got some fuel converters on-board that will refill the tanks using power (which is what the big solars are about), but to keep everything running on the dark side of an orbit, it had to generate its own power somehow. That's why there's a cargo bay that contains a complete power core: I once used this ship to recover some stray debris components, by maneuvering up to them and capturing them in the bay. By the time I hit atmosphere, the parts had rattled around in there and destroyed half the core, so it was a good thing I was on my way home!

The way I see it, it's kind of like being a biker. Nobody will really consider you as one of them until you've got a "two wheels up" story to tell. It's like they say: "There are two kinds of bikers: those who have been down, and those who are about to be." Heck, troops who deployed to Iraq/Afghanistan and were never sent outside the motor pool for six months are considered veterans. So, even if you joined in on 0.19, I'd still say you're a veteran.

Well... shoot. Looks like B9 Aerospace pack includes a unit called "Info Drive" that does almost everything I wanted to put together. It shows the assigned action groups (with custom descriptions rather than just the default part names), and has a log section as well. Well, at least I can take a look at how it's done, and maybe release a standalone part that expands on the idea (no, I know better than to just rip the code and proceed from there!) EDIT: Dagnabbit! There's no source code, and no link to it that I can find for the pack. Gonna have to try hunting it down through the various people associated with it, looks like. Also, it seems the Info Drive's custom info is only good for the individual deployed ship, and is only persistent with that ship, though I can't for the life of me figure out where it's storing the data. EDIT2: Okay, I lied. The info is persistent with the ship, as long as you enter the information in the SPH/VAB, when you open the Action Groups menu and click the Info Drive part. The text you enter is saved with the .craft file when you re-save it again. Anyway, found the source I needed, so now it's time to play!

I had no idea that was in there! Thanks very much! Here are the B9-based ships I've been working on: HSTAC-01 "Silverhawk" HSTAC-03 "Banshee" (current designation X-105 testing) HSTAC-031 "Banshee II" (current designation X-106 testing) IPEV "Seraphim"

That is one mother of a plane! Also, what mod are you using to show the action groups?

Also a thought here: Does he maybe have two installs of the MOD itself? An old install in the legacy folder and the new one in GameData?

*picks jaw up off the floor So.. does it, like, flap the wings to get airborne, or what? O_o

...seriously? So your primary complaint is that you perceive the thread to be some kind of discrimination? "Limiting available posters"... On a single thread... *sigh* No, sorry. It does *not* take a village, and nobody gets a certificate of participation to make them feel good about themselves. This was just a single thread (out of HUNDREDS) calling us early adopters out to share our takes on the game and what it's become since we each first discovered it. No, following somebody's Youtube channel doesn't count by itself, but you know what? You still knew about it before a lot of other people, so how about them apples? You're still part of the crowd of "limited posters" who has something relevant to be contributed. So how about doing that instead of sending up a useless post about how this thread could make somebody feel excluded and hurt from the fun?

Did you try deploying a new "craft" with a new instance of the part attached?

The way I've always tested part changes was to just lob a capsule with the part attached out onto the launch pad and play around. If that doesn't result in changes, then I'm not sure what to suggest. The method I recommended is how I changed the red beacon to amber, and the reload process did result in the change I expected.

Also, bear in mind the reason for a minimum number in each channel is because 0.0 is black.