John Dowson

To use one button for on & off, you would need to overload the assignments (i.e. have both of the assignments on one button) and add an offset condition to check the current state of the lights so that only one control is sent depending on the current state. This depends on the current state of the light being available in an offset. Offset 0x0D0C is the one normally used for this, and holds the state of the following lights: The runway lights seem to be the taxi lights, so bit 3 (and 2^3 = 8 or 08 so you would use that) of offset 0x0D0C will hold this information, so the offset condition for the lights on press would be W0D0C&08=0 and W0D0C&08!0 (or just W0D0C&08) for the lights off press. See page 24 of the Advanced user guide on how to add offset conditions. However, testing this again, it seems that both the switch up and switch down macros actually work as a toggle - did you try them? i.e. try just using the one button and that should switch on and off. As that is the case, you only need one macro entry really, and just use one button. You can rename the macros to make this clear, e.g. just use "Runway Lights" or "Beacon Lights" rather than having both Up and Down versions. This seems to be the case for all the light switches that have two positions, but not the ones that have three positions (Nose, Strobe, Nav & Logo, and landing lights - you cannot really control these with one button for 3 positions, so you will need two buttons for each of these (one to move the switch-up, and one to move it down. However, if you just want to use two positions for these 3-position switches, you can use one button with offset conditions. I can show you how to do this in more detail if needed. John

That is for mouse macros. Macros are also used for sending compound (i.e. multiple) commands, AND for using lvars. Please see the documentation that I referenced: Please translate/read that section to understand how to use macros to set/control lvars. I think that script was for the FSX version. It may work in P3D, but check that the lvars it is using exist, and check the script is actually running. If you have followed the installation instructions, the script will only start when the aircraft name is "F1_Cessna_Mustang1". The name is probably different in P3D, so you will need to change this in the ipc.ready script. Try logging offset 0x3D00 to see what name is reported when the aircraft is loaded, and use that name to update the ipc.reasdy script. Control number 65823 is Throttle4 Set so I do not understand that comment. To test if that control works, you don't need the lua scripts. Just assign to the FS control Throttle4 Set with a parameter of 32. If that doesn't work, then the script will not work either as that is all that does. If there is an lvar called ENGINE4_SET, then you could try setting that lvar to 32 using a macro file (NOT a mouse macro). But again, this seems to be for FSX and I am not sure it will work in the P3D version. Can you show me/attach a log file where you have listed the lvars so I can see what lvars are actually available for this aircraft. That would help. Also please attach your FSUIPC6.ini file. John

The Rotor Brake control is normally only used in helicopters. As it is not used in aircraft, some aircraft developers use this for their custom controls, with the parameter indicating the function. No, sorry. There is a FAQ entry on how this is used in PMDG aircraft here: However, that is NOT applicable to the FSLabs,, and FSLabs don't provide an SDK as PMDG provide, Basically I found these using FSUIPC's logging facilities, which you can use in many (not all!) cases to determine how to control a switch. I showed how I found these in that previous post I referenced, so take a look at that, However, things are a lot more complicated in MSFS2020/2024. Every aircraft seems to use different methods - some custom controls (via Rotor Brake or other means), some Input Events, sometimes Lvars/Hvars/Bvars. These things are very dependent on the aircraft developers. With FSUIPC, I try to provide access to these different methods, and can advise on how to look into the different methods of how to assign a particular button using the features I provide. For most aircraft, presets tend to be the easiest way, and the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/), which is a community-driven effort led by MobiFlight) would be the starting point. However, there seems to be nothing there at the moment for the FSLabs aircraft. As the FSLabs seem to use custom controls via the Rotor Brake control, you can use FSUIPC's logging facilities to determine what is needed to control any particular switch. Set logging for Events (Log->Events), open the logging console (Log->Open Console), and then see what is logged when you flip the switch in the Virtual Cockpit using the mouse. Then either assign to that (if one event is logged), or create a macro entry if multiple events are logged. Thats the basics, but it can get more complicated. John

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

The font you used for that message looked ok... Sorry, but I have no idea why cutting and pasting from your translator program doesn't work. When you paste, you should see a black box below the text entry panel asking to paste in text original format (or rich text) or plain text. Just click plain text after pasting and that usually works.

Presumably you use the lvar BKSQ_IgnitionPosition_1 to move the position of the switch, no? Does this have any actual affect on the starter, besides moving the magneto rotary? I am not that familiar with such complex gauge calc code, but it looks like you also need to set the starterKnobReturnTime_L lvar when you do this. You can set both lvars using a calculator code preset. The rest of the code is setting O-type (component) variables which I am not familiar with. Are any other (standard) events or input events logged (in FSUIPC log / console) when you move the starter in the VC? If its just a matter of holding the magneto rotary in one position for a certain amount of time before changing the position back, you could do this by writing a macro or lua script. But its probably more complicated than that. You could try asking the community if its possible to create a preset to replicate that code. The best place for this type of question would be on the MF Discord server, in the MSFS2024 channel. Sorry but I don't have this aircraft so cannot really look into this in more detail. John

The FSLabs uses custom controls via the Rotor Brake control for the lights - you can see this if you set logging for Events, open the logging console and flip the switches in the VC. I provided information on how to set-up the lights in this thread: You can use the attached macro file which has macros for the Nose, Strobe and Beacon lights: FSLA321.mcro For any other lights/switches, try logging the event(s) used and either assign directly (if only one event) or add another macro to that file to send multiple events. John

Nothing was working before you installed that (was it?), so you mustbe using the old USB-type model and so that is needed. That is not really an issue, as the menu entry would only display the PFC driver version number anyway. Not sure why that is no longer added though. This menu entry used to go on the P3D/FSX add-ons menu, and it may not have been updated to go to the FSUIPC7 add-ons menu. That is not really an error - you add this file to override the default assignments. You need to read the documentation that comes with the driver - the PFChidDLL User Guide and take a look at the PFCmacroIndex csv file If things are not working correctly with the default assignments, you can create macros (in the PFC.mcro file) to override the default assignments. You can use logging in FSUIPC7 as well as in the PFC driver (as well as the PFCmacroIndex file) to determine what macro can be used for each switch (and maybe axis, but I am not sure). Many aircraft in MSFS2020/MSFS2024 do not respond to the standard FS controls which will be the ones used by the default assignments. They can use things like lvars, hvars, input events or custom controls instead of the default FS controls, and can be specific to the aircraft being used. For these, you will need to determine how they work and override them by providing a macro entry. For the trim, you can use FSUIPC/PFC logging to see what is being sent, and can also override the default assignments with your own macro. You can also maybe see if there are any other PFC users with the same console in the FSUIPC7 sub-forum and maybe ask them (either via a message or tag them in an existing post). Your log file does show a few issues: 1. There were a few reconnection attempts (and one looks forced for some reason). You should tune the start-up parameters (or let FSUIPC auto-tune these). See the Advanced User guide and/or the FAQ entry (in the FAQ section of these forums) on this 2. The WebSocketServer is being started - disable this unless you are using it. 3. You have not installed the FSUIPC WASM module. This is not a problem, but you need this if you want to use lvars, hvars, or presets (which are useful for pretty much all aircraft), Install this unless you really have no need/intention of using these. Sorry, but other than that I can't really help any further with PFC products. I don't have any and have never used them myself. The driver is pretty old now (way before my time!) and is provided as-is and is not really supported any more (by me!). You can also try PFC support. Good luck! John

Profile matching can either be done on Title (simvar) or the folder name of the aircraft directory (aircraft.cfg location), the latter by using/setting the UseAirLocForProfiles ini parameter, but not both. It doesn't make sense using both for profile matching, as the name (aircraft title or folder name) is automatically saved and will only match one. However, yes, I can check both to determine if the loaded aircraft is a PMDG aircraft to start the PMDG-specific threads to load/update the PMDG offset area - thats a good idea. Yes, sorry - I should have known that from what you have already said! Could you please try the attached version with MSFS2024 and show me the log file afterwards so I can check to see if the PMDG threads have been started? This version also checks for the string 'pmdg' in the aircraft folder name to determine if the PMDG threads should be started. John FSUIPC7.exe

I have moved your post to the FSUIPC7 support sub-forum, Please use this forum for all questions/issues with FSUIPC7 and MSFS2020/MSFS2024. For newer PFC HID devices, you do not need any additional software. You should be able to assign directly using FSUIPC's assignment panels. However, I think the PFC Cirrus II Pro is a non-Joystick type of HID device. If so you'd need to install the PFChid64.dll. You will not see the PFC menu in the Add-ons menu until FSUIPC7 is connected to MSFS and you may even need an aircraft loaded and ready-to-fly. The log file you attached shows that MSFS wasn't even running. See this thread/comment and later:

Ok, that makes sense. However, this still presents a problem... As the title of the aircraft doesn't contain 'PMDG', the additional offsets available for PMDG aircraft (provided by the PMDG SDK) will not be populated/available. I will need to update FSUIPC to handle this. Do you also use MSFS2020? If so, is the title in MSFS2020 the same?

I currently only have the 777-300er, which is only compatible with MSFS2020 at the moment. I will see if I can get hold of the 777-200er. John

Ah, its the 777-200er...I do have this for MSFS2020. Saw this was now missing for OC2 and so have installed OC3, but I can't see how to install the 777 in MSFS2024.., I will try and get this installed and take a look...

Why is this an issue? Surly the PMDG B772er has a title - and will contain 772 and not 777. Did you add the title of the aircraft to your profile? i.e. when the aircraft is loaded, go into one of the assignment panels and click the 'profile specific' checkbox and then select your PMDG profile. You should then look at the name/title added and shorten that to a substring. However, as the livery name is separate from the title, this may not now be necessary. FSUIPC does not read the aircraft.cfg file for the title, or livery name - it uses the simvars, which were populated from the aircraft.cfg file. If this information is no longer available in the aircraft.cfg file, it must be available somewhere and it will be MSFS that gets this information to make available in the simvars. Are you saying that there is no title now for this aircraft? Could you please show me / attach your FSUIPC7.log and FSUIPC7.ini files, generated after a flight using the PMDG in MSFS2024 and I will take a look. John P.S. Is the SDK (header file) for the PMDG B772er for MSFS2024 the same as the one for the PMDG 737 for MSFS2020? Do you use the specific PMDG offsets? Maybe you could attach the header file for me and I will take a look, Not needed

You have NO aircraft name strings in your profile: How do you expect that to work? I suggested to use this: I also explained how this works: And explained what to check if a profile isn't loaded: Why is this not clear? Sorry but I don't know how else to explain this.... John

No problem.

@GiankMustang Please DO NOT ask for support via DM/PM or email. Always use the support forum. I will ignore any future messages sent via DM/PM. This was your message: First this: No!. "List local panel vars" shows local panel variables, or lvars, NOT lua scripts. This cannot be correct. Lvars are NOT listed under [LuaFiles]. That section only shows lua scripts in your installation folder. Again, they are not 'lua macros'. Lua scripts (NOT macros) are files ending in .lua, macros are files ending in .mcro, and lvars are internal variables (local) to the aircraft. the easiest way to use lvars is to write a macro - see the section 'Gauge local variable access (L:vars)' on page 39 of the Advanced User guide on how to use lvars in macro files. Once you have created a macro to control the lvar, you can then assign to a button or key press. John

That should be the default. i.e. no need to set this. You are not using substrings...change that section to: Then any aircraft whose title matches the substring 'PMDG 737-800' will use that profile. That is how substring matching works. Any time you add an aircraft to a profile, or create a new profile for an aircraft, you should edit the aircraft name in the [Profile.xxx] section to be the shortest substring that matches all aircraft you want to capture/use in that profile. If a profile isn't loaded for a particular aircraft and you think it should, check the title of the aircraft (as logged in the FSUIPC7.log file) and make sure it is captured by an entry/substring match to the names used in the profile section. No idea what this means. SLC should not prevent FSUIPC from working, although SLC itself may not work if not configured correctly. John

Well, no issues installing them and running them individually. However, if P3D is running with FSUIPC6, you cannot then run FSUIPC7 for MSFS, i.e. only one copy of FSUIPC can be active/running at any given point. WideFS7 works with all versions of FSUIPC from 4 onwards. That is old and needs updating. Yes, but WideFS talks to FSUIPC, not the FS. WideFS7 works with FSUIPC6 for P3D versions 4,5 & 6, FSUIPC4 for FSX, and FSUIPC7 for MSFS2020 and MSFS2024. Only one license is required. You can have a single installation to support both FSUIPC6/P3D and FSUIPC7/MSFS2020/2024, or you can have separate installations. It is up to you. You can try the trial license for FSUIPC7, available in a post at the top of this forum. This also contains a trial license for WideFS7. Regards, John

According to the MSFS documentation: But I have tried this here and also don't seen any bmp file. As this is a control provided by the SDK, there is not much I can do about this except report to Asobo. John

This is nothing to do with FSUIPC7 - please use the Asobo forums for all issues with MSFS, including CTDs. Your log file shows that FSUIPC7 was functiong normally and exited as MSFS was no longer available (as it had crashed). Please also use the FSUIPC7 sub-forum for any questions/issues with FSUIPC7 / MSFS, not the main support forum. I will move your post. John.

Ok, that is interesting. You can remove that option from the MSFS24.bat file. Thanks for the update. John

The log file you attached shows that it was attached while FSUIPC7 was still running (always exit FSUIPC before attaching files), and shows that FSUIPC could not connect the the FS, and ends after 104 seconds. It also shows that auto-tuning was active, but I don't know if this completed as you need to keep FSUIPC running until MSFS arrives at the main menu, and FSUIPC7 must obtain a connection to the FS to be able to tune. You should try manually tuning the start-up parameters - see the Advanced User guide, or the following FAQ entry: You need to increase the DetectToConnectDelayAuto ini parameter, and maybe the InitialStallTime ini parameter. Also, try exiting FSUIPC7 once it is auto-started, and then start in manually once MSFS arrives at the main menu. does it then connect or do you still have issues?

You can also ask the developer of this plugin for help here: https://flightsim.to/file/39243/pmco-fnx32x-pilot-monitoring-callouts-for-the-fenix-a320-add-on John

What version of FSUIPC7 were you using before the update? If it was before 7.5.0, it may be due to the FS version number held in offset 0x3308, which is now only populated once FSUIPC7 is connected to the FS. To pre-populate this, you can add init3308=13 to the [General] section of your FSUIPC7.ini file. Note 13 is for MSFS2020 - use 14 for MSFS2024. Otherwise, please attach your FSUIPC7.log file so I can check for any errors / start-up issues. John