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

[ferram4]

@Tiron: That's because FAR has no reason to think that those parts wouldn't be affected by drag It's possible that those parts have too large area / too large drag coefficient for any of their orientations though.

@jbowon: You mean camber? The only way that you can get any camber on wings is if you build it into the wings themselves, otherwise they function as if they are made of thin, symmetrical wing sections.

Why? Because there is no benefit to camber at supersonic speeds (it doesn't produce lift but does increase the drag of the wing), and most vehicles in KSP are designed to fly at supersonic speeds.

Why not add the option to select whether a wing is automatically cambered or not? This would result in similar-looking wings having very different aerodynamic properties (if one was set to be cambered and the other not), which is really bad from a game design perspective--it makes the game world seem inconsistent when two similar things act completely differently.

[TomatoSoup]

I decided to reinstall FAR and just learn how to work with it. Unfortunately, I've hit a rather peculiar bug that is forcing me to uninstall it.

After a launch and return to the space center, none of the buildings are clickable. Although the back button is clickable, returning to the main menu and then to the space center doesn't fix the problem. I have to restart each time.

Is this a problem with a known fix, or is there any information I should forward you?

[ferram4]

Post a copy of the output_log.txt right after you cause the bug to occur. I've never experienced this bug on my end though, so I need more specific reproduction steps than "launch and return to space center."

[NathanKell]

Known issue with the base same, sometimes exacerbated by mods.

[Gamer217]

I'm trying to build a spaceplane but have run into a big issue, when I start getting towards Mach 1.75 and higher my craft become increasingly difficult to control and always tries to pitch down.

Here is the plane itself:

And I have no idea what any of this is but it seems important:

So can someone please explain what I'm doing wrong and what the data in the FAR CAS means?

[Taverius]

Looks like the correct behaviour looking at the curves there.

Your vertical stabilizer is way too small, so I can see it becoming yaw-unstable easily.

The important line in the graph is the yellow Cm one. Above the axis line, as that speed/Angle of Attack it wants to pitch up, below the line it wants to pitch down. It should pretty much always go downwards at some point in the AoA graph or the plane will be un-flyable, but you're never positive which why you're seeing that behaviour.

Solutions is to add some wing to the front of the plane, or add some incidence to wings at the back. Your control surfaces at the back are a good candidate for this.

Suggested reading:

Angle of attack

Angle of incidence

Mach tuck

[Snjo]

I got firespitter updated so it will disable the FSwingletRangeAdjustment if FAR is active, which was casuing issues.

But I notice you handle control surface rotations differently than stock, which becomes apparent on angled wings:

Do you have a quick fix for setting the intended axis a control surface should pivot on? It's only a visual thing, seems to fly just fine.

(Stock control surface rotation is based on the axis of the part base, not the control surface inside it, which is a very very bad idea, so I can understand you changing it)

[ferram4]

@Gamer217: It could be that you have a larger number of high-drag parts on the lower part of the ship. It also looks like your wing-based control surfaces pitch the vehicle down a bit by default; angling them the other way should fix that. You're also using an older version of FAR, which could mean that you're running into bugs that might have been fixed already (though I can't think of any off the top of my head).

@Snjo: FAR rotates each control surface around the control surface "right" vector. Make sure that that vector on the "obj_ctrlSrf" object is aligned with the intended hinge and it should work fine.

[Snjo]

@Snjo: FAR rotates each control surface around the control surface "right" vector. Make sure that that vector on the "obj_ctrlSrf" object is aligned with the intended hinge and it should work fine.

Actually, the hinge is already on X, but the part is still rotated around Z in FAR. I see in the code that you are calling on -MovableSection.right, but the whole logic isn't super readable, so I'm not sure that's all that's going on.

[ferram4]

All the code does is grab that transform's vector in world space, convert it to local space, then multiply it by a number to set the desired angle. Are you doing anything that is different from the way the stock control surfaces are set up?

[Snjo]

Ah, found it!

someone had given me some FAR values they had developed, they were on the messed up parts, but not on the working wings. When I removed them, they started acting normally (but probably with less FARiness?).

The modules on the rudder were:

MODULE
{
 name = FARControllableSurface
 MAC = 1.0
 e = 0.9
 MidChordSweep = 30
 maxdeflect = 15
 b_2 = 1.5
 TaperRatio = 0.53
}

MODULE
{
 name = FARWingAerodynamicModel
 S = 8.33
 MAC = 1.0
 e = 0.9
 MidChordSweep = 30
 b_2 = 1.5
 TaperRatio = 0.53
}

Do you have any suggestions for correct values on these odd angled wings?

[Snjo]

Now they are not smoothly controlled by FAR at all of course. To answer your question, yes I am doing odd stuff, simply because the stock code is super bad, as you know. The setup in unity:

the base of the part is at the odd angle too, to make it work at all in ksp.

[ferram4]

Are you testing with the most recent version of FAR? I know that somewhere a few versions back I included some code so that the FAR modules would automatically turn off the stock winglet / controlsurface modules, and if removing the FARControllableSurface module caused everything to be "fixed" that implies that the stock controlsurface module isn't being switched off and that the clash between those is the source of the error. Otherwise the coordinate system looks fine and like everything should work.

The modules you have been given are correct, though you've doubled up on modules; if you have control surfaces on the part, use the FARControlSurface module; if you don't, use the FARWingAerodynamicModel. Don't use both, that simply doubles the lift and drag of the wings.

[Snjo]

I used the one on spaceport.

[BubbaWilkins]

Ah, found it!

someone had given me some FAR values they had developed, they were on the messed up parts, but not on the working wings. When I removed them, they started acting normally (but probably with less FARiness?).

The modules on the rudder were:

MODULE
{
 name = FARControllableSurface
 MAC = 1.0
 e = 0.9
 MidChordSweep = 30
 maxdeflect = 15
 b_2 = 1.5
 TaperRatio = 0.53
}

MODULE
{
 name = FARWingAerodynamicModel
 S = 8.33
 MAC = 1.0
 e = 0.9
 MidChordSweep = 30
 b_2 = 1.5
 TaperRatio = 0.53
}

Do you have any suggestions for correct values on these odd angled wings?

Probably the "someone" in questions.

In my defense, I just made a barely educated guesses to make things work. I think I changed the config on the tapered fighter wing to make it work recently, but I can't recall off the top of my head what I did there.

The modules you have been given are correct, though you've doubled up on modules; if you have control surfaces on the part, use the FARControlSurface module; if you don't, use the FARWingAerodynamicModel. Don't use both, that simply doubles the lift and drag of the wings.

I doubled up on the module assignments because at the time, I was unable to get the parts to operate correctly without both.

I assumed that they were complimentary since only a fraction of the part was actually working as a control surface. At the time, using only one module either gave lift with no control authority or control authority with very little lift.

This was a couple updates ago, so that may no longer be the case. I'll admit, it was blind insertion on my part assigning things, but they tended to behave in game in a reasonable manner.

Glad to see you two talking directly about it! My two favorite mods.

Edited October 14, 2013 by BubbaWilkins

[requimrar]

@ferram4:

What happened to the 'feature' where we could drag FAR windows off to the side, outside of the screen? Honestly I have little use for the little FAR helper in flight and the (rather large) FAR simulator-thingy in the VAB/SPH; they used to be able to be dragged such that the majority of the window could be outside the screen, so it starting extended isn't a problem... Now they snap to the edge kind of like mechjeb's windows.

That seems to have been removed in one of the recent (0.9.6.2? .1?) updates.

Not a big fuss of course, given it's only a problem if the game is restarted, but still an annoyance nonetheless.

Thanks!

[Snjo]

I'm not sure why the rotations went wonky, but if I can suggest a quick patch to make the thing more configurable, it would be to have a KSPField to specify which axis the control surfaces rotate around.

My first instinct was to do:

[KSPField]

public Vector3 controlSurfacePivot = new Vector3(1f, 0f, 0f);

and rotate on the gameObject's localRotation using that.

However, I see you do a lot of references to the Right vector in other calculations too, but I'm not sure those are actually off.

If you want to take a look at this to replicate the problem, the whole Unity project is here: https://dl.dropboxusercontent.com/u/22972712/ksp%20forum/fighterWing.zip

And the wings with cfgs are on spaceport.

(The main F-86 wings don't have the FAR module on them, and the rudder/elevator don't have the correct lift values, but I'll look into that if I can get my head around the main visual problem)

[ferram4]

@Snjo: I'll add that pivot field to the FARControlSurface module and see if I can clean up the code a bit. I dunno how much the Unity project will help though, since I have no experience in working on new parts, only on plugin code. If I do manage to find a solution to something, I'll tell you.

@requimrar: The windows being able to get dragged offscreen (to the point where they couldn't be dragged back) was a bug; I'll modify the clamping function so that they can be dragged almost completely off, but not to the point where they can't be dragged back.

[Nobody_1707]

I forgot how easy it was to escape Kerbin's atmosphere. I had made a test ship because I was trying to figure out which mod was mucking my game up, and Jeb took 'er for a spin and had a wee bit o' an accident.

I think they might need to scale the solar system up when they add aerodynamics to the stock game.

Edited October 15, 2013 by Nobody_1707

[rhoark]

May I suggest rather than dragging off, the FAR windows (flight and VAB) start minimized? It's really helpful that awhile back the window started remembering its position, but I still have to dismiss the things

Every

Damn

Time

I go to the VAB or launchpad.

Edit: Not that I don't appreciate them. The analysis tools can be helpful with plane building, but it adds a lot of cumulative clicking to minimize those windows when rapidly cycling tweaking and testing a design.

Edited October 15, 2013 by rhoark

[rhoark]

I was just wondering: has anyone used Infernal Robotics to make a useful instance of variable geometry? I tried to use a rotator once to compensate for fuel shift, but only succeeded in making a plane that shifted between stable and lawn dart configurations.

[Hodo]

May I suggest rather than dragging off, the FAR windows (flight and VAB) start minimized? It's really helpful that awhile back the window started remembering its position, but I still have to dismiss the things

Every

Damn

Time

I go to the VAB or launchpad.

Edit: Not that I don't appreciate them. The analysis tools can be helpful with plane building, but it adds a lot of cumulative clicking to minimize those windows when rapidly cycling tweaking and testing a design.

No offense, but its not that big of a deal to close or minimize that window every time you go into the VAB. Try having Kerbal Engineering and FAR, then all you see is numbers when you go into the VAB, I have to minimize both before I can do anything. But sometimes I want them open so I can see what is wrong.

[Van Disaster]

I was just wondering: has anyone used Infernal Robotics to make a useful instance of variable geometry? I tried to use a rotator once to compensate for fuel shift, but only succeeded in making a plane that shifted between stable and lawn dart configurations.

Several of us have tried in the past - you can make moving wingtips successfully ( say 1m length ), but the hinges just aren't strong enough to handle entire wing sections. Caveat that I've not tried really tiny planes, but you don't really need variable geometry there anyway.

Maybe if someone knocked up a pivoting wing glove.

[enki]

the hinges just aren't strong enough

I found sneaking a quantum strut in and toggling it off while adjusting greatly increases the strength of any connection. Specifically wings, IR gizmos, and docking ports. The wings got very wobbly while in flight, but it worked successfully and with the Q struts I didn't have any wobble unless I wanted to.

[Van Disaster]

I've had issues with quantum struts and robotics; I was attempting to build a folding rover, experiments went as follows...

Struts enabled at "launch"

Turned struts off ( this might be a cubic strut issue also, mind - I didn't know the quirks of using them at the time ):

And that was perfectly driveable albeit a bit unsteady you could make some fun planes like that but I'm not gonna rely on it. The problem with moving wings in flight and QS is obviously you have to unstrut the wing to move it, and then you can't force it back into the right position because of flight forces. We just need a better hinge.