Control surfaces?

[frizzank]

I have made a custom control surface and it shows up in-game and produces lift but it doesn't move. Im sure there is some bits missing in unity like a tag, animation or something im missing. I just copied the stock small control surface cfg and used its parameters.

Any help would be appreciated.

[Tiberion]

ControlSurface is one of the last hold-outs using the old system from the DAE days. You just need to name your objects correctly and have the proper orientation.

The moving surface is named obj_ctrlSrf

The base part is named obj_base (not really sure that name is required, its just tradition maybe)

of course now you can just add your own mesh collider to each part instead of making a custom collider.

To get the moving surface to rotate properly, you must align its mesh with the X axis, so that its pivot point is on the line.

Here's the shuttle tailfin as an example:

In blender the inside of the edge is aligned on the X axis, then once in unity I rotate the whole thing -29 degrees to make the bottom edge of the fin align with the Y axis (Z in KSP) which makes it attach in the proper orienation without needing to adjust it with the WASD keys in the VAB.

[frizzank]

Wow, I would have never figured that one out. Thanks for the help. Naming the moving part "obj_ctrlSrf" did the trick. Obj_base was not required.

[TiktaalikDreaming]

I got trapped on this for a bit, so here's my learnings.

Both the non-control surface and the control surface should match their X-axis along the line of hinging.  I spent a bit of time messing around trying to figure out why my control surface kept pivoting around the wrong axis.  :-/  It was pivoting around the axis of it's parent object's x-axis, not it's own X axis.  Although, pivoting at it's own origin.

[TiktaalikDreaming]

Well, I thought I was done.  My control surfaces swing the wrong way.  :-(  I suspect we need to check the other axis.

[wasml]

Just made a fin in 1.0.5 and it seems the control surface no longer needs to be named "obj_ctrlSrf".

From Blender Hierarchy:

FinGameObject
    Fin
        collider      - collider for the whole fin
        control     - mesh for the control surface
        Mesh         - mesh for the fixed part of the fin

 

And the cfg file:

MODULE
{
    name = ModuleControlSurface
    useInternalDragModel = True
    dragCoeff = 0.6
    deflectionLiftCoeff = 0.61
    ctrlSurfaceRange = 40
    ctrlSurfaceArea = 2.3
    actuatorSpeed = 25
    transformName = control
}

 

Edited January 2, 2016 by wasml

[TiktaalikDreaming]

5 hours ago, wasml said:

Just made a fin in 1.0.5 and it seems the control surface no longer needs to be named "obj_ctrlSrf".

From Blender Hierarchy:

FinGameObject
    Fin
        collider      - collider for the whole fin
        control     - mesh for the control surface
        Mesh         - mesh for the fixed part of the fin

 

And the cfg file:

MODULE
{
    name = ModuleControlSurface
    useInternalDragModel = True
    dragCoeff = 0.6
    deflectionLiftCoeff = 0.61
    ctrlSurfaceRange = 40
    ctrlSurfaceArea = 2.3
    actuatorSpeed = 25
    transformName = control
}

 

Yep, looks like you can now define which mesh is the control surface. You can choose not to, in which case I'd guess it defaults to obj_ctrlSrf.  Right click details of parts matched to cfg details is handy for figuring out what the values actually are.  deflectionLiftCoeff seems to be surface area of the whole wing surface in m divided by 3.5ish.  ctrlSurfaceArea appears to the the proportion of that that's a control surface.  For instance if you have a 7sqr m wing, with 25% as control surface, deflectionLiftCoeff would be 2, and ctrlSurfaceArea would be 0.25.  I think.  Not 100% sure on any of that.

[wasml]

Quote

deflectionLiftCoeff seems to be surface area of the whole wing surface in m divided by 3.5ish.  ctrlSurfaceArea appears to the the proportion of that that's a control surface.  For instance if you have a 7sqr m wing, with 25% as control surface, deflectionLiftCoeff would be 2, and ctrlSurfaceArea would be 0.25.  I think.

Ah - I saw ctrlSurfaceArea and assumed it meant what it said - thanks. I'll take a closer look at those cfg details and update.

[The_Doctor_John_Smith]

Hey, does anybody know how to solve the animation inversion problem? I have a pair of elevators, one port and one starboard, that need to be separate as their meshes do not mirror. I have imported them and they work as expected except that the animation for the port elevator is inverted and moves the opposite way. Strangely enough, they control the aircraft normally so it seems to be an animation issue.

[jerethdatiger]

ok while i was following the instructions , even though my mesh was aligned in my 3d app in unit everything is off again

 

[NecroBones]

On 1/19/2016 at 0:24 AM, The_Doctor_John_Smith said:

Hey, does anybody know how to solve the animation inversion problem? I have a pair of elevators, one port and one starboard, that need to be separate as their meshes do not mirror. I have imported them and they work as expected except that the animation for the port elevator is inverted and moves the opposite way. Strangely enough, they control the aircraft normally so it seems to be an animation issue.

 

Do they actually face opposite to each other in your modeler, and in Unity? KSP expects everything to face certain ways. I'd design them both as "left side" parts as far as the coordinate system is concerned, and let the rotation happen in the VAB/SPH.

[The_Doctor_John_Smith]

On 3/9/2016 at 7:20 AM, NecroBones said:

 

Do they actually face opposite to each other in your modeler, and in Unity? KSP expects everything to face certain ways. I'd design them both as "left side" parts as far as the coordinate system is concerned, and let the rotation happen in the VAB/SPH.

I have done that technique for the rudder, but the models are left - right dependent.

[NecroBones]

8 hours ago, The_Doctor_John_Smith said:

I have done that technique for the rudder, but the models are left - right dependent.

 

Right, but I think you'll still get the best results if you design them both as "left" wings in terms of how they're oriented in the Blender/Unity, and let the VAB rotate it back the way it needs to be. In other words, take your right wing, and flip it around in Blender and update the part CFG accordingly. It's worth a try.

[TiktaalikDreaming]

On 3/12/2016 at 0:17 AM, NecroBones said:

 

Right, but I think you'll still get the best results if you design them both as "left" wings in terms of how they're oriented in the Blender/Unity, and let the VAB rotate it back the way it needs to be. In other words, take your right wing, and flip it around in Blender and update the part CFG accordingly. It's worth a try.

I've had an issue with fin control surfaces for my V-2 that is probably this.  Pretty sure I did my fins as right side parts.  Stoked if this is all it was.  :-)

That's all it was, but now ....

Edited May 23, 2016 by TiktaalikDreaming

[The_Doctor_John_Smith]

I have tried that. It corrected the animation, but all that happened was that it started responding the wrong way. (i.e. opposite how it should have.) Currently, only the animation is reversed, but it functions normally.

Edited March 18, 2016 by The_Doctor_John_Smith

[TiktaalikDreaming]

I'm working on some wings (with built in control surfaces, so using ModuleControlSurface), and they're set up the same way I set up other control surfaces.

Outboard is Unity Local -X,  Blender +X.  Forward/Up is UL+Z, B+Z.  I've started parenting control surfaces to an empty object with the right axis as this both works and makes setting said axis a lot easier.  And they work.  But when attached in the VAB/SPH in mirror symmetry, the control surfaces operate in opposite directions.  Again, like most of these issues, it's just the animation of the control surfaces that's wrong.  The wings provide control in the correct direction, but they look like they shouldn't.

Anyways, here's what it looks like, (all the control directions are pitch, no roll, even though it all looks like roll)

 

PS: I grepped out all the stock squad notes on DeflectionLiftCoeff, and it's exactly the listed surface area divided by 3.5 in all cases. 

 

And, as soon as I've described the issue I find the offending config. 

mirrorRefAxis = 0, 0, -1

Which, once removed (like virtually all the control surface parts) it's happy. 

Edited May 23, 2016 by TiktaalikDreaming