pointy56

Many thanks John, I'll pass details to the other (P3D) user who was having problems.

Great, thank you 🙂

Sorry, I should have been clearer - would you be able to put the same 'ground altitude' fix into FSUIPC6?

OK, that seems to be working well - thank you. I've attached the latest log (it's over 200MB unzipped) if you want to take a look. Also, you will see from the attached TrafficLook screenshot that my favourite 3 'strangers' appeared once more, and the data for them looks a bit weird. I'm not worried about them as they didn't interfere with the flight, but I will pursue it with Just Flight as they are creating them (actually a 4th one, 310, appeared later). I may be pushing my luck, but might a similar fix be possible for FSUIPC6? Another PF3 user (with P3D) is seeing the same sort of problem. Best regards, Martin FSUIPC7-20241007.zip

Three similar aircraft, always with incomplete flight details, apparently flying from EGSS to LEVC, but in completely different directions - they've appeared each time I start MSFS. 🤔 I'll give the latest beta a try shortly, but all looked good last time - and the three 'strange ones' are well outside my TCAS air range so don't cause a problem. Martin

Here's a log from the previous version (with To & From the same), but it seems to be doing what's required - I didn't hear any spurious ATC calls. There are a couple of strange AI aircraft all from EGSS to LEVC which you can see in the attached TrafficLook screenshot (1440, 1441 & 1442). I think I need to ask Just Flight about those. I'll try to make another test flight tomorrow with the updated version (7.4.18b). Thanks, Martin FSUIPC7-20241006.zip

I think that you may be outputting the 'From' in both fields as all those log entries appear like this: 1638938 UPDATEAI: Ref=2982 [x0BA6],State="STATE_LANDING" [14],OnGnd=0,Alt=368,Gnd=0,GS=135,AS=135,VS=-245,Flags=03FF,From='LIBR',To='LIBR', Park=0/0/0 1638938 UPDATEAI: Ref=4091 [x0FFB],State="STATE_GO_AROUND" [16],OnGnd=0,Alt=13,Gnd=0,GS=172,AS=172,VS=-3,Flags=03FF,From='EGPH',To='EGPH', Park=0/0/0 1638938 UPDATEAI: Ref=4194 [x1062],State="STATE_ENROUTE_AS_FILED" [12],OnGnd=0,Alt=30000,Gnd=350,GS=320,AS=320,VS=0,Flags=03FF,From='EIDW',To='EIDW', Park=0/0/0 1638938 UPDATEAI: Ref=4450 [x1162],State="STATE_TAXI_TO_PARKING" [17],OnGnd=1,Alt=203,Gnd=194,GS=0,AS=0,VS=0,Flags=03FF,From='GCRR',To='GCRR', Park=104/10/10 Aside from that it's looking good; I restarted FSUIPC with MSFS running, so I'd like to make another test flight with a clean start before providing new logs. Thanks, Martin

Thank you John, will do. Martin

Looking at the Simvars list in the SDK, Ground Altitude is not settable, so I'm not sure what's changing it. With my current scenery set-up EGKK (where I was flying from) has an elevation of 203 feet, so 203/204 for aircraft altitude would seem to be correct - they're on the ground.

Thanks John. Are you saying that FSUIPC uses a different mechanism rather than the OnGnd flag for Ground/Airborne filtering? Martin

OK, I've just made a short flight with FSUIPC logging set to 0x50000 and noticed something strange: Look at the attached screenshot from TrafficLook and slot 10 'Shamrock' (Id 3894) which is shown as Enroute, but with no From or To. If you now look in the FSUIPC log, every AI Update for Id 3894 shows 'STATE_SLEEP' and OnGnd=1 - so why is it in the airborne list? The same is true for slot 11 and probably also slots 12 thru 21; they all have an altitude of 203/204, suggesting to me that like slot 10 they are actually on the ground. This might explain the problem that I have been seeing. Am I missing something here, or is this a bug? Regards, Martin FSUIPC7-20241004.zip

Thanks for the confirmation. And 'Yes' I am seeing the same issue with TrafficLook; here's a screenshot which shows both missing flight numbers, and flight numbers in the 'To' field. I'm using FS Traffic, so I've also logged a support query with Just Flight.

Hi John, I've managed to reproduce the problem with FSUIPC logging enabled, which has given me some very useful information; I am now trying to correlate all the data that I have. Please can you remind me how the timestamp on each FSUIPC log entry works - I seem to recall that it's milliseconds since FSUIPC started, is that correct? Thanks, Martin

Thanks John, I'll give this a go later - my TCAS Id is set to 'Flight', so I'll try running with some logging.

Hi John, I'm hoping that you might be able to cast some light on a problem that I have recently been having with AI traffic data via FSUIPC: A couple of us have noticed that PF3 sometimes spells out the airline name rather than reading it out - so 'Echo Alpha Sierra Yankee' instead of 'Easy'. I'm using MSFS, but the other guy is using P3D, so other than PF3 the common factor seems to be FSUIPC. I made a test flight yesterday where this happened, and I used Paul Henty's example code to capture the AI traffic at the time (screenshot attached). You will see that although some of the flights have complete callsigns, some of them have just the airline name - for PF3 to work properly we need the full callsign. You will also see that others seem to have the flight number in the 'To' field, which seems rather curious. Are you aware of any problems with FSUIPC in this area? Is there any tracing/debugging that I can run that could help identify the cause of this problem? Thanks, Martin

I gave those settings a try and everything seemed to work fine - thank you. I will keep monitoring things - I've attached the log in case you wish to review it. Thanks, Martin FSUIPC7.log

Here are some logs relating to the problem that I have been seeing with hotkeys not working reliably with 7.4.12 - apologies for originally posting this in the wrong forum. I primarily run FSUIPC for PF3, and this uses hotkey support; after upgrading to 7.4.12 (the 9/5/24 version) these were not working after starting MSFS and FSUIPC. I do know that FSUIPC was at least partially working as I was able to retune the COM1 radio from PF3 Web Display; this is a separate application which uses Paul Henty's FSUIPC client. When I reverted to 7.4.11 everything worked fine, as it had being doing previously. In order to try to capture a log with the problem I reinstalled 7.4.12, this time using the 23/5/24 version; when I then started MSFS the hotkeys worked fine, so I thought all was well. However, when I started MSFS today, having made no further changes, the hotkeys were again not working. This time I closed FSUIPC and restarted it manually; normal service was resumed. I'm attaching 3 logs; the one dated 26/05 is with hotkeys working after reinstalling 7.4.12 - the other 2 are from today, a) is with no hotkeys and b) is for the manual restart of FSUIPC. And today, again, I was able to retune the COM1 radio even when the hotkeys weren't working. I should also mention that I use the EXE method of starting FSUIPC, as I have done since the early days of MSFS - it's always worked reliably for me until now. Thanks, Martin FSUIPC7-logs.zip

Hi John, Thank you for clarifying a number of things that are specific to FSUIPC7 - as you say this is necessarily different to previous versions, but I was basing my questions on the documentation. Specifically, both the latest offsets list and the Programmers guide still say: Byte 2 (bits 16-23): Flags from application. Bit 1 (2)= set if Hot Key should be passed through to FS, else it will be trapped. So my understanding was that not setting this bit, and PF3 does not, prevents the keystroke being passed through to the FS - clearly this is not relevant with FSUIPC7. I'm sorry if I missed this specific hotkey handling difference with FSUIPC7 somewhere else in the documentation. But the log entry also made me think that the old action was still the case: 4454609 - no pass through (not checking FSUIPC assignments) I have spent days trying to identify why C/S/Y causes a view change, when I couldn't find the binding. Someone in the MSFS support forum suggested that it was incorrectly taking C/S/Y as plain 'Y' and I've just found that removing that binding (Slew) fixes the problem. So I'll be logging this issue as a bug with Asobo. Thanks again for your patience and explanation of the differences with FSUIPC7. Martin

I am using FSUIPC7 with MSFS to support PF3, and am finding that some hotkeys seem to be being passed through to the FS although they are configured to not do so. The specific key combinations are Ctrl/Shift/N and Ctrl/Shift/Y - I have managed to disable C/S/N in the FS, but cannot 'find' the binding for C/S/Y to disable it (really helpful!). I cannot be sure, but I don't think I was seeing this until fairly recently; over the past few weeks I have updated several times and am now on 7.4.8. The attached log shows a series of C/S/N hotkeys followed by two C/S/Y hotkeys (the second is solely to toggle the effect of the first one in the FS!) - timestamp 4454609 onwards. Is the behaviour that I am seeing expected or a known issue? One other minor thing: The hotkey table near the start of the log doesn't seem to show the 'Shifts' byte correctly; this may be because of the way PF3 loads the entries. (The second attached file shows a dump that I took from the hotkey area after PF3 was loaded, and shows the Shifts byte that has been set for each entry) Thanks, Martin FSUIPC7-log.zip PF3-Hotkeys.txt

Ok, thanks John. Yes, that registry entry was incorrect, although everything else seems to be working as expected! (Most of the 'similar' values in the registry are associated with One Drive, which I don't even use, so seems like another Microsoft special!)

I have just updated to FSUIPC 7.3.24 and noticed in the install log that it placed the documentation in a documents folder for another user. Somehow on my PC I have ended up with 2 user accounts 'Martin' and 'marti' - I can't remember how this happened, but I only log-in and use 'Martin'. From the install log: Updating EXE.XML for Steam install C:\Users\Martin\AppData\Roaming\Microsoft Flight Simulator\EXE.xml has been updated. ... Create folder: C:\Users\marti\Documents\FSUIPC7 Documents directory created: C:\Users\marti\Documents\FSUIPC7 Output folder: C:\Users\marti\Documents\FSUIPC7 I have manually copied the FSUIPC7 folder into my Documents so that I can find the user manuals - interestingly there was an existing FSUIPC7 folder there which contained older versions. I've attached the full install log - I assume this isn't the expected behaviour. InstallFSUIPC7.log

Hi Pete, It seems that from a Windows 10 command line the parameter needs to be enclosed in double quotes to work, e.g. MakeRwys.exe "/>500" , otherwise it creates an empty file for redirected output (called 500 in this case). Regards, Martin