Jump to content
The simFlight Network Forums

Luke Kolin

Members
  • Posts

    351
  • Joined

  • Last visited

Posts posted by Luke Kolin

  1. 3 hours ago, John Dowson said:

    As a long time user, you should know where to look to find this information - from the FSUIPC7 Offset Status document:

    Pause indicator: Shows 3 pause states with flags 0x1 (pause set), 0x2 (pause on/off) and 0x4 (esc pause)

    That's actually the reason for my question - what is the difference between "Pause Set" and "Pause On"? I have users reporting that the sim is not paused when pause set is toggled.

    Cheers

    Luke

  2. 8 hours ago, John Dowson said:

    Looking at the latest header file, it is only the AircraftModel that has changed size, which is held in offset 6C8D, so only this offset and those after it

    It's been way too long since I did this regularly, but if the data element increased in size from 8 to 16 bits, wouldn't the offset stay the same and just the following three increment by one? I was reading 16-bits from 6C8D before and not getting a good answer. If AircraftModel is the only element in the SimConnect structure that changed, why did its offset change?

    Cheers!

  3. PMDG has apparently changed their SimConnect API a little (AircraftModel is now 16-bit, not 8-bit) and this has cased some cascading issues downstream. I'm getting zeroes for all offsets above 6c64 (that's as far upstream as I have checked) and I am certainly not getting the Aircraft model.

    I am enclosing the latest header file. When you get back John, can you check if FSUIPC 7.3.12 still works with the newest PMDG 737 for MSFS? I have 3.0.54 and am happy to validate test builds.

    Cheers

     

    pmdg_ng3_sdk.h

  4. Quote

      6187906 SimConnect_Open succeeded: waiting to check version okay
      6193016 Opened separate AI Traffic client okay
      6218656 **** No SimConnect events or states being received! Re-connecting now ... ****
      6218766 SimConnect_Open succeeded: waiting to check version okay
      6223906 Opened separate AI Traffic client okay
      6249563 **** No SimConnect events or states being received! Re-connecting now ... ****
      6249688 SimConnect_Open succeeded: waiting to check version okay
      6254797 Opened separate AI Traffic client okay
      6280406 **** No SimConnect events or states being received! Re-connecting now ... ****
      6280531 SimConnect_Open succeeded: waiting to check version okay
      6285656 Opened separate AI Traffic client okay
      6311235 **** No SimConnect events or states being received! Re-connecting now ... ****
      6311344 SimConnect_Open succeeded: waiting to check version okay
      6316453 Opened separate AI Traffic client okay
      6346985 **** No SimConnect events or states being received! Re-connecting now ... ****
      6347094 SimConnect_Open succeeded: waiting to check version okay
      6352203 Opened separate AI Traffic client okay

    SimConnect appears horribly broken. Not surprising that neither GSX nor FSUIPC are working.

    Cheers

  5. 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! 

  6. On 8/20/2021 at 10:15 AM, Pete Dowson said:

    1.  You have made a request via FSUIPC which involves FSUIPC asking FS for something and waiting for the result.  Typical would be reading L:Vars, as an example.

    2.  The high (unlimited?) frame rates being allowed in the simulator are precluding sufficient time for other interfacing applications. This would typically be occasional, not constant. Best always to advise users to limit frame rates (either directly by the FR limiter, or via VSync), to something just below the average attained.

    Without knowing more about exactly which requests are timing out I can't really help further. You should also state the versions of both FSUIPC and FS/P3D.

    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!

     

  7. 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!

×
×
  • 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.