RidingTheFlow

You missed it, here is the one, and it acknowledges the problem (though I'd find "placeholder works good enough" bit alarming). http://forum.kerbalspaceprogram.com/threads/82842-Exactly-how-bad-is-the-aerodynamic-model-in-KSP?p=1210627&viewfull=1#post1210627 Personally I don't really care about hypersonic shock, how drag is exact and such. All I want, is that tube which heavy in the front and light in the back flies forward. This is basics of cavemen aerodynamic design which even children know when they launch paper airplanes.

Sorry, probably these concepts are too alien for my mind then As I said I tried to apply the simple way you describe - but it doesn't seem to work every time, so I gave up, and just slap B9 airbrakes at the back - this seem to work every time, probably due to massive drag they have enough to overwhelm everything else. Problem is, even if you master it perfectly, its pretty useless (and not educational like rest of KSP). Probably both lift & drag needs fixing. Since in lot of cases "stabilizing fins" don't really stabilize anything.

Yup. Its actually not simpler than FAR, because it has low of own quirks - and you have to learn all these quirks which completely disjointed with what you expect from real world (even in crude approximation). This makes for really unproductive experience - and one of most respectable things of KSP I thought was how educational it is, in everything except this. FAR is not that hard actually, because, well, it follows real world. And I've got experience with it, suddenly I've noticed that I can get same payload to orbit with launcher twice as small (fairings and all of that) - and this pretty much destroys balance, because I know that all crafts I design for FAR will be hopefully unusable with stock...

Its not that simple. One time I think I've got how it works, next I am pulling my hair out trying to understand why my craft flipping around or turns to the side and starts rapidly spinning... Or why my plane is more stable flying tail-first and its impossible to point nose forward once it starts doing that. Probably one of the issue is that "drag values" don't really follow the parts "look and feel", and also there are some values which don't even show in editor I believe.

I don't mind exact math behind drag (e.g. how exactly it slows ship down for particular mass or will it burn down or not). My main issue is that it creates very strange and counter-intuitive rotational forces (e.g. in most cases crafts orient themselves in opposite direction you'd expect them to, and it nigh impossible to make them behave the way you want, at least unless you use non-stock parts like B9 airbrakes).

I still have hope for one of next big updates bringing both re-vamped spaceplane parts, and improved aerodynamic, this will make perfect sense from development & release standpoint.

If not mk3, can we at least have bigger mk2 cargo bay? current one have zero clearance top-bottom (and this is with paper-thin doors already). Its not possible to put anything there with even smallest side attachments (unless attached to sides only) - which pretty much precludes it from use, say, for landers. Can we have a cargo bay that "taller" in vertical direction?

Umm.... Yes? And? "Doing something" is the whole point of the game? Anyway I don't exactly understand how it supposed to work automatically, considering multitude of possible abort modes. Even auto-staging gets it wrong very often.

Good video, my major gripe with KSP "placeholder" model always was that it completely counter-intuitive when it comes to anything which involves "balancing", and its nigh impossible to make your craft act as you want in the atmosphere. Basically, the most complex thing that it does right, is "faster craft goes in atmosphere, more friction force it gets". If you try to look at anything more detailed, its wrong. And issue is, all stock parts are balanced in mind for this broken model, so game experience changes too much, if you, say, use FAR.

Even if its game size, its does not really matter... Size increase could mean good thing (more content) or bad thing (more unnecessary things, bloat). And size decrease could mean both good thing (optimization) or bad thing (less content/cuts). So drawing graphs based on size don't really correlate with how "better" or "worse" game became.

Size in mb is hardly quantitative measurement of work effort. Its pretty easy to make big size update - just throw bunch of high-res (not even necessary good quality) textures in.

To be fair this is trade off for getting earlier financing for your project development. Try to go traditional way instead and secure development funds via contract with publisher? You will soon find out that these "business guys" in lot respects worse than aforementioned thousand kids - at least these kids are not your bosses you legally obliged to obey

I like this mod. Its lightweight, and does what I want (to transfer crew when docked instead of going on EVA, CLS-aware). Ship manifest tries to do too much and the interface is too complex for my liking.

This is not KSP, its normal behaviour of Windows for any program under 100% CPU utilization. Unless "physical core parking" is enabled (or affinity mask is used), Windows will schedule even single thread over different cores, resulting in "25% load of each core" instead of "100% load of one core" for 4-core CPU for example.

Not necessary, since Harvester already mentioned that you won't get full cost back even if you return it to pad. With SLS parts being crazily expensive, even if you get 75% back, it will still hurt to do without good reason.

Mainsails were never really intended for upper stage usage (Skipper was intended for this role). But people just had to use Mainsail for lack of other heavy lift upper stage engine. And so KR-2L was added for this purpose, being specific super-heavy lift second stage engine no wonder it outclasses Mainsail. But you have to wait untill budgets&costs come in play, it will make you reconsider many points, as "high class" engines will be hard to afford

Next update plans to increase ISP of Mainsail making it more competitive and more appropriate for liquid <b>booster</b> (very high TWR, lower ISP).

I found that with SSTO with maximum possible payload its absolutely essential to get as much ISP of jet engines as possible. 0.24.5 makes it much easier, because jet engine will automatically throttle down if intake air goes low - it only creates problems when several jet engines throttle down asymmetrically due to subtle intake differences. It solved quite easy, either by having enough vectored control authority, or by leaving just one center-placed jet engine running and gradually switching rest off (in pairs), this allows to get this extra high-ISP jet thrust up to 40+km before full flameout (or thrust becoming too low to be useful). Shallowest ascent angle found quite easy, by monitoring TtA, and making sure that it stays approx. constant, say, in 1-2 min range.

No such thing. "native word size" is not even 64-bit on modern Intel CPUs which use RISC-like VLIW native execution engines, translating from many-years old CISC x86 instruction set on the fly. As other people rightly said to you instruction sets for FPU stay the same regardless is CPU is in 64-bit execution mode or in 32-bit. And regardless of mode it does not change performance of FPU, since hardware stays the same. 64-bit execution mode could give performance boost for apps specifically tailored to handle 64-bit integer values (and having to emulate them in 32 bits), also some minor benefit comes from more available (integer) registers in x64 mode, allowing more code optimization. Note that managed .NET apps (like Unity) could "transparently" benefit from more available memory in x64 mode, since this reduces memory pressure and required GC cycles (even when there is enough memory in both modes, it helps to have more available).

Ditto. Making able to build good spaceplanes becomes important and makes perfect sense since budgets will put big emphasis on re-usability & cost saving. Proper re-entry mechanics also important to avoid abuse of current re-entry to land&recover senselessly non-aerodynamic & huge ships (and skew cost balance too much).

Tried it and it works fine for me with EVE & all mods without active texture management, save for some blinking on clouds and briefly wrong scenes on scene switch loading. I think SQUAD definitely should take a careful look of it - most likely with some minor fixes/tweaks it should be completely production-ready (at least as option).

You can use several overlapping heatshields, that what I do.

Why a few extra parts will require lifter twice as large? Main weight on interplanetary ship are engines & fuel. I never had issues bringing the whole nuclear-powered craft back to Kerbin, aerobraking it and landing - its just single quick step, instead of aerobraking, circularizing, rendezvous with space station and docking, and then same again to ferry to/from station (I _can_ do it, but it just feels like unnecessary waste of time).

I thought about it more and one possibility I see that "landed part recycling" not returning full costs, just some percentage. Or adding extra charge just for ship re-build/part refurbishing. This will both still have advantage on landing as much as possible, but "permanent" ships & stations will give the very best cost saving.

Well, for myself I would just slap parachutes & legs on ship, land it, collect the parts, ready to re-launch - why bother with supplying station with fuel & spending time on docking & rendezvous? The issue is that with current stock re-entry its way to easy to get pretty massive/unaerodynamic designs back to the ground - and economics have to be balanced for stock. If you make financing generous, so "classic" discarded rockets won't be issue - then it will make you earn too much profit if you switch to such returnable turnaround. If you make financing tight, so it will force to parachute everything back, this kind of even worse.