John Dowson

I am surprised that works... The problem is that the ipc.execCalcCode call will return almost immediately, but it will take a while for the updated lvar value to be received back by FSUIPC, so when you read the lvar value you will be reading its old value. You should add a delay before reading the lvar value (i.e. ipc.sleep(30)). But it would be better to just either: 1. Add the A:CIRCUIT ON:89 simvar directly to an FSUIPC offset using the myOffsets.txt file (see Advanced User guide), or 2. Add the lvar L:WING_DEICE to an FSUIPC offset using the [LvarOffsets] ini file section. The offset would then be automatically updated when a new/updated value was received. Calculator code is in RPN format (see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm), so try: ipc.execCalcCode("(A:CIRCUIT ON:89, Bool) (L:var_GlareshieldAnnunciatorTest, Bool) or (>L:WING_DEICE)") You could also maybe treat them as numbers and add them: ipc.execCalcCode("(A:CIRCUIT ON:89, Number) (L:var_GlareshieldAnnunciatorTest, Number) + (>L:WING_DEICE)")

Your press assignments are set to repeat - you shouldn't need this as the assignments are just updating an offset (no point in repeating this). So you can maybe change those assignments to a press rather than repeat, but this won't make much of a difference. Other than that, FSUIPC is behaving as expected. As I said in my previous comment, the offsets you are writing to are NOT controlled by FSUIPC, but are reserved for use by other systems. You need to look into what is using those offsets as it is that that should be sending the appropriate controls. If its the Sim-Avionics update that provoked this issue, I would have thought that the issue lies there somewhere. But you seem to be using offsets reserved for both Mark Hastings B777 Systems Simulator (5300-53FF) and Enrico's Project Magenta (5400-5FFF). How did you know which offsets to use - which software/document gave you this information? Maybe check that to see if its changed...

Strange how? Those are all a very long way away (not that that should matter)...have you set a very high or unlimited TCAS air range? Some of he VS values look very strange as well... I think I will make this setting the default, so you don't need to set that ini parameter. I will also update the latest beta release (see Announcements sub-forum) to this version in the next few days. John

Yes, MSFS has always given a lot of issues. By some reports, this can also be related to on-line activity. A few thinks to try: - switch to AI traffic if using live traffic, and maybe try some flights without traffic - turn off live weather if using that to see if that makes a difference - check for add-on conflicts - i.e. try the Simstaller tool from Parallel42 (free) - check the Asobo CTD reference for further tips: https://forums.flightsimulator.com/t/unofficial-reference-guide-to-ctd-solutions/442117 John

Yes, corrected in the attached version (version number unchanged at 7.4.18b). John FSUIPC7.exe

Can you try the attached version - please add AIAboveGroundLimit=1000 to the [General] section of your FSUIPC7.ini file. I need to go out now so haven't had time to test this version - please let me know how it goes and also attach your log file. I am also now logging the to/from ICAO codes, so should be able to see when/if that changes. John FSUIPC7.exe

I am not familiar with the New Weather Interface so not sure I can help at the moment, although I can look into this and get back to you (and maybe ask Pete about this). Are you writing to C800-CBFF to get the requested weather in CC00-CFFF? If so, can you show me how you are doing this.

No files attached,,,!

Done.

First, your log shows a couple of errors: This type of error is usually caused by a corrupt P3D client - please re-install this component and see if they go away. Ok, then can you please supply/ayyach a log file showing this issue. Activate logging for Buttons & Switches as well as Events. You can also monitor the offsets you are using. However, note that the offsets you are using are in an area with this description: i.e. they are reserved for these systems and are handled by them, not FSUIPC. Maybe check the offsets you are using are still valid after the update. John

That shows an exception in FSUIPC - did FSUIPC7 crash? Can you please show me/attach your FSUIPC7.log file from when it crashed. If MSFS CTD'ed, are there any windows events for this? If FSUIPC7 CTDs, this should not affect MSFS in any way, as it is a separate app. If MSFS CTDs, this can cause exceptions in FSUIPC7 (which will be reported in the windows events), but FSUIPC7 should handle this gracefully, and usually exits as it detects that MSFS is no longer running. Your log file would show if this is what is happening. John

Why not? Please show me a log file for this. This usually happens if you have the DetectToConnectDelayAuto ini parameter set too high, and are not waiting long enough for it to connect., If assignments to presets or lvars/hvars/calc. code stop working mid flight, this is usually a sign that the FSUIPC WASM module has crashed, You can prevent this by setting a WASM ini parameter to stop repeated scanning for new lvars - see MSFS have not made it easy for 3rd party developers. Everyone has different add-ons, different PC specs, different controllers, etc. FSUIPC should work pretty much out-of-the-box for most users. However, some initial configuration maybe needed If you have many add-ons and it takes MSFS more than a minute or two to arrive to the main menu state. But even then, FSUIPC will auto-tune itself - but you need to exit MSFS and restart once MSFS has arrived at the main menu AND FSUIPC has connected. Once toy have done the initial set-up/tuning, you shouldn't need to do this again. Auti-tuning will still monitor the connection, and if multiple connection attempts are detected, it will flag auto-tuning to be ran the next time FSUIPC is auto-started by MSFS. For this to work correctly, you need to make sure that you are still in the MSFS main menu when FSUIPC7 connects.

Yes - there weren'r that many updates between these versions, and nothing that could cause a CTD. The log file you attached ends after 80 seconds - so did P3D crash on start-up? Of so, that is usually a sign of a corrupt weather file. Try setting "NoWeatherAtAll=Yes" in the [General] section of the FSUIPC6.INI file to disable weather - if that fixes it, then you have a corrupt weather file which needs to be removed (see that FAQ entry I referenced). If thats not it, check the Windows Event viewer to see where the crash occurred, and maybe check the P3D forums for similar CTD reports.

Ok, although i don't know why you previously said 'The Workgroups are the same'! Once that is corrected, try again. If you still have issues, try setting the ServerName (or ServerIPAddr) and the Protocol - see the WideFS User guide, and also the WideFS Technical guide for troubleshooting network issues. Ok, but you need to sort this out - I can;t help with this... John

Please see the section Auto-tuning of initial start-up ini parameters in the Advanced User guide, and/or the following FAQ entry: No idea, Everyone suffers from CTDs at some point. It is up to you to determine the cause... John

Your log file shows that you didn't load an aircraft and get to the ready-to-fly state, and toy exited after 205 seconds... Apart from the first entry, the numbers are not in the correct position. Maybe the case also matters...try: John

Would be helpful if you attached your FSUIPC4.ini file, but it looks like its coming from an assignment (index 32, to button 8 on device 3) to a lua file, the one with index number 7.

Please respond to that questions - and all my questions. I cannot help if you do not respond. But with which axis? I can see entries for Ruder, Ailerons, Elevator and throttle. Lets try this again... First, choose one axis and let me know which. Then perform the same test, i.e. with logging for Axis Controls activated, just load your aircraft, and move the assigned axis through its full range and back again. Then exit FSUIPC/FSX, and save/copy/show me the FSUIPC4.log and FSUIPC4.ini files. Next, perform the second test. Do exactly the same as before, but change the reverse setting on the axis you are testing. Then exit anf show me/attach those two files again. i.e. two distinct tests, each with two files, trying one axis (and let ma know which!). This is FAR easier of you just look at the values logged in real-time...for example, this is what I see moving my throttle through its full range: i.e. the Param value foes from 0 to 16384 and back again. If I now go into calibration and reverse the axis: it now goes from 16384 to 0 and then back again. So the parameter values have been reversed. (Note the actual range depends on which axis control, but whatever the range, it should be reversed when the Rev checkbox is selected). John

Are you using the correct Active Sky dll (as_connect.dll) for the version you are using? Please check that first. Otherwise, weather CTDs are normally caused by a corrupt *.wx fille, so please check this - see If you still get crashes, please show me your FSUIPC6.log fo;e, as well as any crash reports for this in the Windows Event Viewer. Again, check that you are using the latest version of AS6 and have the correct AS dll installed (if using). I do not provide old and unsupported versions - I only move foreword. I doubt very much this has anything to do with the change from 6.2.0 to 6.2.1, but I have attached the 6.2.0 dll below for you to confirm. John FSUIPC6.dll

No, I cannot. What has this to do with FSUIPC? If your issue comes from an upgrade of the Sim-Avionics 777 flight model, why don't you raise this issue with them rather than here? I know nothing about the Sim-Avionics 777. If you have an issue with FSUIPC I can help, but I do not support 3rd party products/add-ons from other developers... If you have assignments in FSUIPC which aren't working, regardless of which aircraft you are using, then I need to see (attach not paste) your FSUIPC6.ini file (which contains your assignments), and also your FSUIPC6.log file, with appropriate logging activated (i.e. Buttons & Switches and Events (non-axis controls)) that shows what is happening. It could be something simple, such as an aircraft name not currently caught by a profile, or possibly a device GUID change that has made your current assignments obsolete. But I can't really comment without seeing your files. John

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