John Dowson

You can use the ini parameter DontLogThese to ignore those, best used in your profile section. See the Advanced User guide for details on this ini parameter. Yes, strange, However there is an issue with some external controls in that they don't work in the same manner as the internal one. This has been reported to Asobo (a long time ago), but I guess it has not yet been fully addressed. Is there another lvar that holds/controls the light state? If so, you could try using that.... John

Also, for any/all auto-start issues. please see the following FAQ entry: John

You should only use the direct SteeringTiller axis if you want to blend with the rudder (and then assign to the same axis as rudder) If you are using separate axes and don't want any blending, you can try assigning using 'Send to FS as normal axis' and try either the Axis Steering Set and Steering Set axes. You can still calibrate. Axis Steering Set seems to work fine in the longitude. Also no issues if you want to bind that axis in the sim.

So it installed ok after the reboot, including updating the EXE.xml? If FSUIPC7 is not starting with MSFS, then its most likely an issue with your EXE.xml. Please show me/attach that file, together with your InstallFSUIPC7.log file and I will take a look. Note that you should run MSFS at least once after re-installing and before installing FSUIPC7. John

Ah...I think you are misunderstanding FSUIPC's rudder/tiller blending facilities. These are intended to be used when both the rudder and tiller are assigned to the same axis. It doesn't make sense blending these if separate axes are used as there are already separate values for rudder and tiller. That is strange - it should show the deflection that you apply (once calibration has been applied)....

Can you please set logging for Axes Controls, and also log offsets 0C08 and 0C0A, both as S16 (and log to normal log file) and show me a FSUIPC7.log file. Thats strange - I will check this. Note that you have a profile-specific calibration section for the DHC-4 - were you looking there? It is still set to Q in the ini you attached. Strange that the first image you posted shpws the general calibration section though, and not the profile-specific one. Did you make this profile-specific after attaching that image? I don't have the DHC-4, but I will check this in another aircraft. You should also consider changing your aircraft names in the profiles to use substrings, so that they catch mpre variants. e.g. change to and update the other aircraft names in your profile sections to use substring matching. John

WideClient does not transmit axes data, only buttons. This is because the overhead/lag on axes connected to a client PC makes them basically unusable. You should connect your throttle quadrant to the FS PC (the server). John

Maybe the lvar is only controlling the visuals? If thats the case, then something else may be needed to control the actual functionality (and sound). I don't have this aircraft so cannot look into this. There are a few things you can do: 1. Use FSUIPC's logging facilities, and log Events and Input Events. What do you see logged when setting the autobrake with the mouse, and is this different than when using the preset? You can check this in real-time by opening the logging console (Log->Open Console). 2. Inspect the code of the autobrake switch/rotary to see how it is implemented. See https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ 3. Ask about this preset on the Mobiflight HubHop support. on Discord under the MSFS2020 channel. John

Glad you got this working! Yes, doing that should have given you a lot if insight in how and why to use such functionality as assignment overloading, adding lvars to offsets, and using offset conditions, That should be useful for future complex assignments. The lua script is also not a bad solution, but this is probably more resource efficient and will execute faster, as it won't have the thread creation overhead (as all lua scripts are ran in separate threads). No problem - and thanks for the update. John

In short, no. You can only discover/find hvars either by inspecting the xml code of the aircraft, or if published in the aircraft documentation. There is no method (that I know of) to discover hvars by any other means, not even programmatically. This is why you need to provide a file to tell FSUIPC what hvars are available, if you want to use them. Also, it seems to me that hvars have fallen out of favor. Many early MSFS2020 aircraft used them, but later ones have switched to b-vars/input events. If using hvars, I think its better to use them via presets and forget about the *.hvar files. The direct access to hvars was added before the preset/calculator code interface was added. As hvars have no state/value (they can just be triggered), there is really no need for these to be known by FSUIPC, and better/easier to just trigger them via calc code or a preset. John

This depends on where the FD is getting the ILS data. You could try setting the follwing ini parameter in FSUIPC to see if that helps: See It may be worth asking Project Magenta support about this as that post was from Enrico, the author of PM. Is Navigraph using the output from MakeRwys? Note that I do not support MakeRwys, but the source is available if needed: John

I cannot see anything, and no macro button' should appear. The macros's should be available for assignment in the control drop-down menu, preceded by the file name. Are they not there? If I save your macro file to my FSUIPC7 installation folder, I see them all: Note also that presets already exist to control/set those hvars, e.g. Why don't you just use them? You also have the lua file being auto-ran: You should remove that - there is no need or reason to run that file.

Yes, both would work as both strings 'Cockspur PH100' and 'PH100' are contained within the aircraft names 'Cockspur PH100 Brown and Black' and 'Cockspur PH100 Factory 1', hence they are substring matches. This just means that the hvar filename string exists/matches to a string in the aircraft name. You could use the entire aircraft name if you like, but that would just match one aircraft and would not match if you changed the livery/version. Note you can (and should) also use substring matching for your aircraft profile names. Change to which would then match all variants of that aircraft. You should get into the habit of editing the aircraft names in the profile section when you create a new profile or add an aircraft to an existing profile, and reduce it to a substring of the full aircraft name so that it matches other variants.

That's rather strange, as only 10 presets are sent each time - well, 10 on press and 10 on release, so maybe 20. So I am not sure why 1 "fast" inc/dec would change by 40. You can adjust this yourself - just remove some of the fast inc/dec assignment lines from your ini. Try with the release assignments removed, i.e. the ones that start with 'CU'. Note that you can edit the ini with FSUIPC7 running so you can adjust this and test without restarting. Just make sure that the button assignment panel/window is open when you edit the ini, and once you have saved your changes, click the Reload all buttons button to reload the updated ini and then test. You can repeat and add or remove more assignments until it inc/decs how you would like it to. John

The log file shows that the assignments are working as expected: - pressing button 16 without 18 being pressed sends one inc preset: - pressing button 17 without 18 being pressed sends one dec preset - pressing button 16 with button 18 pressed sends 10 inc presets: - pressing button 17 with button 18 pressed sends 10 dec presets: So the assignments are working as expected. What do you actually see on slow/fast clockwise/anticlockwise rotary movements? Are he slow ones now at least working. incrementing and decrementing by 1? Do you see any change when also using button G18 (i.e. the fast/larger in/dec)?

As any lua lvar function using the lvar name is quite expensive in turns of performance (as it has to scan all lvars and do string matching to find the id), you could improve that by just reding the lvar value once:: domeLightDisplay = ipc.readLvar("L:VC_Dome_Light_Display_VAL") if domeLightDisplay == 0 then ipc.execCalcCode("39 (>L:VC_Miscellaneous_trigger_VAL,number)") elseif domeLightDisplay == 1 then ipc.execCalcCode("39 (>L:VC_Miscellaneous_trigger_VAL,number)") elseif domeLightDisplay == 2 then ipc.execCalcCode("38 (>L:VC_Miscellaneous_trigger_VAL,number)") ipc.sleep(100) ipc.execCalcCode("38 (>L:VC_Miscellaneous_trigger_VAL,number)") end I'm trying to figure out how this would work. So, if I define a preset as suggested by you, how do I then proceed? Where do I define such a preset? Can you point me to the right support document or some kind of tutorial? Sorry, I'm pretty new to this part of coding and appreciate some hints. You define presets in a file called myevents.txt (you have to create this) - see the section Using Calculator Code Presets on page 50 of the Advanced User guide. If you wanted to replicate that lua script using presets and direct assignments, you would need to: 1. define 2 presets in the myevents.txt file, e.g. //iFl/737MAX/Lights Dome_Light_Up#39 (>L:VC_Miscellaneous_trigger_VAL,number) Dome_Light_Down#38 (>L:VC_Miscellaneous_trigger_VAL,number) 2, Add the lvar VC_Dome_Light_Display_VAL to an FSUIPC offset. Best to do this in your profile, e.g. if your profile is called xxx, the following would add this lvar to offset 0xA000 as a single byte value: [LvarOffsets.xxx] 1=L:VC_Dome_Light_Display_VAL=UB0xA000 See the section Adding Lvars to Offsets on page 47 of the Advanced User guide. 3. Assign your button to one of the presets. This will result in an entry in your FSUIPC7.ini like the following (the index, joystick letter and button number will differ): 73=PS,3,CPDome_Light_Up,0 -{Preset Control}- 4. Open the button assignments panel in FSUIPC7, and also open the FSUIPC7.ini file in an editor and locate the button assignment line. You then need to duplicate that 4 times, changing the index number and the preset used: 73=PS,3,CPDome_Light_Up,0 -{Preset Control}- 74=PS,3,CPDome_Light_Up,0 -{Preset Control}- 75=PS,3,CPDome_Light_Down,0 -{Preset Control}- 76=PS,3,CPDome_Light_Down,0 -{Preset Control}- 5. You then need to add the delay between the two down presets, and add an offset condition to the offset holding the value of the lvar VC_Dome_Light_Display_VAL: 73=BA000=0 PS,3,CPDome_Light_Up,0 -{Preset Control}- 74=BA000=1 PS,3,CPDome_Light_Up,0 -{Preset Control}- 75=BA000=2 PS,3,CPDome_Light_Down,0 -{Preset Control}- 76=BA000=2 PS,3,C1152,100 -{pause (ms)}- 77=BA000=2 PS,3,CPDome_Light_Down,0 -{Preset Control}- See the section Adding offset conditions on page 24 of the Advanced User guide 6. Save the changes to the FSUIPC7.ini file, and then click the Reload all buttons button in FSUIPC7 to reload the updated ini. The one doubt I have on this is whether the last preset (with index 77 above) will be sent or not: it could be that the lvar is updated, and thus the offset value, before that assignment is considered for execution, and if that is the case it will not be executed as the offset value will no longer be 2 but 1. If this is the case, reduce the delay - 10 or 20ms should be enough really. John - :

Did you check that was the case? i.e. does that offset hold the correct value? If so, you could have a lua script (auto-ran) that monitors that offset (using event.offset) and when the value hits 16383 (or maybe below this) you could write a value of 1 to a different/spare FSUIPC offset and use that in the PM sound config. Of course, you would also need to reset that offset when the value in 0x0BD0 goes back below 16383 (or the value that you use).

Ah, sorry - then no, you cannot use that offset. Try logging offset 0x0BD0 and see what that holds when the spoilers are deployed: John

Ok, no problem.

Take a look at the PMDG-specific offsets - maybe this one: ? John

Also set WAPI Debug level logging (Log->WAPI->Debug) and use the following ini: FSUIPC7.ini

That is very strange...Nothing should happen when G18 is pressed on its own. Could you please activate logging for Buttons & Keys, and show me/attach an FSUIPC7.log file showing those issues, and also attach your current FSUIPC7.ini file. John

Ok. But be aware that is assigned in your general profile to start the ipcReady.lua: Not sure why you would want an assignment to start/restart that, as it is started by default once an aircraft is loaded. I will remove that. Please try the attached and let me know how it goes. When you hold button G18, the inc/dec should be 10x faster. John FSUIPC7.ini

On the same controller? If not, which controller? How many button box interfaces do you have? Your ini shows 4 detected: but you also have assignments to another one that is no longer detected: You have several assignments to this that will not be working: Looks like that device is now the K device (Button Box Interface BBI-64) as you have re-assigned some of those buttons to that. In the attached ini, I have removed those assignments to the missing device that were re-assigned, and updated the remainder to use the K device. I have also added assignments to send the CRS inc/dec on a button release to see if this improves things. If you let me know which device has button 18 that you want to use for fast inc/dec then I can add that for you. Note also that you have several assignments to PMDG 737 presets in your general profile. These should really be in your PMDG profile - shall I move these across for you as well? John FSUIPC7.ini

Ok, thanks, If using the Fenix, it could be the FenixBootsrapper - issues with simconnect connections when using this aircraft have been reported before - see If there is anything in your EXE.xml for the fenix, try moving that to after the FSUIPC7 entry, although I doubt this will help as FSUIPC does not try to get a connection until .the DetectToConnectDelayAuto has passed, which is set to 60 seconds. If there is an entry for the FenixBootstrapper in the EXE.xml, you could try setting the Disabled property to True (temporarily) to see if that helps. You could also try removing the Fenix from your WASM folder (temporarily) to see if that fixes the issue. But its the SimConnect.log file that will tell you which add-on is misbehaving. John