-
Posts
351 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by Luke Kolin
-
-
43 minutes ago, Ray Proudfoot said:
Without the exclusion for ASCA I was getting freezes on just about every flight. Once I added ASCA as an exclusion I had no freezes on five flights. What conclusion would you draw from that?
I may be confused here, but from your AVSIM thread wasn't this being triggered on a flight save, with the PMDG aircraft?
Cheers
-
Yes, that was my error. I'm debating whether I want to roll that back or if an FSUIPC release will be soon.
-
Sorry for the delay - the changes appear to be working correctly. Thank you!
Cheers
-
Thanks! I'll give this a whirl.
Cheers!
-
Thanks John! Looking forward to testing this.
Cheers
-
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
-
Sorry to bump an old thread, but has anything changed in this area?
I am trying to detect MSFS, and it feels like 0x264 is a bitmap, but I am unsure what the bits mean.Cheers!
-
4 hours ago, MIKE MCCARTHY said:
dont understand how to find that
Search the Windows start menu, or select Run and then "eventvwr"
-
1 hour ago, John Dowson said:
Your P3D version is also out-of-date:
Prepar3D.exe version = 5.3.17.28160
Can you update to the latest version:
Prepar3D.exe version = 5.3.18.28350Where does one download that version? It doesn't appear to be available on prepar3d.com.
Cheers
Luke
-
I would also enumerate what add-ons you are using. Any REX products?
Cheers!
-
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!
-
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
-
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 okaySimConnect appears horribly broken. Not surprising that neither GSX nor FSUIPC are working.
Cheers
-
This has been a problem with PMDG for ages. They freeze the sim for a while when the sim saves the flight. I would report it as a bug, just to see how quickly they reject it 🙂
Cheers!
-
Taking MobiFlight out of the equation, is the offset returning the correct value? From your earlier thread I feel like you have a MobiFlight problem, not FSUIPC.
Cheers!
-
Is this the same as here- https://www.avsim.com/forums/topic/613556-fsuipc-offsett-auto-pilot-captain-course-reading/
Does offset 0x0C4E return the correct value?
Cheers!
-
16 hours ago, twilfert said:
thanks for the hint. Would you know where to find these SDK values for heading and altitude setting?
Look in the header file that is provided with the SDK; it should list the control number. You will also want to look at the MOUSE_FLAG constants to see what value to pass to the control.
Cheers!
-
You can't just use 1 and 0, the SDK has constants for simulating left and right clicks.
Cheers!
-
John, you may want to change the links to be HTTPS, if they aren't already. That seems to be the issue.
Cheers!
-
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!
-
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!
-
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!
-
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!
-
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!
Is Current Weight of Aircraft available?
in FSUIPC Support Pete Dowson Modules
Posted
30C0 and 30C8 should give you what you need.
Cheers