[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[ferram4]

Oh, one more thing to try:

I'm starting to suspect that the difference between how vessels are loaded and how new vessels are created has some influence here. If that's the case, then attempting to cause the issue by decoupling a controllable stage from a main vehicle suffering from this should not suffer from the issue. The way to test this should be simple; take any of the current problem vehicles; slap a decoupler and probe core on top of them, and change the root to that new probe core. Set up staging, cause issue, then decouple root probe from vehicle and test.

[JeeF]

ferram4, just a heads-up that Jeef's a KSPwin64 user.

As I stated before, I don't report issues coming from my 64bit build, so don't assume things.

[GorillaZilla]

Ok, Sorry was away for a while helping with the decorating. Your theory holds water. but not quite as expected.

I added the separating drone ship, but forgot to change the root from the lander can to the probe core... So the root in this test is the lander can.

Launched Pusher+Puller ship + Drone Pusher Puller. Got it in air and quicksave. at 100ms bug does not happen.

Then quickload, and fly it to 100ms and the gimbals bug. Then I Decouple Pusher puller Probe and It's gimbals are fine. Mothership's gimbals are still broken if I switch back to it.

But Get this, When I made the probe core root the first stage bugged, and after separation even the drone ship had bugged gimbals.....?

And the previously bugged 1st stage is suddenly, magically no longer bugged and it's gimbals work fine the instant the probe decouples.

It's like the bug splits off and follows the original root....

Another change I noticed is that the speed for the bug reduced to even lower, down from 100ms to 50ms for the 1st stage...

But is 100ms for the second stage that the bug seems to transfer to....

Edited July 2, 2015 by GorillaZilla

[fatjoe2015]

GorillaZilla, would you test this again with 2 identical ships ? (Mother ship and drone ship beeing the same ?)

Nice find btw

[GorillaZilla]

Sure, will do :-)

[GorillaZilla]

Ok Interesting behaviours. For some reason for a certain speed range only the second set of engines from the top bugs out and reverses. The COM is as one would expect in the center of the girder Sure some things can be guessed at, as the engines either end of the girder are about as far apart as the engines would be on each ship once separated....

Heres some more info, Flying up to 750ms without decoupling to observe and test this anomaly.

At 118ms the second engine from the top bugs out and reverses its gimbal

At 316 the top most set of engines begins to bug out and return to normal erratically and randomly, the screenshot caught it in between buggings out so it looks normal.

At 339ms

the top set of engines has fully turned to bugged out

These last two points of data seem to resonate with Ferrams hunch that its something to do with a misplaced COM calculated for the Gimbals that may move as speed changes, moving through this extra long ship.

And as expected at around the 750ms range the bug goes away.

As Far as I can tell after separation the results are the same, whichever ship contains the part which was root at launch inherits the bug and the other ship is fine and gimbals properly

So the interesting data in these tests is not from the identical ships but the interesting behaviors exhibited in this extra long ship with high deflection gimbaled engines along its length to clearly demonstrate the behaviour of the gimbals throughout flight throughout all the different speed ranges.

Edited July 2, 2015 by GorillaZilla

[kcs123]

@GorillaZilla, have you tried to force changeing "root" part of ship with SPH/VAB gizmo ?

Haven't time to make some more test in 1.0.4, but with 1.0.2 I was having some wierdness with FAR and choosing some other part besides command module to be "root" part of craft.

I din't reported it here as I didn't have time to investigate it further and I didn't want to raise false bug alarms. I just stoped habit to change root part of craft, so it was not even a big deal to report it.

But based on provided pictures it seems that you have changed "root" part or "root" part of craft is not actual nose of your craft.

Can you try to force changing root part to be top most part of your craft and test it again ?

Sorry if that does not help, but I think it is worth to try.

[GorillaZilla]

Yeah, I've tested force new root vs the part being root from the start of construction in the editor, The results between them are the same as far as I can tell. Whichever part is root, either initially or via force root inherits the bug and leaves the other separated ship's gimbals unbugged...

[GorillaZilla]

Ok I can Confirm this also affects the RCS thrusters, Heres a series of screenshots taken 3 every second or so as the RCS transitions gradually into the bug as the speed increases.

At 750ish again the bug stops, gimbals and RCS

The fins on the rocket move the com here...

Heres the series of stills, you can see the gradual shift to reversed, as if the COM is moving as the speed is increasing.. But it does not affect the physics. Only the controls that go off COM to determine which RCS thrusters to fire and which way to point gimbals. Reaction wheels do not seem to be affected.

Hopefully that helps narrow the cause of the problem down more :-)

[smunisto]

I may be wrong, but what isn't something fishy going on with the calculations?

I have been trying to make a simple SSTO for the past 20 game-hours or so, and each time I change some stuff in the design and run the sims and transonic design - it gives some numbers, then after a scene reload, it gives different values - most notably a vastly different Wave Drag Area.

Here's 2 shots taken right before and right after a scene reload, no changes to craft:

https://bg3.biz/cloud/index.php/s/l1mP6fVCNPCGC4f

and after a scene reload:

https://bg3.biz/cloud/index.php/s/v4U8NGE3wrPJbSn

I completely lost the desire to trust the numbers, also the CoL indicator. I have absolutely no idea which sims to believe and I don't know whether the Data+Stability derivatives give the correct numbers.

I may understanding the theory wrong, but just as an example - 15km/Mach 2.5 gives Lb of -6, 15km/Mach 2.6 suddenly goes to +25.

Edited July 3, 2015 by smunisto

[GorillaZilla]

Just a thought, What happens if you do Another scene change, come back and run the sim again? Do you get the same result as after the first scene change? Or do they go back to the first sim results before the scene change, Or are they totaly new results that don't match the previous two?

[ferram4]

@smunisto: For what you're displaying, that makes perfect sense; your reloaded vehicle lacks solar panels or radiators in the approximate same body station, of course it's going to have better drag characteristics.

As for the other situation, sounds like the AoA changed a lot because it was suddenly able to successfully converge to a solution. That happens at high altitudes with heavy vehicles.

[kcs123]

It seems taht is not about solar panels or something like that. I asked about reproducing steps in craft exchange thread.

Original post from craft exchange thread.

Reproducing steps:

1. I close the gears - Baha's Adjustable ones btw - via the right click menu(the FAR toggle button does not work with them).

2. I check WDA.

3. Change scene - going back to Space Center, instead of launching a test flight.

4. Going back to SPH from the Space Center screen - craft loads with gear up.

5. I check WDA - it's a lower value.

I think that something is not saved properly, landing gear state, or voxelization is broken - not fully completed before first scene change.

[smunisto]

Yeah, the screenshots are a mistake on my part, I am sorry. I have made so many of them in the past few hours.

Here are some proper screens. I swapped the Adj. LG with the B9 ones, in order to remove the LG mod itself from the possible causes.

Steps to reproduce:

1. Build a craft - Check WDA with gear down - https://bg3.biz/cloud/index.php/s/hcUqVFJqjRHCjPB FAR Toggle Gear button doesn't seem to work with the B9 gears too, by the way;

2. Close the LG via the right-click button - Check WDA - https://bg3.biz/cloud/index.php/s/Im78D6hUrvzAINR

3. Save craft;

4. Exit to Space Center;

5. Go back to SPH;

6. Craft loads with LG retracted - Check WDA - https://bg3.biz/cloud/index.php/s/dfJPyjUhdnInOCs

7. Lower LG - Check WDA - https://bg3.biz/cloud/index.php/s/iaMpbUnWhQgtnYa -it is consistent with the one before LG.

Edited July 3, 2015 by smunisto

[ferram4]

So... he's complaining that gear being in different states results in different drag values.

Not an issue; having alower drag is, but that is fixable a at a later time. The existence of a change in drag values is proper for a change in gear state.

[kcs123]

Most probably craft will behave properly in flight, but for ordinary user it is hard to understand what is "correct" drag value while he try to improve his craft in SPH.

Is it proper value with raised gear one before scene change or the one after reloading ?

On what value user should rally as correct one as reference point in improving craft design ?

For most users it will not be much of issue, but perfectionist will find tedious to change scene all time just to see "proper" drag value.

EDIT:

Also craft with lowered gear state before and after reloading scene have slightly different wave drag value. Changes are more noticable with critical mach number, though.

Edited July 3, 2015 by kcs123

[smunisto]

Most probably craft will behave properly in flight, but for ordinary user it is hard to understand what is "correct" drag value while he try to improve his craft in SPH.

Is it proper value with raised gear one before scene change or the one after reloading ?

On what value user should rally as correct one as reference point in improving craft design ?

For most users it will not be much of issue, but perfectionist will find tedious to change scene all time just to see "proper" drag value.

EDIT:

Also craft with lowered gear state before and after reloading scene have slightly different wave drag value. Changes are more noticable with critical mach number, though.

My actual worry - whether the whole modelling is correct. If it differs a scene change apart for landing gears in the same state, then what does it mean for the other parts? Maybe each time I move a wing, or change the procedural wing's parameters, the data sim breaks and I have to save craft/scene change in order to get the correct values.

So... he's complaining that gear being in different states results in different drag values.

Not an issue; having alower drag is, but that is fixable a at a later time. The existence of a change in drag values is proper for a change in gear state.

I fixed it in my previous post, where you can clearly see - the exact same aircraft with the exact same gear state has different WDA values one scene change apart.

[ferram4]

I need a reproduction case with no other mods to remove confounders.

[smunisto]

Javascript is disabled. View full album

1. Scene in which the craft was built, gear down.

2. Scene in which the craft was built, gear up via right-click menus(toggle gear in FAR didn't seem to update the values).

3. Save craft, back to Space Center.

4. Enter SPH

5. Craft loads, gear down - WDA different.

6. Retract gear via right-click menu - WDA different from point 2.

Toggle gear updates the values, but to something totally different from 1,2,5 and 6. Also should be noted that it only works on stock landing gears.

Craft file: https://bg3.biz/cloud/index.php/s/PqswMCu0spDpTpJ

Output_log: https://bg3.biz/cloud/index.php/s/ztfDCmtN3JTfGXf

[ferram4]

Okay, I can't confirm Toggle Gear producing different results than manual changes. I can confirm the loading errors, which are errors. The data after making changes is what's correct. I'll see if I can figure out what's going on.

[smunisto]

Thank you.

Regarding the numbers - so, is this valid for each part change? Such as Procedural wings changes in shape, thickness, adding new parts, moving wing parts, canards, tails, etc.? Basically, for the numbers to be correct, I need to build the whole craft, scene change and then check the numbers?

And about the Toggle gear button - I am unsure how it works, because the first time I pressed it was before a scene change. It retracted the stock landing gear and gave me a WDA value that kept recalculating itself for a few seconds, maybe I did not wait long enough before I switched scenes.

However I am sure it doesn't work with B9's landing gears, the KAX ones and the Adjustable landing gear mod.

[ferram4]

It is valid for each part change. The initial loaded state is wrong. Based on previous tests, this is only an editor issue; it behaves rather... strangely, I must admit.

It should work fine with the B9 gear, they use the Firespitter gear module, don't they? I have that supported. Hmm. I know adjustable landing gear uses some funky thing of its own (there are like, 5 or 6 different landing gear modules all reinventing the wheel between stock's 3 or so and then the mod ones. This is stupid.)

[taniwha]

Unfortunately, wheels in KSP need reinventing.

[GorillaZilla]

Unfortunately, wheels in KSP need reinventing.

Indeed, only the Smallest rover wheel seems to have sprung dampened suspension... And even they have issues like when transitioning from ground to KSP structures like the runway they tend "Catch", break the wheel and stop the rover dead and/or flip it...

[smunisto]

It is valid for each part change. The initial loaded state is wrong. Based on previous tests, this is only an editor issue; it behaves rather... strangely, I must admit.

It should work fine with the B9 gear, they use the Firespitter gear module, don't they? I have that supported. Hmm. I know adjustable landing gear uses some funky thing of its own (there are like, 5 or 6 different landing gear modules all reinventing the wheel between stock's 3 or so and then the mod ones. This is stupid.)

B9's wheels use FSwheel. I guess that is Firespitter. No idea why they don't work.

Please, do notify when you manage to get to the core of the problem and resolve it somehow, I feel completely dishearted to do any more attempts at SSTOs without a properly working FAR(the Scene changing kills me ). Even if it's in a dev build.