Jump to content
The simFlight Network Forums

Luke Kolin

  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Atlanta, GA

Recent Profile Visitors

2,617 profile views

Luke Kolin's Achievements


Newbie (1/14)

  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare
  • Dedicated Rare
  • Week One Done Rare

Recent Badges



  1. I tried searching but I'm obviously using the wrong terms. Is there an offset in FSUIPC7 that can tell me if it is connected to the simulator? Cheers!
  2. Sorry this dragged a bit. Thank you Pete for the information - I'm matching via the driver rather than Vsync but I suspect it's having the same effect on the P3D (it's in the driver rather than the sim, set to infinity here too). Feedback from the affected user has moved into broader issues which makes me question the sim configuration on his end, but I have a question - is there an enumeration of what offsets are being used by third parties? I'm using the range from 66C0 to 66FF for reading LVARs, but I assume if I'm not the only one playing in that space it may cause issues. I'd prefer to have a 64-byte block of offsets but I'm unsure as to whether I can reserve such a block or at least make it user configurable so that it can be adjusted around a bit based on what other add-ons the user is using. Is there a listing of what's reserved in the 7300, 7840 and 8600 blocks, are there more these days and can I get 64 bytes for my software? Cheers!
  3. Thanks for that - the good news is that I can replicate it myself so I'll give you what I know. I'm using P3D v4.5 and FSUIPC 6.0.14 on Windows 10. 1) Thanks for the information on LVAR reading. I do read LVARs extensively, but it greatly depends on the detected equipment. Aircraft such as the CS757/767 or the PMDG MD-11 extensively use LVARs for autopilot state so I read them regularly, but I've noticed this issue with the PMDG 737 and 777 which uses offsets (thanks!) and so my LVAR reading is only every five minutes or so to refresh some different state/capabilities variables. (Oddly enough that call rarely blocks for long.) 2) Just so I am clear, if I'm setting the frame rate limiter in the driver (via NV Inspector?) I assume that does the same thing as the internal P3D limiter or vsync? I'm never getting below 15 or so fps, but with the limiter never above 45. Cheers!
  4. One challenge I have with my software is that FSUIPC_Process calls will take a variable amount of time, with some significant delays at times. I've instrumented the SendMessageTimeoutA call on my end and while it usually averages around 16-20ms to return, there are significant outliers where it can take up to 2000ms or more. Even on my own machine I'm seeing data like this: FSUIPC!!SendMessage 71,377x Avg:16.47ms Min/Max=0.03/681.98ms ... which is a max of almost 700ms. This is of course less than ideal because in previous versions the UI would block. I've moved on and made those calls in their own thread, but the FSUIPC interface itself on my end is single threaded. John/Pete, when I make that SendMessage call to either FSUIPC or the simulator process, if the frame rate remains decent (double-digits, say) what would cause such delays? I assume that FSUIPC is listening for these Windows messages on a per-frame basis, so it should get handled in under 100ms? My users all swear up and down that their frame rates are excellent (and I'd rather not instrument that any more than I have) but are there any cases that you know of where FSUIPC will take an excessive amount of time to respond? Cheers!
  5. Ray, I can't speak to the correctness of that sequence but have you considered just writing to the door LVARs? That seems to have fewer state issues and certainly a lot less work and timings to go wrong. Cheers!
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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!
  11. Normally. I turned off all of the debug messaging because it was changing the timings too much. Cheers!
  12. 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!
  13. 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
  14. 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
  • 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.