Leaderboard

There's no copyright claim on the original script, so I've uploaded my version of it here... Original file courtesy of Manolo Velez. You'll need to open this in the SIOC utility. Open SIOC.exe Choose "Edit Script" Files -> Import TXT (and select this attached file) Save As... (it'll compile as an .ssi file) Once compiled you may need to click the "Reload" button in the man SIOC utility window. All done! (hopefully) I'm a novice when it comes to this stuff, so I'm afraid I can offer no support. (See latest version below...)

Hi @jonas_llubi, @Abt. I share you frustration with this. In fact, I spent the last 6 hours vibe coding an AI-assisted solution for a SIOC script that correctly handles the COM1/2 active/standby frequencies for both 25kHz and 8.33kHz frequencies. I also changed the logic so that it truly does work as a slave device, in that if MSFS changes the frequency itself (or another app like BATC etc does) then the updated frequency will appear in the panel, and it won't keep overriding MSFS. Limitations: It's really nasty code, made with the assistance of AI. Works with MSFS2020, but not yet tested for MSFS 2024. The SIOC script also doesn't appear to work for the Nav radios. I based it off the originally provided SIOC scripts from opencockpits (I'm not sure if I can share it openly with you, but there is no copyright notice on the original), and that original script doesn't work for Nav radios in MSFS2020 either. For me, the COM 1/2 radios were much more important. I can revisit the NAV modes later perhaps. In testing, the display does sometimes go black, and the panel appears to fail. To fix it, you have to just press the "Reload" button in the SIOC utility. I changed the logic so that it always initialises with the active COM1/2 frequencies from MSFS so that it doesn't reset anything if you have to restart multiple times in the middle of a flight. I hope it works as a stop-gap until something better comes along though! Edit: The NAV VOR and ADF radios don't work, but the ILS mode frequency and course values do work! If you're interested, let me know and I can send the script to you privately. Linguini

Urgent Fix / Update Some Things slipped through, sorry for the Inconvenience! Version 0.8.9 - Fixed Lua Scripts not properly stopped/started (and therefor not working) - Fixed InputEvents.txt (detected B-Vars) not being created - Fixed Version-Check not notifying about new Dev-Builds

Confirmed John. ScruffyDuck has retired and no one else is picking up the baton. Another reason to stay with v5.

Thanks John I have reverted back to an earlier version which accepts fsuipc to assign cyclic controls via aileron elevator and also axis cyclic longitudinal and lateral I posted a bug report regarding the cyclic issue. Cheers Rhys

Hi Ray, That offset is just for the 'Fuel Tank Selector', and it is not a custom control. To set this, you would use the Offset Word Set control. To empty the tanks, try writing 0 to the tank level offsets (using Offset Dword Set😞 John

You can limit the range of the axis by manually editing the FSUIPC calibration entry. If you assign and calibrate the spoilers, then open and find the calibration entry: It will look something like this: You can decrease the minimum value and increase the maximum value to fool FSUIPC into thinking the axis range is larger than it is, and then the calibrated down to the standard -16384 - +16384 range. So, for example, if you doubled the top range: Spoilers=-16383,32768/16 the axis would only move half way through its positive range as your axis input value of 16384 would be calibrated to 8192.Try different numbers to get the range you require (change this when the FSUIPC axis assignments or calibration window is open, and click to reload your settings once the changes have been saved). John

Useful for me to see why it failed. Looks ok/valid on a first look, so not sure why its failing. May help me to improve the install process if its failing on a valid xml file. I will look into it further when time permits. Cheers, John

Yes, I should have mentioned that. Basically, if one program needs admin privileges, then for auto-start (either via FSUIPC or MSFS) then everything needs to be ran with elevated privileges. Previously this was possible, but windows OS is getting stricter and stricter on each release, for obvious reasons I think... I don't think there is anything I can do about this, but will look into it further when time permits. I think that for now you will just have to manually start anything that requires admin privileges. You could also ask/enquire on the support forums for any program that does this as to why this is necessary in the first place... If you find any solution, please update this thread! Regards, John

Glad you have now resolved this. I have updated the title. Regards, John

Ok, that can happen. Thats fine - whatever works for you. Just pointing out that for most things, the various FSUIPC logging facilities should be proficient enough, but you do have to 'connect the dots; as you say. Yes - you need to do it this way anyway if the position lvar only changes the position but not the actual function/lights.

Note that you can see available lvars by listing them (Add-ons=>WASM->List Lvars) - no need to use the MSFS behaviors dialog, except as a last resort (i.e. usually to discover b-vars or h-vars). No problem about the incorrect lvar name - these things happen...! Now you have the correct name, you should check if setting that directly works to control the switch. If so, the assignments can be simplified as you don't need the compound condition on the position of your switches, and you only need to send the one one command to change the lvar two positions instead of three (e.g. switch up, pause, switch up). Anyway, you should try and understand those assignments and try to assign yourself the next time you want to make a conditional assignment. I will help if you run into problems, but you should have enough info in this thread to make a start. Regards, John

Yes - sorry, I forgot to add the conditional letter 'C and the conditional comes after the press 'P' letter'. Should be 7=BA002=10 CP(+M, 29)M,27,CPNav_Strobe_Switch_Down,0 -{Preset Control}- 8=BA002=10 CP(+M, 28)M,27,CPNav_Strobe_Switch_Up,0 -{Preset Control}-

Yes, I understood. Just trying to point out that when using two switches, one for each light, its never going to work in the same way as one 3-position switch to control the lights. The honeycomb light switches are designed for on/off of each of the lights, so however you implement this is going to be a fudge, but maybe ne that you can live with. And no need for the pictures either... Yes, that's fine. No, but you can assign to a preset and then make that assignment conditional on an offset value. Or just also add the lvar VC_Miscellaneous_trigger_VAL to an offset, and just use assignments with offset conditions, as I advised. If you can just tell me what you want the switch position to be in the UP/UP state I can show you how to do this - its easier to do it this way than in lua.

Hi John. you are really the BEST !!! Very very professional and always helping in a very short time. Thanks a lot again Claudio Damiani

Hi Peter, Nice simple solution. I have had P3D controls disabled for years and assign everything through FSUIPC. Rock solid! 👍

Ok, interesting. With P3Dv4, it is always advised to start with a default aircraft, and then switch, especially if using complex add-ons, but probably a good idea to do this when using any add-on aircraft. Thanks for the update.

Ok, thats interesting - and I also don't understand why this would fix your issue - maybe there was an option you set that disabled this for some reason. But glad its now fixed! Maybe try comparing the old prepar3d.cfg (if you saved it) to the new one, to see what has changed that could affect this.

I've never developed anything, but have used every sim since MSFS95 and a whole bunch of add ons, apps, mods etc. I also own the Aviator Edition. I've done a little more testing. All at YSSY Flytampa to stay consistent. I tried the new A359 ULR from Inibuilds and I re tried the A333. Both loaded in fine if I closed GSX before attempting anything. Volenta - no crash, no tracking without FSUICP Navigraph hub/simlink - no crash A Pilots Life 2 - Opens but doesn't speak to the sim as it requires FSUICP BeyondATC - The app opened, but couldn't find a connection to the PC GSX - If allowed to auto start, causes CTD when attempting to start a flight. If GSX closed prior to starting a flight and then manually opened, GSX won't open Active Sky - CTD Simapp pro (winwing) - works, no crash I then did the same with the Cessna Skycourier. When I attempted to open BeyondATC, it attempted to load into the flight and then CTD. All I'm saying is, if CTDs are still happening, even after FSUICP is removed, I think we can rule it out and more then likely Simconnect is the issue.

No problem - permission granted (well, not even needed really!). You could also add it to the User Contribution section if you like, and/or I could include it in the FSUIPC SDK download. Let me know. Regards, 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

Thanks John Followed your instructions and now works great Thanks for your time and knowhow. I started Flight Sim about 20 years ago and using the mouse didn't appeal so building switch panels became part of the hobby, but it was only with FSUIPC with yourself and Pete (hope he is keeping well) that i could get them to work. Kind Regards Brian

Thank you, I moved FSUIPC to starting first, and changed the MaxClients to 128. Now Everything is working well.

Thanks very much John, as always, just done what you explained, works perfect.

Thanks, John, that has worked perfectly. I don't know why my system thought I had the Steam version installed, I have never purchased or installed MSFS 2024 on Steam, only from the Xbox store. Anyway, followed your steps, and FSUIPC is now starting automatically with the sim. Thanks so much for taking the time to resolve this for me, and thanks again for a great product.

Thanks - they look good with that version and show the PMDG-specific offsets have been enabled. However, both your log files do contain errors because you are trying to operate the aircraft far too early. With complex add-ons, such as the PMDG, you need to wait a while before everything is loaded and available. You were operating things around 10 seconds too early in MSFS2024, and around 30seconds too early in MSFS2020. Not an issue though - just incase you were wondering why your initial button presses had no effect. Apart from that, it looks good. Thanks for testing this for me. Regards, John

Thank you for this... The above "Pause" control (c1152) idea was a perfect solution to operate multiple switches in the PMDG 737's and 777's in both MSFS2020 & 2024. I was experiencing the same symptom where only the last sequential switch in a group would operate. Adding the pause control allows all sequential switches to work as expected. Regards,

New Version for the Plugin (only): v0.8.8 - Plugin - Version Reporting: The Version now also includes its Buildtime to help differentiating between Development-Builds - Rewrite of the MSFS Connector: Almost everything is now done natively through SimConnect, the MobiFlight Module is now only required for Calculator Code! - KVAR Command Syntax Change: KVAR Commands can be either a Sequence with each KVAR having exactly one (!) required Parameter -OR- can be exactly one KVAR with 0 to 5 Parameters! - KVAR as Variable: K-Vars or SimEvents can be used as Variable. The initial Value will always be 0 and only change if the Event is ever received (and only reflects the first Index) - Support for FSUIPC Byte Arrays: The Offset Variable now Supports reading a whole Offset Range as Byte Array (Contributed by ngreatorex) - e.g. reading the whole PMDG CDU Offset Range at once. Note that they are only intended to be used in Lua Scripts! - The AVAR Variable Syntax now also supports the Prefixes 'E:' and 'L:' to read Environment and Local Variables (aka L-Vars) - Lua Scripts: the 'SimCommand' Function does not support vJoy Commands anymore. Use the new dedicated 'JoystickCommand' Function which allows sending separate down/up Commands. - Fixed: B-Var Commands not working after switching a Session - FSUIPC Connector (FSX/P3D/MSFS) now allows Commands to be sent when the Simulator is paused - MSFS Connector now allows Commands to be sent when the Simulator is paused - XP Connector now allows Commands to be sent when the Simulator is paused - Visual Overhaul of the Action Designer UI: Elements and Commands now have separate & collapsable Trees and their Appearance was overhauled - Action Designer UI: Copy & Paste now also supports a whole List of Items - i.e. Copying all Manipulators from one Element to another. - Action Designer UI: Added Increment/Decrement Buttons for some Text Fields - Gauge Element (Composite Action): A Range of Markers is now saved as such and the whole Ranged can be edited/changed at once (only for new Marker Ranges). The Syntax for a Marker Range is now '$start:end:step'. - Added an "REST-ish" API to the Plugin to get/set Variables and even send Commands (only understands GET, zero JSON, everything encoded in the URL ). This is mainly intended for Testing and other Edge-Cases, it is not intended as a Replacement for Middleware as FSUIPC or SPAD! - Added Support for X-Plane's WebAPI (12.1.4+) - disabled by default due to an open XP Bug (XPD-16752) 😕 - X-Plane Commands now have an "Command Once" Option (enabled by default) to configure if a Command is send as one Command or different active/release Commands (only relevant when WebAPI is enabled) - The Version Check now also reports if a new Development Build is available - Logging for Errors/Exceptions in Lua-Scripts is bit more detailed now - Updated Libraries / Dependencies - Fixed Event Log Error on Shutdown - Profile Manager - Improved Checking if a Profile was installed during Package Installation. All Profiles in a Package must be either installed or ignored for the Installation to continue! - Now offers to start the StreamDeck Software again if it was closed by the Profile Mapping View - New 'Create Package' View to assist with creating & updating Packages for Distribution - Installer - Rewrite of the Installer to have a shared Code-Base across all Tools - The Installer now shows the current installed Versions (on future Installs / Updates) - The Installer now offers Options for Install & Update (i.e. if FSUIPC7 is used as secondary Connector or if the vJoy-Driver should be checked) - Improved Logging for the Installer

Any issue with button assignments, I need to see both your FSUIPC7.ini and FSUIPC7.log files, the latter with logging for Buttons & Keys activated, and if assigned to presets also WAPI->Debug level logging. Note that it could be that you are using an aircraft with a different name that is not covered by your profile. You should shorten your aircraft names in your profile sections and use substring matching. i.e. change: to You should do the same for all the aircraft names in your profiles. i.e. use the shortest substring)s) of the name that matches all the aircraft you want to capture in that profile and no others. You should get into the habit of editing the aircraft name in a profile whenever you add an aircraft to a profile or create a new profile. John

There are various WASM ini parameters that control scanning for new lvars, but this should only be done in the fist few minutes after aircraft load, as that is generally when all useful lvars will be created. If any lvars are created after this period, then you will need to request a WASM reload (via lua, the provided control or the Add-ons->WASM menu->Reload WASM item) for them to be known by FSUIPC. However if the lvars are specifically created by FSUIPC, either via using lua ipc.createLvar or via offset 0x0D70), then the new lvars will automatically be pushed out to all WASM clients (including FSUIPC) and so no reload is necessary, although a short delay will still be needed before the lvar becomes available. This does not apply if the lvar is created in an ad-hoc manner via executing calculator code as you are doing (although there is nothing wrong doing it this way). Just FYI. Cheers, John

Dear all - the attached lua scripts work for me, maybe you will also find them useful. Thanks a lot to John for all his help. Single Radios.zip

Yes, but it is a different sim, and I have no idea what the issue currently is - previously it was due to the WASM not starting, which looks to be due to the strange permissions issues you are having. Are these now solved after a re-install? Did you try renaming the Community folder as I suggested? I really cannot help you if you do not tell me what you are trying and at least answer my questions - I have no idea what you have done and what the current state is... Is the WASM now running? Is an FSUIPC_WASM.log file now generated? Do you still have the same permissions issues? I am still waiting for this information and to see a log file if available....if the WASM isn't running, then you need to determine why, and if it the permissions are still an issue.

You can start MSFS via steam or however you like. The default auto-start is via the EXE.xml file, although you can select to auto-start via the bat file. By default, the desktop icon(s) installed by the installer just show a splash crean and call steam to start MSFS. If you are using the EXE.xml auto-start and dont want to use the installed desktop icon to start MSFS, you can opt not to have this installed by unchecking the checkbox at the end of the installation process. John

The ! symbol is the logical not operator so !TRUE is FALSE, and !FALSE is TRUE (or, in RPN, TRUE! is FALSE, and FALSE! is TRUE. So the expression (L:someLvar, bool) ! (>L:someLvar, bool) flips/toggles the value of the lvar, i.e. changes it from TRUE to FALSE or from FALSE to TRUE. John Also explained here: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm

This issue is generally due to the axis of your device being defined as a digital on/off axis in the windows registry. See the following FAQ entry: That is specifically for Saitek devices but applies to all - just use the correct VID and PID numbers for your device,

Hi John, As I mentioned, I wouldn’t call myself a "coder," so I often rely on ChatGPT for help. But when I get stuck, I turn to the forum for deeper insights. Thanks to your hints and guidance, I now have a working script again. I really appreciate your help—thank you so much! Best regards, Isak Here is the working lua script: dev = com.open("COM6", 115200, 0) -- Open COM port with baud rate 115200 ipc.display("Lua script is running...", 3) function processInput() local datastring, length = com.read(dev, 256) if length then ipc.log("Raw data received: '" .. datastring .. "' [" .. length .. "]") if datastring:match("^NAV1SB") then local frequencyStr = datastring:match("NAV1SB%s*(%d+%.%d+)") -- Extracts the frequency if frequencyStr then ipc.log("Extracted frequency: " .. frequencyStr) -- Debug log local bcdValue = convertToBCD(frequencyStr) ipc.log("BCD Converted: " .. string.format("0x%X", bcdValue)) -- Debug log ipc.writeUD(0x311E, bcdValue) -- Send to FSUIPC ipc.display("NAV1 standby set: " .. frequencyStr, 3) ipc.log("NAV1 standby frequency set to BCD: " .. string.format("0x%X", bcdValue)) else ipc.log("Error: Failed to extract frequency!") end end end end -- Convert frequency to BCD (e.g., "113.45" → 0x1345) function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end while true do processInput() ipc.sleep(100) end

okay, found the issue, @Paul Henty program did not have time to start the service 🙂 wil clean up my code and fix the code to read it here

I've tried this here using the Key_Press_and_Hold control. It may not do what you're expecting. It doesn't repeat the key until you call the release command. So you don't get the action repeating. You can try it for yourself and see if it does what you're expecting... Just paste this into your code and call. sendKeyHoldToFS - holds the key for the specified HoldTime (in milliseconds) then releases it. sendKeyDownToFS - presses the key down but does not release it. snedKeyUpToFS - releases the key. private void sendKeyHoldToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); // Wait Thread.Sleep(HoldTime); // send the key up SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } private void sendKeyDownToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Press_and_Hold, (int)Key + ((int)Modifiers * 256)); } private void sendKeyUpToFS(Keys Key, SendModifierKeys Modifiers, int HoldTime) { // First make sure FSX has the focus SendControlToFS(FSUIPCControl.Key_focus_restore, 0); // Wait for focus change Thread.Sleep(150); // Send the key down SendControlToFS(FSUIPCControl.Key_Release, (int)Key + ((int)Modifiers * 256)); } Paul

I have added the LIVERY NAME simvar to offset 0x2480 (128 bytes) in the attached version if you would like to try it. This offset will only b populated in MSFS2024 and not in MSFS2020. John FSUIPC7.exe

It's not obviously clear from the SDK what the new (2024-native) livery structure should look like... But essentially liveries are now a child of the parent aircraft in 2024 VFS Child liveries don't have their own aircraft.cfg (and therefore no TITLE= line). Instead, they now have a livery.cfg that defines the parent aircraft (and engine-type relationship), with a [General] section where you can give a livery a name [Version] major = 1 minor = 0 [General] name="<Livery Name here>" So in 2024 native aircraft/liveries, TITLE returns the name of the parent aircraft only, and the new LIVERY NAME simvar exposes the name in [General] from the livery.cfg FS2020 aircraft and liveries that are "compatible" with 2024 (but are literal copy/pastes into the MS2024 community folder), still exhibit 2020 behaviour when it comes to TITLE, so aren't "problematic". But as developers slowly adopt the new 2024 livery packaging format, this will become more and more problematic to those of us who need livery info exposed. Thanks for the clarification around which SDK you're compiling against, and appreciate that FSUIPC serves both sims simultaneously at present. I'd have thought though, that any application that has historically relied upon livery detection would be interested in this feature potentially. As a VA we certainly have a requirement from an ACARS perspective, but appreciate this is probably the first your hearing of it. If this thread starts the ball rolling for others to chip in, awesome. If not, we'll have to potentially consider an in-house solution as you previously advised. TITLE has been around for donkey's years, has always served its purpose, and its frustrating that Asobo have decided to suddenly change this in 2024. Going forward, I for one certainly consider the new simvar as "core" as TITLE has always been. Thank you for engaging with this thread, and I'd ask (if possible) to keep this in the back of your minds when it comes to your wider development roadmap.

This one works, John! Matt

Sorry, I do see 16 now, I forgot that numbers start at 0. Thank you for your involvement, Ihave uninstalled one controller that is rarely used for the moment and solved the problem of two devices having the same GUID by re installing one of them.

Ok, I will leave it as is in the version I posted above.

Hello John, And to confirm above : "my traffic" on ND has also returned with fsuipc 7.5.x ! Thanks for the help. Have a good Christmas and a happy New Year, Regards, Marinus Bergsma.

There is no point adding that line again if its already there, and that is to dix a specific problem - to fix issues with 3rd-party programs that are expecting a value in that offset even when FSUIPC is not connected to the FS (i.e. basically for software not yet updated for MSFS2024). If you get any issues with a new release, you should always raise a new support topic. John

Sorry but can you please five your topics a more appropriate title... I will update it... 7.4.18 attached below - save and remove the .7418 extension... John FSUIPC7.exe.7418

Would have been helpful, can't replicate that: - Created a Simple Button Action (Control, 65798, no Toggle) on 0.7.12 - Installed 0.8.4 - Checked Action: Toggle still disabled So for the Moment I can just assume you had actually set a Toggle Switch unintentionally. And that a Setup of Toggle Switch enabled +no Alternate Command+ no Monitor Address + no Monitor Value/Comparison just behaved differently with a on pre-0.8.0 Versions 🤔

Hi John - thanks for the update and appreciate you spending the time looking at this.

Background PMDG Aircraft for FSX and P3D do not typically use the normal controls provided by the flight sim. This means that many of the aircraft's switches cannot be assigned to buttons and keys using the list of controls in the FSUIPC dropdown boxes. Assigning a standard control in FSUIPC will likely do nothing in the PMDG aircraft when the button or key is pressed. Solution Instead of using the standard list of controls shown in the FSUIPC dropdown box, users must use a different set of controls provided by PMDG for the specific aircraft. These are known as custom controls (or custom events). The custom controls vary for each aircraft and are listed in the SDK that is installed alongside the aircraft. This guide will show you, step-by-step: How to find the SDK files How to calculate the custom control numbers How to work out the parameter value How to assign the control to buttons/keys in FSUIPC The specific examples shown will be taken from the PMDG 737NGX, but the same method works for any PMDG aircraft with an SDK and custom controls (e.g. 777, 747). 1. Locating the SDK From your main Flight Sim install folder, or your MSFS Community folder, and open the PMDG aircraft folder Then select the folder belonging to the aircraft you want to use. e.g. PMDG 737 NG3 or pmdg-aircraft-737 Then select the SDK folder or Documentation\SDK folder for MSFS2020 Locate the file with the .h extension. For the 737 it's called PMDG_NG3_SDK.h (or maybe PMDG_NGX_SDK.h, depending on the sim and variant you are using) You can open this file with Notepad or your favourite text editor. As an example, the document you need for the 737 in MSFS2020 will be: [Community]\pmdg-aircraft-737\Documentation\SDK\PMDG_NG3_SDK.h 2. Calculating the control numbers 2.1. Find THIRD_PARTY_EVENT_ID_MIN The first thing to find is the definition of THIRD_PARTY_EVENT_ID_MIN. Search for the following text: #define THIRD_PARTY_EVENT_ID_MIN You will find a line like this (from the 737 file): #define THIRD_PARTY_EVENT_ID_MIN 0x00011000 // equals to 69632 Note the decimal value at the end. In the case above it's 69632. You will need this value to calculate the control number in the next step. 2.2. Find the control you want to use. Search for the control by name, or look through the listed controls to find the one you want. They are helpfully grouped together by panel. The controls are listed under a comment: // Control Events You can search for this to find where the list of control numbers starts. As an example we'll use the Autopilot CMD A swtich on the MCP. This is the relevant line in the 737 SDK: #define EVT_MCP_CMD_A_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 402) To calculate the control number for this switch we just add 402 to the value of THIRD_PARTY_EVENT_ID_MIN we found earlier. 69632 + 402 = 70034 We have now calculated the control number. We will use this in step 4 to program the button/key. 3. Finding the parameter value PMDG controls need a parameter value. These can one of type types: 3.1. Mouse Click Codes (Shown in the example) You can use these to simulate a mouse click on the particular switch. Mainly it will be the left mouse button, but other clicks types are available (e.g. Right button, left double click etc). To find the codes for each type of click, search for MOUSE_FLAG You'll find a block of #define statements for each type of mouse click. Here are a couple of examples from the 737 sdk: #define MOUSE_FLAG_RIGHTSINGLE 0x80000000 #define MOUSE_FLAG_LEFTSINGLE 0x20000000 Find the click that you want to simulate and get the code. For example, we'll have our key assignment simulate the left mouse button clicking on the CMD A autopilot button. So we'll need 0x20000000 as the parameter value for the control. 3.2. Direct Values (Not shown in the example) Alternatively, some controls can accept a direct value to set the switch to a specific position. To find the direct values you need to look at the top part of the .h file to find the switch definition. These are named differently than the events so you need to search. Taking the battery selector switch as an example, we find the control: #define EVT_OH_ELEC_BATTERY_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 1) For the parameter value we can find the same switch in the top part of the .h file: unsigned char ELEC_BatSelector; // 0: OFF 1: BAT 2: ON This tells us that in addition to mouse clicks, we can also send direct values. In this case: 0 for the OFF position, 1 for the BAT position and 2 for the ON position. It's possible to make a key or button set the Battery Selector directly to the ON position by setting the parameter value to 2 instead of a mouse click code. Simple ON/OFF switches will not have values listed (and will be declared as 'bool'). For these types of switches you can just pass the value 0 for OFF and 1 for ON. 4. Assigning the control to a button or key in FSUIPC Select the [buttons + swtiches] or [key presses] tab in FSUIPC and select the button or key to program. From the "control sent..." dropdown select <custom control> (it's near the top of the list) A popup window appears asking for the control number. Type in the control number you calculated in step 2. For our 'autopilot CMD A' example, we enter 70034 and click OK. The controls dropdown box will now show the control number in angled brackets. In the "parameter" box (below the controls dropdown), enter the parameter value from step 3. This can be a mouse click code or a direct value. Mouse Click Codes: Do not include the first 0 from the number listed in the PMDG SDK. Start with the x. With our example, we would enter x20000000 for the left-button single-click. Note that this code is in hexadecimal. FSUIPC will convert it to the equivalent decimal value. This is nothing to worry about. It's the same number. Entering the value in Hex is more convenient. Direct Values: Just enter the value as a number. Do not add the x at the start like mouse codes. If you're programming a key press, remember to press the [confirm] button. Here is our example control assigned to a button in FSUIPC: Your button or key press should now operate the switch in your PMDG aircraft.