Luke Kolin

So, another interesting data point. I have a key binding set in FSUIPC to restart my LUA scripts which is helpful when debugging and updating them. It just runs LUA <script> which starts it if it has terminated, or kills the existing script if running. Now, it seems to hang P3D... perhaps I'm not cleaning up properly? here's the log. Cheers! FSUIPC6.log

The most recent DLL in this thread looks good, both for the equipment code (0x6CID) and tail code (0x6C3C). I suppose I can check the door status as well to validate the padding on the other blocks but I think that will be good too. The earlier DLL did _not_ work. FWIW I got some differing messages regarding LUA shutdown handlers like we discussed earlier. I don't believe it's at all related and doesn't seem to harm anything, but I am enclosing in case it triggers a eureka moment on your end. Cheers FSUIPC6.log FSUIPC6_prev.log

If Jason doesn't get to it today, I'll take a peek after I go to get shot. What exactly is new? I have a document dated November 2016 that has all this. I'm pretty certain it all works correctly; I do a sanity check on the flight number IIRC. Cheers!

Normally. I turned off all of the debug messaging because it was changing the timings too much. Cheers!

I made some changes and I think I got them all (param, poll, and terminate) but I'm still getting the termination warning. I'm not going to sweat it since it seems to clean up OK. Thanks for your help in understanding the Lua system better. Cheers!

That makes sense. I'll try that. Cheers

Sorry, I'm not worried about the latency - I understand why that happens. This is the part that is interesting to me: 112578 LUA.1: Event canceled 112578 LUA.1: ...ke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua:101 112578 LUA.1: CS757/767 Button Handler shutdown 112578 LUA.1: ...ke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua:103 112578 LUA.1: Waiting for an event in "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua" 113750 Lua threads being terminated: 113750 1 = "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua" 113922 LUA: "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua": killed 113922 === Closing global Lua thread By line 103, I've already called event.cancel() so why is it waiting for an event right afterwards? Cheers

So I turned on a lot of debugging (which seemed to cause some latency and interesting race conditions) and I've attached the log. Note at the end, even after event.cancel it looks like LUA is still waiting on an event, and perhaps the cancel() isn't working? Attaching log and LUA so you can see the line numbers. Cheers FSUIPC6.log cs7x7ap.lua

Looks clean now! Interestingly the com.close appears to take a while... I've enclosed the log and the shutdown function (I've changed the logic a bit as we've been working and can't remember if you've seen it). function HandleShutdown() if (hidHandle ~= 0) then ipc.log("Shutting down USB device hnd=" .. hidHandle) com.close(hidHandle) ipc.log("USB Device disconnected") hidHandle = 0 event.cancel("HID_Poll") ipc.log("Event canceled") end ipc.log("CS757/767 Button Handler shutdown") end FSUIPC6.log

I tried the last plugin with TimeForLuaClosing=5, and got the following log. Do you want me to try the earlier ones as well? Cheers! FSUIPC6.log

OK. Thanks!

It definitely made a difference. I got a warning, but the process terminated. Cheers! FSUIPC6.log

Sorry, brain fart - I removed event.cancel(). I'll remove event.terminate as well. Cheers

No change. Here's the log and INI. Cheers FSUIPC6.ini FSUIPC6.log

Doesn't appear to make a difference. I've attached the full log/ini files, and here is the relevant function: function HandleShutdown() if (hidHandle ~= 0) then ipc.log("Shutting down USB device hnd=" .. hidHandle) com.close(hidHandle) ipc.log("USB Device disconnected") hidHandle = 0 -- event.cancel("HID_Poll") -- ipc.log("Event canceled") end ipc.log("CS757/767 Button Handler shutdown") end You can say for sure, but my uninformed guess is that the com.close is throwing an error that isn't getting caught or logged. I'll try again with the parameter set to 5. Cheers FSUIPC6.log FSUIPC6.ini

Interestingly, I checked my INI and the parameter was already there... set to 2. I'll try again with the event.terimate removed. Cheers

So I changed the shutdown function to be this: function HandleShutdown() if (hidHandle ~= 0) then ipc.log("Shutting down USB device hnd=" .. hidHandle) com.close(hidHandle) ipc.log("USB Device disconnected") hidHandle = 0 event.cancel("HID_Poll") ipc.log("Event canceled") end ipc.log("CS757/767 Button Handler shutdown") end So I'll close, log, then cancel. I didn't even get the log message: 72484 -------------------- Starting everything now ---------------------- 72563 ASN active function link set 72563 Ready for ActiveSky WX radar with additional data 72563 LUA.1: USB Device Connected, hnd=1 72563 LUA.1: Poll loop started 72563 LUA.1: Registered CS757/767 Button Handler 73641 Advanced Weather Interface Enabled 103406 Sim stopped: average frame rate for last 39 secs = 34.8 fps 103406 Max AI traffic was 5 aircraft 103406 ------------------------------------------------------------------- 108984 === Closing session: waiting for DLLStop to be called ... 119719 === DLLStop called ... 119719 === Closing external processes we started ... 120719 === About to kill any Lua plug-ins still running ... 120719 LUA.1: Shutting down USB device hnd=1 120875 Lua threads being terminated: 120875 1 = "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua" 121172 **** DevCom read/write threads still running - will exit anyway but could cause issues... 121313 LUA: "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua": killed 121766 **** DevCom read/write threads still running - will exit anyway but could cause issues... ... so I think you're correct about com.close() taking too long. Is there any possibility to increase the cleanup limit? 5ms seems awfully short. Cheers

That's the complete log. I'll try commenting out the event.cancel and add some additional logging details to see if it makes a difference, and report back. Cheers!

I've implemented some LUA scripts to handle extended button reads, and I've noticed that P3D isn't shutting down properly at times. Looking at my logs, it appears that my Lua shutdown function is terminating abnormally. I call event.cancel() and then com.close() but it looks like one is failing and then the script is getting terminated by FSUIPC. The changelog for 6.1 suggests that there are some changes in com handling. Am I doing things incorrectly? Is there a conflict with the new button handling post-6.0.12? Cheers! Luke FSUIPC6.log cs7x7ap.lua

I have the Honeycomb Bravo throttle quadrant, and I use the software for configuring the lights and some of the buttons (specifically, the PMDG autopilot integration). However, there's nothing stopping you from using it as a regular joystick with FSUIPC. Cheers! Luke

There are four areas I recognize I am ignorant in and leave it to the experts - thread synchronization, dates/times, encryption and character encoding. 😄 From what little I know, UTF-8 and UTF-16 should be a superset of ASCII, so regular ASCII characters should be encoded the same way in all three. It should a simple modification to change the signature for that function and any comparisons it does, then see what happens. I'd be slightly surprised if that's all it took to make it work, but even more surprised if that broke the ASCII case. YMMV, of course. Cheers Luke

If I can load it into VS2019, I'd be willing to look at it. My point is that your challenge is upstream, when you load the strings out of the BGL. I suspect (being optimistic) it might be enough to either load the strings as wchar_t* instead of char* (or cast) and then have your encoding function that you shared here operate on *wchar_t instead of *char. The challenge is going to be how you read from the BGLs, but I suspect it's all bytes and the cast should be OK. If you want a low-effort experiment, change the function signature of your encoding function to take wchar_t* instead of char*, cast the pointers before you call it and see if it works. Cheers Luke

Stop mucking about with char*. Seriously.... these aren't ASCII strings and probably everything is a wchar_t or LPWSTR/LPWCSTR (which is a pointer to a wchar_t). What is the character encoding in the BGLs? Given how P3D has moved to Unicode I suspect that they are UTF-8 but you'll need to ensure that you are reading them as Unicode strings and then doing your translations on wchar_t variables, not chars. Cheers Luke

Pete doesn't realize it yet, but he's going to go insane - or in a few years, John will. 😄 These are WCHAR or wchar_t typedefs, not byte arrays or char pointers. I'd work with them as such if possible. Cheers Luke

To paraphrase Dorothy, "Toto, I don't think we're in ASCII any more." You're likely to see that 1:1 byte/character mapping for most ASCII characters, but once you get out of that world all bets are off. I'd check the SDK to see what character encoding they are using in the BGLs - I suspect it is UTF-8 but you really need to be sure. If it is, you can probably just do the standard copy of bytes but I expect there are a number of Visual C constructs that treat them as Unicode strings rather than ASCII byte arrays. From there, instead of a BOM I would just add the encoding to the XML header. A parser should probably ignore the BOM and focus on the declaration; that's why it's there. I'll also echo pallelil - you really don't want to be rolling your own XML (or JSON or other structured text format). Cheers! Luke