thorfinn

Isn't that a bit too harsh? Strike fighters like the F111 can go (barely) supersonic on the deck in real life... then again, I suspect their ailerons aren't commanded by keystrokes to flap wildly around. Flying with a joystick should make things easier?

What? That looks to me one of the very last things that should be declared physicsless... (how does it even handle the joints to the stack then?)

Ferram says that future versions of FAR could dump tables of aerodynamic coefficients vs. various parameters to a text file; this at "compile" time in the VAB, for now, I've asked him whether they could be recreated in flight on demand. Do you think that could be enough to integrate flight trajectories with the simplifying assumptions made above? (i.e. following zero lift or maximum L/D or some other extremal point)?

not really: the difference in delta-V between a Kerbin-Eeloo transfer and a Kerbol escape (transfer to infinity) isn't really much. I don't see life support getting in the mainline game soon (if ever) so travel times aren't really a problem, so no incentive to flying much faster than a Hohmann. Future inner planets would be a much bigger challenge.

With three (four?) tiers of parts, I think meaningful balancing will be almost impossible until cost is introduced. There should be a slight general progression towards better engines in career mode after all, and some of the very first engines should become obsolete by the end (me, I'd add some 0.625m lowish Isp parts as the starter tier...). On the other hand, things like the Mk.55 should be avoided, that's certain The problem for now is that science isn't the best limiting factor at all, and Harv admits this... even if the tech tree was sensibly arranged (which it isn't). By the way, I think that to give a better choice, price should be dynamic: the more you use a part, the less it costs to you. This was a very real phenomenon in engineering (the "learning curve", refer to this page for details) and has only recently become less true due to computer controlled machining/assembly taking over everything. But KSP is set in the bizarro 1960s anyway, isn't it? If parts had a cost curve, the tradeoff between better and cheaper would persist for a lot longer: a dirt cheap RT-1 could be a sensible choice even very far in the future (since you've used thousands of those in your career by then) and a LV-T45 cluster would cost more or less than a Mainsail depending on your history. Old launchers could be soldiering on in the late game due to price, etc.

Skin drag is a thing, you know Also you probably aren't exactly at zero angle of attack. And the automatic fairings are not the same thing as the user-defined fairings that give the "shielded" attribute. That fairing piece is dragging with just 11.8 kg of force, I don't know your speed but it doesn't look excessive out of hand. By the way, @ferram, technical question: is there a way to access the VAB aerodynamics simulator while in flight? Could an external mod retrieve an L/D curve for the current craft? Doesn't need to be extra fast, I'm rethinking an old idea of mine

Well, since FAR can already chart L/D ratios in function of AoA and speed, could you try plotting three trajectories beginning at the entry interface? "MAX LIFT UP" / "ZERO LIFT" / "MAX LIFT DOWN", maybe with dotted/red lines if instability or excessive loads are detected. This assumes that the craft is controlled all the way of course, but I don't think that predictions of uncontrolled reentries of unstable things would be of much interest. No, no, better yet: plot a TARGET ELLIPSE on the planet! a red dot at the zero lift IP and the boundary at the maximum reachable distances (max crossrange, max/min downrange and mixes). Doesn't have to be realtime, one update every 10 seconds would be fine. It would be <robbaz>GLORIOUS</robbaz>

Help us eggrobin, you are our only hope

What happens to an asteroid that hits another asteroid, that's what I'd like the most to see (They feel super light for their volume from the videos, though.... some rebalancing mod is in order)

Beautiful explanation, thanks. By "previously existing", you mean stuff carried over from .12?

I have noticed a minor bug in the 0.13 experimental: after decoupling a tank from a shuttle, all the debris parts got labeled as shielded. If one switches to the tank, it is unaffected by atmo drag, but drag comes back if the craft is unloaded and reloaded. It is repeatable (you might notice that the pictures refer to two different tanks) I should add that the .craft file is mostly from 0.12.whatever, but one part was added in the VAB after 0.13 was installed.

While playing with my shuttle (which finally launches AND reenters quite well, the only challenge remaining is actually landing on the runway...) I wondered, would you consider adding custom control mixing? I.e. substituting the on/off buttons for pitch-roll-yaw with sliders that set the gain for each channel, from zero to full deflection. Shuttle elevons would have something like 15% roll, 100% pitch and 0% yaw.

Well, it's a missile now, and missiles do fly Lots of things can fly at a speed over 500 kph and a TWR over unity, as you most probably have here (KSP turbines are overpowered, more than its physics )

Thanks a bunch, I was going to ask just that but then I though "he just said he wants to redo everything, maybe it's too much of a pain"

Yeah, that's a problem when you build shuttles, with all the idle engines at the back of the glider the tendency to lawndart can get really strong. I don't remember, is there an extra drag boost specifically for engines or just for any unattached node at the back?

Krakensbane was a patch of an already existing system, I suspect they would have had to rewrite lots of things from scratch to keep the ship always at the origin. Also, remember that it cuts in only above a certain speed - I don't know where it's defined, I tried to get into the KSP code a couple times and never had the patience to really manage anything useful. Oh, by the way, since you're rewriting dozens of things if you happen to stumble on a way to rewrite the ASAS logic, please tell us (and tell Ferram before anyone else)

Gah. Sorry. As for the correlation with angular rates, do you mean the centrifugal force due to the phisics calculations being done wrt. the root part and not the center of gravity?

I think he was talking about a multiple star system, that shouldn't have such pressing issues: the other stars would be within a few dozen AU, and Kerbal-scaled AU at that. If separated star systems were ever to be implemented, I think that making each system its own island and considering interstellar flight a special case would be the sensible choice: there is literally nothing of interest in the void between stars after all...

It might just be a slightly squashed sphere from now on

I like a lot the alternate "realistic model" for the LV-Nc. Look at that, isn't it cute, doing its best to slow down my Moho probe train? (Or accelerate, depends on what frame of reference you like.) I'd have just a small suggestion for the emissive maybe: the graphite next to the nozzle throat (and the throat itself maybe) should be the hottest part of the engine, up to yellow at max temp.

Of course it does, at the very least 500 m/s less delta V to orbit compared to normal KSP going on 1000 for very streamlined designs, remember?

Crazy idea: let the user define some keyhole regions along the orbit (or maybe even auto-define them with suitable artificial stupidity) and when the trajectory drifts too far from one or more of them, adjust velocity to re-center the predicted trajectory through the next keyhole(s). Of course they would have to be defined in phase space, more than in regular 3D space, BUT it might be possible.... OK, end of crazy talk for today. Anyway, I'd worry about all this after the basic N-body is done Also: Genesis probe halo stationkeeping design << While many options exist and have been tested, a simplified version of a target point method developed by Howell and Pernicka [Howell 93] is used to generate the results presented here. The goal of this controller is simply to apply an impulsive maneuver, or ÃŽâ€V, in order that the error, the deviation in position between the actual trajectory and the nominal trajectory at some target time downstream, is reduced to zero >> LAST EDIT: Hey, not so crazy talk after all then (at least my physical intuition still works late at night, always nice to know. Don't ask me how to minimize a cost function over a 6x6 matrix though...) FOLLOWING DAY EDIT: it would be probably better to split the task in two cases, one for "weakly bound" trajectories (like L1 halos) where the thread-the-needle method is employed, and a "strongly bound" case for orbits at least up to geostationary where Keplerian parameters adjustment is periodically done (with some deadband)

Thanks a lot for this. Since I'm playing with FAR, Deadly Reentry et cetera and I'm full of mods I can't really appreciate the complete system, but the engines alone were a godsend. Non-OP engines with decent gimbals made my first shuttle possible. I'll keep watching this space anyway; I'm sure that someone will work on FAR compatibility sooner or later

After 0.24 comes out (so, no hurry at all ) I bet you'll want to look into how to handle the asteroids that will be introduced; they should be in the thousand-ton class more or less, and N-body will be perfect for moving them around in clever ways. I can see Scott dropping one onto the Mun with a fire extinguisher and a weak stability boundary trajectory already.

Please, read the first posts The point of much of his talk is that by using better, research grade code, you can be as fast or faster than KSP is today even with all the added n-body complexity. Also, Lagrange points (one capital, the guy came from Italy, not Chicago ) aren't all they're cracked up to be, it wouldn't be worth it to make an exception case just for them and hacky solutions are.... horribly hacky, no other way to put it. By the way: "That's pretty arrogant... I like that in a pilot" (cit.) Do you have an idea of how that would work?