Project Lua Script Helicopters!

Here are even better instrument textures (there are separated textures below):
An interesting thing on GitHub:
And this could be very interesting (instruments are interactive):
 
Is there a test vessel, yet
If you mean the mesh, then I'd like to add some things to it first, but I almost finished. I can add other features later.

I added one istrument (its texture was taken from the GitHub link I attached above), without arrow, so it can and have to be animated. It's inside the panel and behind glass. Looks very nice:

Без імені.pngБез імені2.png
 
Is there a test vessel, yet
I'm getting there with your Bell 222. It's more or less flyable, but I am still sorting out the VC and MFDs and such. I'm not 100% happy with the flight controls and need to think a bit more about how to apply the rotor forces. I want to make it such that wheeled helicopters can taxi as well, so I need to get my wheel model in, add more animations...

EDIT: I've attached my script code to date. If you install your Bell 222 and extract this zip in the same Orbiter directory you can play with it. Press E to turn on engine, comma/period for collective up and down, and typical Orbiter keypad controls for pitch, bank, yaw, and throttle.
 

Attachments

Last edited:
Updated the cyclic and it is much smoother and easier to control in hover.

Controlling the throttle, collective, and cyclic all at the same time during near hover using a keyboard is...complicated. Landing on a stable approach isn't too bad, but from a near hover it's very challenging without stick and rudder controls. I nerfed the realism a little by not applying the main rotor torque, assuming that gets countered automagically by the tail rotor without pilot intervention. I think I need to lower the sensitivity of the cyclic at low speeds as another concession to keyboard users to give them half a chance of hovering.
 
Maybe having two versions: simplified (for keyboard) and complex (for joystick) could be a good solution. Just in order not to lose a more realistic model if you've already implemented it.
 
Maybe having two versions: simplified (for keyboard) and complex (for joystick) could be a good solution. Just in order not to lose a more realistic model if you've already implemented it.
Even a joystick would only offload the cyclic controls from the keyboard, and it would force you to manage the throttle, collective, and tail rotor all with your remaining hand. In the actual helicopter you have the cyclic, the collective (which usually incorporates the throttle using a twisting handle like a motorbike), and the rudder pedals. There is just a lot that needs to be controlled simultaneously. Helicopter pilots need both hands, left wrist, and their feet to manipulate all the necessary controls.

The thrust produced by the main rotor also isn't static at a given throttle and collective setting either. Propeller thrust depends on the relative airspeed as well. If you pitch or roll a little bit, not only does your vertical component of thrust decrease by the cosine of the angle, but you pick up some relative airspeed which further lowers the thrust. You need to be able to quickly adjust the collective and throttle to compensate.

Another challenge is visual reference when hovering. Helicopter cockpits have lots of windows in all directions because the pilots need them all for visual reference. I need to set the FoV of the cockpit cameras really wide and angle them downward to see the ground clearly. Even then, if the surface textures are washed out, you can start drifting in any direction and not really realize it until you are moving so fast that your vertical stabilizer weathervanes the helicopter.

So I am trying to strike some balance where hovering flight can be done practically with a keyboard, but behaves in a way more reminiscent of a dynamic helicopter and not a ShuttlePB calmly hovering on its thrusters, magically stable as a rock. An altitude hold autopilot that manages the collective while hovering might be very helpful. If the throttle is set at an appropriate power level, that would reduce workload to pitch/roll/yaw controls.
 
So I am trying to strike some balance where hovering flight can be done practically with a keyboard, but behaves in a way more reminiscent of a dynamic helicopter and not a ShuttlePB calmly hovering on its thrusters, magically stable as a rock. An altitude hold autopilot that manages the collective while hovering might be very helpful. If the throttle is set at an appropriate power level, that would reduce workload to pitch/roll/yaw controls.
Sounds very nice (y)
 
Even a joystick would only offload the cyclic controls from the keyboard, and it would force you to manage the throttle, collective, and tail rotor all with your remaining hand. In the actual helicopter you have the cyclic, the collective (which usually incorporates the throttle using a twisting handle like a motorbike), and the rudder pedals. There is just a lot that needs to be controlled simultaneously. Helicopter pilots need both hands, left wrist, and their feet to manipulate all the necessary controls.

The thrust produced by the main rotor also isn't static at a given throttle and collective setting either. Propeller thrust depends on the relative airspeed as well. If you pitch or roll a little bit, not only does your vertical component of thrust decrease by the cosine of the angle, but you pick up some relative airspeed which further lowers the thrust. You need to be able to quickly adjust the collective and throttle to compensate.

Another challenge is visual reference when hovering. Helicopter cockpits have lots of windows in all directions because the pilots need them all for visual reference. I need to set the FoV of the cockpit cameras really wide and angle them downward to see the ground clearly. Even then, if the surface textures are washed out, you can start drifting in any direction and not really realize it until you are moving so fast that your vertical stabilizer weathervanes the helicopter.

So I am trying to strike some balance where hovering flight can be done practically with a keyboard, but behaves in a way more reminiscent of a dynamic helicopter and not a ShuttlePB calmly hovering on its thrusters, magically stable as a rock. An altitude hold autopilot that manages the collective while hovering might be very helpful. If the throttle is set at an appropriate power level, that would reduce workload to pitch/roll/yaw controls.

Speaking of which, I have a nice Thrustmaster HOTAS + Rudder pedals set, but I have no idea to use it in Orbiter, that's really a pity 😥
 
I need a little help regarding the air speed indicator. Wikipedia says that the maximum speed of the Sikorsky R-4 helicopter is 65 knots. So, I would like to change numbers on the texture:

s.png

Maybe anyone knows what the maximum value instead of 160 I should write?
 
I need a little help regarding the air speed indicator. Wikipedia says that the maximum speed of the Sikorsky R-4 helicopter is 65 knots. So, I would like to change numbers on the texture:

View attachment 41675

Maybe anyone knows what the maximum value instead of 160 I should write?
This is probably a better source of information. The R-4 civilian variant was designated the S-47.


Maximum speed (Vne, velocity never exceed) is indicated to be 82 mph (90 kts), with a normal cruise speed of 65 mph (72 knots).

I can't find good photos of an R-4 panel, but the original airspeed gauges probably indicated mph, and didn't have the colored arcs, just the white dial indications on a black background. They generally just installed whatever airspeed indicator had the most appropriate range for the particular aircraft. It may have had some indications of Vne on a bezel, but it also wasn't uncommon for such markings to get painted on the instrument in the field back then. My best guess would be that the gauge probably ranged from 0 - 100 mph and looked something like this:

10-02910.jpg


Note that the scale isn't linear as airspeed goes with the square root of dynamic pressure (airspeed indicators are essentially just pressure gauges comparing stagnation pressure to local static pressure to measure dynamic pressure, which corresponds to airspeed), and the Bourdon tube inside acted like a spring that resisted needle movement at the high end of the arc.
 
Last edited:
Yep, a simple altitude hold autopilot that manages the collective does help out a lot during hover. It's still pretty challenging to taxi and land.

It did occur to me that I am flying what is meant to be a physically accurate facsimile of a Bell 222 which is a pretty powerful high performance helicopter. It's rather like getting your learner's driving permit and jumping right into a Lamborghini.
 
I'm trying to get the strobes and light beacons established. The beacons are created and they work if I set the beaconspec.active == true when I make the beacons, but I can't seem to toggle the beacons on/off by changing beaconspec.active.

I am making the beacons with this function:

Code:
function make_pretty.beacons()

    beaconpos = {}

    beaconpos[1] = vec.sub({x=-2.327, y=-1.37, z=2.138},cg)
    beaconpos[2] = vec.sub({x=2.327, y=-1.37, z=2.138},cg)
    beaconpos[3] = vec.sub({x=0, y=-1.774, z=2.1},cg)
    beaconpos[4] = vec.sub({x=0.193, y=2.42, z=-7.35},cg)
    beaconpos[5] = vec.sub({x=0.193, y=0.222, z=-7.14},cg)

    beaconcol = {}

    beaconcol[1] = {x=1,y=0,z=0}
    beaconcol[2] = {x=0,y=1,z=0}
    beaconcol[3] = {x=1,y=0,z=0}
    beaconcol[4] = {x=1,y=0,z=0}
    beaconcol[5] = {x=1,y=1,z=1}

    beaconspec = {}
    beacon = {}

    for i = 1, 5 do

        beaconspec[i]=
        {
            shape = BEACONSHAPE.STAR,
            pos = beaconpos[i],
            col = beaconcol[i],
            size = 0.2,
            falloff =  0.3,
            period = 0.8,
            duration = 0.3,
            tofs = (6-i)*0.2,
            active = true
        }

        if i < 3 then

            beaconspec[i].period = 0
            beaconspec[i].duration = 0

        end

        beacon[i] = oapi.create_beacon(beaconspec[i])
        vi:add_beacon(beacon[i])

    end

end

These beacons are made correctly and work. However, if I attempt to toggle them on/off by modifying the beaconspec.active boolean in the keypress L I can see that the boolean is being properly switched, but the lights remain on:

Code:
    if oapi.keydown(kstate, OAPI_KEY.L) then

        if lights_on == false then

            lights_on = true

        elseif lights_on == true then

            lights_on = false

        end

        for i = 1, #beaconspec do

            beaconspec[i].active = lights_on

        end

        oapi.dbg_out(beaconspec[5].active)

    end

I have similar beacons in my VWThing code and they work fine, so I don't know what is going on here.
 
Looks good. One thing to note is that in the gyrocompass (second instrument from right), the dial with the compass headings is what turns, with usually a small bug on the bezel for reference. Similarly, the blue/green background of the artificial horizon (middle instrument) is what moves relative to the white indicator lines.
 
Thanks. Yes, I know. It looks I finished:

Без імені.png

By the way, I'm not using transparent textures with FLAG 0x20, since I don't really like the way the border looks, so all moving elements are separate mesh with the corresponding border.

It looks the artificial horizon will be the most difficult to animate. I have no Idea how it could be done. I hope you have ideas, I'll send the new mesh with these instruments to you.

Also, I did some non-optimal things with the arrow textures, but that can be fixed in the future if needed.
 
It looks the artificial horizon will be the most difficult to animate. I have no Idea how it could be done. I hope you have ideas, I'll send the new mesh with these instruments to you.
Is the blue/green background a texture? The artificial horizon is typically a spherical indicator that can roll on its axes to indicate both pitch and roll.


If it is a flat mesh or just a texture then it is going to be difficult to do much with it.
 
Back
Top