NAV and BEACON ON/OFFs

[Muas]

Hi Pete and hi everyone.

I believe this must have been discussed before, specially between pit builders, but still I didn't find an answer, so:

I use a cockpit console with button, rotary and toggle switches (MJoy16 card) and I'd like to have separate on/off switches for NAV LIGHTS and BEACON LIGHTS. As we know FSX only provide toggle support for these functions. Anyway, studing the FSX SDK, I realized there are ways to get these light states from the sim, so I think one could easily program a script to get ON/OFF facility for these light switches.

This could be something like:

Is NAV LIGHTS on? If YES, get JOY1 BUTTON31 to TOGGLE NAV LIGHTS; if NO, get JOY1 BUTTON32 to TOGGLE NAV LIGHTS.

Joy1 buttons 31 and 32 would be connected to each side of a mini toggle switch on a cockpit panel.

Now could this solution be implemented on FSUIPC? Or, what kind of script should be made for this? Lua? Via simconnect?

Thanks.

[Pete Dowson]

Anyway, studing the FSX SDK, I realized there are ways to get these light states from the sim, so I think one could easily program a script to get ON/OFF facility for these light switches.

... Now could this solution be implemented on FSUIPC? Or, what kind of script should be made for this? Lua? Via simconnect?

You don't need anything so complicated. All the lights (10 of them in all) can be individually controlled by 10 bits in a word in FSUIPC offsets. You can assign buttons to "Offset" controls in FSUIPC's dropdowns to set and clear individual bits, thus controlling individual lights as you wish.

Try reading through this thread, which i found by searching for "Lights":

viewtopic.php?f=54&t=76621&p=472792

If there's anything not clear from that, after getting through it, let me know.

Regards

Pete

[Muas]

You don't need anything so complicated. All the lights (10 of them in all) can be individually controlled by 10 bits in a word in FSUIPC offsets. You can assign buttons to "Offset" controls in FSUIPC's dropdowns to set and clear individual bits, thus controlling individual lights as you wish.

Works a treat! Thank you very much!

[Muas]

I'm so happy about this possibility, I wonder if it's possible to use these kind of FSUIPC features to other "toggle only" commands like Parking Brakes, etc, making them ON/OFF's, even those ingame 6***** offsets?

[Pete Dowson]

I'm so happy about this possibility, I wonder if it's possible to use these kind of FSUIPC features to other "toggle only" commands like Parking Brakes, etc, making them ON/OFF's, even those ingame 6***** offsets?

Yes to the first part -- look for the function you want in the Offsets lists (part of the FSUIPC SDK). Note that they aren't all bit-oriented. when there's a value involved, as for Parking Brake, you'd use the "Offset XXXX Set" control with the value as parameter. the "XXXX" is the size of the value -- byte for 1 byte, word for 2-byte, dword for 4-byte, float32 or float64 for 32 and 64 bit floating point numbers (which are divided by 1000 so fractions can be used).

I'm not sure what you mean by "ingame 6*** offsets", but I suspect if they are application ones it will depend entirely upon the application. Certainly many of the Project Magenta offsets are offset both read and write enabled, and most folks' cockpit switches operate them directly.

Parking brake is listed at 0BC8, and is a 2-byte value (so a "word"), and is 0 for off, 16383 for on.

Regards

Pete

[Muas]

Parking brake is listed at 0BC8, and is a 2-byte value (so a "word"), and is 0 for off, 16383 for on.

Again, it works 100%. Thanks.

One more, if I may...

I have this old Project Fokker F100 installed on FSX and it works ok, except the liftdumpers which should "close" when thrust is applied on ground - there was an old gauge that made that happen but it doesn't work on FSX anymore. These liftdumpers are set by the TOGGLE_WING_FOLD event.

What I'm asking is if its possible to toggle the wingfold automaticly to the "off" position by opening the throttle on ground.

That should be dependant on the "on ground" and "throttle >0" conditions, and we can read the wingfold state using the FOLDING WING LEFT/RIGHT PERCENT variable, but is it possible to implement this with FSPUIC?

[Pete Dowson]

... These liftdumpers are set by the TOGGLE_WING_FOLD event.

What I'm asking is if its possible to toggle the wingfold automaticly to the "off" position by opening the throttle on ground.

That should be dependant on the "on ground" and "throttle >0" conditions, and we can read the wingfold state using the FOLDING WING LEFT/RIGHT PERCENT variable, but is it possible to implement this with FSPUIC?

Pretty easy with a little Lua plug-in. On Ground is offset 0366 (2-byte word) being non-zero, throttle1 is a signed word at 088C, folding wing left is a float64 (double) at 2A48, similarly right is at 2A50.

For most things I'd have it based on an event -- so that the Lua program is automatically activated by things happening in FS. But the event here is presumably the throttle going positive (or greater than a nominal positive number, more likely) -- and there's no way to get a single event like that. An event based on throttle changes would trigger on every throttle change, and that's a potential performance hit.

So, I'd suggest making an "ipcReady.lua" file, in the Modules folder, which contains a loop, checking things say, twice a second or so? e.g.

PrevThrottle = 0
ThrottleThreshold = 256 -- nominal positive throttle value

while 1 do
    ipc.sleep(500) -- do nothing for half a second
    ThrottleNow = ipc.readSW(0x088C)
    if ipc.readUW(0x0366) ~= 0 then 
        -- We are on the ground
        -- see if throttle has just gone over threshold
        if    (PrevThrottle < ThrottleThreshold) and 
              (ThrottleNow > ThrottleThreshold) and
              (ipc.readDBL(0x2A48) ~= 0)  then
                   -- left wing fold is non-zero
                   ipc.control(66390) --Toggle wing Fold control
       end
       PrevThrottle = ThrottleNow
    end
end

... or something similar. I'm not sure which way around the folding wing "fiddle" should be operating -- to fold or to unfold -- but i'm sure you can adapt this as you need.

Regards

Pete

[Muas]

So, I'd suggest making an "ipcReady.lua" file, in the Modules folder, which contains a loop, checking things say, twice a second or so... or something similar. I'm not sure which way around the folding wing "fiddle" should be operating -- to fold or to unfold -- but i'm sure you can adapt this as you need.

Great! Your code works as should. No further edits were necessary. Thanks a lot.

As I mentioned, the lifdumpers on the Project Fokker F100 are deployed using the assigned TOGGLE_WING_FOLD event key. As it was programmed, I believed this had only one condiction to follow which is the "aicraft on ground" condition, so the assigned key works as an "arm" button when the aircraft is flying. With the lua plug-in you wrote, this works as it should on landing, being that, when previously armed, the liftdumpers extend upon touchdown and retract when a small thrust amount is applied, say, for taxi. Ok, good job.

Now to be accurate, this system should also be deployed on rejected take off, where liftdumpers would extend when speed was once greater than 80kts and throttle retarded to idle. For this to work, we need to "arm" the liftdumpers on ground - and they should not extend this time - and then they must extend if the "speed greater than 80kts and throttle retarded" event occurs, if not, they should be automatcly disarmed upon lift off. This is as closer as it gets to the real life F100 (there is also a manual extension based on thrust reversal, if system was not armed). I'd appreciate if you could help me develop this liftdumpers system a bit further.

Now, as an "ipcReady.lua" named file, it will be running when FS is "ready to fly", even if I'm not flying the F100. I don't have any wing folding aircraft installed anyway, but I'd prefer this solution could be aircraft assignable - if at all possible?

Thanks again.

[Pete Dowson]

Now to be accurate, this system should also be deployed on rejected take off, where liftdumpers would extend when speed was once greater than 80kts and throttle retarded to idle. For this to work, we need to "arm" the liftdumpers on ground - and they should not extend this time - and then they must extend if the "speed greater than 80kts and throttle retarded" event occurs, if not, they should be automatcly disarmed upon lift off. This is as closer as it gets to the real life F100 (there is also a manual extension based on thrust reversal, if system was not armed). I'd appreciate if you could help me develop this liftdumpers system a bit further.

Sorry, I'm not clear what you mean by "arm", "extend" and "disarm" in this context. Can you not figure out the logic from what you describe? The ground speed can be read from an offset, and you already have the throttle setting being read. The syntax of the Lua part is easy enough to see, I think. You just need to be clear about what you are reading and what you do with it.

Now, as an "ipcReady.lua" named file, it will be running when FS is "ready to fly", even if I'm not flying the F100. I don't have any wing folding aircraft installed anyway, but I'd prefer this solution could be aircraft assignable - if at all possible?

You could have it "event" driven, based on the event of the aircraft name changing. On that change you can read the aircraft name and compare it to the one you want to use this with, and if it matches, enter that loop, if not don't, or force it to exit if already started. It's only a few extra lines, but it isn't quite so easy to understand.

The only other way, really, is to have it saved under a different name (eg "liftdumper.lua") and try to remember to run it -- by button or keypress assignment -- when you load your aircraft. At present there is no facility to automatically press a button or run a plug-in, or anything else, when an aircraft is loaded -- although that's perhaps not a bad idea and one which perhaps I'll think about.

Regards

Pete

[Muas]

Here's the code with the rejected take-off amended - works a charm!

--------------------------------------------------------------------
-- FSX Lua plug-in for Project Fokker F-100 liftdumpers operation --
--------------------------------------------------------------------

PrevThrottle = 0
ThrottleThreshold = 128 -- nominal positive throttle value

while 1 do
    ipc.sleep(500) -- do nothing for half a second
    ThrottleNow = ipc.readSW(0x088C)
    if ipc.readUW(0x0366) ~= 0 then 
        -- we are on the ground

        -- 1: liftdumpers retraction on power up
        -- see if throttle has just gone over threshold
        if    (PrevThrottle < ThrottleThreshold) and 
              (ThrottleNow > ThrottleThreshold) and
              (ipc.readDBL(0x2A48) ~= 0)  then
                   -- left wing fold is non-zero, liftdumpers are extended
                   ipc.control(66390) -- Toggle Wing Fold to retract liftdumpers
        end

        -- 2: liftdumpers extension on rejected take-off
        -- see if IAS has reached 80 kts
        if ipc.readSW(0x02BC) > 80 * 128 then
            -- we are over 80 kts
            -- see if throttle has been cut to idle
            if    (PrevThrottle > ThrottleNow) and
                  (ThrottleNow < ThrottleThreshold) and 
                  (ipc.readDBL(0x2A48) == 0)  then
                       -- left wing fold is zero, liftdumpers are retracted
                       ipc.control(66390) -- Toggle Wing Fold to extend liftdumpers
            end
        end
    end
    PrevThrottle = ThrottleNow
end

Now about the aircraft dependable plug-in...

At present there is no facility to automatically press a button or run a plug-in, or anything else, when an aircraft is loaded -- although that's perhaps not a bad idea and one which perhaps I'll think about.

Keep the good work.

[Pete Dowson]

Here's the code with the rejected take-off amended - works a charm!

Good! I see you quickly got the hang of elementary Lua! ;-)

Now about the aircraft dependable plug-in...

I will definitely be implementing a facility to automatically execute a specified sequence of Lua plugins or FSUIPC Macros when an aircraft is loaded. It will be done by adding sections to the INI file like this:

[Auto.]

1- or ,

2=

...

I am currently not sure whether it should run these on every loading of the aircraft, if it is the same aircraft, or only when the aircraft is changed. Normally these things are only looked at on aircraft change. What do you think?

For consistency I might also have a global section:

[Auto]

...

which is run initially (after ipcReady) and on every aircraft load, before the aircraft or profile-specific section.

One of the things I'd need to remember to do is kill any still-running Lua threads which were started by one of these Auto sections when lookinbg at executing another, as otherwise those in loops like yours will proliferate!

None of this is hard to implement, so expect it in an interim update within a week or so.

Regards

Pete

[Muas]

I will definitely be implementing a facility to automatically execute a specified sequence of Lua plugins or FSUIPC Macros when an aircraft is loaded.

I'd follow the original FSUIPC ini file structure, including a common LUA section to list every threads to run everytime FS is "ready to fly", and specific LUA sections for each aircraft which would be started "on specific aircraft load".

I am currently not sure whether it should run these on every loading of the aircraft, if it is the same aircraft, or only when the aircraft is changed. Normally these things are only looked at on aircraft change.

Could you make it check if the loading aircraft is the same as the previous, in which case nothing should be done, and specific aircraft threads should continue running...

One of the things I'd need to remember to do is kill any still-running Lua threads which were started by one of these Auto sections when lookinbg at executing another, as otherwise those in loops like yours will proliferate!

...if the aircraft "on load" is different from the previous (aircraft changed), then it should kill all specific threads, and start the new aircraft ones according to the ini file - the common threads would still be kept running though.

This is my thinking, hope it helps.

[Pete Dowson]

I will definitely be implementing a facility to automatically execute a specified sequence of Lua plugins or FSUIPC Macros when an aircraft is loaded.

I'd follow the original FSUIPC ini file structure, including a common LUA section to list every threads to run everytime FS is "ready to fly", and specific LUA sections for each aircraft which would be started "on specific aircraft load".

They are "[Auto]" sections, and can list macros and/or Lua plug-ins, not just Lua ones. Aircraft- or Profile- specific ones folow the same method as for Axes, Buttons and Keys -- the name after a '.' character. All that side is standard as it is common code.

Could you make it check if the loading aircraft is the same as the previous, in which case nothing should be done

Actually that's the way it has to be without a lot more work. that's the way the Profile and Aircraft-Specific actions work.

the common threads would still be kept running though.

The common threads, those in the base [Auto] section, will be killed and restarted. I think that's okay.

Thanks & Regards

Pete

[Pete Dowson]

None of this is hard to implement, so expect it in an interim update within a week or so.

Okay, the [Auto] facilities are available now in FSUIPC versions 3.939 and 4.544, from the Updates Announcement. See the update notes in the Announcement.

Regards

Pete