John Dowson

ODOC is 2 bytes, so you can read the value using the lua ipc.readUW function. You can then get the value of the bit you want to test using the lua logic library. So, to check for landing lights, which is bit 2 (and 2^2=4), do something like n=ipc.readUW(0x0D0C) v=logic.And(n, 0x4) and v will hold 1 if the landing lines are on, 0 otherwise.

You shouldn't need to restart the simulator. You can issue a reload, as I said.

Thats ok, but there is no 'value' associated to an hvar, so you can just use: 1=H:A320_Neo_EICAS_2_ECAM_CHANGE_PAGE_ENG=Set 2=H:A320_Neo_EICAS_2_ECAM_CHANGE_PAGE_BLEED=Set 3=H:A320_Neo_EICAS_2_ECAM_CHANGE_PAGE_PRESS=Set (and no space between the 'H:' and the hvar name - I'm surprised it works if you have that...although white space may be removed, I'm not sure without checking the code....) If you list hvars (see the Add-ons->WASM->List Hvars... menu entry), can you see that hvar? If so, it may be that extra space after the 'H:'. Otherwise, the hvar is not know to FSUIPC7. FSUIPC7 only knows about hvars loaded from the aircraft *.hvar file, located in the FSUIPC7 WASM folder. Check that file and add it there if its not there already. If you do this when FSUIPC7 is running, issue a Reload (from the Add-ons->WASM menu) to reload the hvars (and lvars) for the current aircraft.

We don't get any feedback from issues raised. Best to check yourself it its available or not. It was recently reported that the to/from fields are now populated: I'll check the remaining fields in the next few days and raise another support request for the missing info. John

This may work as you are using different commands (Set, Dec, Inc), and so the menu entries are different. However, due to the lvar name being the macro name (internally) this can cause problems. Its fine if it works for you, but if you get problems doing it this way the first think I would recommend is that this be changed.

You have to write the controlling command (GLOB) to offset 0xC800 last - it is this write that triggers the weather change. See here for more details: I'm not sure if you also need the GLOB control in the Metar string, maybe @Pete Dowson can clarify. Try the WeatherSet2 utility, available from: although I'm not sure if the source is included....

Many aircraft continuously omit certain events, which are different for different aircraft. To stop such events being logged, you can use the DontLogThese ini parameter, which will stop the events being logged for all aircraft if in the [General] section, and for specific aircraft when in your [Profile,xxx] section. See the Advanced User guide for details. And make sure you have only activated logging for Events and Buttons & Keys. You can also open the FSUIPC7.log file in an editor and find your button press there.

Not 100% sure what you mean, but, depending upon what you want to achieve, lua scripts can be auto-started and wait for 'events' and then act upon them . Events can come from various sources, such as a button press or offsets. So you can set a lua function to be called when one of the gear position offset changes (or the landing light offset). Take a look at the event library documentation in the Lua Library.

FSUIPC7 should not run anything, it is MSFS that should run FSUIPC7. It was only in earlier versions of FSUIPC that the desktop icon started MSFS. So, first download the latest version of FSUIPC7 (v7.0.9 or the latest beta, v7.1.0f). Before your run it, best to uninstall your current version by running the uninstaller located in your installation folder. Don't wirry, when you re-install into the same folder all your current settings will be preserved. Also, you may have remnants of your Steam install left over, so if the following file exists, please delete (or rename) before installing FSUIPC7 again: <USER>\AppData\Roaming\Microsoft Flight Simulator\UsrCfg.opt

If you open your FSUIPC7.ini file in an editor, look in the [General] section and you will see these lines: Change to: TrafficStallTime=-2 InitialStallTime=120 NormalStallTime=-2 i.e. make the TrafficStallTime and NormalStallTime negative values. However, this will not solve your problem, but just prevent the re-connections due to stalled data. Looking at the new log you attached, the parameter for all your axis controls are 0 for the first minute and a half or so: Was it during this period you had no control? Than just over minute later there is a break of 4 seconds where there were no rudder controls, but could be sue to them not being used: Do you maybe have auto-rudder or some co-pilot functions active in MSFS?

In a text editor.

As well as what Pete says, your log shows two disconnect/reconnections due to stalled data. Try changing to the following ini parameters to the following - the -tve numbers will just log messages when data is stalled rather than re-connect: Also, activate logging for axis controls, and if you open the console you can see if/when any rudder controls are sent. You can attach the log if you get the same problem. And as Pete says, its not clear from the log the aircraft you are using when the problem occurs - and is it just in one aircraft, or all or multiple? Your log shows you using both the DA40-NG Asobo and the Just Flight PA28 Arrow III OE-DSN. In the former your rudder axis is assigned to the FS AXIS_RUDDER_SET, and in the latter it is assigned Direct to FSUIPC Rudder control.

The following license is valid until 5th May: FSUIPC7.key

But that is now an old and unsupported version. You should use 6.1.0 (or 6.1.1a), which are the latest supported versions. There is no change to GF handling in these versions from 6.0.14.

No! You cannot use the same lvar more than once in a macro, as the lvar name is also the macro name. Therefore there is no way to distinguish between those entries. If you want to do it that way (i.e. multiple macros on the same lvar), you would need each macro definition (using the same lvar) in its own file.

The GFDev64.dllv should be placed in your FSUIPC6 installation folder, wherever that is. If you don't Know, you can open that folder using the Open Folder button in the logging tab. Check (or post) your FSUIPC6.log file - there will be a message in that file if the GF dll is found and loaded, and show the devices detected, e.g here's mine:

Your FSUIPC7.log shows that FSUIPC7 was running and connected to MSFS ok: So FSUIPC7 is running and connecting ok. If you open the FSUIPC7 main window it will show that it is connected. As Pete says, make sure you are ready-to-fly and check you at running Pilot2Atc at the same privilege level (and maybe check the Pilot2ATC logs). As for why FSUIPC7 is not starting with MSFS, can you show me this file please: C:\Users\BD3B484275CE462B\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\EXE.xml

But in normal shutdown, there are only termination messages. The "warnings" are only in your debug log: 112203 **** DevCom read/write threads still running - will exit anyway but could cause issues... 112500 **** DevCom Read thread terminated Anyway, I think things are ok as they re for now.... Cheers, John

Normally, or when in debug?

And neither the event.param

You could also explicitly terminate the thread yourself in your HandleShutdown function - just add an ipc.exit() call to the end.

It has the same timestamp, so is just something that occurred around the same time, before the cancel completed. Its not an issue.

Note that when you see this: in the log: This indicates that the thread didn't close correctly, and the initial termination code didn't stop the thread, and so was eventually killed by the main thread (or the DLLStop thread). This can cause issues if the com thread is not fully closed, but I haven't seen such an issue (with the updates in 6.1) so far....

Yes, if you debug it will increase the latency. But I'm not going to adjust for this - and it still closed down correctly anyway, so I don't see an issue.

Yes, but that maybe because you have TimeForLuaClosing=5 still set, which is the time betwwen these messages: 90688 Waiting for lua threads to process termination event... ... 95688 Lua threads being terminated: The com.close is done hbetween these log messages: 90688 LUA.1: Shutting down USB device hnd=1 ... 91328 LUA.1: USB Device disconnected So is taking roughly 0.65 seconds. You can try reducing the TimeForLuaClosing back to 2, or maybe even try 1. Also, for such issues, its also a good idea to enable logging for 'Extras', as this will then log the thread that is producing the message. Most shut-down issues are thread & timings related. The thread is still being killed later though, which is a bit strange, but at least the com has closed so this isn't an issue. However, I did reduce another timing that may have caused this - I will increase again slightly when I release this. Thanks for you help on this, John