John Dowson

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

First, please use the FSUIPC7 sub-forum for all issues/questions on FSUIPC7, not the main forum. I have moved your post. Which version of MSFS - 2020 or 2024? Or do you get this issue with both? I have checked with both versions here and do not see any issues, so it is something specific to your system. If FSUIPC cannot connect to MSFS, this is usually because there are no SimConnect connections available. This can only happen if something else has taken / used all the available connections. Are you running any other 3rd-party/simconnect applications? Do you have the Fenix aircraft installed? The first thing to do is to reboot and try again. If you get the same issue check your EXE.xml (location is in the InstallFSUIPC7.log if you do not know where this is) and see if any other applications are being started. If so, try re-ordering them so FSUIPC7 is started first. If this is due to another simconnect application using up all available connections, then you need to determine what application this is. To do this, you can enable SimConnect logging - see the following article on how to do this: The log file will show each connection, and should tell you if one or more of your clients is behaving badly and taking up all the connections - there are several known clients that have done this over the years (e.g. Fenix bootstrapper). If you have not done so already, it is also a good idea to increase the number of SimConnect clients allowed, by setting the MaxClients parameter to 128 (default is 64) in your SimConnect.xml file (whose location is the same as for the SimConnect.ini file described in that post I referenced above). John

Its not that difficult.... First, do your rotaries have 1 or two buttons on each direction? You can check this in the FSUIPC button assignments window - do you see different buttons registered if you turn fast and slow, or just the one button regardless of speed (try a few times)? If just one button, do you want to use a different button or key press to switch between slow and fast selection? And do your rotary buttons emit just presses, or alternate press and releases? If you show me your assignments (FSUIPC7.ini file), I can help you set this up. John

I have just looked into this further. I have rotaries with two buttons in each direction, for fast and slow, and the rotary alternates between sending button press and release events. If I assign both the fast and slow inc/clockwise buttons to the preset PMDG_B737_MCP_FO_CRS_INC on both press and release (with a similar assignment for the dec), then I can get single increments when turning slowly, and large increments (>100) if I turn fast. No need to overload the assignments to send multiple controls. Not sure what these offsets hold, but it is not the actual course set, so this cannot be used.

Yes. If you use ipc.createLvar, FSUIPC knows that a new lvar is created and will rescan/reload all lvars so that the one created is available/known to FSUIPC. This also applies if you create an lvar via FSUIPC offsets. If you create an lvar in an ad-hoc manner by executing some calculator code, then FSUIPC does not know that a new lvar has been created and so this lvar will not be known to FSUIPC until a WASM reload/rescan is performed. There is a known issue, in both MSFS2020 and MSFS2024, in that the FSUIPC WASM module can crash when scanning for lvars - see Previously the FSUIPC WASM would occasionally re-scan for new lvars and push these out to FSUIPC (as well as any other clients) when found. However, this facility was disabled quite some time ago due to this causing a WASM crash. Yes, that is as expected due to the reason given earlier. John

There are various methods to have fast & slow inc/dec on a rotary button, and this depends on the rotary and what button events it sends out. Some rotaries have two buttons in each direction, one triggered on a slow move and another on a fast move. For such rotaries, you can assign the slow buttons to the small inc/dec and the fast buttons to the larger inc/dec controls. For rotaries that have only one button in each direction, you can either: 1. Use a lua script to convert the single button press/release to two virtual buttons, one for fast and another for slow, and then assign to the virtual buttons. There is an example script provided that does this (will need configuring for your system), called Rotaries.lua. 2. You can overload the buttons to have both fast and slow in/decs, and then use a compound condition on the assignment so that only one of these is fired depending upon the state of another button or offset. You could also do this on the state of a key press, but to do this the keypress would set an FSUIPC offset and then the inc/dec assignment would use a compound condition on this offset, and the key release would then clear the offset. Note also that some rotaries alternate between sending out button presses and button releases. For such rotaries, you need to assign to both the press and release. You also need to determine what to send for the fast increment/decrements. FSUIPC does provide some fast controls (e.g. Heading Bug Inc Fast, Heading Bug Dec Fast), but I doubt these work with PMDG. The simplest thing to do would be to send the same control that you use for the slow inc/dec, but send it multiple times (e.g. duplicate the fast assignment line 10 times, changing the index number for the assignment so that it is unique, to send the control 10x). Alternatively, you could have a lua script that read the current left/right course value, applies whatever delta you need to that, and then send that. The current course headings are held in the PMDG-specific offset 0x6520: and the following PMDG custom controls allow you to set the course directly: John

You cannot read the value of an lvar directly like that, as it only exists in the simulator, not in FSUIPC or the lua thread. To read an lvar value, use the ipc.readLvar function, e.g if ipc.readLvar("L:VC_Dome_Light_Display_VAL") == 0 then ipc.execCalcCode("39 (>L:VC_Miscellaneous_trigger_VAL,number)") end You could also define a preset with the following calc code: (L:VC_Dome_Light_Display_VAL, number) == 0 if{ 39 (>L:VC_Miscellaneous_trigger_VAL,number)} then assign to that preset - no lua needed (more efficient!). John

Try the preset TCAS SWITCH POSITION TA RA: John

Why not just use the provided preset Autbrake Off? That uses the following calculator code: 10 (>L:VC_Autobrake_SW_VAL) If you really want to do this via lua, then a simple script just containing ipc.execCalcCode("10 (>L:VC_Autobrake_SW_VAL)") should do the trick. I see you just replied... Yes, thats fine. But there are presets available for this - the following presets are available for the Autobrake: There are two presets for 'autobrake off', but if you look at the descriptions the first is incorrect and switches to max, and the 2nd one is the correct one. I don't know or understand why they did not just correct the first one rather than leaving it and adding another preset. This 2nd preset was also added after the current release of FSUPC7, and so is not available in the current version. In fact, as there is also other presets with the same name, it won't be loaded as preset names must be unique in FSUIPC. Therefore, I would advise that the best way to do this would be to define your own preset in the myevents.txt file: //iFly/737-Max8/Gear IFLY_737Max_Autobrake_Off#10 (>L:VC_Autobrake_SW_VAL) Then assign to that preset. John

Did you try the presets? As I said, if they are not working, you can ask about this on the MobiFligh support on Discord. How does that variable change when you start it manually? Do you also see any events or input events when starting it manually? It could be that something else is needed. You can also try inspecting the switch behavior to see how it works - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/

👍

I have done some further testing on writing to offsets 0x3110 (for control number) an4 0x3114 for the parameter, and this works as expected, i.e. the control is always sent when writing to offset 0x3110, even if its the same control number, and if the parameter in 0x3114 has been changed or not - whatever that offset holds when 0x3110 is triggered will be used. This is the case in the current released version, so that patched version I attached is not actually needed. So if you are seeing different behavior when writing to these offsets via SIOC, then it is an issue with SIOC. John