Jump to content

Aerodynamics have changed substantially after 1.7.3


Recommended Posts

I spend a lot of time in Kerbin's atmosphere to get my spaceplanes into orbit. Recently I've made the switch from 1.7.3 to 1.10.0 and to my surprise I noticed a substantial increase in the delta-v requirements to get my craft to orbit. Some SSTO designs with slim margins in 1.7.3 are now unable to reach orbit at all. Now I know that KSP 1.8.0 had some issues with drag cube calculations, but according to KSP's version history this should've been fixed in 1.8.1.

I performed some basic aerodynamic evaluations to check whether my observations were legitimate or if was losing my mind... or worse, if my spacecraft flying abilities had deteriorated to disgraceful levels. Anyhow, I designed a simple rocket with a bit of fuel and LF ballast in the nose cone:

ZgILemy.png

 

Then I shot it straight up in KSP versions 1.7.3, 1.8.1, 1.9.1 and 1.10.0 (not 1.10.1, my bad, I'm not from the future) and logged the max altitude (repeated 5x per version, the standard deviation is indicated by the black error bars):

EUn0TZV.png

As you can see from the graph, there is a substantial reduction (>5%) in the rocket's atmospheric performance post KSP 1.7.3. Since this test rocket has few parts, a high TWR and shoots straight up, I can imagine that these effects are exacerbated the longer you spend in the atmosphere and are particularly detrimental for high part-count air-breathing spaceplanes that rely on building up speed in the lower and medium atmosphere.

@SQUAD Are you aware of this issue, and if so, are you looking into fixing it? Since the version history documentation doesn't mention any aerodynamic changes after KSP version 1.7.3, I'm assuming this wasn't planned. These changes greatly impact my designs so any info would be immensely appreciated!

Edited by Yakuzi
Link to post
Share on other sites

This kind of thing happens, for very little obvious reason, between versions.   The drag model introduced in version 1.2 is very very sensitive to small changes in the shapes of parts, and for reasons mysterious to me the computed drag changes slightly when the unity engine changes.

In your case, the drag-coefficient for the cylindrical sides of the probe core goes from 0.68 in version 1.7, to 0.70 in version 1.10 (by comparing PartDatabase.cfg between versions).   You can use a Module Manager patch to copy the old drag cubes into your new installation if you want, and then get the old performance.

Spoiler
@PART[probeStackSmall] {
 %DRAG_CUBE	{
  cube = Default, 0.294,0.6796,0.7279, 0.294,0.6796,0.7279, 1.402,0.9681,0.1515, 1.402,0.9704,0.1515, 0.2854,0.6611,0.7582, 0.2854,0.6625,0.7582, 0,0,0, 1.334,0.22,1.359
}}

 

Parts that changed the visual models had a bigger change in performance (bug report).

You have to redesign some of your craft when you change KSP versions.

If it makes you feel any better, new players have to redesign their craft between the tutorials and the game.  Players who try to build the very first craft from the training mission (which uses an old model) in a sandbox game (using a new model) see drastically different performance:

 

Link to post
Share on other sites

The drag was changed on purpose. From my understanding there was a bug that was causing the drag cubes to not be calculated correctly. 
So the extra drag is actually the result of a bug being fixed. 
EDIT: Except for engine plates, those have issues with drag currently. 

Edited by MechBFP
Link to post
Share on other sites
On 7/17/2020 at 7:20 AM, OHara said:

This kind of thing happens, for very little obvious reason, between versions.   The drag model introduced in version 1.2 is very very sensitive to small changes in the shapes of parts, and for reasons mysterious to me the computed drag changes slightly when the unity engine changes.

...

You have to redesign some of your craft when you change KSP versions.

...

So the drag cubes for every part are recalculated between every KSP version? Or are they dynamically calculated every time you start up KSP? Why not calculate them once and keep them consistent between versions? These changes have significant ramifications in craft performance, so I'm very puzzled why they're being made in the first place. Especially without notifying the player base.

My apologies for pinging once again, @JPLRepo @TriggerAu would either of you be able to explain what's going on?

 

On 7/18/2020 at 4:28 PM, MechBFP said:

The drag was changed on purpose. From my understanding there was a bug that was causing the drag cubes to not be calculated correctly. 
So the extra drag is actually the result of a bug being fixed. 
EDIT: Except for engine plates, those have issues with drag currently. 

This is news to me. Which version were those changes made? Could you share a link where the devs explained why they changed the drag on purpose?

 

On 7/17/2020 at 2:53 AM, Cavscout74 said:

Nope, sorry, I don't believe that.  This is some kind of conspiracy!!!   :D

2020 would not be my first choice for a travel back in time destination... Then again, maybe I had no choice :ph34r:

Edited by Yakuzi
Link to post
Share on other sites
6 hours ago, Yakuzi said:

So the drag cubes for every part are recalculated between every KSP version?  every time you start up KSP?

They are calculated on start-up whenever KSP detects a change to the part.  They are stored in PartDatabase.cfg which seems an obvious way to avoid recalculating on every start.

The part-creator can define the drag values in the .cfg file for the part, and many mod authors do so, and where there is such a definition it is used permanently.

Put that way, it sounds like a wisely-designed system.  The trouble is the resulting table of numbers is not popular with mod authors (example) and even my faulty sarcasm-detector senses that KSP maintainers are frustrated with drag cubes.   The mechanism for automatic generation is hidden from users and mod-authors, and when new artists joined KSP about 1/3 of their models had un-physical numbers in the automatically-generated drag cubes.

6 hours ago, Yakuzi said:

Could you share a link where the devs explained why they changed the drag on purpose?

All the intentional changes that I noticed were for purposes of bug fixing, so on the bug-tracker searching closed items for 'drag'.  None of the on-purpose changes that I know of happens to affect any parts in your example.  Simply the original scheme for drag is rather sensitive to how the layers of software, modelling to Unity to KSP, describe the exact shape of parts.

Edited by OHara
Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...