surge

No, why would they do that? They are still 'above' the mass when carrying the main tank, and they still need to point 'down' through the centre of it. Because they're not so high up, they don't need to so much though. Also, some images I've seen suggest they had a small 3rd rocket pointing very nearly 'down' (some 50-80 degrees from from flight path) which I assume gets turned off when they drop the boosters. I further assume the big control flap below that was used to control that torque as the fuel runs out. Hmm, I wonder if I can do that in KSP...

hmm, maybe not. you know there are several buttons to display centre of mass, thrust and lift, right? Left bottom in assembly. There's nothing wrong with you talking about moments. The game just doesn't show it... and some countries are never taught about torque. http://https://www.youtube.com/watch?v=1hwX854eG8E Let this thread be answered, please.

https://www.grc.nasa.gov/www/K-12/airplane/bga.html Rockets that generally pass mach 2 are not relevent of course, except for 'ol baldamundo there, who seems to know whats up. And not down. Do you try to ditch stages in atmosphere thus avoiding space junk? Or if a long mission, fire directly at the planet, dump the boost stage so it falls into it and then orbit? Those are the important KSP expert traits.

I'd rather suggest that you strut the wings and engines to the fuselage. Many, many seemingly wierd aerodynamic problems are easily solved by rigidity. Actually, if you're carrying anything (in a bay or so), make sure that is rigid too. That's caught me out more than once.

I suppose perhaps this is what I'm really asking then - in what circumstances and what limitations can make weird thrust angles necessary? In KSP, none! Or when materials are preventative. If you dont need to make stupid inefficient designs, don't! And I expect to see you land and return a couple of Kerbals from Eeloo soon! It's that simple. That's why both professional aerodynamists and yokel idiots love this game.

Closing fairings requires the closing point to be free of parts along the line of the fairing. It's not difficult, but it is a bit touchy. Remove lights, science experiments, etc. that are in the way, and it should work. You can put them back in place after you've made the fairing if you want. Which I consider a bug - along with the excessively large area that the fairings seem to need. Fairings do not provide any structural support at all. If you craft is falling apart, it's because you didn't use struts appropriately.

Data has been exactly 427.328 since this thread was started. It has been that since I first filled it with Minmus science, as I've already said. It has never changed. I have now amassed 0.845... 0.851...0.882... i cant keep up with the rate as I have 2 3-star scientists on board! I am literally watching it rise, since the sending off of the 300+ before, not that it's relevant. Data is still 427.328. RoverDudes thread has been read (at least his posts - not interested in people whining about it). This will remain unanswered, and hopefully recognized as a bug someday...

In short, there is no advantage to having wierd thrust angles. It always loses some energy. It's only ever done to compensate for poor design and/or materials limitations. As The_Rocketeer said, the big engines on the NASA shuttles are only for the huge tank on the bottom. Of note is since they carry solid boosters on that axis, these engines are the widest gimbaling ones ever made - during SRB boost, they are pointing 'up', but when it drops them, they must point 'down'. KSP does not have engines that can gimbal so much, so although it's possible to build a shuttle-like craft, it's very difficult. Also, commercial aircraft wings have dihedral (look it up) which, among other things, puts the underslung engine thrust closer to the centre of mass. If you design all your craft like you say, you are doing great! Maybe you should apply for a job at NASA, and show them how to do it

Interesting. In my case the data value has never changed since I filled it with science. I recently had values of Data: 427.328, (and from memory) Science: 358, until I transmitted the science. If that's true, it would be impossible to get values for data and science that add up to more than 500, no?

http://pastebin.com/qECY4n0M Similar to the way Scott Manley once demonstrated how the old massless parts work, this easily made craft will answer your questions - fire, switch to launched craft, and compare trajectories. (This craft was made in a game with some addons, but hopefully they will be discarded, as no specific parts were used)

I have a station orbiting Minmus with a MPL-LG-2, that has some 400+ data in it. I have seen a video of other people using these new (v1 - I'm using 1.0.4) MPLs, and when they transmit the 'science', it empties out the corresponding data thus allowing more experiments to be processed. Mine does not seem to be doing that. When I transmit science, the data value stays the same, and I now have some 20+ experiments in the station queued up! Have I found a bug? Am I doing it wrong? I suppose most would be ecstatic about this - free science, forever! Not so much for me, this is my 3rd career game, and for once I wanted to send some probes to other planets before completing the entire science tree. At this rate, that Minmus station will fill it all by itself before I even get to Eve!

That's just the recent clogging up your graphics board rendering the desktop in pointless 3d, when it should be rendering your desktop in 2d and the game/program you're currently using in 3d. Gnome now calls it oh... unity. How odd. I've just switched to Xfce recently in absolute discust of this idiocy. I said before I hadn't used it for decades... I like how it isn't so complicated to configure now.

Ah yes, the F-104 starfighter a.k.a. "the widowmaker", named for it's T-tail design and extremely small camber/low lift wings that tended to kill people at subsonic speeds. A perfect example of the yanks outdoing the kerbals Joking aside, that photo doesn't show it but those wings are very thin - maybe about 20cm at the chord root. That's how important drag is IRL. Pity the wings in KSP are all barnyard doors still, but that's 1/2 the fun isn't it. @nestor_d I notice that you seem to be tending towards really large planes... you may want to take into account that there is a fairly large difference in building philosophy between small and large, namely 'drag is everything' for small ones, but it doesn't matter so much when your plane is already a giant brick and you just need every little bit of power you can get. Continue to play around with it and inform us of your findings. I will continue to do so too, but my space program is focused on other things at the moment.

There's quite a few grammar mistakes in this. I can't cut 'n paste them for you because you presented it as an image, but maybe you should proof read it (many are just missing words). Also, the 'moar intakes' thing has always been a common, but dubious recommendation, more so now that drag is somewhat more realistic. While modifying one of my SSTOs for KSP v1.0, I had to remove all the extra intakes to get it into orbit. I personally use the mantra 'drag is everything', but you've already covered drag well enough. Otherwise, nice to see a fairly good SSTO tutorial for 1.0 - it's a difficult topic.

A shroud for a heat shield needs special treatment?! Or even exists? Uh-huh.

No, because I'm not allowed to. I'll try to describe it to you though: Completely black arena... took me a while to find the solar cell (this particular craft has no lights): HUD: ------ Altitude: 000166m Atmosphere: left limit??!! Vertical change: 0 Gear Down Lights Off Brakes Off NAVBALL: ----------- Surface: 0.0m/s 10/58 degrees. HDG: 58 G: <0.2 Throttle: 0 RCS off SAS off Solar Cell right clicked: --------------------------- SP-L 1x6 Photovoltaic Panels Sun Exposure: 1.00 Energy Flow: 1.71 Status: Direct Sunlight Retract Panels <button> Neither you nor I can see which way the solar panel is facing. As I said.. it's just black! [Move to bugs]

Windows KSP -popupwindow is dubious... there is a quite recent thread here about it. It has never worked in linux AFAIK. You have to remember that unity is primarily a windows platform. We were lucky to get KSP on linux at all. See `man xrandr`. And you are correct about the multi setup... you can create any desktop size you want using eyefinity/twinview or any proprietry garbage, but they all just present a standard X11 desktop called Xinerama/XRandR to programs. It won't help you start KSP at that size (-geometry ....) because being essentially a windows program, it has never heard of that commandline argument, even though it's standard on unix/X11. That is why I just give up and use my little script so I can move the window to the biggest screen I have and then manually fullscreen it.

Barring a 'scoop less than a jiffy' meaning meaningful frame rate loss, my game time flashes yellow every so often too. In my case it's about every 4 seconds. I'd be surprised if anyone's didn't. But no visible effect -> no care. You can play with General -> Max Physics Delta Time in the options. When the clock shows yellow (or red) it just means the physics thread wasn't able to calculate all it wanted to. Physics works on an iterative system, and when it isn't able to calculate as much as it wanted to, it turns the time yellow and reduces the amount it will try to calculate next time. If you don't have real speed problems, it will make up for it the next cycle, and then some thus increasing it again. That's why it flashes yellow every so often. If you're getting actual, rather than perceived FPS loss during yellow times, try adjusting Graphics-Frame Limit instead, and/or turning Physics Delta the other way. ...or your disk system may be incredibly slow, as 7s is about the same rate that linux tends to flush the VM system on modern systems. In that case the time would probably show red though.

The names you can use in settings.cfg are here: http://docs.unity3d.com/ScriptReference/KeyCode.html There is stuff like 'LeftWindows' etc... In my experience not all have worked, because the linux-windows mapping isn't entirely correct. You want to change the MODIFIER_KEY entry, of course.

-popupwindow only works on windows (and very old versions only I think). I soooo wish it did on linux too, or used XRandR properly, I have a script to reset the config to windowed, and then I have to move the window to the correct screen and then set it to fullscreen on every start: sed -i 's/^FULLSCREEN[ ]=[ ]True/FULLSCREEN = False/' settings.cfg KSP doesn't support multi-displays. The best you'll get is resizing a window across your screens as you've already done. Unfortunately unity/mono/windows crap doesn't do standard X11 -geometry 120000x6000000+0+40000 arguments either - they've never had a standard way to define window size and position. I've not used Xfce since it was called fvwm (several decades ago), but if you don't click on the window for the screen it started from, you're likely to focus something else like the taskbar or background. Incidentally, has anyone uncovered all the cmdline arguments that work?

I'm uninclined to change the former, being part of a logged and tested set of changes amounting to a new version. Although, while the code that comment is referencing must remain unknown for IP reasons, was it introduced in 1.0 or 1.0.2? An area cannot be negative. It is possibly another 'fix' that will eventually turn out to be a bug? I did try the latter though, and it didn't make much difference alone... Might have made a few radial things explode more, but I came screaming in at 2.5km/s directly down, face first, and the Mk1 pod survived until it hit the ground. That definately wasn't 1.0 behaviour, or realistic, or in the catastrophic failure/sadistically amusing spirit of KSP! Really the only problem 1.0 and 1.0.1 (I think) ever had in this regard was a single value in the heatshield parts being wrong (PhysicsSignificance). I pre-fixed this and was a happy clam until 1.0.2. For some reason all these other changes have rendered the heatshields useless. That can't be intended behaviour after you worked so hard to include them, can it?

FYI, when the claw is armed, it goes into an odd mode where the physics for clipping is mostly disabled. This would be why opening it stops it. Don't know why it doesn't explode when you close it again though, mine usually do!

So how would one go about changing it if the framerate isn't an issue? My IVA camera consistantly moves at an infuriatingly slow speed comared to the external camera (including via the keyboard). I notice there is a VAB_CAMERA_ORBIT_SENS and FLT_CAMERA_ORBIT_SENS in the settings, but there doesn't seem to be one for IVA. I get the feeling it might be related to a linux problem, as I've seen windows users play with the IVA and their speeds seem fine.

You have to rotate it around (randomly!) until it turns green to attach it to something, and then the next part has to attach to the opposite side (sort of like a stack part). After that it works normally. You can then remove the 2nd part if you just wanted an L shape or something. I'm guessing (some of) the surfaces are inside out, but it gets so little use no one's ever gotten around to fixing it.

What seems to be happening is that the CoM comparison point on the wing the control surfaces are attached to is wrong. The point they appear to be using is the leading edge of the root of the wing. The point they should be using is the *trailing* edge of the root of the wing (or better yet, the MAC, but that would be too slow to calculate) It becomes extremely problematic with swept wings, because the apparent difference between those 2 points is large. As others have mentioned, moving the wing back so that the leading edge root is behind the CoM fixes it. I'm pretty sure this is a bug, but I'm new here so I probably don't have enough 'clout' to make it realised. If anyone with more experience wants to test this for themselves, and then file it as a bug, please do.