John Dowson

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

👍

That is not going to happen I'm afraid. All lvar values are just treeted as 8-byte/64-bit values. It is up to the user to know the actual type and treat accordingly. No. The Java Native Interface (JNI), which is what is used to call narive C/C++ code from java. See https://www3.ntu.edu.sg/home/ehchua/programming/java/javanativeinterface.html. There may be other frameworks built on top of JNI that are easy to use, but I don't know about them. I was a java/J2EE programmer/architect for many years, but now I'm back in the C/C++ world I haven't touched java for 3-4 years or so....

Would you be populating these offsets yourself, or via some third party program? Although the information to populate the weather offsets is not available, I'm not sure its possible to write to them directly at the moment. You could try this, and if it doesn't work let me know and I can maybe look into free-ing those offsets to allow them to be used as free user offsets. Alternatively, you could write your weather data to a free user offset area, and spoof the actual weather offsets you want to use (replacing them with the data in your user offsets) using the spoofing offset at 0024. There are a couple of recent support requests where I have shown how to use this offset to spoof data - you can take a look at this support request (for spoofing the Parking Brake offset for the A320):

Event files (*.evt) should go in your FSUIPC7 installation folder. You may also need the MobiFlight WASM module installed, although I'm not 100% certain if the A32NX events are handled by the MF WASM module or the FBW A32NX itself. Once the event file is recognised, you should see the custom events in the controls drop-down menu, in the assignment panels. FSUIPC will just log the events it receives from MSFS. As custom events are handled by the add-on, I am not sure if you will see them logged in FSUIPC. Which version of the FBW mod are you using? This is the comment on that event (in the MF spreadsheet): dev version, soon on experimental, this does not work on the stable version. See A32NX_FCU_AP1_PUSH i.e. only on the dev version at the moment.

Before you buy, download and try it first. You can download from www.fsuipc.com, and there is a trial license available here: FSUIPC7 should be all you need. For the FBW A320, you need to use lvars and hvars to control many functions, sometimes by simply setting a value to an lvar, or activating a hvar, and sometimes more complex code is needed that can be ran using the FSUIPC lua ipc.execCalcCode function. There are various examples/support questions in this forum, as well as user-contributed lua scripts, on how to do this. Some people find it easier to use the MobiFlight WASM module, in conjunction with FSUIPC event files (to make the MobiFlight events assignable in FSUIPC7), so that they can use events rather than lvars/hvars/calc code directly. There are a couple of topics in this support forum that show you how to do this. A good resource for available hvars and calculator code id the MF spreadsheet: https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=373655063 If you decide that you wish to purchase a license for FSUIPC7, it is available from SimMarket: https://secure.simmarket.com/john-dowson-fsuipc7-for-msfs.phtml John

I thought this was done automatically when you set the com/nav buttons. How are you doing that? You could try using hvars. These are the ones available for the GN530: and these for the GN430: To test them (before adding them), you can use the Add-ons->WASM->Execute Calculator Code... menu option. So, for the GNS530, you can try to execute the following: That should switch between Com and Nav/VLOC. and highlight the frequency that is controlled by the inc/dec knob.. If that works, you need to add an *.hvar file for the C172 (e.g. Skyhawk.hvar) containing the hvars you wish to use (preceded by 'H:') to the FSUIPC7 WASM folder (under modules). You can then trigger the hvar via either lua or using a macro - details are in the Advanced User Guide.

Just took a look and I think I know what you mean... The UI yoke seems to behave as if a response curve has been applied, or at least doesn't appear to move linearly with the input through the whole 90 degree rotation (in each direction). It will be with Asobo not brunner - you can ask on the Asobo forums for MSFS.

Yes, this is something I could add. I am planning to refactor aa few areas of the WASM in the coming weeks, so I will also look into adding some sort if automatic lvar refresh. For the time being, you can now easily do this with a simple lua script- just a matter of using event.timer to call a handling function at regular intervals, then in the handling function just call ipc.reloadWASM(), i.e. local period = 600 -- period in ms, adjust as needed function reloadLvars(time) ipc.reloadWASM() end event.timer(period, "reloadLvars") Save that to a file called reloadLvars.lua, then add a line to the [Auto] section of your FSUIPC7.ini (create section if you don't have it): [Auto] 1=Lua reloadLvars Wow - impressive! If using the Java SDK, you could also access lvars directly using the WASM API (WAPI). There is a dynamic library available that you can use (via the Java Native Interface). Using that, your program would have access to an internal table of all lvars/hvars directly.

You have an additional comma after the condition, should be: 24=CP(-B,1)C,2,C66587,40002 Pete accidentally added that - I will correct his post...