pincushionman

The only problem I have with "chopped nose" is it means another part slot is taken up on planes. When there's already a 30-part limit in the level 1 SPH.

The wing lift and mass are also applied at their roots; this is not a problem unique to the airbrakes.

As somebody mentioned earlier, we need a better system for self-built engine clusters and interstages. Sort of like KW Rocketry's thrust plate (or was it Procedural Fairings? I remember it being procedural), to put multiple engines on back of a stack to tailor the thrust output, without causing a big drag problem with the surface mount options. And the interstage engine shrouds need to go; they've given us a fairing system we can use to make our own - including properly surrounding engine clusters and diameter changes.

Is there a difference? Now, I say that firmly believing that "publicity stunt" /= bad. It's only bad if that's the only thing going on, or if it's obviously unrelated to what we're supposed to get interested in. The mission is the real deal; this part is to create interest (which is exactly what a publicity stunt is).

No, you have much more advantage by building a bigger rocket, which is what we're all doing now. The losses you overcome with a tall launch platform (or one on a mountain; we've discussed these before) or an airship are more than offset by the support costs for your assembly and launch infrastructure.

Yowza - I forgot about that one. Is there a nearby key handy to pair with Tab to be it's "cycle backwards" counterpart? Tilde maybe? …I know that's the standard console access, but KSP doesn't have a console?

It's the 32-bit build. Even when the Wx64 was made available (as a test), you still had to go out of your way to use it. So you'll be fine with what Steam gives you. Well…you'll be as fine as everybody else is. Underlying Unity and KSP logic bugs affect all platforms.

SQUAD needs to use the game-default mod key (Alt in Windows) for all the "backwards" behavior (target toggle with Tab in the map, symmetry selection in the build scene). Shift is usually used for this, si that's what most users default to; using shift for it only half the time causes confusion. The modifier key needs to be consistent across uses. In short, if Shift is throttle-up, it should ONLY be throttle-up - no exceptions. If the modifier key is Alt, it should ONLY be Alt - no exceptions.

I like how this ties the existing stats to gameplay, but even this becomes micromanagement. It's going to be tough enough to plan supplies for missions (see my previous post) without having to work out variable consumption rates per crew member and account for ill-defined living spaces. For stock it would be best to stick with a flat 1 unit/day (or hour, whatever. The point is it's an abstract unit so might as well make it easy to calculate), perhaps with an added wrinkle that tourists use 1.5 or something.

Lemme guess. You have multiple wing sections. There's a well-documented bug where symmetric part attachments have different stiffnesses, and the flex and twist caused by pitch-up tends to cause uneven deflection in the wings. Try adding more struts between the wing sections and/or install the KJR mod, and see if that helps.

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!