asmi

I think you guys are expecting too much from Squad at this point - remember they've got only 2 or 3 developers who actually write code, and aero overhaul will eat up a lot of time and involve fair amount of head scratching and brainstorming (if you don't believe me - ask Ferram - and he's EXPERT in this area while Squad devs are not). I'd say if they will get aero more-or-less working as they want it to for the next update - it will be good enough.

RealFuels mod supports SRB thrust curves for quite some time. It doesn't have GUI to edit them thou - NathanKell told me a while ago that it's in works, but it's not there yet. In the mean time you need to use config files to edit it (Bob Fitch provides a good guide on how to do it in one of his videos).

ATM is hard at work...

Experienced players don't need it by definition. Besides keeping the code there will just make Squad's job at supporting it harder.

I know - I've tried to explain why they are implemented by different mods. There's WIP mod RealHeat though which aims to implement proper thermodynamics, and ferram is consulting developer (who himself works for NASA/ISS and knows what he is doing). So hopefully it will cover that area.

They are different because they target different subsystems of simulation, one of them (applying physical forces to parts) is realistic (well as realistic as PhysX is), another (heat transfer/management) being placeholder-to-the-point-of-being-almost-useless.

Good. As long as Squad keeps their intention not to screw up FAR, I'm fine with whatever they do (even if that means zero new content for me in the new update).

THAT is the thing - most plausible-looking designs I came up with actually perform well with FAR, or can be made as such with relative ease. Basically if the vessel looks like it will fly - it most likely will fly with FAR. I would like to see practical examples of "plausible" builds that would have problems with FAR and yet not belong to any of categories I've mentioned above. That sounds like a good candidate for inclusion into difficulty settings. Although I'm not so sure about aerodynamic failures - I'd dare to say most (unprepared) people would expect planes to fall apart during high-G manoeuvres. I'm sorry but from my own experience with FAR it's not that easy to build a plane such that it would fall apart from aerodynamic failure, moreso when I totally didn't expect it to. I think the problem with reentry heat is that existing thermal management system is also kinda "placeholder'y", and that was a major issue DR had to deal with at some point (and there are still issues in DR that crop up every so often).

My statement still stands - if they will make aero system (un-)pluggable, dedicated enough fans of stock "aerodynamics" can build a mod that recreates their experience, while if they will hardcode new implementation we all will be stuck with that option. I prefer to have a choice. Honestly I don't see any reasons NOT to use FAR/NEAR other than building lolcraft, infinigliders, pancakes and similar ridiculous stuff. The perception that FAR is complex is grossly overstated. But this is just my personal opinion as someone who haven't played non-RSS KSP for over a year.

So you know nothing about FAR yet you make a statement on how realistic or not it is? Hmmm...

That is why I'm worried a bit. But I hope they realize the pivotal role of FAR for a big part of community who don't buy this "ololo bam-bam explosions lol lol so kerbal moar busterz" motto and are looking for more realism, and approach this task with utmost care. At the end of the day they've managed to build KSP to enable so many awesome realism-oriented mods that keep myself personally in game.

I'd say whatever they do is fine as long as they would make sure FAR can still be implemented to replace it. The reasoning is quite simple - you don't need to be an aerospace professional to build a craft for aerodynamics, but you DO need to be an expert in order to implement a proper simulation. And since to the best of my knowledge Squad ain't got one on their team - well you get the idea. Besides - I use FAR curves and simulations a lot during design (yea I went into "trouble" of reading up on them to figure out what they are and what they mean), and so far Squad seemed to maintain a motto that numbers scare away people (that's why we still don't have deltaV readouts in stock). Well - I DO need these numbers. For me KSP does not exist without FAR with all its instrumentation since I started using it about 2 years ago or so. This is the single most important mod for me - I can make do without all other mods, but this one is absolutely must.

I gotta thank you for amazing writing - can't wait for the next chapter!

Good. Please keep in mind that I did make significant simplifications in order to better "crystallize" the principle. The most important one being that in reality - while it is true that to change inclination you burn along normal direction, you need to realize that the system of coordinates itself rotates as you burn - because it's defined by three vectors (velocity vector (X), radius-vector from the Earth towards your craft (Z), and normal to the plane defined by X and Z (Y)), and one of these vectors changes its direction (velocity vector, or X on my picture), causing the the normal vector to follow. By the way this is exactly why it's very hard to plot high inclination changes using vanilla KSP's maneuver node - as you drag your normal direction farther, you see that Pe/Ap change as well, and for very high changes there is a point at which further increases into "normal" direction changes Pe/Ap much more than the actual inclination (try getting into low orbit, create a maneuver node and pull normal hard - you'll see what I mean). This happens because KSP assumes you apply the entirety of deltaV instantaneously, while in fact if you'd burn normal you'll have to constantly steer your vehicle as "normal" marker drifts away. This might sound rather confusing (that's why I skipped that part), so I'd suggest you get into stock KSP's sandbox, go to the Minmus orbit (it's useful for these things because orbital velocity is low there and so you can change inclination and even reverse orbital direction for a very modest amount of deltaV) and start burning in normal direction - you will see how normal and prograde vectors' markers shift around (while radial marker stays put because it always points from the center of celestial body to the craft). Scott Manley in the Part 2 video I've linked gave a correct formula for inclination change calculations using cosine theorem, which is a generalization of the Pythagorean theorem onto arbitrary triangles.

Try watching Scott Manley's "Orbital Mechanics on Paper" videos: Part 1 Part 2 Second one explains why inclination change is cheaper when velocity is smaller. For combining burns into a single one: On this picture X is prograde direction, Y - normal, Z - radial. I is inclination. To change inclination you burn in normal direction (Y), to circularize - in prograde direction(X). Normal and prograde vectors are perpendicular (by definition) Here dVn is inclination change burn, dVp - circularization burn, dV - combined vector (I've omitted Z coordinate as it's irrelevant in our case). As you can see, dV = sqrt(dVn * dVn + dVp * dVp). It's not *entirely* true story, but I hope you will get the principle.

It's not me - it's a basic math. Once you realize that inclination change vector and circularization vector are perpendicular to each other, you can apply Pythagorean theorem to figure out combined vector, and as we all know hypotenuse is always smaller than the sum of two other sides. If you won't manage to do it, prioritize changing inclination over getting circularization right - fixing apogee later is much cheaper than fixing inclination after you circularize.

Try combining inclination change and curcularization into a single burn at apogee/node and be prepared to be amazed to realize how much deltaV you're wasting for not doing so (this is especially ridiculous for high-latutude launches like 51.6 from Baikonur where the difference is huge).

Period of geostationary orbit has to be 23hrs 56min 4.0916sec, not 24 hours. You can read explanation here: http://en.wikipedia.org/wiki/Sidereal_time

These pads will exist anyway (for A5). I'm honestly not sure what's the strategy of Soyuz 2.1v vs A1.2 is though, so I guess we'll see.

IDN standard has been implemented only in 2010, before that top-level domains had to use ASCII. That's not true as well, as accoring to IDN all non-ASCII domain names have they equivalent in ASCII precisely to allow anybody to access it. Here are some more details: http://en.wikipedia.org/wiki/Internationalized_domain_name But this is offtop here.

My point is that - despite what some people are saying here - scientists and engineers do make incremental improvements to existing technologies (RD-0124 first flew in 2001). But nobody in their right mind expects anything revolutionary coming out of this, since we came very close to limits already. And talking about ORSC engines - it's material science is what's limits improvements (for higher efficiency we need higher pressure, but existing materials are not strong enough to withstand these conditions). Just to make it clear - we're talking about the kind of conditions that burn steel in a split second.

Isp of RD-0124, the most efficient KeroLOx engine in the world, is 359 sec! Right - just one second below what's theoretically possible! The only realistic way of making more than marginal improvements is to hit into material science hard. By that I mean inventing materials that are 1) stronger 2) lighter 3) cheaper all at the same time. Also ORSC engines are very heavy due to extremely harsh conditions they need to withstand, so making them lighter would also help.

This looks awesome! Sorry - I had to say that

Any chance to get engine group controller in? I think a lot of people would find it useful - especially in light of recent D4H/Orion flight

There are few exceptions though in real life - for example RD-0146 engine has been repeatedly test-fired using HydroLOx and MethaLOx. RD-0110 has also been fire-tested with MethaLOx, but there were modifications (although as far as I know they were mostly aimed to adding more instrumentation to a serial-produced unit that was meant to run on KeroLOx). There are also rumors that NK-33 can also run on MethaLOx (couldn't find reliable sources to confirm or deny it, although it is known that it's quite accommodating with regards to fuel - the same unit can run on both RG-1 kerosene and RP-1, either subcooled or not), and there were studies for modifying RD-1xx family engines to run on MethaLOx (can't remember which exactly engine it was). So some combinations of fuels are actually plausible, but not mixing up hypergolics and regular fuels as they drive radically different engine designs, and just about the only part that can be re-used is nozzle bell.