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

[KerbMav]

Edit: Ok, I was looking at it flying forwards, which it does correctly; I never got it to flip around backwards. I see what the issue is; the SRB's attach nodes aren't set to be the correct size, so it's acting far more aerodynamic than it should be. You can quick-fix it by going and finding the config file and setting the last number on the nodes to "1" instead of "0", and it should work from there on.

Mighty Kerbol ... if Squad ever gets around to change their aerodynamics - your way or another - they seem to be in for a complete overhaul of everything ...

[ferram4]

Here's a really quick change to fix the SRB floating issue, as well as a few other improperly sized attach nodes. Just copy the code below into the bottom of the FerramAerospaceResearch.cfg in the GameData/FerramAerospaceResearch folder and it should all be fixed.

//These parts don't have their attach nodes at the correct size, so drag isn't calculated correctly on them
@PART[solidBooster1-1]
{
	@node_stack_bottom = 0.0, -3.914617, 0.0, 0.0, 1.0, 0.0, 1
	@node_stack_top = 0.0, 3.939497, 0.0, 0.0, 1.0, 0.0, 1
}
@PART[mk2LanderCabin]
{
	@node_stack_top = 0.0, 0.7519293, 0.0, 0.0, 1.0, 0.0, 2
}
@PART[rocketNoseCone]
{
	@node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2
}
@PART[standardNoseCone]
{
	@node_stack_bottom01 = 0.0, -0.138, 0.0, 0.0, 1.0, 0.0, 0
}
@PART[noseConeAdapter]
{
	@node_stack_top = 0.0, 0.555, 0.0, 0.0, 1.0, 0.0, 0
}
@PART[ionEngine]
{
	@node_stack_top = 0.0, 0.2135562, 0.0, 0.0, 1.0, 0.0, 0
	@node_stack_bottom = 0.0, -0.1872844, 0.0, 0.0, 1.0, 0.0, 0
}
@PART[xenonTank]
{
	@node_stack_top = 0.0, 0.1404661, 0.0, 0.0, 1.0, 0.0, 0
	@node_stack_bottom = 0.0, -0.1404661, 0.0, 0.0, 1.0, 0.0, 0
}
@PART[miniFuelTank]
{
	@node_stack_top = 0.0, 0.1742737, 0.0, 0.0, 1.0, 0.0, 0
	@node_stack_bottom = 0.0, -0.1742737, 0.0, 0.0, 1.0, 0.0, 0
}

[English Mobster]

I just did recreate your described case 1:1 and launched it 5 times. No control inputs from my end. Depending on flameout altitude and speed, the resulting end orientation of the vessel differed greatly, which indeed had an important effect on the descent profile. If the vessel was near-vertical, it descended fairly quickly and after some nice mach effects during descent it impacted with around 100m/s.

If it was horizontal, it stayed horizontal and impacted with ~60m/s, but drifted much more horizontally. This behavior appears odd to me as well. I'd expect the vessel to be shifted to a vertical position during descent automatically due to the path of "least drag".

No audio in video:

<snip>

EDIT: On 2 of 5 roughly the same of the above happend, in variations (one time its orientation was horizontal, but it slowly spiraled downwards instead of coasting in a single direction). The other times, the vessel stabilized in a vertical orientation, with aforementioned much higher speeds.

Yep, precisely what happened. Thanks, I would've made a video myself if I could get FRAPS to work properly on this computer.

Here's a really quick change to fix the SRB floating issue, as well as a few other improperly sized attach nodes. Just copy the code below into the bottom of the FerramAerospaceResearch.cfg in the GameData/FerramAerospaceResearch folder and it should all be fixed.

<snip>

And, as far as I can tell, that did it! Working great now, thanks a lot.

[Senshi]

As usual: Awesome work in providing a super quick fix for such an exotic bug that's not even your fault .

[andqui]

I'm using a tech tree which limits you to mastering atmospheric flight before you get rockets, so I'm going on a bit of a learning curve with FAR.

1) For propulsion, the best I have are turbojet engines (no rockets). These flame out around 20km or so, no matter how many intakes I add. Is this the best I can hope for am I doing something wrong? I'd like to be able to get higher to get more science points so I can get to rocketry.

2) The aircraft has excellent control and stability below Mach .9 or so. From .9-2 control inputs are sluggish, as expected, but the aircraft is still steerable. Above Mach 2, especially up in the upper atmosphere around 15-20 km, the pitch controls are very mushy and it's easy to get into oscillations, while the roll control is too good and extremely sensitive. It is doable to fly very very fast at 20 km with the reentry effect going, but it's difficult to keep stable and you need to watch the engines very carefully for a flameout, and trying to change direction/descend is extremely difficult. In the stability derivatives screen in the CAS, when I plug in the above values everything is in the green, but when you get above Mach .9 "Xw" in the longitudinal derivatives is in the red. What does this value represent, and how do I fix it? Adding more lift aft makes it go up to -0.015 or so but that's the best I can get by trial and error. Everything but this value is green, which I assume means they're OK.

thanks

[Surefoot]

@andqui: it took me quite a few hours and flight tests to make a design that is stable at mach 2+ at high altitudes. Try procedural wings, it's almost a requirement. Then you need more stability, if you lose control at high speed you want more wing sweep, for roll control you need some dihedral (or anhedral, which worked for me), you probably want yaw control too so more vertical surfaces. Then you can experiment with winglets, control surface distribution, wing camber (with elevons or leading edge slats)... Good luck and have fun, i had a lot doing this.

For jet powered flight you can aim for 25km at mach 4.5+.

[localSol]

I was curious so I tested and got the same thing as english mobster and senshi. I tried the fix and it did make things more stable with no control input at all. That vehicle with no other control-help still flips eventually with the cfg fix, though I'm not complaining, only noticing. Only one reaction wheel or either four rotatable fins made rockets like this very easy to control. I don't know anything to say about realism but that's what happened. Fun though, I noticed that a ncs adapter and nose cap that I rarely use was much more aerodynamic for this purpose than a regular nosecone. Somehow only a bacc with a okto2 on top doesn't flip at all, but also doesn't get nearly as far an apoapsis, IIRC I think ferram may have mentioned before something about that being a side effect of the simplified cylinder aerodynamic calculations compared to what's used for nosecones? The RT-5 SRB from TV PP is more stable than the bacc or rt-10 for this purpose..less drag, less thrust, less dry mass, less wet mass but similar effect because of the thick atmosphere. In testing a dozen or so of these I was reminded how much easier it is to control the ascent of a small light rocket!

andqui : Orbit won't be possible but you can sometimes hop up to 40km or so(engines won't work there but you can get science or maybe even a risky eva..maybe try experimenting with throttle and swooping up and down at different angles of attack once you're already at around 10-15km. Ability to do it depends on the shape of your wings, control surfaces, twr, total mass if not other things I would think. Edit 2 : I don't know how to fix the "Xw" longitudinal derivative. I hardly know what it is.

Edited November 15, 2013 by localSol

[Senshi]

@andqui: Feedback on plane design really is only possible if you provide a VAB/SHP screenshot of your plane. Makes it much easier to give suggestions.

General design rule if you want a high-speed high-altitude plane:

Get as little wings and control surfaces as you can afford. When your plane becomes uncontrollable in flight stages, you can still revise this later on.

Slapping on more intakes still helps, but not as much as you might think. Mostly because jet engines have been nerfed considerably in FAR:

Actual thrust scales with current velocity. I have made a quick graph to show the considerable difference between stock and FAR:

Also take note that the maximum thrust of the engines has also been reduced as well, which also has a big impact.

Stock Turbojet: 225

FAR Turbojet: 200

Stock Jet: 150

FAR Jet: 140

Basic jet engines are basically useless for anything supersonic, but Turbojets still are worthwhile, running most efficiently at 900m/s.

Doing a parabolic suborbital jump into higher atmosphere is not easy to do without rocket support. Surefoot's approach is the best there is, I think. The atmosphere only starts to get thin enough for a properly high apoapsis at around 20km...

Actually, I think this would make for a nice challenge: Reach the highest apoapsis with your FAR plane using ONLY the Turbojet engines...

But if it's about gathering science, try and gather ground samples from the plethora of biomes on Kerbin. Those bring in plenty of science points to unlock. Once you have your first basic rocket (even if just a small SRB ), getting to upper atmosphere and even to space low above Kerbin should be way easier.

[ferram4]

@andqui: If the plane is comfortably stable at subsonic speeds it's probably going to be too stable at supersonic speeds. Generally, you need the plane to be only barely stable at subsonic speeds to make it perform well in supersonic flight. Bring less ailerons though, since you don't really need them too much at higher speeds. Make sure that you spend more time in the lower atmosphere picking up speed instead of heading straight for your flight ceiling. If you want to try doing a suborbital hop using only jets make sure to stay lower than you would so that you have more room to spend gaining vertical velocity before your thrust cuts out.

The Xw value indicates how the plane's drag changes as a function of angle of attack; if it's negative that means that increasing angle of attack will decrease the drag coefficient. Normally that doesn't occur, which is why it turns red when that happens; it's a warning that something very strange might be going on with your design. Don't worry about it too much if the plane feels right though.

@localSol: Yep, the adapter + small nosecone is much more aerodynamic than the 1.25m nosecone; it just weighs more. The added stability of the SRB without a nosecone was due to the fact that nosecones actually make things less stable; if a nosecone ends up at an angle to the flow it produces a lifting force on it, and if there is a long cylinder full of heavy stuff behind it that lifting force can tilt te cylinder off-course. It's actually supposed to happen, but it's the least efficient way to gain stability; you'd be better served with fins or flaring the bottom of the rocket.

@Senshi: The only criticism I have this that the graph is technically wrong; the curve is smoothed through each data point, so thrust doesn't change as suddenly as is implied there.

[Surefoot]

Get as little wings and control surfaces as you can afford. When your plane becomes uncontrollable in flight stages, you can still revise this later on.

I second that and add this: more sweep, more high speed control. But tradeoff is low speed becomes really bad (think about landing..). Also turbojets run out of thrust around 1450m/s, cannot go any faster.

Actually, I think this would make for a nice challenge: Reach the highest apoapsis with your FAR plane using ONLY the Turbojet engines...

I just tried with my atmo design (which is a compromise for low speed agility), starting with level flight at mach 4.5, 19.5km, then 25° pitch up, i reach around 44.6km apo. This was a quick try with a design maybe not the best suitable for this, i'll try and make a hypersonic demon (that forfeits any low speed ability) and different starting altitudes and pitch angles to see if i can top that. Also having a heavier design might help counter the drag...

(edit) quick try screencaps:

Edited November 15, 2013 by Surefoot

[LoSboccacc]

Hi I am getting this problem when loading a crashed vessel debris

after upgrading to the last version and flying in the 2.0 km range of a debris of a previous flight, I get a load of these errors in the logs:

[EXC 20:22:33.687] FieldAccessException: Cannot set a constant field

[EXC 20:22:33.690] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.691] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.707] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.708] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.710] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.711] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.712] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.714] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.715] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.716] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.717] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.719] NullReferenceException: Object reference not set to an instance of an object

[EXC 20:22:33.720] NullReferenceException: Object reference not set to an instance of an object

and in data log

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARControllableSurface.CalculateSurfaceFunctions () [0x00000] in <filename unknown>:0

at ferram4.FARControllableSurface.LateUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARWingAerodynamicModel.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ferram4.FARWingAerodynamicModel.FixedUpdate () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

now the log CLEARLY points to ferram but this never happened with previous versions. The special thing that comes to mind to that debris is that one of the control surfaces was a flap,

which has in ferram a completely separated control mechanism and thus may or may not interfere with the commands delay or something.

stack trace of the field exception

(Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

FieldAccessException: Cannot set a constant field

at System.Reflection.MonoField.SetValue (System.Object obj, System.Object val, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0

at System.Reflection.FieldInfo.SetValue (System.Object obj, System.Object value) [0x00000] in <filename unknown>:0

at ProtoPartSnapshot.Load (.Vessel vesselRef, Boolean loadAsRootPart) [0x00000] in <filename unknown>:0

at ProtoVessel.LoadObjects () [0x00000] in <filename unknown>:0

at Vessel.Load () [0x00000] in <filename unknown>:0

at Vessel.Update () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

Part deltaWing cannot load module #1. It only has 1 modules defined

(Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

PartModule is null.

(Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

[X6 Scipko Debris]: landed - waiting for ground contact to resume physics...

(Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

NullReferenceException: Object reference not set to an instance of an object

at Part.ModulesOnStart () [0x00000] in <filename unknown>:0

at Part+.MoveNext () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

[a.g.]

I already sent a fix for that to Ferram. The root problem seems to be that something in the stock KSP loading code chokes fatally on public const fields in some circumstances, and the controllable surface class has one.

[LoSboccacc]

challnege accepted

just pointing up and shooting:

all while madly spinning because I crossed the air density boundary too fast

it has 4 intakes and three engines.

[Surefoot]

I see, no level flight then, just pitching up from the start ?

[LoSboccacc]

I guess it depends on the twr

[localSol]

@localSol: [...] if a nosecone ends up at an angle to the flow it produces a lifting force on it, and if there is a long cylinder full of heavy stuff behind it that lifting force can tilt te cylinder off-course. It's actually supposed to happen, but it's the least efficient way to gain stability; you'd be better served with fins or flaring the bottom of the rocket.

@Senshi: The only criticism I have this that the graph is technically wrong; the curve is smoothed through each data point, so thrust doesn't change as suddenly as is implied there.

Flared bottoms of rockets, more drag I would think. That makes sense. No wonder I keep seeing rockets that look like that. I'll try some more exaggerated flared bottoms and see what happens.

It's nice to see those graphs Senshi, -

I tried over the last hour to make a graph of TV's Engines but I don't understand the extra slope control variables in the cfg for velocitycurve. ferram posted as help in a reply in september, "The extra zeroes specify the slope of the curve at that point; the first specifies the slope coming from the left, the other specifies it coming from the right. This can be used to specify the curve more exactly with fewer inputs."

Anyone know if there is any official info on this? How do they work? Can't be angles or radians? TV's turbojet has '0 28000000' for density 0 atmospherecurve and '-400 0' for density 1. I have no idea how to interpret that I guess unless it's part of some curve variable..never tried to program a curve..almost..then I got sleepy. Ha ha. By the small values in the velocitycurve curve-mystery-variables I would guess they are much less curvy but that's all I can guess.

[NathanKell]

They're tangents for the curve (AnimationCurves, and hence FloatCurves, use bezier curves)

http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html

[localSol]

They're tangents for the curve (AnimationCurves, and hence FloatCurves, use bezier curves)

http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html

Oh, thanks! After finding myself literally scratching my head over the code there for 15 minutes, I read wiki's article on bezier curves and tangents to get concepts I forgot. With what I'm imagining, at some point humongous values make less and less of a difference to the curve's shape..

I guess the two values in the cfgs are the two control points (p1 and p2 aka c1 and c2) in a cubic bezier curve. And if that's so, then the atm and isp values in the cfg would be enough to be start and end points p0 and p3..But if that's it, the two extra values in the cfg are only enough to define one axis for each of the two control points, where they would have the same value as the start and end points respectively, i would guess, or, enough to define only one control point, making it effectively quadratic? Hmmm...hmmmm...?!

How far off could I be misunderstanding it?

[NathanKell]

For any two keys k0 and k1

k0 is p0

k0 out-tangent is p1

k1 in-tangent is p2

k1 is p3

The tangents are given as slopes rather than positions, that's how they get away with it.

[localSol]

For any two keys k0 and k1

k0 is p0

k0 out-tangent is p1

k1 in-tangent is p2

k1 is p3

The tangents are given as slopes rather than positions, that's how they get away with it.

Ah! Slope from the adjacent start or end point. Clever way of doing it, that is just what I needed, thank you.

Now to test it and see if what I'm visualizing makes sense.

[NathanKell]

Hey, if you do get it working, can you do some floatcurve work for me? I couldn't get it to work quite right and I've been too busy since!

Sorry for clogging your thread, ferram. :]

[Camacha]

Thanks guys, this cleared up a lot for me. Coincidentally I am working on a hoverscript for kOS. Even though you could assume that most hovering is done at standstill, I would like to calculate thrust the proper way. Assuming less leaves less margin for error.

I have, however, no clue how to derive a value from those curves and how to get the appropiate curves from KSP. Any pointers?

[StevenRS11]

0.10 finally fixed the issues with heat-shields flipping things over, hurray!!!

[Sokar408]

Does anyone else have a problem with the FAR menu button not sticking to the position you place it in? It keeps going back to default positioning which is in a terrible spot. Is there anywhere I can fix that?

[KerbMav]

It does not safe its VAB location, but its inflight one - for me at least.