1.1.2 Drag increased by almost 20%?

[Thrimm]

I hope I'm in the right place to post this, but I've noticed a major increase in the applied drag after the recent update. I did some testing in the current 1.1.2, 1.1.1 and 1.1 versions of the game and noticed that 1.1 had significantly less drag applied than subsequent ones. According to what I could conclude, 1.1.2 applies almost 20% more drag, which is never mentioned in any of the release notes. (1.1.2 just introduced some optimization). This practically grounded 90% of my spaceplanes, so I'm curious if anyone else noticed this?

Here are some screenshots with flight data GUI for both 1.1 and 1.1.2. (notice that 1.0.5 aero was more similar to 1.1).

Flight stats in 1.1

And the same situation in 1.1.2

 

[bewing]

I assume that with such a monster that you have struts and/or fuel ducts in there? Those parts (and radial drogue chutes) accidentally got set with new insanely high drag values. It is almost certainly not "generic" drag that you are experiencing. Atmospheric drag itself is unchanged between 1.0.5 and now.

For many parts, their drag values are unchanged. For MK1 parts, the drag has been reduced by perhaps 25%.

[bewing]

@llanthas: BTW -- have you tried taking your little wheesley plane to 5km altitude, level flight, and going to full thrust? If not, you may be surprised what happens.

[Thrimm]

7 hours ago, bewing said:

I assume that with such a monster that you have struts and/or fuel ducts in there? Those parts (and radial drogue chutes) accidentally got set with new insanely high drag values. It is almost certainly not "generic" drag that you are experiencing. Atmospheric drag itself is unchanged between 1.0.5 and now.

For many parts, their drag values are unchanged. For MK1 parts, the drag has been reduced by perhaps 25%.

This is exactly why I'm puzzled. The values I could look up in the config files are mostly the same and drag multipliers are the same, so I don't know where this difference comes from.

This plane has some struts and fuel ducts, but nowhere close to the amount that would explain such behaviour in an intentional way. I've tried this with other planes I have and Mk2 planes seem to have similar problem, even without struts nor fuel ducts. The only ones that work fine are as you said, Mk1 planes. I'm going to see if removing drag from non-physical parts fixes the problem - I think it was the case anyway in 1.05.

[bewing]

2 minutes ago, llanthas said:

Yeah, it's going super-sonic around 1-3km.  Just a BIT overpowered/low-drag, I suspect lol.

Ha. No way. I have found that the wheesley is totally underpowered compared to the panther, so I was always using the panther exclusively. I much prefer mach 2 to mach .8 -- but this has brought the wheesley back into balance again for me. Mach 1.5 with good fuel usage and a ceiling of 15km is much more tempting -- and I think it'll be better for noobies, too.

[herbal space program]

The Wheesley can go supersonic now? Cool!

[sal_vager]

Been doing some tests here, just a probe core, flea SRB and a nosecone with a bunch of aerobrakes in 1.1, 1,1,1 and 1.1.2 (should have called it 1.1.1.1)

I'm reaching the same altitude each time, so drag seems to be the same, maybe there's something weird with Thrimms craft?

I don't usually suggest using the aero overlay (F12) as it doesn't tell you how much drag there is, but it can help pinpoint where it is.

[luizopiloto]

My shuttle are Stalling more easily on approach... maybe it's related to how drag is applied to angled surfaces...

[boolybooly]

21 hours ago, bewing said:

I assume that with such a monster that you have struts and/or fuel ducts in there? Those parts (and radial drogue chutes) accidentally got set with new insanely high drag values. It is almost certainly not "generic" drag that you are experiencing. Atmospheric drag itself is unchanged between 1.0.5 and now.

For many parts, their drag values are unchanged. For MK1 parts, the drag has been reduced by perhaps 25%.

Sounds credible.

[luizopiloto]

1.1.2 changelog says: *Optimized drag calculations
well... I don't know...

[zarakon]

AoA 5.874 degrees in the first screenshot, 7.004 in second

[Thrimm]

10 hours ago, zarakon said:

AoA 5.874 degrees in the first screenshot, 7.004 in second

That is true, but I was trying to maintain the same pitch for extended period of time in both cases - this is the result. I've also recorded a video of both flights for better overview so I am sure that there is a drag issue. I also did testing with other spaceplanes and results were similar, smaller Mk2 ones included. Issue seems to be present everywhere.

I checked if removing non-physical parts drag solves the problem, and in certain cases it drops the drag values to what was observed in 1.1 or 1.05. Another thing is that now default settings apply phantom forces to some of my crafts even when they are landed, but removing non-physical parts drag also removes these phantom forces. Building the crafts from scratch in new version of KSP doesn't solve it so it's probably not the port problem.

I tried applying the non-physical parts drag as parents centre of mass, but strange and horrible things happened, so I don't recommend doing that.

If someone has doubts about my crafts, then the simplest thing to make is download any ssto and check the deltaV while in orbit and compare it with what was attainable before (if you manage to get it to orbit in the first place). For me, the deltaV dropped by 25-30%, provided I managed to take off.

[herbal space program]

I played around with my  longest-range Mk1 SSTO design from 1.0.5  for a bit last night, and it seems like the air has gotten significantly more favorable for this sort of design. In 1.0.5 it could only go transonic in the stratosphere with some loss of altitude. Now it seems to shrug off the sound barrier as if it's not even there anymore. I presume this is because of the reduction in Mk1 part drag, and I'm really happy about it because it seems like it more than undoes the nerfing that these designs suffered in 1.0.5. My best-ever dV left on LKO in 1.0.3-4 was just shy of 6km/s (with nukes, no ions), which came down to around 5km/s in 1.0.5.Now I feel like I could beat even the numbers from 1.0.4. Unfortunately, I made the mistake of trying to upgrade my landing gear from the previous save and overwrote the original file, and I ended up spending the rest of my time struggling on the runway. I'm not sure yet  if this is due to all the wheel bugs people have been talking about or just my own problems adapting to the new parts, but it pretty much shut down my efforts to see what this plane could do for last night. I'll have to investigate further with a copy of that save file from a different machine tonight. It was very strange. When I had the plane as its original save, it took off just fine but the gear usually got damaged on takeoff. Then when I tried to use the next size up, the plane would not go straight no matter what I did and wanted to steer the wrong way. Inverting the steering on the gears made it steer the right way, but then engaging the SAS caused it to flip the wrong way. Without SAS it kept wanting to veer off course so much that takeoff was essentially impossible, and repeated attempts to re-place the parts fixed nothing. I sure hope I can figure these problems out tonight, because if I can then I think flying these Mk1 space planes is going to be a lot of fun again!

[bewing]

@herbal space program: the best answer I know is to turn off steering on the main gear, and crank the friction settings down really low on all your wheels.

[herbal space program]

14 hours ago, bewing said:

@herbal space program: the best answer I know is to turn off steering on the main gear, and crank the friction settings down really low on all your wheels.

Thanks for the pointers. I found last night that turning off steering on the back wheels helped significantly, and oddly that turning off the springs and dampers, while it made the plane do a ridiculous little dance while stationary, seemed to cause it to be willing to go straight down the runway once real forces were applied. I would start it off that way, immediately engage the brakes, then time warp briefly  to kill the physics and stop all the jiggling. Only then it seemed could I take off like I could before without inexorably veering off the runway. 

[Thrimm]

Ok so I did some serious investigation and I think I've found the issue. The AoA difference pointed out by @zarakon actually got me on the right track. As you can see in the previous screenshots, the lift value is actually smaller for larger angle of attack, which should never be the case if aerodynamics model is anywhere close to logical. Drag is obviously larger, but the real issue seems to be a decreased lift.

And it looks like it comes from total removal of body lift in 1.1.2 for many parts. Here are sample screenshots for 1.1 and 1.1.2. Body lift does not contribute much, but it adds around 20% or so for bigger planes.

Aero forces in 1.1

Aero forces in 1.1.2

Now find light blue arrows in the second screenshot.

Adding more wings to my planes hotfixed the issue (missing lift is added, but also slightly more drag via lift/drag ratio).

Edited May 5, 2016 by Thrimm

[bewing]

@Thrimm: OK! Now you have a real bug to report!

It doesn't look like you have a bugtracker account, though? Are you going to create one and post this issue?

Edited May 6, 2016 by bewing

[sal_vager]

Guys, just delete your Physics.cfg, it'll force KSP to reset it, you (like me) must have an incorrect Physics.cfg file.

[Thrimm]

@sal_vager I tried and it fixes the body lift issue.

The new file does however put incorrect values of jointBreakForceFactor and jointBreakTorqueFactor (10 instead of 30 and 50 respectively), which causes most of the vessels to explode on unpack.

Setting jointBreakForceFactor=30 and jointBreakTorqueFactor=50 removes body lift entirely. Reverting back to 10 does not introduce body lift again, I need to delete the entire physics.cfg file. I tested this on both x32 and x64 versions.

So it's either playing with exploding vessels and body lift, or with stable vessels and reduced lift.

Edited May 6, 2016 by Thrimm

[smjjames]

1 hour ago, Thrimm said:

@sal_vager I tried and it fixes the body lift issue.

The new file does however put incorrect values of jointBreakForceFactor and jointBreakTorqueFactor (10 instead of 30 and 50 respectively), which causes most of the vessels to explode on unpack.

Delete again and retry?

Alternatively, if you guys use Steam, delete the physics.cfg and try a cache verification.

[Thrimm]

11 hours ago, smjjames said:

Delete again and retry?

Alternatively, if you guys use Steam, delete the physics.cfg and try a cache verification.

I installed a clean copy of the game each time while removing the physics file, verifying the cache integrity. I've also tried restoring the old-new physics file after the body lift disappeared when I reverted the jointBreak values and the conclusions are:

• physics.cfg installed via steam version of the game does not produce body lift in game
• removing the physics.cfg as suggested by @sal_vager restores the body lift, but set incorrect values of jointBreakForceFactor=10 and jointBreakTorqueFactor=10 which causes issues with vessel stablity
• changing those values by hand in the new physics.cfg file removes body lift entirely - reverting back to 10 doesn't restore the lift either, physical removal of the file is necessary.
• interestingly, the only changes in the physics.cfg file between the one installed with the game and the one game creates after removal are jointBreakForceFactor=10 (old 30) and jointBreakTorqueFactor=10 (old 50), aerodynamics parameters are the same.

To me it looks like a more complicated bug than just incorrect config values. It would be great if someone tried to replicate these steps and see if results are similar.

[sal_vager]

What OS are you using @Thrimm? This could a a linefeed verses carriage return thing.

Edit:

I tested saving the Physics.cfg with no edits, the default on Linux  when using Leafpad is to save with linefeeds instead of carriage returns as a UTF-8 file, and the saved  file breaks body lift.

Saving with carriage returns doesn't fix it, it may be file format instead.

Oh btw, don't trust the aero overlay lines, they can mislead as can be seen in this image.

Spoiler

The drag is there and the plane is stable without any rudder trim, but because the wings are in symmetry the drag lines fail to show correctly.

Checking the file in a terminal tells me it is us-ascii

Quote

$ file -bi Physics.cfg
text/plain; charset=us-ascii

 

[Thrimm]

I am using Windows 8.1 x64, Intel Core i7-4770K @ 3.50Ghz, 8GB RAM. I've tried saving physics.cfg with the ASCII/UTF-8/Unicode/ANSI format and each and every one breaks the body lift. Interestingly, I've also tried copying the "right" file back into the game folder, but it does not restore the body lift, the aero forces behave as if the file was modified/saved.

I understand that aero forces overlay can be misleading, that is why I tried to use aero-GUI to determine the values of lift and drag as was the case in the OP screenshots - I hope these are correct.

I seriously can't find a workaround for this issue. I hope you guys can fix it soon.

[sal_vager]

@Thrimm, maybe it's timestamps? There's software to edit timestamps such as this, it's worth a try.

[Thrimm]

@sal_vager I've just played with timestamps and it didn't solve the issue for me, but I have another interesting observation - the physics.cfg file created by the game after launch (one with body lift) does not produce body lift in second and consecutive launches of the game. It works only once, when it's created.

I've also tried saving the database via the debug menu into another file and reloading it in-game, both with and without any modifications. Body lift is gone in both cases.