Question ASCII-3 (Lua Script J-3 with mesh made with Notepad) Adventures and Questions

[Thunder Chicken]

Full power engine run-up with parking brake set - no motion at all until I release the parking brake:


If you apply the parking brake just before touchdown and hold the elevator all the way back you can do bush landings on the aiming point markers at the SLF. If you have a stick/yoke and rudder setup this should be pretty fun, but pretty hard with a keyboard only.

 

[Thunder Chicken]

More adventures. I looked to see if I could update the set_touchdownpoints model to the new model that allows more than three points, so when my J-3 noses over when I slam on the brakes it doesn't flip and go below ground level. It seems by a cursory examination of the OpenOrbiter code that the updated Lua Interpreter supports this, but something isn't working right. I may be misunderstanding the Orbiter code as well.

Right now I am using the default three-point contact model in Lua, which works as far as it goes:

vi:set_touchdownpoints(tail_wheel_contact, right_wheel_contact, left_wheel_contact)

The contact definitions are all vectors {x=N, y=M, z=P}.

From the API Reference and the code I can see on GitHub, the format for the new touchdown points definition for Lua should look like:

vi:set_touchdownpoints (tdvtx, ntdvtx)

where tdvtx is a "list" of touchdown points, and ntdvtx is the number of points in the list. There is no list construct in Lua, so I initially assumed a table would be used instead (what else could it be)? As an initial test I tried making a table of all the contact points (all are vectors):

td_points =
{
            tail_wheel_contact,
            right_wheel_contact,
            left_wheel_contact,
            prop_hub,
            left_wing_tip,
            right_wing_tip,
            left_elevator_tip,
            right_elevator_tip,
            rudder_tip
}

and applying it like this:

vi:set_touchdownpoints(td_points, 9)

But I get this error: set_touchdownpoints: argument 1: invalid type (expected vector) table given

So using a table is out. So I then tried it with an additional point at the nose of the aircraft using this format:

vi:set_touchdownpoints(tail_wheel_contact, right_wheel_contact, left_wheel_contact, prop_hub, 4)

This runs without error, but it seems to ignore the fourth contact point, but it doesn't cause any errors otherwise. Similarly, the following works without any indication of the number of vertices:

vi:set_touchdownpoints(tail_wheel_contact, left_wheel_contact, right_wheel_contact, prop_hub)

So it looks like it only reads the first three arguments and ignores everything else.

Does anyone know whether the new contact model was fully implemented in Lua? It does not seem so, but the code seems to suggest that it should be?:

int Interpreter::v_set_touchdownpoints (lua_State *L)
{
    static const char *funcname = "set_touchdownpoints";
    AssertMtdMinPrmCount(L, 2, funcname);
    VESSEL *v = lua_tovessel_safe(L, 1, funcname);

    if (lua_gettop(L) == 2 && lua_istable(L, -1)) // new API
    {
        AssertPrmType(L, -1, PRMTP_TABLE, funcname);
        TOUCHDOWNVTX *tdvtx;
        DWORD ntdvtx, nbuf;

        ntdvtx = nbuf = 0;
        lua_pushnil(L);
        while (lua_next(L, -2)) {
            if (lua_istouchdownvtx(L, -1)) {
                if (ntdvtx == nbuf) { // grow buffer
                    TOUCHDOWNVTX *tmp = new TOUCHDOWNVTX[nbuf += 3];
                    if (ntdvtx) {
                        memcpy(tmp, tdvtx, ntdvtx * sizeof(TOUCHDOWNVTX));
                        delete[]tdvtx;
                    }
                    tdvtx = tmp;
                }
                tdvtx[ntdvtx++] = lua_totouchdownvtx(L, -1);
            }
            lua_pop(L, 1);
        }
        ASSERT_SYNTAX(ntdvtx >= 3, "Too few arguments");

        v->SetTouchdownPoints(tdvtx, ntdvtx);

        delete[]tdvtx;
    }
    else // old API
    {
        //AssertMtdMinPrmCount(L, 4, funcname);
        VECTOR3 pt1 = luamtd_tovector_safe(L, 2, funcname);
        VECTOR3 pt2 = luamtd_tovector_safe(L, 3, funcname);
        VECTOR3 pt3 = luamtd_tovector_safe(L, 4, funcname);
        v->SetTouchdownPoints(pt1, pt2, pt3);
    }
    return 0;
}

 

[dgatsoulis]

More adventures. I looked to see if I could update the set_touchdownpoints model to the new model that allows more than three points, so when my J-3 noses over when I slam on the brakes it doesn't flip and go below ground level. It seems by a cursory examination of the OpenOrbiter code that the updated Lua Interpreter supports this, but something isn't working right. I may be misunderstanding the Orbiter code as well.

Right now I am using the default three-point contact model in Lua, which works as far as it goes:

vi:set_touchdownpoints(tail_wheel_contact, right_wheel_contact, left_wheel_contact)

The contact definitions are all vectors {x=N, y=M, z=P}.

From the API Reference and the code I can see on GitHub, the format for the new touchdown points definition for Lua should look like:

vi:set_touchdownpoints (tdvtx, ntdvtx)

where tdvtx is a "list" of touchdown points, and ntdvtx is the number of points in the list. There is no list construct in Lua, so I initially assumed a table would be used instead (what else could it be)? As an initial test I tried making a table of all the contact points (all are vectors):

td_points =
{
            tail_wheel_contact,
            right_wheel_contact,
            left_wheel_contact,
            prop_hub,
            left_wing_tip,
            right_wing_tip,
            left_elevator_tip,
            right_elevator_tip,
            rudder_tip
}

and applying it like this:

vi:set_touchdownpoints(td_points, 9)

But I get this error: set_touchdownpoints: argument 1: invalid type (expected vector) table given

So using a table is out. So I then tried it with an additional point at the nose of the aircraft using this format:

vi:set_touchdownpoints(tail_wheel_contact, right_wheel_contact, left_wheel_contact, prop_hub, 4)

This runs without error, but it seems to ignore the fourth contact point, but it doesn't cause any errors otherwise. Similarly, the following works without any indication of the number of vertices:

vi:set_touchdownpoints(tail_wheel_contact, left_wheel_contact, right_wheel_contact, prop_hub)

So it looks like it only reads the first three arguments and ignores everything else.

Does anyone know whether the new contact model was fully implemented in Lua? It does not seem so, but the code seems to suggest that it should be?:

int Interpreter::v_set_touchdownpoints (lua_State *L)
{
    static const char *funcname = "set_touchdownpoints";
    AssertMtdMinPrmCount(L, 2, funcname);
    VESSEL *v = lua_tovessel_safe(L, 1, funcname);

    if (lua_gettop(L) == 2 && lua_istable(L, -1)) // new API
    {
        AssertPrmType(L, -1, PRMTP_TABLE, funcname);
        TOUCHDOWNVTX *tdvtx;
        DWORD ntdvtx, nbuf;

        ntdvtx = nbuf = 0;
        lua_pushnil(L);
        while (lua_next(L, -2)) {
            if (lua_istouchdownvtx(L, -1)) {
                if (ntdvtx == nbuf) { // grow buffer
                    TOUCHDOWNVTX *tmp = new TOUCHDOWNVTX[nbuf += 3];
                    if (ntdvtx) {
                        memcpy(tmp, tdvtx, ntdvtx * sizeof(TOUCHDOWNVTX));
                        delete[]tdvtx;
                    }
                    tdvtx = tmp;
                }
                tdvtx[ntdvtx++] = lua_totouchdownvtx(L, -1);
            }
            lua_pop(L, 1);
        }
        ASSERT_SYNTAX(ntdvtx >= 3, "Too few arguments");

        v->SetTouchdownPoints(tdvtx, ntdvtx);

        delete[]tdvtx;
    }
    else // old API
    {
        //AssertMtdMinPrmCount(L, 4, funcname);
        VECTOR3 pt1 = luamtd_tovector_safe(L, 2, funcname);
        VECTOR3 pt2 = luamtd_tovector_safe(L, 3, funcname);
        VECTOR3 pt3 = luamtd_tovector_safe(L, 4, funcname);
        v->SetTouchdownPoints(pt1, pt2, pt3);
    }
    return 0;
}

Disclaimer: I have never tried setting the new touchdown points in Lua, only in C++, so take the following info with a grain of salt.

You need to use an array of TOUCHDOWNVTX tables , where each TOUCHDOWNVTX table contains the required key-value pairs ("pos", "stiffness", "damping", "mu", "mu_lng"). The issue with the current implementation seems to be that you are trying to pass a table of vectors directly instead of a table of TOUCHDOWNVTX tables.

This should work:

local tail_wheel_contact = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local right_wheel_contact = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local left_wheel_contact = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local prop_hub = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local left_wing_tip = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local right_wing_tip = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local left_elevator_tip = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local right_elevator_tip = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }
local rudder_tip = { pos = {x=N, y=M, z=P}, stiffness = value, damping = value, mu = value, mu_lng = value }

local td_points = {
    tail_wheel_contact,
    right_wheel_contact,
    left_wheel_contact,
    prop_hub,
    left_wing_tip,
    right_wing_tip,
    left_elevator_tip,
    right_elevator_tip,
    rudder_tip
}

vi:set_touchdownpoints(td_points)

For an example of stiffness, damping etc values that work, try getting the Deltaglider's touchdown points with v:get_touchdownpoints(0) (0 = index of touchdown point) or look them up directly in the Deltaglider's source code.

 

[Thunder Chicken]

There still seems to be a problem. I tried the following. Note that the pos are all Lua Orbiter vectors.

        td_points =
        {
            {pos=tail_wheel_contact, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
            {pos=left_wheel_contact, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
            {pos=right_wheel_contact, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1}
        }
        vi:set_touchdownpoints(td_points,3)

I still get this error:

set_touchdownpoints: argument 1: invalid type (expected vector) table given

I noticed that the vectors used in the Atlantis Lua code for pos are C++ vectors (_V(N,M,P) format), not script vectors.
I tried this:

        td_points =
        {
            {pos=_V(tail_wheel_contact.x, tail_wheel_contact.y, tail_wheel_contact.z) , stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
            {pos=_V(left_wheel_contact.x, left_wheel_contact.y, left_wheel_contact.z), stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
            {pos=_V(right_wheel_contact.x, right_wheel_contact.y, right_wheel_contact.z), stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1}
        }

but I get exactly the same error. I don't see what I am missing because the td_points is a table construct.

EDIT: I also tried enumerating the vector arguments, still same error.

        td_points =
        {
            {pos=_V(0.0, -0.179, -4.298), stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
            {pos=_V(-0.921, -1.3565, 0.87), stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
            {pos=_V( 0.921, -1.3565, 0.87), stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1}
       }

However, I also noted that in the Atlantis Lua code they use the form set_touchdownpoints(tdvtx) with no second argument for number of vertices. I tried that (vi:set_touchdownpoints(td_points) using the enumerated vector, still the same error. It simply can't see td_points as anything but a table, because it is a table?

 

[dgatsoulis]

td_points =  {pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1} }

 vi:set_touchdownpoints(td_points)

EDIT: BTW, I think that Orbiter expects the first 3 touchdown points to be in the order front_center, back_left, back_right but you seem to have back_center, left, right. Not sure if it affects the new touchdown points but if you get an upside-down orientation this might be what's causing it. Anyway, give the code above a try and see if it works.

 

[Thunder Chicken]

td_points =  {pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1} }

 vi:set_touchdownpoints(td_points)

I don't see how this code improves matters. The unmatched } at the end of the statement breaks the script and it won't load anything after it. Removing the unmatched } does the same.

 

[dgatsoulis]

my bad, typo. Instead of removing the unmatched } at the end, add one opening at the beginning

td_points =  {{pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1} }

 vi:set_touchdownpoints(td_points)

 

[Thunder Chicken]

my bad, typo. Instead of removing the unmatched } at the end, add one opening at the beginning

td_points =  {{pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1} }

 vi:set_touchdownpoints(td_points)

It was just a problem with my arrangement of brackets? Really?

So I tried this, and it loads without error. But it is not setting the contact points correctly:



And as soon as I touch the throttle I get yeeted to Alpha Centauri.

EDIT: BTW, I think that Orbiter expects the first 3 touchdown points to be in the order front_center, back_left, back_right but you seem to have back_center, left, right. Not sure if it affects the new touchdown points but if you get an upside-down orientation this might be what's causing it. Anyway, give the code above a try and see if it works.

The J-3 is a tail-dragger, so that rather screws things up with the baked-in assumption of a nose wheel. There really isn't a sensible way to fake an artificial nose wheel and have it handle correctly. Additionally, the second and third arguments apparently must be the left and right gear respectively for the default differential braking to work in the correct direction, at least for the old contact model. So I really don't have any less bad options.

This orientation was generally working fine for taxiing, but if I pitched or rolled over, it would flip inverted under ground. That was rather my motivation for moving to the new contact model in that my hope was that stopping the inversion with a nose or wing tip contact would keep the aircraft "in-play".

 

[Thunder Chicken]

Something strange is going on. I think this code:

td_points = {
        {pos=_V(0.0, -0.179, -4.298), stiffness=1e8, damping=1e6, mu=0.0, mu_lng=0.0},
        {pos=_V(-0.921, -1.3565, 0.87), stiffness=1e8, damping=1e6, mu=0.0, mu_lng=0.0},
        {pos=_V( 0.921, -1.3565, 0.87), stiffness=1e8, damping=1e6, mu=0.0, mu_lng=0.0}}

vi:set_touchdownpoints(td_points)

is attempting to put the updated contact point list into the deprecated 3-point model. The new contact model supposedly has a second mandatory argument for the number of points (per the API_Reference):

vi:set_touchdownpoints(tdvtx, ntdvtx)

But if I try this:

vi:set_touchdownpoints(td_points, 3)

it breaks the script and nothing loads after it.

 

[dgatsoulis]

I am not sure that it would work as you'd like, but you can try to implement a dummy front_center touchdown point that is at x = 0, y = the (neg)distance of the lowest front part and z = the z distance of the same point. That is used only if the ship is at a landed state (or when the groundspeed is at value below a threshold). When the ship isn't landed the y distance is moved to 0. Keep the first touchdown point you have now as a 4th point.

(change the y and z values of the first point to the actual distances according to your mesh)

td_points_landed =  {{pos = {x=0.0, y=-0.15, z= 2.5}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1}}

td_points =  {{pos = {x=0.0, y=0, z= 2.5}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1}}

planet = vi:is_landed()
if planet != nil then
    vi:set_touchdownpoints(td_points)
    else
    vi:set_touchdownpoints(td_points_landed)
end

This is a sloppy approach that jumps between two different sets of touchdown points and could lead into trouble when the state changes from landed to in_flight.

My guess is that you want it to behave as follows:
When the vessel is landed or taxiing, you want the nose to point slightly up. As you build up speed to take off you want the vessel to take a more horizontal position.

Introduce a variable that ties into the y position of the front_center td point, that is relevant to the ground speed. For example:

(this runs in every frame)

take_off_speed = 80
spd = vi:get_groundspeed()
if spd > take_off_speed then spd = take_off_speed end
offset = 0.15 * spd/take_off_speed
contact = v:get_groundcontact()
if contact == true and spd > 0.01 then
             td_points_landed =  {{pos = {x=0.0, y=-0.15+offset, z= 2.5}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=-0.921, y=-1.3565,z= 0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x= 0.921, y=-1.3565, z=0.87}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1},
             {pos = {x=0.0, y=-0.179, z= -4.298}, stiffness=1e8, damping=1e6, mu=1.6, mu_lng=0.1}}
             vi:set_touchdownpoints(td_points_landed)
end

I am guessing that you still need to initialize the td points (without the offset) at the vessel configuration part of your script, otherwise it might lead to strange behaviour.

Give this a try and see if it works.

 

[Thunder Chicken]

I don't think the location of the contact points is a major problem. It hasn't been unless I invert the aircraft in some manner, then it wants to be inverted.

On a whim, I wondered if the model was working and the stiffness / dampening parameters were not appropriate for the low mass of this vessel (J-3 empty mass is ~450 kg with pilot). I set the mass to 10000 kg, started the simulation, and hit the throttle. I stayed in place, but slowly sank into the runway.


4000 kg seems to be the minimum mass that I can apply without being punted into space, and it seems to assume the correct contact landing points when I tap the throttle:

Right now the contact model code is:

    stiffness_value = 1e8
    damping_value = 1e6

    td_points = {{pos=tail_wheel_contact, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=left_wheel_contact, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=right_wheel_contact, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=prop_hub, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=left_wing_tip, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=right_wing_tip, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=left_elevator_tip, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=right_elevator_tip, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0},
    {pos=rudder_tip, stiffness=stiffness_value, damping=damping_value, mu=0.0, mu_lng=0.0}}
    
    vi:set_touchdownpoints(td_points)

This runs without errors, but I haven't been able to test the other contact points as I can barely get the vessel to move as it is 10 times heavier than normal. Do you know the units / derivation of the stiffness and damping values? I know it is some spring-damping model, but I'd rather see the equations and see if I can derive appropriate values for a 450 kg vessel.

If set_touchdownpoints accepts all of the contact points, that means the ntdvtx parameter isn't needed, at least in the Lua version. We really need to get the documentation for scripting sorted out as it is maddening trying to guess Lua methods based on the API reference, and trying to infer it from the Orbiter code base is challenging as the Atlantis and DG are much more complicated vessels. I'm thinking if I can get this to work I might write up how I made this airplane. That might be helpful for other confused souls who just want to make something simple. I'd help with the Orbiter documentation if there is something I can contribute.

 

[Thunder Chicken]

I ramped up the engine thrust so I could get enough speed to crash it, and it seems that the vertex cloud is in place:


You may have noticed that I put the friction coefficients to 0. I did this for the three wheel contacts as I have a separate model for modeling rolling wheels and brakes and basically want to shut off the default braking behavior. I should set mu to some better values for the other contact points as when I crashed in the picture above I was actually spinning like a puck on an air hockey table.

OK, so it seems that model works. I just need to restore the proper mass and engine thrust, and to do that I need to sort out good values for the stiffness and damping constants.

 

[Thunder Chicken]

Dropping both the stiffness and damping coefficients by an order of magnitude in alignment with the change in mass seems to work OK. But something else I noticed when updating the scenario file for the proper landed configuration - even with zero thrust and brake applied, the vessel status is "Orbiting Earth" and not "Landed". The vertical speed indicator is jiggling a bit as well. Something still isn't happy with the model.

EDIT: It seems if I sit long enough I still get yeeted into space at some random time in the simulation. When it works it seems to work well, but it's not particularly stable. Can't get the status to Landed no matter what.

 

[Thunder Chicken]

I still have some punch-list items to wrap up but they are mostly cosmetic, and it's pretty fun to fly, so I figured I'd put it out for folks to play around with. Unzip the attached zip file to your OpenOrbiter directory.

Some notes and basic info:

• It should work with OpenOrbiter Mar 15 2024 March 21 2024 release or later. It absolutely will not work with Orbiter 2016 or earlier as a majority of the necessary Lua methods are not available in them. This is all done in Lua script, no C++ code was abused during the making of this add-on.
• The animated aircraft instruments work with the exception of the compass (TBD) and the panel status animations. I'm still struggling with how to update the UV coordinates to update the panel status indicators, and I need to make a mesh and texture for the compass wheel. I'd like to get a slip indicator animation at some point too. I have temporary annotations set up to provide true heading and the status of the parking brake (toggle with B) and auto-coordinate feature (toggle with A). These instruments are as they would have been in a circa 1940 J-3 Cub. The airspeed indicator provides indicated airspeed, not true airspeed. For a constant true airspeed, indicated airspeed will decrease with altitude due to the reduction in dynamic pressure due to reduction in air density.
• The auto-coordinate feature basically commands the rudder to keep yaw to the incoming wind near zero and will be helpful to those without rudder pedals. If you do have rudder pedals you might like to shut this feature off. In straight and level flight you may wish to disable this because if you start to bank, the rudder will try to coordinate your turn, which increases the rate of turn. The actual original J-3s had nothing like an autopilot, this is just a concession to the folks who might want to fly this using a keyboard or joystick without rudder pedals.
• Try taxiing around using the rudder and differential brakes to steer. I have created my own rolling wheel and brake models that replace the usual Orbiter ground handling. You can lock up these brakes. You can do static engine run-ups. You can lock up one of the wheels and using engine thrust turn around on a point. Try some bush flying and short field landings by hitting the brakes on wheel contact and holding the elevator all of the way back. Both brakes can be set using the parking brake (toggle with B) or individually (usual , and . keys).
• If you are trying this out just after coming from flying a DG through a Mach 25 re-entry, be aware, this is a slow aircraft. It's size, speed, and performance are all as realistic as I can make them. Enjoy a slow flight exploring KSC at a nice leisurely pace.
• Improved reciprocating engine and propeller models are planned for the future, and maybe some improved aerodynamics so one can do spins and such, but right now it is a basic (but good) implementation of standard Orbiter thrusters and air control surfaces.

Enjoy, and post your feedback here on this thread. When I get everything polished up I'll put it up on OrbiterHangar.

Cheers, and thanks to all the folks who helped me wrestle with the Orbiter code, that is always appreciated (and very much necessary until I get better at it). Also thanks to the folks maintaining the OpenOrbiter code base who put a LOT of effort into porting a lot of capabilities into Lua format, without which this add-on would not be possible.

 

[misha.physics]

It doesn't work with OpenOrbiter (Mar 15 2024) for me. I don't see any vessel after launching a scenario, and the "Apply" is inactive:



But it works with OpenOrbiter (Apr 05 2024):

 

[Thunder Chicken]

It doesn't work with OpenOrbiter (Mar 15 2024) for me. I don't see any vessel after launching a scenario, and the "Apply" is inactive:

View attachment 38854

But it works with OpenOrbiter (Apr 05 2024):

View attachment 38855

Thanks. That was my mistake. The version that I was using was March 21, 2024. Necessary Lua capabilities were being generated at a furious rate during that time, and it wouldn't surprise that a week would make such a difference. I'll update my previous post with the correct version.

 

[Thunder Chicken]

I am strangely having a lot of fun just taxiing the plane all over KSC. It handles on the ground really well, and seems to handle terrain just fine. The brakes appear to work on a slope. Maybe I should make a car add-on?

 

[Buck Rogers]

Maybe I should make a car add-on?

AFAIK all driving mods, General Vehicle etc.. are position displacement hacks and therefore very crude and don't take into account engine power, slope etc. A real driving module would be awesome! How easily could one convert Lua script to a .dll?

Dropping both the stiffness and damping coefficients by an order of magnitude in alignment with the change in mass seems to work OK

I've been working with TD points recently and have got most of it figured, the settings are very mass sensitive. General rule, if it sinks- increase spring/damp, if it likes to NaN, decrease, the lower the mass the lower the value, mu the other way aound (one can make a nice water landing effect if one gets it right).
I haven't tried a reverse tri config yet, what did you use?

For forward tri the sequence is= front, left, right
Quad is= left front, left back, right front, right back

And then= body left, body right, back, top, front

as a minimum setup, one can add extra points inbetween.

 

[Thunder Chicken]

AFAIK all driving mods, General Vehicle etc.. are position displacement hacks and therefore very crude and don't take into account engine power, slope etc. A real driving module would be awesome! How easily could one convert Lua script to a .dll?

Delivering engine power to the wheels could be done easily with something similar to the braking model. Steering could be handled similarly to the flying tail feature I coded. I might just try to do this.

I suppose it wouldn't be hard to convert a script back to a C++ equivalent and compile it, but why is that necessary? The beauty of scripting is that you don't have to compile a module.

I've been working with TD points recently and have got most of it figured, the settings are very mass sensitive. General rule, if it sinks- increase spring/damp, if it likes to NaN, decrease, the lower the mass the lower the value, mu the other way aound (one can make a nice water landing effect if one gets it right).
I haven't tried a reverse tri config yet, what did you use?

For forward tri the sequence is= front, left, right
Quad is= left front, left back, right front, right back

And then= body left, body right, back, top, front

as a minimum setup, one can add extra points inbetween.

I understand all this. The old contact model requires the left main wheel to be the second argument and the right main wheel to be the third to comply with the default braking orientation, so nose gear had to go in as the first argument. That wasn't a problem unless you did something to flip the vessel, then you'd be underground. Part of the reason I wanted to get the new touchdown point model was to eliminate that behavior and still keep it sensibly modeled as a tail-dragger. Now the wings, nose, or tail will generally keep you upright if you stop or turn too quickly and prevent "turtle syndrome" where you flip and can't recover.

I would like to know the math under these stiffness and damping numbers and maybe derive something more suitable. I think the new touchdown model turns off a lot of people because some mismatch between the vessel mass and these parameters shoots them into space. It actually works pretty well, but still randomly will yeet you into solar orbit. I have tinkered with the time propagation timesteps, lowering them to see if that aids in stability. I'm making an educated guess at how that physical model works, but some stability criterion might apply to it that would make it generally stable, but I would need to see the underlying math of that model to determine if that is possible.

 

[Buck Rogers]

these setups worked

2kg- 320 12 15 15
10t- 255000 110000 2.5 2.5

for solid contact with ground