John Dowson

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

You can use the same hvar file with all aircraft that have a GN530/430 - just copy the file and rename it to a substring match of the aircraft (name/title) for which you wish to use it. You can also add any a/c specific hvars to each aircraft hvar file. Once you have the hvar files, it is really quite easy to set up a macro file to use these, and then assign your button/switch/key to the hvar macro. You should just go ahead and try it. I can assist if you have issues.

@Blake Buhlig Thought I would take a look at this. I have copied the Controls List for MSFS Build 999.txt file and mobiflight-msfs2020_eventids.cip.txt file to the root folder, but am now getting the following error when trying to run: What is the custom_ctrls_info.tsv.txt file and how can I generate it? Are there any other files I need? Is there a config file I can update with the file locations - or any general usage instructions? Thanks, John

What happens if you try to start FSUIPC7 manually (by double clicking the FSIOPC7.exe file)? Your problem is most likely with the VC++ redistributables. Please see the provided README.txt:

There are only minor differences (bug fixes + new ini parameters) between 5.155 and 5.157, which are: So why doesn't the software work with 5.157? You should contact the developers and ask them to make it compatible. There should be no reason for it not to work unless they are explicitly checking the version number.

First, for support, please post in the main support forum. I have moved your post. Why do you want to have 5.155? You should really be using the latest version, 5.157. Why can't you use that version? Note that 5.155 is no longer supported - I only support the latest version of each product. John

👍