Deadweasel

I get the impression that PhysX is nothing more than a promotional gimmick that's being touted so heavily because it's "better than nothing", and that's how it's being treated by the development community. At the time of its introduction, it was mind-blowing because there really WAS nothing better back then. Now? It's just dated and all-around crap (in comparison to other projects like Bullet) since it hasn't really been expanded upon all that much, except to support more modern hardware. It feels like Adobe Flash, where it never really got buffed up after release because of its initial grand reception, and now the devs are just sitting back and raking in the royalties thanks to the lack of competition. And, just like Adobe, they (nVidia) are now so deep in their complacency that others are now coming out of the woodwork to produce the improvements and refinements to the idea that they didn't feel motivated to stay on top of. With any luck, PhysX will eventually be relegated to just another first-comer story who was left completely behind. At least, that's how I'd like to see it happen, because honestly, with something that has such broad and positive implications, I find it saddening that a company wouldn't try to expand their reach by working out a deal with AMD and other video card developers instead of doggedly focusing on supporting only their own hardware, let alone at least try to keep the public interest focused on them by staying ahead of the game (so to speak) in terms of physics emulation. Seems like since PhysX's release, most -if not all- of the improvements have been coming from OTHER (third-party) developers, and that's just sad.

"I'm okay with this!" MechJeb could be considered "cheating" if there were an official scoring or achievements system. Since there isn't, and this is a SANDBOX game (at present), there's no such thing as cheating. Even HyperEdit, which I would propose is about as close as one can come to the (non-existent) cheating concept, simply allows the player to skip the part they're bored or otherwise tired of, and get to the part they want to play with. Basically my argument is that there's no such thing as cheating when a mod or feature lets the player experience the specific portions of the game that tickle their fancy at the moment without having to experience the drudgery portions every single time. Case-in-point: I've played GTA San Andreas' story through to death, and now I have more fun just going in to cause extreme mayhem for the lulz. I don't necessarily keep my game saves between installations, so when I re-install it, I just drop in a trainer or codes to open up the whole world and basically set the game as if I'd played it through and won everything so I can go nuts with vehicles and weapons without having to play through the whole thing, dealing with timed missions, cut-scenes, the works all over again. The modifications to the game provide another aspect that allows the game to keep its place in my heart as thoroughly fun and enjoyable without lobbing in extra work to get to the part I actually enjoy now. That's all MechJeb and HyperEdit do: they take the difficult or tedious portions of the game out of the equation for some players and let them just keep having fun with it. Besides, mods like MechJeb can actually be teaching tools too. How many of us have actually had that proverbial light bulb go off over their head about interplanetary transfers after seeing how the automated system does it?

So... Because both units serve different functions, is there a way to use BOTH on a craft, and then switch between one or the other? Say perhaps through action grouping? I'm not at my game rig at the moment or I'd be testing the idea...

I'm actually going to guess 0.16, since Scott usually posts videos running the current release, and 0.16 was the most current when he posted that video. A quick Google image search seems to confirm the UI look for that version as well (been too far back for me to remember myself, at this point!)

I see the landing gear (mostly) survived. I'm calling shenanigans on these "death" claims of yours, sir! /note to self: do not watch again while intoxicated

These are way too unrealistic. There's FAR too much leg room happening here!!! Somebody get this guy in a protection program somewhere before the major airlines see these and get scared people will get ideas from them! <3

You want to keep a decent framerate on this game? Play it as it was originally designed to be played first, then comment if you feel there's something more that needs the devs' attention. How far have you extended the vanilla install? Unload the mods and extra parts and try again. The devs can't be expected to accommodate the additional demands that mods might place on your particular system. Mechjeb makes the whole game tangibly slower for me when I'm flying a large ship, so I don't install it, and I generally have fun with even multi-hundred-part ships. How many *other* processes are running on your computer at the same time? Close uTorrent Alternatively, close Vuze/Auzureus (HUGE memory-hogging wastes of code for simple download clients) Close Winamp/Windows Media Player/Foobar2000/wtf ever media player you favor Close EVERY freaking add-on, theme app and other sundry running process you've installed (aside from anti-virus and necessary services of course) on top of the OS Which OS are you running? Windows/Mac: good as long as your hardware isn't sweating before the game is even running. Windows Vista/7/8 is NOT appropriate for a P4/AthlonXP/Celeron-D, and OSX is NOT appropriate for PowerPC. The OS devs are building for the largest common current and future hardware, NOT a system that has a "Built for Windows XP" sticker on it. Though there are a few rare exceptions, generally you can't just keep upgrading the OS over the years without eventually upgrading the hardware too. Linux: Sorry, too many variables here. No central dev team working from a locked spec means every single little element, from the kernel itself to the lowliest insignificant config file, can be influenced by anybody's individual preferences. Your install could be the best possible config for that distro and still suffer from a bug in a driver or procedure call somewhere. Or you could be running Ubuntu, in which case, my condolences. What hardware are you using? Time to chuck that old Dell Dimension XPS/Compaq Presario/Gateway2000. Pentium-D was the bee's knees... six years ago, when WoW players were spouting these same gripes about a "measly" 40fps in massive battles. For the love of Jeb, can you save for a week or two and install a bit more than the 1 or 2GB your machine came with when you bought it? If your machine can't handle more than 2GB, then it was never designed to run games like KSP and can't be made to do so fluidly, no matter how many tantrums you throw. A 2GB limit on the motherboard is an indicator of age or intentional power limitation for basic purposes like web surfing and navigating corporate spreadsheets. Intel integrated video = shattered dreams and dead unicorns. Sorry, that laptop was not meant to be used as a gaming rig, and KSP is a far cry from Farmville and Bejeweled 2. Please note, none of these were meant to single anybody out, they were meant solely as tongue-in-cheek suggestions to point out various factors that *could* be responsible for perceived poor performance. In all seriousness, no mention is ever made in the OP about installed mods or even current hardware config, so all this discussion could very well have been sprung from some kid running a hand-me-down eMachine on Debian Sarge, for all we know.

The UI says "way old version". Also: "Published on: Aug 24, 2012".

It's not about having free nodes in general, the issue is that the ROOT part doesn't have a free node. The root part is the first part you brought in to build the assembly. If you remove that part, the second part you added becomes the root. If you use the single pilot cockpit as your starting point, then tack on say an ASAS, then a fuel tank, you won't be able to save that assembly because the single-pilot cockpit only has one attachment node (which is connected to the ASAS). Now, if you pull the ASAS (and therefore everything below that), you will find that you can save THAT assembly without issue. Make sense? If you plan ahead a bit, you can make a subassembly that starts with a separator ring as the root part, so you can import it into another ship with the "root" node already in a place that makes the assembly mount the way you need it to in the final build. Sadly, this doesn't help if the "assembly" you want to import requires careful balancing and testing during the initial build, such as a VTOL plane, because your "throwaway" root part is inevitably going to throw off the balance.

It's a bit easier, actually. If you're working with the one I originally modified, all you need are the texture file and the color values in the config to make it all work in the new layout: In the folder for the new v3.3 lights, duplicate one of the lightbeacon .cfg files, and rename it appropriately ("lightbeacon_amber.cfg" as an example) Copy in the amber light texture file from the old version and rename it to "model000strobe_amber.png" Open the new config file In the new system, texture files are referenced directly instead of being expected to be present in the folder. As such, you will find a line in the config for "texture = model000, AviationLights/Parts/lights/model000nav_x". Change this line so that the "model000nav_x" now says "model000strobe_amber" (leave out the .png part of the filename). Don't forget to edit the description so it is described accurately in the game Near the bottom of the config, look for a line inside the MODULE section that starts with "Color =" Replace this line with "Color = 1.00, 0.70, 0.07" Save the .cfg file, and you should be good to go!

Heh, there's definitely a noticeable frame drop at the launch pad, but it's not that bad at all once in orbit. In fact, the only time I realize that the framerate had gone down is when I take the Mosquito out at-range, and everything suddenly gets extremely smooth and fast. I'm not one for building teensy tiny ships, so I guess I'm used to the slower performance.

Man, I still can't get over how sexy these things make everything look! All the long-haul ships have been getting outfitted with "boo" lights for standby and inspection lighting, which makes things look 100% more awesome! The strobes are also massively useful in pinpointing a docking port from a distance too! Squad needs to take notice; these things should be stock!!

IPEV Excursion committed its first testing launch, carrying the rover component of an experimental exploration vehicle delivery system. The initial launch and orbital insertion were fraught with issues, however, prompting Mission Kontrol to direct the crew to begin a post-launch damage assessment of the flight. Danbry drew the short straw, and began the assessment in the rover bay, checking the lightning system. With the rover and its support systems checked clear, Danbry moved on to the crew pods. The only faults to report there were a few missing snacks that "obviously" had not been loaded prior to launch, per the supplies manifest. Last stop on this portion of the assessment was the Mosquito bay, where Danbry verified the berthing port's integrity, as well as the other various support systems connections. Two days later, IPEV Fearless approached, on its way to Duna, transferring a Mosquito drop-ship to Excursion as it passed by. Johnoly brought the tiny ship into its berth with a smooth and experienced hand, and immediately retired to a crew pod for some well-earned rest. Danbry couldn't resist going out for a closer look at the brand new ship, fresh out of assembly only one week prior. 30 minutes after Danbry left on EVA, Bill -on watch duty in Excursion's cockpit- was startled to see a sudden and unexpected drain on Excursion's power systems, which were already at capacity while the fuel converters were online. Because he hadn't been on duty when Mosquito arrived, it took him a few more minutes to isolate the power draw and switch to one of the Mosquito bay cameras. Suddenly the power drain -as well as the odd sounds coming over the comm- had an explanation. "Danbry," Bill keyed up, "I know it's cool and all, but for the love of Bob, could you turn the nav systems back off? And quick making whooshing sounds on the mic!"

Today I discovered that Kerbals can control nearby components, not just fix rover wheels. Following a particularly troublesome launch and orbital insertion of IPEV Excursion, Danbry inspects the rover's lighting systems as part of the post-launch damage assessment. Followed by an inspection of the Mosquito bay, which will receive the rover drop-ship in a couple of days, courtesy IPEV Fearless as she departs for Duna.

Man, for as nice as this looks, she certainly doesn't like to play nice, does she?

Amazing stuff, isn't it? Welcome to what all the cool folks are doing these days!

You can upload it to a service like Dropbox or Google Drive and paste a link here.

Got a .craft file to share for that one? I'd love to see how that bugger handles!

You seem to have lost a bit there, just at the tippy top of the nose. Just a little one. I'm sure it's not really important. Still an awesome-looking ship, and I hope that Kerb's got a steady hand on the stick for any future flights on that monster.

Lawn dart?

They're great for low hull lighting! White for active operation/inspection, blue while at standby or passive operation (cruising between maneuvers). Pilots are calling these "boo lights", in the superstitious belief that the color scares off the Kraken.

Depends. Do you consider Kerbals to be generally disposable, or would you realize a learning and discovery benefit from trying to send a purpose-built rescue mission?

He started with Kerbals, and soon graduated to cats...

*wrings hands anxiously* SWEET! Can't wait!!

[--post snipped as redundant--]