John Dowson

👍

No, I wouldn't say that... The weather data is requested and received via SimConnect. As I said, I am not that familiar with the weather interface and I will look into this further when time permits and get back to you, but this may take a while...

Please find FSUIPC6 v6.2.2a which contains the same fix. John FSUIPC6.dll

Ah, yes, sorry - I can certainly do that...

No it can't - but you don't need to. You can just correct for this in the offset event handling function, and set the lvar to a value of 1 when the value if the simvar is > 1370, otherwise set it to 0 (as the calc,. code does). You do not implement any logic in the myOffsets.txt file. This only allows you to add simvars to FSUIPC offsets so they you can read/write/update them. The logic in how you use the values is encapsulated in the lua script that uses the offsets. So instead of this: ipc.execCalcCode("20 13 (>A:BUS LOOKUP INDEX,number) (A:CIRCUIT CONNECTION ON:20, number) ! (>L:CBL_BAT_RELAY)") in your offset event handling function for the simvar A:CIRCUIT CONNECTION ON:20, you would use: ipc.execCalcCode("20 13 (>A:BUS LOOKUP INDEX,number) " .. value .. " ! (>L:CBL_BAT_RELAY)") where value will be the value if the A:CIRCUIT CONNECTION ON:20 sinvar that is passed into the handling function. John

I can't see how I can fix this in FSUIPC - how would I detect such aircraft in the first place?

Well, its not coming from there either...can you show me / attach your FSUIPC4.ini file. Do you have controls disabled in FSUIPC4? If not, also check any assignments there. This assignment/control isn't coming from FSUIPC

I have done this now if you would like to try the latest beta (InstallFSUIPC7.4.18beta.zip). You can remove that new ini parameter with this version. John

Great! Yes, I am sure that would be helpful for others. Regards, John

No problem... Also, if assigned to a momentary button (as opposed to a switch or sticky-button) and you only want 2 controls to be sent, you can assign one control to the press and the other to the release.

You can do this by either: - using a macro (see documentation on macro usage) - overloading your assignments via editing the ini- this is described in many other support requests, e.g. That is for FSUIPC6 but the procedure is the same for FSUIPC7. - defining a preset to send both controls and assign to the preset For issues and questions on MSFS/FSUIPC7, please use the FSUIPC7 support sub-forum - I will move your post. John

I have just done some tests as well, and setting the same cloud layer at 3000ft to 6000ft I see this for cirrus: 750719 46208 Monitor IPC:CE80 (U16) = 975 750719 46208 Monitor IPC:CE82 (U16) = 914 750719 46208 Monitor IPC:CE87 (U8) = 1 which changes to the following when switching to cumulus: 822422 46208 Monitor IPC:CE80 (U16) = 2133 822437 46208 Monitor IPC:CE87 (U8) = 9 so I am seeing a bigger difference for the cirrus which is way off... Checking in P3Dv5 - the upper altitude for cumulus is even more out: 73906 44992 Monitor IPC:CE80 (U16) = 3469 73906 44992 Monitor IPC:CE82 (U16) = 914 73906 44992 Monitor IPC:CE87 (U8) = 9 and Cirrus give the same as P3Dv6: 212172 44992 Monitor IPC:CE80 (U16) = 975 212172 44992 Monitor IPC:CE87 (U8) = 1 Not sure why the upper altitude mismatches the P3D value at the moment... Update: a 3000 foot thick layer of cirrus is either not possible in reality or very highly unlikely. The cirrus layers are usually very thin. I’m not sure what P3D actually does when you tried to set such values. My logging suggests that this is being reduced by P3D, but you seem to be seeing the correct value, which is strange... Also I think the upper altitude is calculated, not provided, so may not be a 100% match with the set value. But I need to go through the code and look at what is being received to generate these values. As I am not familiar with this section of the code, this will take me quite a while. I will look into this further when time permits and get back to you, but this may take a while... John

Yes - only log files from the current and previous sessions are available. No need to post it unless FSUIPC actually crashed. As I said, it was most likely an exception due to the MSFS crash, and then FSUIPC7 would exit gracefully. Just look at your log file to confirm this, and only post it crashed, i.e. no closing log statements, like the following: John

It doesn't/can't.... Can you show me/attach the A320 Mode.lua script - it may come from this assignment:

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