Artem Crum

Here is a part of debug log from console: 1141584 LUA: LINDA:: 1436953176 -- 1 1141630 LUA: LINDA:: 1436953176 -- 2 1141677 LUA: LINDA:: 1436953176 -- 1 1141724 LUA: LINDA:: 1436953176 -- 1 1141771 LUA: LINDA:: 1436953176 -- 2 1141818 LUA: LINDA:: 1436953176 -- 1 1141864 LUA: LINDA:: 1436953176 -- 1 1141942 LUA: LINDA:: 1436953176 -- 4 1141958 LUA: LINDA:: 1436953176 -- 0 1142005 LUA: LINDA:: 1436953176 -- 1 1142052 LUA: LINDA:: 1436953176 -- 2 1142098 LUA: LINDA:: 1436953176 -- 1 1142145 LUA: LINDA:: 1436953176 -- 1 1142192 LUA: LINDA:: 1436953176 -- 2 1142239 LUA: LINDA:: 1436953176 -- 1 1142286 LUA: LINDA:: 1436953176 -- 1 1142332 LUA: LINDA:: 1436953176 -- 2 1142379 LUA: LINDA:: 1436953176 -- 1 1142426 LUA: LINDA:: 1436953176 -- 1 1142473 LUA: LINDA:: 1436953176 -- 2 1142520 LUA: LINDA:: 1436953176 -- 1 1142566 LUA: LINDA:: 1436953176 -- 1 1142613 LUA: LINDA:: 1436953176 -- 2 1142660 LUA: LINDA:: 1436953176 -- 1 1142707 LUA: LINDA:: 1436953176 -- 1 1142754 LUA: LINDA:: 1436953176 -- 2 1142800 LUA: LINDA:: 1436953176 -- 1 1142847 LUA: LINDA:: 1436953176 -- 1 1142894 LUA: LINDA:: 1436953176 -- 2 1142941 LUA: LINDA:: 1436953176 -- 1 1142988 LUA: LINDA:: 1436953176 -- 1 1143034 LUA: LINDA:: 1436953176 -- 2 1143081 LUA: LINDA:: 1436953176 -- 1 1143175 LUA: LINDA:: 1436953176 -- 4 1143175 LUA: LINDA:: 1436953176 -- 0 1143222 LUA: LINDA:: 1436953176 -- 1 1143268 LUA: LINDA:: 1436953176 -- 2 1143315 LUA: LINDA:: 1436953176 -- 1 1143362 LUA: LINDA:: 1436953176 -- 1 1143409 LUA: LINDA:: 1436953176 -- 2 1143456 LUA: LINDA:: 1436953176 -- 1 1143502 LUA: LINDA:: 1436953176 -- 1 1143549 LUA: LINDA:: 1436953176 -- 2 1143596 LUA: LINDA:: 1436953176 -- 1 1143643 LUA: LINDA:: 1436953176 -- 1 1143690 LUA: LINDA:: 1436953176 -- 2 1143736 LUA: LINDA:: 1436953176 -- 1 1143783 LUA: LINDA:: 1436953176 -- 1 1143830 LUA: LINDA:: 1436953176 -- 2 1143877 LUA: LINDA:: 1436953176 -- 1 1143924 LUA: LINDA:: 1436953176 -- 1 1143970 LUA: LINDA:: 1436953176 -- 2 1144017 LUA: LINDA:: 1436953176 -- 1 1144064 LUA: LINDA:: 1436953176 -- 1 1144111 LUA: LINDA:: 1436953176 -- 2 1144158 LUA: LINDA:: 1436953176 -- 1 1144204 LUA: LINDA:: 1436953176 -- 1 1144251 LUA: LINDA:: 1436953176 -- 2 1144298 LUA: LINDA:: 1436953176 -- 1 1144376 LUA: LINDA:: 1436953176 -- 3 1144392 LUA: LINDA:: 1436953176 -- 0 1436953176 -- is a device handle, and the number after "--" is a discards counter. If I remove jittering by moving all axises to the extreme position, discards drop to 0 at the same moment.

At the moment I cannot imagine how to implement this in my case. If only to automatically generate the separate lua script for each HID-device, run them and make them interface with the main process through the global vars... But I don't think, it will really help. I see the same delays even if I unplug all other HID-devices except the CH Throttle.

Yes, I remember the comments inside hiddemo.lua, but com.readreport(jdev, 0) gives just the same result anyway: n == 0. I've tried it yesterday.

Yes, Pete, I'm missing something here. I'm pure novice in all these HID- things. Ok. If readreport requires the report id as the second parameter, is this the same report id which is required in openhid call as the fourth parameter? Then if I do the readreport call with correct device handle which is recieved from the openhid, then why I'm receiving the len == 0 no matter what report id I set to it? I've tried both: CurrentData, n = com.readreport(jdev) CurrentData, n = com.readreport(jdev, 1) In both cases n == 0 and CurrentData seems empty.

As I'm working with several HID devices at once, I'm initially filling the array like this: jdev[jid], rd[jid], wrf[jid], wr[jid], init[jid] = com.openhid(VID, PID, UID, Report) And then I'm using this array data to make the com.readlast calls in the For Loop. CurrentData, n = com.readlast(jdev, rd) As you can see rd contains the data which was recieved on init stage from openhid call. Actual values in rd table ar 11 for one device and 13 for another. (Is it normal?) If I try to replace rd with 0 or 1 it doesn't work also.

Have it tried by simple replacing readlast with readreport. Doesn't work. Len is always a Zero value. Take your time if your are busy. These delays are not a critical issue at the moment.

Bob, Nice to meet you here (we talked earlier on CH-Hangar). The problem with these delays does happen not only with my CH Throttle, but with Logitech and I believe with any other device with jittering axises. And more the axises device have leads to more jittering and the bigger "traffic jam" (bigger delays). By the way. Is it normal that CH Throttle axises are so unstable? Values constantly jumping +/-1 points from the current position. Eclipse axises are rock-solid in comparision.

Yes, sure. This could be the way out... I stick with HID- approach because the GUI part of my application implements it's own internal "driver" for HID devices. And it was the easiest way to sync list of devices in GUI and Lua parts of it. In GUI I make device ennumeration and differentiate them by VendorID/ProductID (exactly as you do). If I change the lua part to work with common event.button approach then I need the way how to convert VID/PID to exact device number for event.button call. The other problem could happen that i. e. Saitek X52 has 3 hats. One normal/common Hat Switch and two others with custom usage codes but with the same logic of bit encoding (they are Values, not the Buttons in HIDs notation). Will the event.button work with them correctly? And how I can know what values will event.button send to the handler function for these additional hats? I need some kind of universal approach which will work with any types of joysticks and the HID library suits this goal the best.

Ok. Here are the results... 1. Using com.read instead of com.readlast makes things much worse on all devices 2. Discards counter shows values about 1-2 on problem device and 0 on other devices 3. CH Throttle axises are constantly jittering and it seems that this is the main problem - they are constantly send new values and this lead to the delay. As I said when all axises are full forward or full backward delay is reduced and this is because in extreme positions there is no jitter on axises values. Also this problem was confirmed on other system with completely different set of devices. Older and now I'm suppose jittering Logitech Extreme device was working with the same delays. So the conclusion is that while devices sending a lot of updates about axises values something inside FSUIPC HID library chokes and this cause button reaction delay. Could it be changed somehow? Does or can the FSUIPC axis filtering affect this (remove jitter I mean)?

Oh! So many ideas to play with :-) I'll try to see the discards number and try the "read" instead of "readlast" because I don't need axises values at all (except for hats, but they behave like buttons). Will report the results. Thanks.

Hello again, Pete Other topic and other question now.. I'm using FSUIPC/Lua to read data from HID devices (those com.openhid and other commands). My script is based on your example provided with Lua library documentation (hiddemo.lua). Everything works fine, but sometimes I get some kind of strange behavior. My system consist of 3 CH devices - Eclipse yoke, Rudder pedals and Pro Throttle quadrant. All of them are working in programmed mode (not direct... if you know what it is in CH logic, but I don't think it really matter). And from time to time (quite often) I see a noticeable delay about half of second between button press and HID library catch of it. This happens only on Pro Throttle (no ever delay happened on Eclipse). Then, if I move throttle axises somewhere from their current position delay disappears (but not always). And then delay could appear again. Eclipse keeps working without delays at the same time. This delay is could be seen ONLY IN LUA. If I open CH Control panel I see that button presses detected as usual without any delay. It seems that this delay depends on quadrant axises positions. If I put all of them full forward or full backward, the delay is lower. If all axises are in different positions about the middle, the delay is bigger. Sometime there no visible delay at all, but most of the time there is a feeling of some lag. And from time to time the lag becomes too much. Do you have any ideas, why this could happen?

Works fine on my system! Thank you, Pete

I'm on it...

Ok, I'll run the beta test this week and wait for your update before public release. Sure I can do my tests with updeted FSUIPC as soon as you give me a download link (LINDA is using FSX/FSUIPC4). Or you can test it yourself if it will be more convinient to you. The simple example of code using LFS lib: lfs = assert(require('lfs')) local dir_obj = lfs.dir ('.\\modules\\') local dir = dir_obj () while dir ~= nil do ipc.log(dir) dir = dir_obj () end This code should read the FSX/modules folder and show all it's entries in FSUIPC log.

Pete, When can we now expect the update with DLL paths and LFS? I'm going to release a freeware project next days which is using FSUIPC/Lua at it's backend and need the LFS library to work. I can include it in the release package, but it will be much better if it will be compiled in FSUIPC dll. Here is the project intro: http://forum.avsim.net/topic/336857-welcome-to-linda/ It a device assigning tool to replace the "Buttons and Switches" settings in FSUIPC. It also implements it's own VRinsight MCP Combo dirver written in lua with much more capabilities than original SerialFP software.

Great news once again. Happy holidays!

Ok, will be glad to hear any news about DLLs placement. Anyhow, you are doing a marvelous job as always! :-D

Yes! It magically work now! Great thanks, Pete! Little question is left... Library is loaded but it requires lua5.1.dll to be placed inside the root FSX folder. When I put this dll in FSX/modules or FSX/modules/lua it doesn't work. Is it ok? Or where should I place this library?

Oh! Just saw your last reply in Lua capabilities... waiting for new version to be uploaded.

Thank you for your fast reply, Pete. LuaFileSystem - is a common library often distributed with Lua. I'm not the author of it and didn't compile it myself. But it's quite small and simple - 17kb of source code with just few functions implemented. Info could be found here: http://keplerproject.../luafilesystem/ Sources are here: http://luaforge.net/...ystem-1.4.2.zip I have read "Lua capabilities" thread but actually not understanding your solution recomendations (I'm not a C-programmer). May be you can include LuaFileSystem in your FSUIPC-internal Lua implementation in some future versions?

Hello, Pete I need to get list of directories from Lua script (script is running inside FSX/FSUIPC) and have a problem with it. I can use os.execute or os.popen calls to run DIR command and then parse it's output. It works but they both open black-DOS-window (cmd.exe actually) to run this DIR command. This window appears for a moment an dissappears again. Not a big problem but distracting and I want to get rid of this. Other way to do this is to load some Lua library containing native dirctory listing functions. I was trying "LuaFileSystem" library but it crashes the FSX when loaded. Is there any other way to get dir. listing? Or may by to load "LuaFileSystem" without a crash?