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

[ferram4]

64 bit is a complete nightmare. I've seen it crash when my memory usage is at 2.5 gigs, and there's not much rhyme or reason to it. I know a few ways to exacerbate a crash, but nothing on how to cause them reliably. In particular, lots of exceptions being thrown seem to make it worse.

In any case, if you can do so, play on 32 bit instead. Even if you get the odd crash on loading because you installed a new mod and you went over the limit, it's at least at the beginning before you put any work in.

[BudgetHedgehog]

Ok, so I found/did something..

Load up any craft in the SPH, go to the stability derivs window, enter Mach number as 0 and then calculate stability derivs. The whole FAR window greys out, is now unusable and the following is spammed in the log:

Mass: 11491.0000747768

S: 67.3976

MAC: 2.64358582388193

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Cl needed: Infinity, AoA: 24.1999999880791, Cl: 1.05107839727618

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

ArithmeticException: NAN
  at System.Math.Sign (Double value) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.StabilityLabel (System.String text1, Double val, System.String text2, System.String tooltip, Int32 width, Int32 sign) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

ArithmeticException: NAN
  at System.Math.Sign (Double value) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.StabilityLabel (System.String text1, Double val, System.String text2, System.String tooltip, Int32 width, Int32 sign) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint
Aborting
  at UnityEngine.GUILayoutGroup.GetNext () [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayoutUtility.DoGetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayoutUtility.GetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayout.DoToggle (Boolean value, UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayout.Toggle (Boolean value, System.String text, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.StabilityDerivativeGUI (Boolean tmp) [0x00000] in <filename unknown>:0 

  at ferram4.FAREditorGUI.ActualGUI (Int32 windowID) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 

  at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0

I get that telling FAR to calcuate stability derivs at a speed of 0 might return some weird data, but would it be possible to not break the entire FAR window without reloading the craft/re-entering the SPH?

Edited August 6, 2014 by ObsessedWithKSP

[Jovus]

I can get to orbit (semi)reliably for between 3100 and 3900 dv, so I'm fairly sure I'm doing it right(ish) now.

[Stephanie the Viking]

64 bit is a complete nightmare.

You can say that again, it's just one crash after another and like you say, for no apparent reason half the time - no stress, no load, no conflicts that wouldn't have already appeared at any time in the last ten minutes. I was tempted to start again in 32bit to be honest because 64bit is more trouble than it's worth.

EDIT: Ok I installed and ran 32bit with all three mods installed, plus a couple of others which 64 bit didn't like for some reason, and they all worked together perfectly on the first run. Ah well, I guess we'll just have to wait a bit longer for the 64bit version to get fixed.

Edited August 7, 2014 by Stephanie the Viking

[steve_v]

Or run GNU/Linux

Rock solid at 6.5GB RAM usage here - actually I don't recall a *single* crash that wasn't my fault.

Of course it'll only be a matter of time 'till the Windows build catches it.

[taniwha]

Linux 64-bit KSP does have one issue: the png loader (but there's a patch for that). Otherwise, yeah, rock solid.

[Scienceofdead2811]

This plugin makes it worth me building SIMAR Rockets (My word for Elite or welldesigned rockets or planes, they can cost from 5000 to 20000+)

And do i have to tell SIMAR Stands for: Science Industries Mechanical and Intelligent Rockets? (I dont see Kerbals as dumb, i see them as worthy workers, a white suited kerbal that flies one of my rockets can ensure his future)

[Sevio]

Hi Ferram, is there any chance of testing a dev build for a fix with the control surface orientation? In case it may help, I've simplified the steps to produce the bug down to an 11 part plane as shown here:

The docking port is the root part facing towards the outside, the rest of the plane is built in reverse, cockpit facing towards the back of the hangar.

When it is launched, control starts with the cockpit and the control surfaces start inverted from what they should be.

[ferram4]

@ObsessedWithKSP: Added a simple prevention to the code, hopefully it doesn't break anything.

@Sevio: The simplest version possible should already be there to play around with; I uploaded it maybe an hour or so ago. If that doesn't work, more extreme measures might be necessary.

[Sevio]

@Sevio: The simplest version possible should already be there to play around with; I uploaded it maybe an hour or so ago. If that doesn't work, more extreme measures might be necessary.

I've just downloaded FAR from github master and tested the above plane once more, unfortunately control surfaces are still inverted

Curiously, in both versions they're also wrong when you control the plane from the docking port.

[BahamutoD]

Is there a way to modify the following MM config node to exclude parts whose name contains "rotor"?

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[IntakeAir]]]:BEFORE[FerramAerospaceResearch]:NEEDS[!AJE]
{
	@MODULE[ModuleEngines*]
	{
		@maxThrust *= 0.5
	}
}

Cutting the thrust is fine for jets, but it makes most mods' helicopter rotors un-usable.

[EzinX]

Ferram, I'm curious as to the main idea behind your aerodynamics modeling. You have generously included your source code, however, I think I might have better luck figuring it out if I knew the ideas behind the algorithms.

Starting from a "clean sheet", I came up with the following method for aerodynamic modeling :

1. Game has fixed parts defined ahead of time. This is true both for this game and most games that allow user creations.

2. Each predefined part has a high end aerodynamics solver run on it offline, essentially pre-baking the parts. I'm aware that it's a huge and complex subject, and accurate solutions are very computationally expensive because essentially you are numerically approximating certain PDEs for thousands of volumetric subunits that represent the air (or fluid) interacting with the surface.

3. The solver spits out the coefficients of lift and drag for either 6 or 18 possible orientations of the part. (the 6 solution you just solve for the Cd/Cl for each orthogonal direction, the 18 you include the 45 degree angles).

4. Armed with these constants, you raytrace parallel to the vehicles current direction of airflow. These rays hit the parts on the surfaces of the vehicle exposed to airflow, and this lets you determine how much air (or fluid...) each part of the vehicle is actually exposed to. You have a Cd/Cl, so you just apply the corresponding lifts and drags from each part to the rigid body model for the entire vehicle, converting drag that is off of the center of mass to a vector that includes torque when appropriate, and you're done. KSP seems to treat each individual part as an independent rigid body so in this game you would apply the forces to the individual parts instead. You of course interpolate between the 6 or 18 Cd/Cl values for the angle each part is actually at.

That's the simplest and obvious way to do it I can think. I recall reading somewhere in this very thread that you tried a similar method with poor results, and I'm curious why it didn't work. My first thought is that perhaps this method is very unstable? Forces on the vehicle change the angle the vehicle is facing, so the next timestep the forces are different and perhaps the vehicle "judders" around unrealistically?

[BudgetHedgehog]

Two quick unrelated questions:

1, how can I make a taildragger with FAR? I don't know much about making/flying them and what looks like it should fly, doesn't. The tail sits firmly on the ground and I crash.

2, how does FAR handle part clipping? Does it recognise that only part of the model is sticking out or does it apply drag to the whole part? How about things clipped completely inside other things with no visible external protrusion?

@Baha: Maybe something like HAS[!name[rotor]] or something? I'm not too sure if that syntax is right though. Maybe the guys in the MM thread would be able to help out more?

Edited August 8, 2014 by ObsessedWithKSP

[ferram4]

@BahamutoD: You could try making it:

@PART
[*]:HAS[@MODULE[ModuleEngines*, !#title[*rotor*]]:HAS[@PROPELLANT[IntakeAir]]]:BEFORE[FerramAerospaceResearch]:NEEDS[!AJE]
{
    @MODULE[ModuleEngines*]
    {
        @maxThrust *= 0.5
    }
}

I'm not sure if the "!#" section will pick up though.

@ObsessedWithKSP:

1. The tail dragger has to be built so that it's takeoff AoA is created by the landing gear. So it should be pitched up 10 degrees or so by the placement of the main and tail gear.

2. Nope, no way for FAR to detect that without lagging everything. Common misconception that FAR will handle that properly.

[EzinX]

2. Nope, no way for FAR to detect that without lagging everything. Common misconception that FAR will handle that properly.

The method I described above, you would cast a series of rays from appropriate samples in each part towards the normal of the air stream. O(n) complexity with the number of parts. That would let you detect partial part exposure. Uh, how are you actually determining the drag and lift coefficients for each part? Are you approximating them in realtime?!

[Renegrade]

1, how can I make a taildragger with FAR? I don't know much about making/flying them and what looks like it should fly, doesn't. The tail sits firmly on the ground and I crash.

Ferram already said what I was going to say, but I was also going to add that in my experience, taildraggers are kinda fiddly to land as that AoA they have makes them want to go back into the air right away unless they're going really slow. Basically they don't want to land unless their AoA-required-for-flight is greater than their sitting-on-the-tarmac AoA..

(I have a technique where I use the wheel brakes and pull up to counter the pitch down that the brakes provide, but it's kinda risky)

[tetryds]

Ferram already said what I was going to say, but I was also going to add that in my experience, taildraggers are kinda fiddly to land as that AoA they have makes them want to go back into the air right away unless they're going really slow. Basically they don't want to land unless their AoA-required-for-flight is greater than their sitting-on-the-tarmac AoA..

(I have a technique where I use the wheel brakes and pull up to counter the pitch down that the brakes provide, but it's kinda risky)

You can also add spoilers.

Kinda ugly, but works.

[DaMichel]

You can also angle your wings upward, so you can take off at 0 AoA when you're fast enough. I'd also add flaps. They help taking off and you can retract them right on touch down to help stick the plane to the ground due to the loss of extra lift they provide.

[Juncoph]

You can also add spoilers.

Kinda ugly, but works.

I always just make my ailerons double as spoilers, so that I don't need to compensate for new control surfaces

____________________________________________________________________________________________

Question: do proper winglets (wingtips that get raised up/pushed down to reduce wingtip vortices) actually achieve their real-life counterpart's purpose, or are they more like small rudders, like in stock KSP?

[tetryds]

I always just make my ailerons double as spoilers, so that I don't need to compensate for new control surfaces

____________________________________________________________________________________________

Question: do proper winglets (wingtips that get raised up/pushed down to reduce wingtip vortices) actually achieve their real-life counterpart's purpose, or are they more like small rudders, like in stock KSP?

That is a good idea.

On my jet fighters I used to set the cannards as spoilers, so I could touchdown at higher angle of attack.

But since 0.24 the airplane goes too unstable when you do that.

I know that winglets are not like stock KSP, but I'm not sure how simmilar to real life their effect gets.

[BudgetHedgehog]

The tail dragger has to be built so that it's takeoff AoA is created by the landing gear. So it should be pitched up 10 degrees or so by the placement of the main and tail gear.

I get that and it is, but the plane sits firmly planted to the ground. There's some weird buckling going on with the wheels whenever I go above 50m/s and then it veers off and I crash. If I pitch down to bring the tail up, I crash at 30m/s or so. For instance, is there any particular reason this doesn't take off? The CoM and CoL are, AFAIK, ok, there's positive pitch from the landing legs..

Javascript is disabled. View full album

Compared to takeoffs of RL tail draggers, I'm expecting the tail to lift up but it doesn't happen. It's like the rear is glued to the tarmac.

[tetryds]

@ObsessedWithKSP:

Are you really pitching down?

That tinny wing on the tail (horizontal stabilizer) doesn't seem to be enough to lift that tail, your COM is very far away behind the front landing gears.

Pick some shorter landing gears for the front ones and place them a lot closer to the COM.

Basically you are trying to lift the entire plane with only the horizontal stabilizer on the rear.

So, make it bigger, a lot bigger.

Edited August 8, 2014 by tetryds

[Renegrade]

There's some weird buckling going on with the wheels whenever I go above 50m/s and then it veers off and I crash.

This part is kind of alarming. I had an issue like that, but it turned out that the ailerons hadn't duplicated to the far side. Oops~

You can also add spoilers.

I tend to stick those on the ailerons, but my usual design involves a tiny aileron on the outside edge of the main wing(s), with a big only-flaps control surface near the body... In that configuration the spoiler doesn't seem to do too much..

@ObsessedWithKSP:

Pick some shorter landing gears for the front ones and place them a lot closer to the COM.

^ I think this will help quite a bit. My own designs look like this:

..note how the main gear are close to the CoL indicator. The tail does rise up just like a real life taildragger. Of course I have to take off immediately after that happens or it starts to bounce as it's a low-speed, lightweight craft

(reaction wheel is for ballast only; nowadays I use a little MM config that removes reaction wheels from cockpits/pods/probes and nerfs reaction wheels down to 0.25/2/8 torque and shrinks the stripey one to 0.625m size)

[NathanKell]

Wow, even those gear are *way* the heck far forward.

[tetryds]

Yeah, it helps a lot.

My ultralight is also a taildragger, but it has so much lift on the rear that i had to move wheels forward:

http://forum.kerbalspaceprogram.com/threads/20451-0-24-2-Ferram-Aerospace-Research-v0-14-1-1-7-25-14?p=1310927&viewfull=1#post1310927

Remember to turn off the power on the wheels, for some reason it didn't save itself with them disabled.