Using undocumented FS Control codes

[jaxx]

Hello,

is it a problem when I use undocumented FS Control IDs as trigger events for Lua scripts?

I have hardware that I can configure to send any 5 digit decimal >65535 on button presses, dials etc.
But some planes I have only really work well when using L:Vars (e.g. the A2A Comanche with its 3-position gear switch does not really work with the FS control gear up/down events from the 2-postion switch on my hardware.

When I use the standard FS Controls those don't seem to get suppressed when processing in lua.
Is it ok to use undocumented FS control codes for this (e.g. 78001), or are those used for internal stuff and will cause problems?

Like doing this:

function gear_up(controlnum, param)
   ipc.writeLvar("L:LandingGearLeverPos", 0)
end

function gear_down(controlnum, param)
   ipc.writeLvar("L:LandingGearLeverPos", 2)
end

event.control(78001, "gear_up")
event.control(78002, "gear_down")

Is that ok? I mean it seems to work fine, but I don't know if there are any side effects.

Thanks
Jaxx

[Pete Dowson]

6 minutes ago, jaxx said:

is it a problem when I use undocumented FS Control IDs as trigger events for Lua scripts?

I have hardware that I can configure to send any 5 digit decimal >65535 on button presses, dials etc.
But some planes I have only really work well when using L:Vars (e.g. the A2A Comanche with its 3-position gear switch does not really work with the FS control gear up/down events from the 2-postion switch on my hardware.

When I use the standard FS Controls those don't seem to get suppressed when processing in lua.
Is it ok to use undocumented FS control codes for this (e.g. 78001), or are those used for internal stuff and will cause problems?

I dont think it's a really good idea, though this should work unless you are using some other add-on which happens to use those control numbers. The only ones i know of are the PMDG Boeing aircraft add-ons, which obviously wouldn't apply. But there could be others.

There are two rather more usual ways of doing what you are trying to do:

1.  Have a macro file (.MCRO) with macros for those operations. A macro can do the same L:var writes you are using Lua for. See the section "Macros to change Lvars! on about page 42-3 in the FSUIPC Advanced User's guide. That's probably the most sensible way. Then just assign to the macros.

2.  Use the offsets provided for Users, 66C0-66FF.  Use them to signal the action you want and detect it in the Lua plug-in using event.offset or event.offsetmask. Assign to Offset Byte Set or Togglebits to trigger the action.

Method 2 would be the most similar to what you are doing, with a similar Lua plug-in and different assignments, but method 1 is by far the simpler one and involves no loading of any special plug-ins.

Pete

 

[jaxx]

39 minutes ago, Pete Dowson said:

I dont think it's a really good idea, though this should work unless you are using some other add-on which happens to use those control numbers. The only ones i know of are the PMDG Boeing aircraft add-ons, which obviously wouldn't apply. But there could be others.

There are two rather more usual ways of doing what you are trying to do:

1.  Have a macro file (.MCRO) with macros for those operations. A macro can do the same L:var writes you are using Lua for. See the section "Macros to change Lvars! on about page 42-3 in the FSUIPC Advanced User's guide. That's probably the most sensible way. Then just assign to the macros.

2.  Use the offsets provided for Users, 66C0-66FF.  Use them to signal the action you want and detect it in the Lua plug-in using event.offset or event.offsetmask. Assign to Offset Byte Set or Togglebits to trigger the action.

Method 2 would be the most similar to what you are doing, with a similar Lua plug-in and different assignments, but method 1 is by far the simpler one and involves no loading of any special plug-ins.

Pete

 

Thanks for your answer, but I'm not sure how to do this with the restrictions of the configuration drivers of the hardware (from VRinsight) I use.

For 1: How would I link it to the buttons of the device, it will only let me set a 5-digit decimal greater than 65535 plus a single value that is send as FS Control to FSUIPC. (Only other options would be normal keyboard shortcuts and there I see a greater risk of some key-bind conflicts with the flightsim or anything else).
For 2: Basically the same problem as with 1, as far as I understand the offsets are not the same as FS controls, and even if they were the range you provided would be less than 65535 in decimal and the VRInsight software would not accept that value.

EDIT:
Do you mean intercepting the default Offset codes the device sends to FSUIPC when there is no custom config? The software sends the control codes through offset 3110 (not only the custom ones I made, it also uses it this by default for some actions and for some actions it uses "native" offsets.

When I now listen to those offsets manually, like with event.offset, will it suppress the default action for this?

[Pete Dowson]

2 hours ago, jaxx said:

Thanks for your answer, but I'm not sure how to do this with the restrictions of the configuration drivers of the hardware (from VRinsight) I use.

For 1: How would I link it to the buttons of the device, it will only let me set a 5-digit decimal greater than 65535 plus a single value that is send as FS Control to FSUIPC.

Oh, so you can't actually assign them in FSUIPC? It seems a very odd capability, to be able to send only "a 5-digit decimal greater than 65535 plus a single value that is send as FS Control to FSUIPC". I obviously didn't fully comprehend this. And why only greater than 65535, when all of the specially-added fSUIPC controls have numbers in the few thoudads (1000 upwards)?

2 hours ago, jaxx said:

Only other options would be normal keyboard shortcuts and there I see a greater risk of some key-bind conflicts with the flightsim or anything else

Keystrokes are first intercepted by FSUIPC, only sent on if they aren't assigned there.

2 hours ago, jaxx said:

Do you mean intercepting the default Offset codes the device sends to FSUIPC when there is no custom config?

Sorry, I don't know ehat this means in this context. Do you mean it addresses specific FS offsets to control things though FSUIPC?

2 hours ago, jaxx said:

When I now listen to those offsets manually, like with event.offset, will it suppress the default action for this?

No, because most sch offsets are read-outs in any case, even if they can also be used to control.

Unless you want to try keystrokes after all, you are probably best off sticking to your existing plans. But remember, FSUIPC can assign combination keystrokes, like Control+Shift+X or whatever, so there are lots of combinations probably not interfering with anything else.

Pete

 

[jaxx]

16 hours ago, Pete Dowson said:

Sorry, I don't know ehat this means in this context. Do you mean it addresses specific FS offsets to control things though FSUIPC?

Maybe I should clarify what the device does. It is an VRinsight M-Panel.

From what I can see from the FSUIPC logs it writes offsets (the values from the "FSUIPC5 Offsets Status.pdf" documentation) to FSUIPC when I press a button, dial in a number etc.
But they (the natively supported offsets) are hardcoded and I cannot change them.

In the configuration utility I can choose either a standard keybind (like ALT+X) or a "FSUIPC Control":

All custom IDs/Values set in that way will be written to FSUIPC using the "3110" offset ("Operates a facility to send any ‘controls’ to Flight simulator.").
The GUI also prevents entering any ID below 65535 and the configuration file generated by the GUI is a binary file, so not easy to edit without the GUI.

Sidenote: Even in the default/hardcoded state it does not use dedicated FSUIPC offsets for every action, some are just send via offset "3110", just like the custom changed ones.

PS:
I've also seen the VRinsight specific documentations for lua but I don't know if they are applicable (at least for the M-Panel) as they seem to be based on the deprecated method of directly configuring VRi devices with COM ports etc. in FSUIPC. The drivers (at least for the M-Panel) work out of the box with FSUIPC for many years now.

Jaxx

[Pete Dowson]

6 hours ago, jaxx said:

I've also seen the VRinsight specific documentations for lua but I don't know if they are applicable (at least for the M-Panel) as they seem to be based on the deprecated method of directly configuring VRi devices with COM ports etc. in FSUIPC. The drivers (at least for the M-Panel) work out of the box with FSUIPC for many years now.

"Many" years? All the VRInsight devices I ever had, "many" yesrs ago, were not USB HID devices, but serial port "COM" devices, and the default 'driver' was "SerialFP2".  So, I'm confused. If the methods I implemented in FSUIPC to support them are now "deprecated", why have VRI users requestedsuch  support in FSUIPC5, for P3D4?

I thought only the more recent VRInsight devices had moved away from this method. If not, and now all their devices, old and new, are well supported by a new system, I would be delighted to be able to remove this support. Can you confirm this please?

When VRI changed tack and went, as I thouht, to standard USB methods, I never got any more information or anything from them.

Everything you've told me about the driver you are using is news to me. Help would be appreciated.

Pete

[jaxx]

No, it is still using SerialFP, but something has changed since I first used it years ago.
I remember it needed some manual tinkering with the COM port configurations and it was not easy to set everything up (I can't really remember what I had to do exactly to get it running). But soon after that when I used a newer software version it worked out of the box without needing any manual configuration. I also don't have to do this VRi-device configuration from the FSUIPC advanced users guide, it just works. That's why I thought those were for that old manual configuration (of course I can't speak for other device models).

[Pete Dowson]

Hmm. Interesting. I no longer have any VRi devices, else I'd take a look. but thanks for explaining.

Pete