pincushionman

Then each strut/engine "sees" full drag at the front and the back. Plus the tank will have additional suction drag at the back from the open node. I don't know how big an effect this will be, but I expect it won't be negligible. Try again with drag disabled in the debug menu.

The real question I think is: how are you attaching the clusters? Are they all mounted to the same tank somehow, or their own tanks? Part attachment to anything but a node is assumed to be exposed to freestream air.

Pull your far part away with the translation tool. Attach your struts from your close part to the far part. Translate it back. The strut will clip through the parts between. That's how I strut between wing sections, which otherwise doesn't work very well.

While landing on the ocean might be a logistically sane move, taking off again might be a whole different story. I would say ideally you want to be near a large river delta. The ecological diversity in these areas is huge. By default you are on a coast, so you have access to any other coast area by water, given enough time. You also have a means to get, potentially, a long ways inland (the river), again by boat. This gives you a great deal of flexibility.

I'm halfway with Alshain in that if we never get life support, I won't be too put out. But if we did, I would back something with a GLSR (generic life support resource) paradigm like USILS and Snacks! do. With appropriate management options (supplies: pack/grow; waste: stow/recycle/dump), of course. I'm going to bring up something brought up in another thread, though - mission planning. I posted in that thread and may have blown off the question a little (and if I did, I apologize because it was important). The gist of it is that the implementation of resources is really easy, and we can thank Roverdude for that - but knowing how much to take is most certainly not, because we don't have any in-game tools for it. What I see is: Current Mission Control contract functionality is moved to Admin Building, freeing Mission Control for mission planning activities. It has a simplified version of Tracking Center interface, with a 2-D display of planets and user-selected target objects. You can add "legs" of a trip, each with a starting and ending orbit (within altitude and inclination ranges), and will best-guess a trajectory starting at a user-defined time in the future, and give DV and duration estimates, assuming competent flying. Building upgrades would allow warnings of SOI interferences or reccomendations to wait for least-time or least-dV. TL;DR: The actual resource implementation side of life support is actually pretty easy - trivial, I'd argue, especially if it uses a GLSR. But it causes issues to mission planning that we don't have good tools for.

Understand the different licenses available (in the US: sport/recreational/private/commercial/ATP), then determine the least that is applicable to what you intend to fly. If you're going to just putter around the farm on nice days, don't go for a Private. But if you want to take the wife and kids on long trips, a Sport ain't gonna cut it. Unless the extra effort for the next one up is relatively low. TL;DR think ahead.

As others have said: FPS effect meager at best. Also, this would be a Unity feature, not KSP in particular.

I think part of the multiplayer discussion is a problem with half the people talking about one thing…and half of them talking about something completely different. There are really two different concepts to multiplayer: nowadays, most multiplayer is "served," where you find an internet server and join it - and get the whole people-do-their-own-thing-multiplayer-only-in-name thing or internet trolls and griefers problem. Servers with hundreds of random players, that kind of stuff. I think this would be a terrible mistake. But back in MY day (you whippersnappers! Get off my lawn!), everything was HOSTED, and you played with your friends, because that was the ONLY people you can play with. You had a maximum of four to eight people (sixteen if you were particularly ambitious and your parents were willing to pay for good Internet and computers), so if you had PKers and griefers it was your own damn fault. The second type of game seems much more suitable to me. Not that it must be hosted; you could serve such a game no problem, even over the internet. But the limited scale would encourage the types of games where collaberation can actually happen. You don't want the only interactions between players to be their ships passing in the night.

Put me in the "barn isn't so bad" camp - as a concept. The artwork did seem to me to be more cartoon than the style of…well, everything else in the game. But I can totally go for the bunch-of-guys-and-gals-with-bigger-ideas-than-budget aesthetic it appears they were gunning for - it seems to fit the game (or a game, really) better than a this-is-a-realistic-history-of-rockets! take. Though I agree a whole upgrade cycle of uber-small, less-capability-than-Stayputnik parts to complement that tier would not be a bad thing for career. And I thought the last mention in a devnotes might have been that Tier 0 may become more of an industrial park look. Which is okay, I guess. Oh, and thanks for chiming in, Kasp - it's good to see that you guys still do check on the pulse, even if only intermittently. And one last thing - i'd be totally down with #bringbackthebarn…as a ground scatter on grasslands! We need more signs of life, man.

I…can dig that. But if that's the case, an engine change is a big enough by iself to be the entirety of a major point release. It would certainly be advantageous in identifying porting bugs.

I don't see how the U5 update could be at anything except 1.1. If it's not ready, it's not time for 1.1 yet.

Given that there have likely been far more than 20,000 GRBs that have happened in the history of the Universe, I'd say "by chance" doesn't sound so far-fetched.

I presume he's talking about the NES-101, which had the top-loading cartridge port similar to the SNES. And ditched the RCA video/audio out. If they hadn't taken away those RCA ports, he wouldn't be in this problem.

And if it's following up on an existing help request, just reply to the existing thread.

Settings->System->Tablet Mode has options about this, as well as whether you get a normal, limited (or no?) taskbar. I've used this menu to disable the autoswitch based on opening my 2-in-1's screen too far and accidentally going into tablet mode. The manual switch is in the swipe-from-the-right quick actions, but I haven't found any other option for doing it with keyboard & mouse (such as a notification area option). Where I'm missing some customizability is in the display settings. When my 2-in-1 is in tablet mode, the auto-screen-rotation is great, but in desktop mode I'd like it to always orient to the "normal" direction. Only way to make this happen is manually, using the orientation lock in the aforementioned quick actions. Another shortcoming of the display settings is the "size of the display items" option like the taskbar, icons, and text. I can scale all these together to 125%, or it says the advanced display options can scale the text independently (but I haven't been able to get that to work). What I really want is to scale the taskbar only (for my thumbs), but keep the icons and text the smaller size. My screen size is small enough as is, dammit!

There's a way to pan the camera or rotate in some other manner than slewing about the CoM. I believe it's middle-click-drag. You might be able to view the motor stacks from the side if you do this.

Fixed that for you. Of course, subasseblies and merging have their own problems, but the build tools should at least be defaulting to the most useful mode.

I've seen several times in this thread where Ferram4 has mentioned his "list of dead aerodynamicists", so I believe you are 100% on the money there.

I thought the local P2P option actually sounded like a really good idea (the internet one, no thanks)…and then I thought about how it was actually gonna work. See, we've got six machines on our network; four will be running Pro (including one best described as the "server plus"), and two on Home, both laptops. Which ones will be prompted to download updates first? Probably the Home machines, unless there's a hidden setting to let the server box (always on, always online, it's a SERVER, for pete's sake) do the heavy lifting on it. We'll just have to see.

I think they don't care about direction at all. Which implies they're just in strong in shear as well. Which, as a structural engineer, twists my head around the wrong way every time I have to deal with it.

How is this different from getting science from several different survey sites?

Reverse power has always worked better than brakes. If you have reaction wheels, it will also apply torque to keep you from flipping out.

Goin' on my laptop tonight. Everything else has important stuff on it we can't afford to lose from a snafu.

I'm guessing your TWR went from "adequate" (1.2 to 1.7ish) to "excessively high" (>3.0) by adding the rhinoboosters to your first stage. Depends how big your upper stages are. Excessive TWR = too fast too low in atmosphere = transsonic with too much drag = rocket flips! Also, copying your first stage in 6X symmetry = moves CoM aft = rocket flips! Exacerbating above problem. Pics would help immensely.

Kerbals are seen outoors in both the "Launch" video (at least long enough to get from the Astronaut Complex to the van) and in the "First Contract" video at Jeb's Junkyard.