John Dowson

Yes, copy and rename... Then I suggest you re-read it until you understand...did you not read this: If they are too bug to attach, just zip them. They are text files and zip pretty small. BUT, I do not need to see any files if your issue is that you have not put the hvar file in the correct place with a suitable name. Please try that before anything else. John

Did you check the name and location of your hvar file? If you think there is a problem, you need to enable debug logging in the WAPI and WASM, and show me your log again and also the FSUIPC_WASM.log. But first please read the Advanced User guide on how to use hvars, P44.

Yes. You need to manually change the Vendor, Product, possibly the device and also the Rotaries array (for your button numbers) John

Which is it? I can't understand this - is there not a menu item below the 'List Lvars' one, which you say is working, that says 'List Hvars'? If there is, and the lvar menu item is working then this must also be working. Are you sure that it is just not listing 0 hvars (check your log)? Why do you need that? It needs to match a substring match on the aircraft title, as logged in the FSUIPC7.log file, and also in the aircraft.cfg file I believe. For the FBW A320, it is this: Aircraft="Airbus A320 Neo FlyByWire" so your file name is not a substring match. Also, check that it is in the correct location, under the FSUIPC WASM modules folder, or in its persistent storage folder (under AppData). Please see the Advanced User guide for details.

What do you mean by 'open' in this context? If you can list lvars, the List Hvars menu item should be visible/accessible. Or do you mean no hvars are listed for the loaded aircraft? If so, have you added a hvar file for the aircraft you are using (with name if hvar file a substring match to the aircraft)? Have you read the section on how to use hvars in the FSUIPC Advanced User guide? John

...you could also try using a mouse macro, if no appropriate control or lvar exists.

For the PMDG: - check available custom controls (see the SDK documentation) - check available lvars - there is an DSUIPC control to do this which you can assign to a button or key press. The lvars and their values are listed in the FSUIPC6.log file If any look applicable, you can try changing their value (using a macro or lua script) to see if they have any affect - ask on the PMDG support forum to see if it is possible to control the switch guards externally John

How is your throttle assigned? I don't see any throttle assignments to axes either in your general [Axes] section or your profile specific [Axes.PMDG] section. Are they assigned to buttons or keys (on inc/dec controls)? If so, could try activate logging for Buttons and key operations as well as Events (non-axes controls) and produce another log file, where you load your aircraft and then operate your throttle (using your controller/assignments), then close down and show me the FSUIPC6.log file. Looking at your ini, there re a few things you could change/improve, although not related to your issue. First, you have assigned all your individual POV buttons - from your general [Buttons] assignments: You do not need to do this. You can assign a single POV button press (any) in the axes assignments tab to the axis control Pan View. However, as this is an axis control, you would also need to add this to your profile [Axes.xxx] sections. Your profile sections are also large, as you are using the full aircraft name, instead of substrings. Doing it this way, you have to add each change of livery of an aircraft manually to the profile. Instead, you could use substrings, i.e. change your [Profile.PMDG] section to the following: or maybe even just: John

What FS, version of FSUIPC and aircraft are you using? There are no standard controls for switch guards. You should look into any available lvars, or if its an add-on that comes with its own SDK, there may be custom or rotor brake controls. For MSFS aircraft, there could be hvars or more complex calculator code. As I say, it depends on the FS, aircraft and version of FSUIPC. John

There is no need to attach pictures. If you say the read isn't being logged, then I understand what that means... But what is your actual issue? That the read isn't being logged, or that MF is not seeing/receiving the value? If the latter, then you need MF support. If MF is seeing the value, i.e. it is being read, then the IPC Read logging should log this. So, is MF seeing the value? If not, please try MF support. If it is, I 'm not sure why it isn't being logged, but I am not going to look into this until you confirm that the value IS being read by MF.

Presume you mean offset logging, so you are logging the value in that offset and can see it change. If the offset is being read from an IPC client, then yes, the IPC read should be logged, if IPC Read logging is turned on. I think you need MobiFlight (MF) support, if MF cannot read the value. Your offset logging is showing that the FSUIPC offset is holding the correct value, no? So your problem seems to be with MF not reading the value, for which you need MF support. I do not use and cannot help you with MF. John

That is what is supposed to happen (i.e. the desktop link that FSUIPC creates os ONLY used to start MSFS, not FSUIPC7), and it is MSFS that is supposed to start FSUIPC7, via your EXE.xml. There is no auto-start component in your EXE.xml, which is why FSUIPC7 isn't being started by MSFS. The issue is that your EXE.xml is not a valid xml document - looks like it has been corrupted by the AFC_Bridge installer. There is no opening 'SimBase.Document' element. However, I am surprised this isn't logged in yout installation log. But, the solution to this issue is given in the README.txt (item 3 under Problems running FSUIPC7 : You should rename/delete your EXE.xml, and let the FSUIPC7 installer create a new one. You then manually add back in the AFC_Bridge, if you also want that started. But I have corrected your EXE.xml. Download the attached and use that to replace your current one. John EXE.xml

This did not sound quite right to me, so I checked with Pete, and this is his response: John

Just tried the MSFS Add-on Linker and it seems to be working fine here (I have a steam install): If using an MS Store installation, check the Add-on linker documentation as I think there can be permissions issues for that type of installation. John

Btw, you may/should comment out the logging statements in that lua, once you have it working. It is also designed to toggle between forward/reverse thrust on a button-press and release, so one press (and release) when throttles are at idle will switch from forward to reverse thrust, and a second press (and release), again when throttles at idle, will toggle back to forward thrust. If you plan to use this on a switch/sticky-button/slider, you can update to switch to reverse thrust on a press, and back to forward thrust on release. The script also only toggles each thrust (left/right) independently, so if one thrust lever is in the idle range and the other not, only reverse thrust will be triggered for the idling engine. not the other.

No. The lua Rotaries script should be auto-ran from the [Auto] (or profile [Auto.xxx]) section of your FSUIPC6.ini file. The way it works is to change the rotary 'button press' in each direction to a fast/slow virtual button press in each direction. You therefore need to assign in the FSUIPC Buttons + Switches tab to the fast/slow event (or offset) control to each of these virtual buttons. If you turn the rotary and you see the physical button number number rather than the virtual one, you can use the ini parameter IgnoreThese to ignore those physical buttons - you can do this while the assignments dialog is open and then click 'Reload all buttons' for this to take affect. Cheers, John

PMDG offsets are read-only, you cannot write to them. To update the values, you will need to use either standard events/controls, or more likely PMDG custom controls. Sounds like a question for MobiFlight, but I thought you just configured MobiFlight to read data from FSUIPC offsets. John

Could you please explain further? Why was it 'not good'? The shortcut installed by the FSUIPC7 installer starts MSFS (and displays a splash screen for 30 seconds), not FSUIPC7. It is MSFS that starts FSUIPC7, but only if you select to install the auto-start component. Looking at your installation log, it looks like you did not install the auto-start component, and so FSUIPC7 will not auto-start with MSFS. Your EXE.xml file also shows that MSFS is only starting the ADC_Bridge program, and not FSUIPC7. John

By this, you mean that you do not have a valid license for MSFS? Well, I do not, especially as you are the only person reporting this issue. I cannot look into this any further if you are not using a valid/officially licensed copy of MSFS. John

Ok. This is very strange. Is this a new issue or have buttons those buttons never been recognised by FSUIPC? You could try the 'old' method of using such buttons (ie. those outside the 32 button limit), which is using the lua com library. An example script id provided in the Example LUA plugins.zip, called HidDemo.lua. But I do not know what could be causing your issue. If windows can see those buttons, then so should FSUIPC. You could also try the HiDScanner program, to see if that recognises those buttons. available from here: John

I believe this is due to an error with the FLT path (for MS Installs only) introduced in version 7.2.13. This is fixed in the latest beta available in this post: John

Make sure you are not running the x56 software if/when using FSUIPC. Also, if you installed any saitek drivers, try uninstalling those and let windows install the default ones instead. The saitek software and drivers are known to give issues. Regards, John

Do you mean the Heavy Division mod (https://github.com/Heavy-Division/B78XH)? Thats not FBW... Some strange things in your WideClient log: - it seems that a 2nd BAV Merlin client is being started at around the 1h44min mark: - Connection is then lost but reconnected at around the 2h 28min mark: - Connection lost again at around 5hours: Maybe the second BAV Merlin client started affected the first one? Or did you the first BAV merlin client exit due to the "Aircraft paused for too long" message and you manually restarted? Having said that, I think your issue looks to be with the BAV merlin client. As the sim/aircraft was not paused, why did this client think it was? Maybe you can contact the provider/developer of that 3rd party client to determiner what is triggering this message. Otherwise, you could try setting the ReconnectMinutes WideClient ini parameter, but as your other clients are ok I doubt it is to do with the WideServer/WideClient connection, but rather the WideClient/BAV Merlin connection... John

Yes, sorry, I was mistaken...as documented, relative paths are taken from the current default path, which will be the P3D sounds folder, and not the FSUIPC installation path - that is used in FSUIPC7, not FSUIPC6! Ok. However, I think the installation folder location would be useful, I will look into adding it to an offset - I'm surprised its not already there.... John

Hi @light_blue_yonder. Could you try the attached lua. You may need to adjust/tune for your needs. Take a look at the comments in order to know how to condigure/tune, it should be straightforward but let me know if you have any difficulties. Once it is tuned and working, it should be started from your CRJ profile's Auto section. I still don't know how to trigger the engine 1/2 shutoff guards though, and move the throttles to cut-off. I'll take another look at this when I have time. John crjThrottle.lua