John Dowson

203 is the elevatiuon of the aircraft, and the ground elevation was 194. This is normal. However, what changed was that the ground elevation received at timestamp 952687 changes the ground elevation to 0, hence the issue - as I previously showed: So the ground elevation of the aircraft IS changing, as received via simconnect. So something somewhere is changing this... I can change FSUIPC to ignore the difference between ground and aircraft altitude, so it doesn't change the state or the OnGrnd flag. I will provide you with a new version to test this when I have time....

The OnGnd flag is used as received, except when the AI aircraft state is sleeping or waiting for engine start (states 1 and 0). When an aircraft is in one of these states, FSUIPC will look at the difference between the ground altitude and the aircraft altitude, and if this is < 100 it will set/change the OnGnd flag to 1 (internally, regardless of the value received), and if >=100 it will set the OnGnd flag to 0 and change the state (internally) to show the aircraft as Enroute. This is why it is shown as airborne. I am not sure why FSUIPC does this - maybe the OnGnd flag (plus other data fields which are also changed) cannot (or could not) be trusted for such aircraft - I am not sure. I can remove this feature, or maybe add an ini parameter that can enable/disable this functionality. But the real issue is why is the Ground altitude changing to 0 for these aircraft when they are sleeping?

Ok, thanks - I was going to ask if you use any traffic add-ons. I have seen no issues when using standard MSFS AI traffic. I am not familiar with FS Traffic though... There is certainly an issue somewhere....but lot 10 'Shamrock' (Id 3894) (and others) maybe in the STATE_ENROUTE_AS_FILED state, so are Enroute. If you look at the log entries, e.g. See the number in brackets after the state string - this is the state number, where 1 is STATE_SLEEP and 12 is STATE_ENROUTE_AS_FILED. So it looks like there is certainly something wrong somewhere ...for that aircraft, the state seems to change here: For some reason, the ground altitude of the AI aircraft is changing from 194 to 0, which seems to be the problem. When an AI aircraft' altitude is more than 100 above the ground altitude, then FSUIPC will automatically change the state (internally) to Enroute if it is currently in STATE_SLEEP or STATE_WAIT_FOR_ENGINE_START. So this issue seems to be due to the ground height being received (or misinterpreted). Of course, this may also be an FSUIPC issue - I will check your log further and look into this more over the weekend, when time permits, and/or next week. John

But doesn't it also have a component installed in the MSFS community folder, or even update some official files? And if it is only a separate application, it uses other APIs as well as SimConnect. For example, there was a known bug in the NavData API (used by GSX) that could cause the sim to crash, although I believe it is fixed now (haven't followed this though). There are also many reports of MSFS CTDs when using GSX, although this doesn't necessarily mean that GSX is at fault. But its certainly worth trying a few flights without GSX to see if the CTDs continue or not. Cheers, John

Yes, WideFS is a separate program/license, and is composed of two parts - WideServer and WideClient. The registration is for WideServer, which is built into FSUIPC since FSUIPC4 - before that it was a separate executable. This is why you need to register it with the FSUIPC installer. Note that you can also now run FSUIPC7 on a client machine, which is another solution for running clients/controllers in a client PC, and no additional license for WideFS is needed, However, this is not the same as running WideClient on the client PC, so may not be suitable for all use cases. See the appendix in the Advanced User guide if interested in running FSUIPC7 in a client PC. Note that you cannot run both WideClient and FSUIPC on the same machine, although both can be installed if you want to try and switch between the two. John

Yes Ok, that's good. Do you see the same issue in the FSUIPC TCAS tables then (or in TrafficLook)?

No - there are still no functions to export the wxr radar image as far as I am aware. so this is still not possible. John

WideClient isn't connecting to WideServer/FSUIPC. You need to sort this out before anything else. Please see the WideFS documentation on connection issues (check your Workgroup name!), as well as other forum posts. Do you see '...wth WideServer waiting for clients' in the titlebar of FSX? If so, WideServer is running but WideClient is not connecting - you need to correct this before anything else. All firewalls - client, server and routers? Your FSUIPC4.log file shows that this was attached while FSUIPC was still running - please ALWAYS exit FSX/FSUIPC before attaching files. And also please attach your WideServer.log file the next time.

Ok, that sound sensible. But I don't think there is anything I can do about this issue anyway. It has been around since 2010 at least, and seems to be an issue with RC4 and so needs to be fixed in RC4. If there was a possible fic in this for FSUPC, I would have thought that Pete would have done this a long time ago. Pete was also an RC4 user, and I have no experience with RC4 and so cannot really help much with this issue. I am certainly not going to go through a 400Mb log file to try and understand what RC4 is doing to look into this...! John

What changed to give this message? Did you re-install FSUIPC or P3D, or anything else? Try uninstalling FSUIPC, either by double-clicking the uninstallFSUIPC6.exe file or via the windows app management panel, and then re-install FSUIPC into the same folder and try again. If you get any issues, show me your InstallFSUIPC6.log file as well as your add-on.xml file - the location of which can be found in your installation log (it is usually under Documents\Prepar3D v5 Add-ons\FSUIPC6). John

If MSFS crashes, you need to look at the Asobo forums. FSUIPC7 is a separate application and it cannot cause MSFS to crash, and the WASM is sandboxed - if that crashes, it should not affect MSFS. Your WASM log shows no issues - except that it didn't exit cleanly (as MSFS had crashed), and your FSUIPC7.log shows no issues. I think your issue may be with GSX - I have heard a lot of reports of CTDs with GSC, e,g, see https://forums.flightsimulator.com/t/gsx-ctd/537743/7/, Have you tried without GSX? Other than that, as I can't see how this can be anything to do with FSUIPC. Not really. This just means that you may not be able to distinguish an lvar by name, using FSUIPCs lvar facilities, as it will be truncated to 55 characters.

The log file is again useless as it is a continuation log, has excessive logging and is not logging what is needed (Axis Controls). I do not even know which axis you are talking about - your ini file shows that you only have reversing set on your Throttle. Is this the axis you are trying to reverse? Please do the following: - activate logging for Axis Controls. - move the axis you are having issues with through its full range. - go into FSUIPC's calibration and change the reverse setting - move the axis you are having issues with through its full range again, in the same direction as before. Then show me the log file. Do the in/Out values change/reverse when you change Rev setting? i.e. if you move your axis in one direction without the Rev option checked and the In/Out values are positive, then if you check Rev and move the axis in the same direction, the values should now be negative - is that not the case? Which aircraft are you using for this?You should update all your profiles to use substrings to catch all variants, e.g. change: to Also , if this is with the FSLabs A320, can you also try a different aircraft to see if it is specific to the FS Labs, Some aircraft to not play well with FSUIPC calibration - if this is the case, you need to remove the calibration in FSUIPC and scale the axis to reverse, as I mentioned in my earlier post. John

The log file you attached is a continuation log - please only provide full log files, i.e. do not start a new log. You also have logging for IPC Reads and Writes activated for some reason, and no logging for Events or Buttons & Switches. And I cannot see when this change of view is occurring - only you. So try again, but only with the suggested logging activated, and keep the logging console window open. Then look to see what is logged when the unwanted view switch occurs. This may then tell you where this is coming from, if its from an FSUIPC assignment. Do you have anything assigned to witch to the external view? If you attach your FSUIPC4.ini file I can check. John

You can try using FSUIPC's logging - set logging for Events and Button & Keys and take a look at the FSUIPC7.log file when this switch occurs and see if you can see the event that does this - if it comes from FSUIPC you should also see the assignment as well.

If the axis goes through calibration (do the In/Out numbers change?) then I can't see how reversing the axis doesn't work - please show me/attach your FSUIPC7.ini and DSUIPC7.log files. If the axis doesn't go through FSUIPC calibration, you need to use an axis scaling factor of *-1 - see the Advance User guide (page 42).

Does your FSUIPC7 key still validate? If so, you are entering it incorrectly or you are using a different name and/or address for your WideFS key. If that is the case, check the appropriate box and enter those details. Otherwise, let me know your WideFS7 order number and I will check your key here.

By the way, where is your TCAS ID coming from (in Options->Miscellaneous)? It should be set to Flight (the default), but you could try Tail to see if that improves things. I am not sure where that example program is getting the callsign information from... Just looking at traffic with TrafficLook and I see no issues with the flight number in the 'To' field: Note for the logging, start with a custom value of x10000 and look for the following strings in the log: This will show you the data that FSUIPC is receiving regarding the identification of the AI aircraft and its to/from fields.

I don't think this can be anything to do with FSUIPC, as this will just be supplying/holding the string "Easy", and it will be up to the software to interpret this. That looks rather strange but I do not know the software you are using - could this be at fault? Could you try the TrafficLook program instead - do you see the same? FSUIPC just stores the information received, so if there i no callsign then none has been provided. I do not know of any issues. You can log AI traffic by using a Log->Custom value of x10000, (Logs AI data), x40000 (Logs additional AI data) or x50000 (logs both). I will take a look here later to check the callsigns and flight number / to field - this does look like data is being misinterpreted but I am not sure if this is in FSUIPC or in the program you are using... John

To freeze altitude and position, you can use the standard FS controls: 66833 FREEZE_ALTITUDE_TOGGLE 66834 FREEZE_ALTITUDE_SET 67216 POSITION_FREEZE_USER You can also use offset 0x3402 to both read the current freeze mode and set it for both freeze position and freeze altitude. Fuel freeze is more complicated - there is no such thing so you would have to implement this yourself. You would need a lua script that monitored the fuel tank level offsets and reset the value each time it decreased. Try and write this yourself, and I can help if you have difficulties. You just need to some offset events (event.offset) that are called each time a fuel tank level offset is changed. On the first call (when script started/initialised) would read the current value of the offset and save this as the current level to be maintained, and then on each subsequent call you would use that value to set the offset. Maybe better to just read the initial values and then have a timer event to set those values every half a second or so while the script is running. You could even have the script automatically running/active when position freeze is active.

WASM stands for Web Assembly Module, and is the architecture used by many MSFS add-ons. The FSUIPC WASM module provides the functionality to access lvars, hvars and presets, which are needed to control many add-on aircraft and even some functions in Asobo aircraft. Please see the Advanced User manual - there is a section on the FSUIPC WASM Module starting on page 47. John

See the above. This keeps getting reported - you should check for similar topics before posting. I do not support vamsys. Check FSUIPC is running and connected and you can check your FSUIPC7.log for errors.

WideFS is WideServer + WideClient. WideServer runs on the FS PC and is built into FSUIPC4 (and later versions - previous to FSUIPC4 it ran as a separate application). WideClient runs on the client PC.

T There are two ways - either via a cable or using WideFS. From the FSUIPC4 User guide (GPSout section): John

The trial license is available from the first post in this topic. It is valid until the 1st October (i.e. it will expire on the 2nd), and I will replace it with a new license, valid until 1st November, on the 3rd or 4th of October. John

Your files show that the GUIDs of your Razer Tartarus V2 and WINWING URSA MINOR CIVIL FLIGHT STICK have changed, causing issues. Can you please do the following: 1. Run Regedit (the Windows Registry Editor application) and take a back-up of your registry (File->Export...) 2. Disconnect/unplug your stick and Tartarus 3. Save the attached regedit script to your computer and run it (i.e. double-click it in Windows Explorer): removeDevices.reg 4. Reboot your PC and re-connect your devices. Once that is done. run FSUIPC7 and then exit (no need to run MSFS), and re-attach those 3 files again and I will check them again and see if your joyletters need updating. John