Artem Crum

I'm doing all this com-port (and HID, and FSX too) staff for the first time in my life, so I just don't know if there any nuances until face them myself. I'm doing things and learning them at the same time now. And there are many discoveries on each step. But sometimes it meens that I have to do a step back to make the same thing a better and the right way. Vriread and direct com-port read is the case. :-) Thank you for explanation and your patience!

I have already done the optimized Lua parser for VRi MCP Combo "language". It works fine without any visible delays on buttons and rotaries operations. All LINDA's comunication with MCP Combo is based on this parser and tested in all possible conditions. But I thought that event.vridrv does some serious pre-parsing of raw COM-port coming data from MCP Combo. That was my question about, And in fact I've just replaced the event.vriread with event.com and the same parser works fine without any modifications in it's code. It seems that event.com(dev, 8, 3, 0, 'vriHandler') does pretty much the same job as event.vriread(dev, 'vriHandler'). The only difference I see for the moment is that event.com sends an empty datastrings from time to time... :-) Or am I missing something?

Pete, Another theoretical question. Currently I'm using the event.vriread to handle VRi MCP Combo events and it works fine. But there is little (non-critical) problem with it. If VRi device was not switched on before the FSX/FSUIPC was started, then vriread event doesn't work. But even with not working vriread, I can successfully send comands to the MCP Combo using com.write call (no matter when it was switched on). 1. Is there any way to ask FSUIPC to reinitilize vriread library on a runtime? ..or.. 2. Can I replace event.vriread with event.com without big performance loss? This is more interesting for me, because then I will not need to do any changes to fsuipc4.log to make VRI devices working.

Works fine, as usual. Thanks!

Great! Will test them and report. Meanwhile, LINDA release candidate is in public testing now. If you are interested, here is the link: http://forum.avsim.net/topic/337777-public-testing-started/

Thank you. I'll remind you.

Because this is too much additional actions for user to do. I'm making now something like the FSUIPC console, but with additional controls like filters, searchers and some other LVars related stuff. And it would be logical if logging options were possible to set from this advanced console's control panel. Actually I need only two control to be available -- switching IPC writes and Events logging on/off. Without that I have to open FSUIPC window > switch to Logging tab > set option > close window... instead of just pressing one button on console's control panel. And then the same operation in back direction when I want FSUIPC to stop flooding me with data I don't need anymore. This all is about usability and convenience for future developers and myself too.

I'm still working on LINDA project and now making instruments for future developers of Lua modules for it. Sure, you do know this problem with LVars hunting and searching for FSX controls used by addon aircrafts. I want to simplify this process as much as possible. And ability to switch FSUIPC logging options (at least IPC writes) on/off without need to open FSUIPC window would be very useful.

Pete, can I change FSUIPC logging facility options from inside the Lua script or by API calls? I need any ability to change all those parameters: Logging level (LogExtras), IPC reads/writes and others.. on fly, without reloading FSX.

Yes, ok. Just wanted to let you know the latest findings..

More news from the same field... MS/TT panels DO WORK inside Lua, but there is a little nuance. As we've found out their report consits of two pages (two sequential data blocks). But com.GetHidButtons doesn't differentiate them and always interprete them the same way as if it was a report about button states. For example, when button 13 is pressed com.GetHidButtons returns this 32bit string (converted from Integer to Binary): press : 00000000000000000001000000000000 / 13 And that is ok. But then if device sends some data about axises` values changes, com.GetHidButtons returns new Integer genereted from the other UsagePage which does nothing with current buttons states. And now it returns another integer value, while the real buttons are still in the same state as before. And Lua script then believes that there were a real changes in button states which is not true. The TT Panel (which doesn't have any physical axis controls) from time to time sends the all-zeroes report about axises values. And this cause com.GetHidButtons returns Zero too, which is then parsed by Lua script as a state with NO BUTTONS PRESSED.. but at the same time several buttons or switches on panel could be press or switched on. Script interpretes that Zero as a command to release all buttons, which is wrong. On the MS Panel everything is worse, because on the second/axises page it sends not the all-zeroes report, but the real state of the real axises, which is then beeing interpreted in Lua as a "random" button presses/releases. So.. the conclusion is: com.GetHidButtons should differentiate and don't mess two report pages with each other. But I don't know how it's could be done. I know only that on these particular devices Report 1 is about axises and Report 2 is about bouttons states. ====== I'm not sure about all that, but it looks like that very much... But still needs confirmation.

For some strange reason beta-tester just reported, that both of his TT and MS panels have started to work inside Lua without any changes done in Lua code... One more weirdness. I've asked him to reboot and re-plug devices into other USB-ports and they are keep working anyway. :oops:

Yes, certainly. There is no rush with it. These panels are not so popular, and LINDA is still in closed beta-testing yet.

First of all, I think you are much better programmer than me, and your code is better. I cannot call what am I doing the "proper programming". Scripting, yes. Interface building, yes. But the low-level system programming is not my best side. And the second reason, that I don't want make users to run one more background application, where the FSUIPC/Lua can do it all.

There are two different devices MS panel and TT panel with different sets of controls, but both have the same hardware inside. I was thinking the same way but it is wrong. Second report starts with 4 bits for Hat and 30 bits from 5 to.. whatever for buttons... Don't understand the logic behind it. And yes, it's totally weird :-)

No-no, I'm talking about Delphi application. GUI for LINDA. This GUI works with HID devices using it's own library. But the main core of LINDA is the Lua script inside FSUIPC/FSX environment and uses your implementation of com/HID library.

Mine current solution is not a solution but a quite dumb workaround. I didn't understand the logic of all this double UsagePages and so on. All I did is just simple debuging of reports comming from the device where I've found that there are two different reports coming one by one, and that the "buttons-report" is coming second on THIS PARTICULAR device. Then I make handler to skip the first report for this device and only parse the second one by individual rules... But DirectInput seem to know The Secret about how to correctly decode such types of devices... :-) BTW I don't have an access to this device too. Only some debug logs from LINDA supplied for me by beta-tester.

Pete, there could be another problem with HID library. We are now doing the compatibility tests with different HID devices, and I've just found a possible problem. I'll try to explain but it will be hard for me... sorry :-) Common joysticks are sending the only one HID report per cycle. One button press generates one portion of data sent to the driver. But there are some non-standard devices that sending two or may be more reports at once. By report I meen that raw data packet from HID device which we need to decode/parse to get buttons and axises states from it. As I can understand that is done for "economy" purposes. Device I'm talking about has 30 buttons, 6 8bit axises, 1 4bit Hat, but it's report length is only 7 bytes which is definitely not enough. That's why the whole device state is transmitted in the two sequential reports. First report brings data about Values (axises) and the next report -- about the Hat and buttons. I've made changes to LINDA's GUI to make it work with these devices, but the Lua part of application seems doesn't work. Can you, please, confirm if FSUIPC/HID Lua library could work with such devices? Attaching two diagnostics reports about this device. HidScanner: Device at "\\?\hid#vid_0417&pid_0130#7&2e740b48&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0417, Product=0130 (Version 1.0) Manufacturer= b padt=0130 (Version 1.0) Product= usb pad Serial Number= b pad=0130 (Version 1.0) Usage Page: 1 Input Report Byte Length: 7 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 2 Number of Input Button Caps: 1 Number of InputValue Caps: 7 Number of InputData Indices: 37 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 Buttons range 1 -> 30 at indices 7 -> 36 Value Thr at index 0, range 0 -> 255, using 8 bits Value Rdr at index 1, range 0 -> 255, using 8 bits Value Y at index 2, range 0 -> 255, using 8 bits Value X at index 3, range 0 -> 255, using 8 bits Value Z at index 4, range 0 -> 255, using 8 bits Value U/RX at index 5, range 0 -> 255, using 8 bits Value POV at index 6, range 0 -> 7, using 4 bits ************************************************************************** Note the Number of Link Collection Nodes: 2 Other similar tool: "usb pad" VID=$0417 PID=$0130 UsagePage=Generic Desktop ($0001) Usage=Joystick ($0004) CollectionType=Application ($01) Button Input Range: UsagePage=Button ($0009) 1..30 Value Input: UsagePage=Simulation ($0002) Usage=Throttle ($00BB) Value Input: UsagePage=Simulation ($0002) Usage=Rudder ($00BA) Value Input: UsagePage=Generic Desktop ($0001) Usage=Hat Switch ($0039) UsagePage=Generic Desktop ($0001) Usage=Pointing Device ($0001) CollectionType=Physical ($00) Value Input: UsagePage=Generic Desktop ($0001) Usage=Y Axis ($0031) Value Input: UsagePage=Generic Desktop ($0001) Usage=X Axis ($0030) Value Input: UsagePage=Generic Desktop ($0001) Usage=Z Axis ($0032) Value Input: UsagePage=Generic Desktop ($0001) Usage=Rotational X Axis ($0033) Note the TWO-levels hierarchy and the second UsagePage. Usually there is ONE-level and ONE UsagePage per device. This is the VRinsight MS/TT panel. And it works fine in FSUIPC Buttons&Switches panel. Also it's normaly detected by Windows as a generic game device with all buttons and axises working.

Pete, you are taking it too serious. I was asking it from perfectionism point of view. I you don't have a quick answer for it, then just leave it. This is many times less important issue than the button delays. I cannot imagine that many of end users will ever face this problem. And even so, restarting FSX is not a big deal for those quite rare cases. If you'll be interested some day you could install and test LINDA yourself to see how it behaves, but for now device unplugging issue is not really important. And thank you for your great and instantaneous support on any question!

Oh, sorry. I thought you know the CH devices logic. Forget about mode switching then... it's something like switching between pure hardware to software emulated modes. Ask Bob Church, if you really interested - he well describe it better. From the HID library's point of view the device mode switching is like fast unpluging one device and pluging in another one on it's place. As for Lua script hang ups... Ok. Script doing several things simultaneously. It handles the event.vriread calls, event.timer and some event.offset's. Timer event polls for updates all available HID devices in one loop. Then if I unplug any of joysticks, all other joysticks stop working too. I think it's the com.readlast call stops working. At the same time all other event handlers continue to work without any problems (vriread, timer and offsets monitoring).

Ok. Just asked... :rolleyes:

Correction.. there are two different events: 1. Pure device unplug 2. Switch device from Programmed to Direct mode in CH Control panel My GUI hangs only on device mode change now. And the lua part doesn't hang - the only HID- part of the script stops working. Other events like vriread countinue to work without a problem.

I'm not sure, what I'm expecting :-) It's just the same problem I have with my GUI app. It hangs up when I unplug any active device. It's not a big deal though.. But after all, lua script should not hang up on device removal (zero values will be good). Also I see that CH Control panel hangs up too until I exit the FSX.

Is there some simple way to get list of current LVars and their values from the external application? Now I'm using the 0x66C1 offset to exchange data between the GUI and Lua parts of application. And I know I can use this "pipe" to ask Lua script for what I want and make it return the requested values back to the GUI part. But may be there is some other more clean and simple way to read Lua vars through the FSUIPC API? I need all this to make some kind of GUI replacement for log lvar.lua script with more features for those who making Lua scripts for addon aircrafts.

I think I'll better try to live with these delays, as they are visible not on every device. It seems to be the less evil, than not supporting 2 additional hats on the popular X52 joystick. Also I can use the GUI part of my app to catch joybutton presses and send them to Lua script.. It will require to keep GUI running, but if it will be the only solution, I can live with it too. One more question about HID lua library. Can you please check what is happening when I'm unpluging the device which is currently opened and polled in Lua. It seems that Lua library doesn't detect device removal and leaves some resources locked, until the whole FSX be restarted.