TMS

Don't place your CoM and CoL in the same place. More often than not, it will make the aircraft squirly without excessive control authority devices As someone else said earlier in the thread, place CoL slightly behind CoM. Also, your CoM will likely shift backwards as fuel is expelled, so your CoL should be placed far enough behind the CoM to account for that. Clever fuel routing or fuel management mods can minimise the CoM shift, but that's a whole other thread.

Science, money and reputation are supposed to be interchangeable, in that you can cash one in for another. Of course, these plans may have changed.

Not sure which parts of the build you're wanting feedback on (using overhaul 7), so I'll just type and you can discard/use as appropriate: The GUI is a thing of beauty and makes navigating the options and possibilities far easier. Tooltips for buttons would be useful as some of them seem non-functional. Would be good to have a restore default option. Why? This couldn't be changed via GUI and needed a re-start to fix: The clouds seem better formed and higher resolution to the current release. Also, the transition 'hole' from 2D to 3D seems better managed (wider angle???). The city lights from orbit are a little distracting on the dark side. The tight, grid-like texture of them seems to make them flicker/shimmer - especially in 'densely populated' areas with high contrast (yellow/black) present. You can see this on the day side, but it's less apparent due to the reduced contrast. Anti-aliasing settings don't affect it. Dropping detail scale to 15 reduces the effect somewhat when viewing a city at a right/obtuse angle angle but, obviously, looks absurdly oversized (unless Kerbals have boulevards the width of a football field). I'm wondering if the texture needs de-pixelating somewhat, or if the overlay texture is causing it? I may have a crack at experimenting with that (should I ever find time). Clouds don't render when zoomed out during orbit, in map or title screen. Texture on the mountains is lost at a distance. Getting some weird z-fighting issues where the grass texture meets the KSC hex structures - most notable on the runway mount. I note that this is present in stock KSP, but the choice of matching colours/textures by SQUAD minimises its appearance. Is it possible to have the terrain detail texture be applied to the KSC hex structures as well? The ocean texture is a tricky one. The new texture doesn't seem to permit shadows to be be cast onto it (rather, they trace the seabed), so I found it really tough to instinctively know my altitude by sight. Sure, there's an altimeter, but shadows really do make a difference to intuitive flight. I don't really know how you get the transparency thing to work at certain angles/heights, but the effect is subtle and effective. However, I get this line at low altitudes: Not sure how you'll prevent tiling as, even at lower detail scale values which work up close, the titling is still visible from orbit.

Where are those inline stack legs from?

Downloading now...

Does anyone else have problems placing a node far into the future? Or have I dropped a few IQ points? I'm currently trying to get a stable node set up for my return journey from Eeloo. Based on phase angle projections, the next available window is in 182 days. I'm punching in numbers to get to the approximately correct date-time, using finer grain numbers to attune my exit angle and velocity. Trouble is, the greater precision results in all sorts of wobble and paradoxical behaviour. For example, I add "1" to each additional decimal place on the date-time, which should result in an increasingly smaller (but unidirectional) increment on the ejection angle: Uhhh... as I'm writing this, I just noticed the ejection angle readout going absolutely crazy, spitting out hundreds of numbers per second. I expect the problem is something to do with stock KSP (increasing error further in time), but felt the need to log it. What happened to the "we've fixed nodes" statements of .23.5???

I seem to recall someone saying it was ALT-E now.

I managed to play with the test version of Astronomer's pack for a few hours of the last week. Even in that very short time I had, I have to say it was apparent that there's a really light touch throughout. Really nicely done. Nothing looks too oversaturated or busy.

Agreed on only releasing things you're confident about. Good decision. Bon voyage, navy.

Is it worth making contact with N3X15 to gauge his interest? No idea if he's been burnt too much on the issue or how draconian his NDA is, but his earlier dev notes indicated that he'd progressed pretty far with Spaceport 2.

Which version of module manager are you using? There's been a fair few issues with 2.x. I think I'm still using 1.5.x for that reason.

Probably fell into disrepair after N3X15 was canned. Either that, or the offsite hosting was provided by N3X15.

Heheh... this is nice. Do you want feedback in this thread or via PM?

Interesting use of the new SRBs as a boom for a solar panel array. Cuts down on parts and probably wobble. I assume they were empty on launch?

Linked to this earlier, but it got passed over. TweakScale is a plugin that allows parts to be rescaled on the fly in the VAB. I believe the author is allowing others distributive use. Basically means you only have one part in the VAB, rather than multiple.

http://kerbalspaceprogram.com/?s=Copenhagen&x=-898&y=-71

I was wondering the same thing. Happy to be a guinea pig.

*excited squeal* Looks great!

E-dog, have you seen TweakScale: http://forum.kerbalspaceprogram.com/threads/72567

Still a very useful resource. Just rediscovered this after messing around with spaceplanes today. Many thanks for your efforts here, alterbaron. I just wish someone would create a standalone mod (not mechjeb) that performed aerobraking/capture predictions!

Can I ask what I think is a rudimentary question? I assume certain values are already calculated by stock KSP and are 'merely' presented by the mod in an accessible fashion, but that others are derived/calculated (such as current in-flight delta-v) based on stock input values. Basically, I'm trying to determine if I don't display certain calculated values, whether it reduces the computational overhead of the mod, or whether the calculations happen anyway behind the scenes?

This is compatible with the boards current software. Unlikely to remain compatible if they upgrade to the VB5 garbage. Otherwise, it'll be MathJax. Not sure who manages server-side installations, but given how long it took for a simple BB Code spoiler to be re-added, you might be waiting some time. Would be good to have it implemented though.

Just nerf the smaller reaction wheels. They've needed it since 0.21 and the 0.22 SAS rebalance.

"End flight" dialogue all over again. One confirmation is fine. The reasons for making an error on the first confirmation (habit and haste) wouldn't be prevented by the second. I don't think I've ever deleted a flight unintentionally.

Probably for the same reason that people use KER instead of mechjeb. Or something.