[0.90] Stock Drag Fix - Mar 19, 2015 (BETA UPDATE)

[Justin Kerbice]

I saw you've managed to remove unwanted files, that's great .

By the way, I'm going to need some kind of repro information here besides 'someone stole my antenna' or 'try it and see if it happens to you'

I need to know exactly what happened to the antenna and how you got to where the antenna detached itself.

It's so basic in fact that I'm really surprise it behave like this:

I build a small rocket (just a command probe core, some fuel tank and an engine), add some RT2 antennas (the modified stock basic one for example), I extend it, comms are ok, but when the rocket reach ~ 100 m/s => antenna made a self-eject itself (like a broken solar panel, but without debris style anim as I guess there is none here), whatever the angle is (radially attached or on top of a wider fuel tank like this:

    FFFFFF  A
    FFFFFF  A
BFBFBFBFBFBF
BFBFBFBFBFBF

with F a 1.25 m diam. fuel tank, BF a 2.5m diam. and A the antenna.

Like this (two antenna out of four was extended before, one of the space left by missing antenna is visible on the right):

(note: RT2 doesn't seems to be save-friendly, I means you have it or not for ALL your games when it is installed, not really cool IMHO).

[Starwaster]

Also on the test result front, seems to mess with MJ's ability to calculate terminal velocity, or somehow changes terminal velocity values. rockets I have built that previously would throttle back during a MJ launch due to terminal velocity now do not. I don not know if the values have changed, or if MJ cannot accurately compute TV because of changes due to this mod, nor do I know how to find this information.

I'm not quite sure what's happening with terminal velocity. I need to do more in-game testing but it seems like terminal velocity is much higher than it should be. I did three tests: stock, FAR and SDF using a small 1.25 fuel tank and also consulted NASA's terminal velocity calculator and SDF just seems to be several times greater than it should be. There's a parameter in the settings file that can be used to tweak drag, and I haven't really tried any alternate values yet. The thing is, at its default setting, rockets are experiencing what seems to be the right amount of drag (experimentally). So I'm hesitant about changing the scale because it seems like it would have to be scaled too extremely.

This seems pretty neat.

Have you thought about changing lift to be proportional to v² instead of v¹? The linear proportion in stock leads to some unfortunate effects at very fast and very slow velocities. Drag dominates lift at high velocities, meaning a spaceplane can't adjust its trajectory on re-entry, and the opposite is true at low velocities, which I believe leads to infiniglide.

Also, nice job on breaking the aerodynamics fix monopoly!

I haven't given consideration to altering lift at this point as it that involves a different set of parameters. However, there is a lifting surface module (ModuleAerodynamicLift that is currently unused in stock KSP. It was unveiled and discussed nearly two years back. But to this date it is unused even by Squad. Given the way it was talked about, it seemed like it was ready to go. Either that's not the case or Squad simply hasn't gotten around to migrating the Winglet parts over. Mu talked about it here

and shared a good bit of the code behind it. It references velocity squared in its equations so it seems like they were taking realistic lift into account though I have't delved all the way through the math. If it's functional, it might be worth migrating some parts over and seeing how they perform.

The reaction to this should be particularly interesting to see; it's nice to actually have some competition in the aerodynamics realm.

A thing that you might want to mention is that drag-related instabilities are now a thing that players will need to think about, even though this isn't FAR or even FAR-lite. Since drag and (total) mass are now decoupled, the center of drag and the center of mass are no longer necessarily in the same place, and that will allow stability issues to crop up, although I don't think they'll be as severe as the ones in FAR.

I hadn't considered that CoD might actually be affected though I did notice my test plane's stability affected when I jettisoned some drop tanks. No, definitely not to the extent FAR might have....

I saw you've managed to remove unwanted files, that's great .

It's so basic in fact that I'm really surprise it behave like this:

I build a small rocket (just a command probe core, some fuel tank and an engine), add some RT2 antennas (the modified stock basic one for example), I extend it, comms are ok, but when the rocket reach ~ 100 m/s => antenna made a self-eject itself (like a broken solar panel, but without debris style anim as I guess there is none here), whatever the angle is (radially attached or on top of a wider fuel tank like this:

I seem to recall seeing somewhere that some (not all; the animated ones that extend) antenna can break if extended in the atmosphere with any serious speed. Edit: Yeah, just took a look at RT2's antenna code and it will snap under high dynamic pressure (exact threshold configurable per antenna). I don't know why you haven't seen that happen prior to trying this mod. Unless maybe it had something to do with FAR nullfying stock aerodynamics and you had previously used it under FAR. The RT2 forum thread also makes some mention in passing about making RT2 FAR compatible and I can't think what they might have referred to except the antenna...

At any rate you should probably take it up with them, but it looks to me like it was performing as it should

(note: RT2 doesn't seems to be save-friendly, I means you have it or not for ALL your games when it is installed, not really cool IMHO).

That's pretty much the norm for plugin mods. A mod would have to be specially designed to only apply to specific games. They need to store enabling configuration in the save file (probably via a SCENARIO{} node) and then implement enabling/disabling code based on that setting. I'm not sure any mods that are out there are set up to do that so it seems unfair to single out RT2.

Edited July 6, 2014 by Starwaster

[vardicd]

I saw you've managed to remove unwanted files, that's great .

It's so basic in fact that I'm really surprise it behave like this:

I build a small rocket (just a command probe core, some fuel tank and an engine), add some RT2 antennas (the modified stock basic one for example), I extend it, comms are ok, but when the rocket reach ~ 100 m/s => antenna made a self-eject itself (like a broken solar panel, but without debris style anim as I guess there is none here), whatever the angle is (radially attached or on top of a wider fuel tank like this:

    FFFFFF  A
    FFFFFF  A
BFBFBFBFBFBF
BFBFBFBFBFBF

with F a 1.25 m diam. fuel tank, BF a 2.5m diam. and A the antenna.

Like this (two antenna out of four was extended before, one of the space left by missing antenna is visible on the right):

http://i.imgur.com/LkyyIR1.png

(note: RT2 doesn't seems to be save-friendly, I means you have it or not for ALL your games when it is installed, not really cool IMHO).

Uh, I get that behavior on the default RT2 mod. that's standard and has nothing to do with this mod. you need one of the fixed antennas for in atmo flight.

[marach]

I haven't given consideration to altering lift at this point as it that involves a different set of parameters. However, there is a lifting surface module (ModuleAerodynamicLift that is currently unused in stock KSP. It was unveiled and discussed nearly two years back. But to this date it is unused even by Squad. Given the way it was talked about, it seemed like it was ready to go. Either that's not the case or Squad simply hasn't gotten around to migrating the Winglet parts over. Mu talked about it here

and shared a good bit of the code behind it. It references velocity squared in its equations so it seems like they were taking realistic lift into account though I have't delved all the way through the math. If it's functional, it might be worth migrating some parts over and seeing how they perform.

Hmm I wonder if modder has ever bothered to test this code to see if it works or even what it's effect is.

[Justin Kerbice]

@starwaster: ok and the weird thing is I play RT2 without FAR, on a test 0.23.5 install, and I have extend some antenna in atmosphere on rocket which speed only increase. Never witness a brake. Don't understand.

For the mod apply to a save, it may be more or less complicated, but some mod are not "global" like Extra Planetary Launchpads, you can play with a save and do all the work needed to drop a ship far away from KSC, and you can play normal game without bothering of all these work (and even hide all parts with SPO).

RT2 may have an ON/OFF trigger on its toolbar button maybe but it's not related to your plug-in .

@vardicd: ok.

[Jahulath]

Really excited to try this out - I always wondered why it makes no difference if my tanks had gas or not . I look forward to slamming into Kerbin at a rate of omfg where did the ground come from! And then to do so much less with less fuel of course.

For the aerial issue folks, I thought that was stock behavior? As in never unfurl your Photovoltaics when moving or don't take off with the aerial extended... Didn't RT have a trash can lid for exactly this purpose? If this stock behavior is triggered by speed NOT drag and this mod allows you to get more speed by reducing drag then like your gonna have a bad time. Maybe I have just misunderstood.

[Starwaster]

Ok, regarding MechJeb2 and landing predictions, I took my KSP back to stock except for leaving SDF installed. No Deadly Reentry, so I could use a stock lander all the way through reentry. No Real Solar System and no Real Chutes. So everything except drag is just the way MechJeb expects it.

MJ2 was 46 meters off target and I'm going to lay that entirely on Mech Jeb because it knew it was off target. Its prediction for the final 2km was 46 meters and ~46 meters it was. (note the target marker says 51, but it's a few meters lower in elevation). So it gave an accurate prediction and decided on final approach to live with the results. (picture at bottom of post)

So, the question is, how many people are using this with Real Solar System? Because that's the primary reason any of us really notice and want to do something about drag AFAIK. And MechJeb has certain codified perceptions regarding the atmosphere, which is that atmosphere cuts off after air pressure falls below 1e-6. That means that as far as MJ2 is concerned, a RSS sized Kerbin's atmosphere only extends out to.... I think it's 106km? I forget the exact altitude because it hasn't been true for a long time ever since we went to non-legacy atmosphere for Kerbin. The new atmospheric cut off is at 180 km which means MJ2 is ignoring 74km of atmosphere for braking purposes. A lot of that is negligible above 120km but that still leaves enough to throw off its calculations.

[Whirligig Girl]

You mean like, reality?

I am aware this happens in real life, but I don't think it's fun for a game about absurdly-made rockets.

So, the question is, how many people are using this with Real Solar System?

I use it with 6.4:1 Scale Kerbin.

[Starwaster]

You mean like, reality?

Hey StarWaster can you compare this to FAR? Are you trying to deal with something FAR isn't, or are you duplicating some of what FAR does while leaving the rest alone? Just trying to understand where each sits on the playing field.

Interestingly enough, I just did have a rocket flip out using this. It was a lot squatter than what I usually make but it didnt seem unreasonable as a design.

I had to lengthen it quite a bit to stabilize it, from a single stage to two stage. Ferram had indicated that instability could still be a thing since it was possible for center of drag to be different from center of mass but I hadnt seen it happen yet.

[NathanKell]

This isn't a game about absurdly-made rockets per se; rockets are absurd because aero is broken and parts are (mostly were) wobbly. You're mixing cause and effect.

Many, many people when they first start playing KSP make their rockets looking like real rockets. Pretty natural. It's only once they find that due to weird issues in the game physics that other rockets work better, do they change to that.

[BigFatStupidHead]

I am very interested in this. FAR aerodynamics are way more complex than I want, but stock falls short. Thanks!

[rynak]

Dito. I too am running this and will follow its development. FAR's complexity/realism as well as performance cost isn't to my taste. I don't need or want a fully realistic aerodynamic simulation. I just want aerodynamics to have some reasonable effect, without simulating too much, so that:

- designs behave someway intuitively

- as a result, tweaking designs for aerodynamics can have (reasonable) benefits

- performance is barely affected

So, not a full-blown simulation, but just accounting for overall basics like:

- "this plane has quite a lot of wing area... will probably lift well, but won't get too fast"

- "i should put fairings/cones on this stuff... to reduce drag and safe fuel"

Basically, accounting for stuff any newb could notice just be looking at a craft.

[nubeees]

Quick question:

Does this mod make cargo bays and fairings useful (other then for aesthetics)?

[Starwaster]

Quick question:

Does this mod make cargo bays and fairings useful (other then for aesthetics)?

Not at this time, but that's going to be in the next update.

Right now I'm just trying to nail down the exact method I go about implementing how payload is detected. (all payload parts will have drag zeroed out)

Procedural Fairings will be easiest to check that for.

Nose cones are also something I'm looking into....

[nubeees]

Not at this time, but that's going to be in the next update.

Right now I'm just trying to nail down the exact method I go about implementing how payload is detected. (all payload parts will have drag zeroed out)

Procedural Fairings will be easiest to check that for.

Nose cones are also something I'm looking into....

Ok

I was thinking it could work somewhat like Deadly Reentry, where parts blocked by other parts are not heated.

(I'm not actually quite sure on how DR works)

[Jahulath]

Functional nose cones and drag cancelling fairing FTW. Add those and this hits my completely indespensible list of mods! Fyi I have been really enjoying what you have so far, the pleasure of watching stuff scream off to the ground cos it's full is ace and I have a reason to manage my fuel!

[MainSailor]

Nose cones are also something I'm looking into....

I'm assuming then that with this plugin currently, nose cones act the same way they do with the stock game model, they just add additional drag and mass penalty (albeit adjusted, so to speak, relative to more weighty parts)?

Edit: Another question based on Ferram's point:

A thing that you might want to mention is that drag-related instabilities are now a thing that players will need to think about, even though this isn't FAR or even FAR-lite. Since drag and (total) mass are now decoupled, the center of drag and the center of mass are no longer necessarily in the same place, and that will allow stability issues to crop up, although I don't think they'll be as severe as the ones in FAR.

Does this adjust center of lift marker in the VAB/SPH like FAR does? That is, if the marker moves at all because the drag doesn't change, just the rocket's behavior in said drag does.

Edited July 15, 2014 by MainSailor

[enneract]

If this implements drag shielding for payload fairings, I doubt I'll use FAR again

[AngusJimiKeith]

So, how does this mod affect typical ascent profile? Would I still gravity turn at ~9-10 km? Should/could I start earlier?

IIRC, the main reason people turn so late in stock KSP is the drag issue, so I would think this would at least help with that.

In any case, if fairing drag shielding is implemented, this'll become a must-have for me!

[CaptRobau]

I'm assuming then that with this plugin currently, nose cones act the same way they do with the stock game model, they just add additional drag and mass penalty (albeit adjusted, so to speak, relative to more weighty parts)?

Since 0.22 stock nose cones improves stability of craft in the atmosphere. Don't have any numbers though.

[Starwaster]

I'm assuming then that with this plugin currently, nose cones act the same way they do with the stock game model, they just add additional drag and mass penalty (albeit adjusted, so to speak, relative to more weighty parts)?

Correct. Given the approach that I've taken with this plugin, it wouldn't even be enough to reduce drag for the cone to zero because it would still add mass that would affect your final delta-V. What will have to happen is that the other parts in the stack under the nosecone will have to have their drag altered. That's actually very easy, problem is going to be by how much. The test rockets that I've sent up (three times each, stock, SDF and FAR) tell me that a simple rocket without a nosecone in SDF has comparable performance to the same rocket with a nosecone in FAR. Without a nosecone, the drag FAR assesses against the rocket results in pretty substantial losses to delta-V and therefore final maximum altitude.

So, with SDF, there is actually too little drag. When I do something about nosecones, I'll have to increase the total drag felt by the rocket when it has no nosecones.

Also see CaptRobau's comment about stability.

Does this adjust center of lift marker in the VAB/SPH like FAR does? That is, if the marker moves at all because the drag doesn't change, just the rocket's behavior in said drag does.

CoL marker is not modified at all. In theory the stock code might change it if the drag change results in changes to lift. And the plugin only operates during flight mode and not in the editor. I'll most likely look into adding another marker to represent center of drag in the editor. I'm having less luck with adding any debug markers than in other areas of code that I've done in the past however

So, how does this mod affect typical ascent profile? Would I still gravity turn at ~9-10 km? Should/could I start earlier?

IIRC, the main reason people turn so late in stock KSP is the drag issue, so I would think this would at least help with that.

In any case, if fairing drag shielding is implemented, this'll become a must-have for me!

It does affect it. I wouldn't say that turning early is a strict requirement with SDF, but there are benefits to doing so because turning late (5-9km) is just plain inefficient. Early turning means that by the time you reach your orbital altitude you'll have to burn less to finalize your orbit.

And it's still possible that some rocket designs might be less stable with late turns. I've never been very big on the 'asparagus' thing so even when it wasn't necessary to build aerodynamically stable rockets, I usually built them as though it were necessary. So I just don't have a lot of unstable rockets in my catalogue to test with. Except for one recent rocket that has stability problems with SDF just as it might have in FAR. It is a definite test candidate for when I finish the fairing code.

Since 0.22 stock nose cones improves stability of craft in the atmosphere. Don't have any numbers though.

I'm a little skeptical of Squad's claim about nosecones from 0.22 on. They just haven't done enough changes to the stock drag system that I can see as having any effect on cones. AFAIK they've always had a lower drag rating and the drag system has always resulted in rockets orienting towards their point of lowest drag. What I think (and this is just my opinion) is that they did make some change that they thought would affect cones but then just never really tested it to see what the actual outcome was.

There are alternate drag models that might affect cones if they were set up to utilize those drag models but as best as I can tell, they just aren't set up to work with anything except the default drag.

And there's actually some disabled code in SDF that attempts to assign the conical drag model to cones but AFAIK, all the conical drag model does is apply different drag to the cone based on its orientation to its velocity vector. Enabling it doesn't have any effect right now because the maximum_drag for nose cones would have to be increased. Eventually I'll go back to experimenting with it but it will always be an optional thing for SDF because it will definitely affect MechJeb's reentry predictions. (that's one of the reasons MJ has trouble with FAR is that FAR disrupts MJ's notion that drag will always be the same regardless of orientation)

Edited July 15, 2014 by Starwaster

[AngusJimiKeith]

It does affect it. I wouldn't say that turning early is a strict requirement with SDF, but there are benefits to doing so because turning late (5-9km) is just plain inefficient. Early turning means that by the time you reach your orbital altitude you'll have to burn less to finalize your orbit.

And it's still possible that some rocket designs might be less stable with late turns. I've never been very big on the 'asparagus' thing so even when it wasn't necessary to build aerodynamically stable rockets, I usually built them as though it were necessary. So I just don't have a lot of unstable rockets in my catalogue to test with. Except for one recent rocket that has stability problems with SDF just as it might have in FAR. It is a definite test candidate for when I finish the fairing code.

Awesome, I can actually use a realistic flight profile now!

[Starwaster]

Awesome, I can actually use a realistic flight profile now!

If you use MechJeb:

For stock Kerbin,

set your turn end altitutde to 50km

set your turn shape to 50%

For Real Solar System,

Set turn end altitude to 120-150km. If you have a good amount of thrust in your upper stage then 120km is doable and I've read some literature for Orion that had it ending its turn at ~120 which is what prompted me to try ending my turn at that altitude. YMMV with your rocket design. I think most rockets are closer to 150km for their ascent profile IRL...?

In each case, end pitch angle for your turn will vary according to the thrust you have in the upper atmosphere. You should still be pushing apoapsis away from you. If you're catching up to it then you should increase pitch angle. 2-5 degrees works for me. Usually.

And I've increasingly been using MJ with corrective maneuvers off in the ascent AP.

[AngusJimiKeith]

No MechJeb here, so I'll just fly a bunch of test flights and see what works best. I can report back findings when I have some for people who fly without MJ.

[NathanKell]

CaptRobau: all that is meant by that is that the nosecones now have <0.2 Cd, which means that proportionally the rear of the rocket will be making more drag per ton, which moves the CoL (really, Aerodynamic Center) back, which increases stability. tl;dr they decreased the drag values in the nosecones' part.cfgs.