John Dowson

@Tom87 Done.

If/when MSFS crashes, it usually generates faults like this in FSUIPC7 as the simconnect connection is no longer available. In such cases, FSUIPC7 will also exit, as the option 'Exit with FS' is set (and always set if FSUIPC7 is auto-started by MSFS). Check your FSUIPC7.log file, it should show that FSUIPC7 closed down gracefully as MSFS was no longer detected. If this is the case, then you should report the CTD to Asobo, including the crash event log. If/when FSUIPC7 does actually crash, the FSUIPC7.log will be cut short, i.e. no close-down messages logged. However, if this happens it should not affect MSFS as that is in a separate process.

This is usually due to having the document already open somewhere - the installer can't replace the document as its being used. Make sure that the document is closed, and then re-run the installer. If that is not the issue, then please show me your InstallFSUIPC7.log file, if there is one. John

No, sorry, there is no tutorial. And how you configure can also depend on the aircraft. Most MCP/Autopilot functions can be controlled using lvars or hvars (or MobiFlight events), if the standard controls don't work (or aren't available). You can try listing the available lvars/hvars (using the Add-ons->WASM-< List Lvars/Hvars menu entry), and then setting/changing (lvars) or activating (hvars) them, using the menu options under Add-ons->WASM. Once you have found the ones that work, you can assign them to your buttons using either macros, lua or the lvars-to-offsets functionality. I can't really help with such a general request, but if you let me know what aircraft you are using (and which mod, if applicable), and which button & function you would like to assign, I can maybe help you with that, which would then give you an idea of how to set-up the remaining buttons. John

Hi Mario, could you try the attached version please, v7.2.2b: FSUIPC7.exe Thanks, John

Could you please attach your FSUIPC7.log file created after the CTD. Also check the event log to see if there was an MSFS crash reported before the FSUIPC one. Thanks, John

Hi Mario, I'm not sure I fully understand this. Could you explain an actual use case, i.e. which lvar and which aircraft? This may be due to the way client data areas function - if the data doesn't change (i.e. writing the same data, lvar +value) a second time won't be registered. There was a similar issue recently related to executing calculator code - if you executed the same code twice, the second would be ignored. I got around this by sending a dummy calc code request after each one requested, just to reset the CDA. I probably need to do something similar for the various other CDAs that FSUIPC uses, i.e. to set lvars and activate hvars. I will look into this next week, but a concrete example would help. Thanks, John

Tried what - using DontLogThese? That will work - just add DontLogThese=68068 to your [General] section or [Profile.xxx] section.

See the following:

I don't think so. FSUIPC is just logging the events it receives from MSFS (it is not sending those). You can stopped those messages from being logged by using the DontLogThese ini parameter (which can go in the [General] or your [Profile.xxxx] section) to prevent those messages being logged, but that will prevent all of those messages being logged, even (perhaps) when you are interested in seeing them. You can always turn off Event logging, or close the console window! Sorry I can't be of more help for this. John

If you check the offset status spreadsheet provided with FSUIPC7, you will find that this simvar has been added to offset 0x0C46 (read-only). I am now working on merging the spreadsheet and the offset document to provide a single source of offset information for FSUIPC7, but this will take a while. For now, you should use the spreadsheet I provide, and consult the document for the offset description (where available). Note if using the A320, offset 0x0260 also contains the current autobrake setting (0=Off, 1=Lo, 2=Med, 3=Max) John

The first execution of the script started at timestamp 1872344. The second execution started at 1872469, which 125ms later. As the first execution of the script was still running when you ran it again, the thread with for first execution was terminated. You can only ever have a script running once - if you try to run it again and it is already running, the current running instance will terminated. Also seems a strange script.... You don't need the ipc.exit() as the script will exit anyway, and you don't need the function call (or delays). The following script would do the same: ipc.runlua("DC6_MP_CONTROL")ipc.sleep(50)ipc.runlua("DC6_RPM_CONTROL")

I just took a look at this and I get the full +/- 16k range in the calibration tab, as expected. How have you assigned your ailerons? Using 'Direct to FSUIPC Calibration' assigned to Ailerons? Which aircraft are you using? Do you have any honeycomb software running? If so, please disable and try without. And do you have controllers disabled in FSX?

If you can populate free user offsets with the weather data from your 3rd party source, you can then spoof the reading of the original FSUIPC offsets to the offsets where the data is actually located. You can do this using the offset spoofing utility at offset 0024. You will first need to get the weather data into the FSUIPC (free user) offsets, and see how they map to the existing FSUIPC weather offsets. Once thats done, I can help you set-up the spoofing of the original offsets, i.e. when anything tries to read the original offset, it will read the data from the new offset that you added to hold this data.

What do you mean by this? You already gave the offsets you are using (for the ETA/ETE), 0x60E8 and 0x60E4. You can try logging the offset data for the offsets you are interested in, using FSUIPC's offset logging facility. They are currently documented as "Probably Working", i.e. they should hold the correct info but this has not been verified. The sim variables for these are documented so they should be available (but only for reading).

But does it actually work with MSFS? I doubt it. There are no weather facilities currently provided by SimConnect, and as FSUIPC interfaces to MSFS via SimConnect, it is not possible to write (or read) weather data via FSUIPC for MSFS. I think you need to find a mod compatible with MSFS to do this. Looking at FSrealWX, I can find anywhere that says it supports MSFS. There are various weather mods available for MSFS, both free and payware. For example, you could try this free METAR based one: https://unrealweather.blogspot.com/2020/09/unreal-weather-live-metar-released.html

The Rotor Brake controls will be shown in the event log. For the continuously logging events, you can use the DontLogThese ini parameter to prevent these being logged (see Advanced User Guide for details). They are just noise.

I can't really help you with this as I don't have the DC6 or access to the documentation. If you are having issues deriving the parameter to be used, you could create a new topic with a relevant title that would attract other DC6 users, or ask on the PMDG forums.

Sorry, what does this mean? Did you uninstall any redistributables from 2015, 2017 & 2019 (any of those installed) and then install the combined redistributable from the link provided? If you did that, what is the error that you get when you try to start FSUIPC7 (by double-clicking the FSUIPC7.exe in windows Explorer)?

They are Rotor Brake controls. PMDG use this mechanism a lot. In FSUIPC, assign to the Rotor Brake control in the drop-down menu, and give the appropriate number for the parameter, so for: DC6_AP_ALT_HOLD_OFF#43601 (>K:ROTOR_BRAKE) you would use parameter 43601. Check the PMDG SDK documentation for a list of available Rotor Brake control codes. I can't see those events in the MF spreadsheet - are you sure they are Mobiflight events?

No, its a timestamp (milliseconds since started). Just use the DontLogThese ini parameter, as suggested. I haven't noticed that in the logs, but maybe I have them ignored already. I'll check tomorrow,

Of course, no problem with this. Thought I'd take a look as this looked quite interesting. I'll go through your comments in detail next week and take a look at the code areas you mentioned. I'll let you know how I get one. Regards, John

The ETE offset is in seconds, so it should be relatively straightforward to get the HH (divide by 60*60) and the MM (divide by 60 and subtract HH*60). The ETA offset will be elapsed seconds since January 1st 1970 (midnight) in local time. You should be able to calculate the timestamp from that, but maybe easier to just get the local time HH:MM and then add on the ETE.

All (or most) aircraft in MSFS continually emit certain events, which are different for different aircraft. The more complex the aircraft, the more of these type of events they seem to emit. These events are just noise - you can ignore them by using the DontLogThese ini parameter. This can go in your [General] section, or, better, in your [Profile.xxx] sections, where you can specify the events to ignore for just the aircraft in that profile. John

Yes - I will update to a case insensitive match. The easiest way to find this folder is by checking your FSUIPC7.log file, near the beginning the FS UNC path is logged, and the Community folder is under this - here is mine: 313 10248 FS UNC path = "D:\MSFS2020\" and my Community folder is D:\MSFS2020\Community That is where the FSUIPC_WASM.log file is located, as well as the user FSUIPC_WASM.ini. This is explained in the Advanced User Guide. Thanks for the detailed description, which I'm sure will help others. John