Jump to content
The simFlight Network Forums

Luke Kolin

Members
  • Posts

    351
  • Joined

  • Last visited

Everything posted by Luke Kolin

  1. Things look good here. I'm enclosing the log, INI, and Lua script in case you need them. (FWIW right when the script starts it takes focus away and then refuses to give it back for 3-5s, but that's been there for a while.) Cheers! cs7x7ap.lua FSUIPC6.ini FSUIPC6.log
  2. Yes, that's actually why I needed to restart - when debugging to fix silly mistakes like that one. 😄 I'm enclosing two logs. The first is with a hang, the second without. The only difference is again the com.close() - for some reason that is making things unhappy. I don't have a problem keeping it commented out, but the old programmer in me still feels a little unclean at not cleaning things up when I'm done. (My wife says that doesn't stop me around the house.) Cheers! FSUIPC6.log FSUIPC6_prev.log
  3. 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
  4. 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
  5. 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!
  6. Normally. I turned off all of the debug messaging because it was changing the timings too much. Cheers!
  7. 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!
  8. 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
  9. 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
  10. 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
  11. 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
  12. It definitely made a difference. I got a warning, but the process terminated. Cheers! FSUIPC6.log
  13. Sorry, brain fart - I removed event.cancel(). I'll remove event.terminate as well. Cheers
  14. No change. Here's the log and INI. Cheers FSUIPC6.ini FSUIPC6.log
  15. 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
  16. Interestingly, I checked my INI and the parameter was already there... set to 2. I'll try again with the event.terimate removed. Cheers
  17. 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
  18. 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!
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.