John Dowson

For nose wheel steering in the PMDG 737, you need to use the Rotor Brake control with a parameter of 32501, according to the MF HubHob preset list site (https://hubhop.mobiflight.com/presets/). However, I am not sure how this works as there is no way to give an additional parameter for the amount/direction. Maybe try that control or MF preset to see what affect it has. Note there is also a preset / rotor brake control for the nose wheel steering guard. If the presets don't work as expected, you can ask about them on the MobiFlight discord channel. John

No, sorry - there is no way to control the MSFS profiles externally as far as I am aware. It should be MSFS that loads the correct profile for each aircraft loaded - maybe try raising this as a new feature request via the Asobo forums. John

It would be useful to me if you could try without that for a while, just to see if that is causing issue, as that is currently the default setting, but not essential... Thanks, John

First, the WASM will always load as that is started with MSFS. What is probably happening is that FSUIPC7 is connecting to the WASM but it is not receiving the config data for some reason. However, I will need to see your log files to diagnose. Could you please activate Debug level logging in the WAPI - to do this, add the line: LogLevel=Debug to the [WAPI] section of your FSUIPC7.ini file. Then, the nect time this happens, please show me your FSUIPC7.log file. Also, rather than restarting the sim, you could try either 1, reloading the WASM data, using the Add-ons->WASM->Reload menu option, if available or 2. Disconnecting and reconnecting FSUIPC7 from the sim, using the MSFS menu options Either (or both) of those options should work, and be a lot quicker than reloading the sim. I also experienced this occasionally with earlier versions of FSUIPC but thought I had fixed this occasional issue, so make sure you are also using the latest version, v7.3.6 John

Ok, then that is an aircraft that i don't have, and doesn't seem to be listed om the MF HubHob site. All I can advise it to see if anything is logged when you activate via the UI (make sure event logging is activated in FSUIPC, and open the logging console), or try listing lvars to see if anything looks relevant and if so try changing the lvar value to see if that works.

The first thing you need to determine is what to read to hold the current panel lights setting/value. I don't think there is a standard simvar (or FSUIPC offset) for this - just a flag to indicate if on or off. Try listing lvars to see if there is an lvar that holds this value - if there is, and it is writeable/settable, then you can add that lvar to an fsuipc offset and simply use the offset increment/decrement controls - no need for lua. What aircraft are you using? I could take a look, but it may take me a day or two - just back from holiday so it will take me a few days to get through the backlog of support requests. If you can let me know which aircraft you are using I can take a look and advice further. John

I'm on holiday now until next Thursday - I will take a look then.... John

This is support for FSUIPC. We do not support Xplane - that is XPUIPC from a different developer. John

You should try the standard controls first - there should also be a document that lists the available controls... Also, if you are not sure to which control to assign, the standard procedure is to activate Event (non-axis controls) logging, activate whatever you are trying to assign via the cockpit UI, see what event/control is logged in the FSUIPC log file and then assign to that. I've not seen that document before...I've no idea what the 'FSUIPC Export module' is that it refers to. Way before my time I'm afraid... John

@PSantos Please try and add your comments outside of the quoted text. It makes your post difficult to read when everything is quoted (even though you have underlined the text quoted in the quoted text box...).

I really can't help with the wiring - you need to sort that out yourself. And please attach your FSUIPC log and ini files, not screenshots. However, that screenshot does show something strange is going on. First a button 1 press and release was sent, but you have no assignments to the press, just the release, so that was sent. This was then repeated. Then button 0 was pressed, and you have an assignment to this which was sent, then a release received with no assignment. Why do you have an assignment to button 1 release and button 0 press? As I said, just assign to the press for both buttons and no assignment on release. Any further issues please attach your log and ini files. I have just noticed that you posted this in the FAQ section, where it explicitly states NOT for support requests. I will move this topic to the main support forum. Also please note that I am now on holiday, back on the 9th. John

I have discussed this with SimMarket. It seems that when a bundle is purchased, this is registered in your SimMarket account as a WideFS7 purchase, but with FSUIPC4 bundled. As there is no specific FSUIPC4 purchase, there will be no discount available. There is nothing I can do about this. I have asked SimMarket to update the discount text to mention that the discount is not available if FSUIPC4 was purchased in a bundle. Sorry about that. John

ok. Maybe activate logging for Buttons & Keys as well as Events, open the logging condole (Log -> Open Console...) and see what is logged when you press the buttons. This should help you understand what is occurring and how you should assign. Maybe also check that it is not assigned in MSFS as well.

That is a possibility...but you should still be able to get it to work - you just need to understand when/if it is sending the releases. If its sending the release straight after the press, or not at all (but that would be strange...) then you can assign to the press of buttons 0 and 1 instead and not assign to the button release.

Check your FSUIPC7.log file - if FSUIPC7 is exiting as it thinks MSFS is no longer running then you need to add DisableMSFSMonitor=Enum to the [General] section of your FSUIPC7.ini file. This is a common problem on Windows 11 systems and is documented in the README.txt file. John

Where is this in the G68? Have you tried activating it and seeing if an event is logged? For the G58, there are the standard Pitot Heat controls (for de-ice), as well as the presets G58 PROP DEICE ON and G58 PROP DEICE OFF controls.

Some switches work that way, i.e. with separate buttons for each position. If the switch just has two buttons, and when you switch a release is sent for one of the buttons and a press for the other, you don't need to assign anything to button#1 as the parking brake will be turned on by the button#0 release. Alternatively, you could remove the assignment to the button#0 release and assign that to the button#1 press instead.

As it looks like it is not getting AI data from FSUIPC anyway, there is nothing I can do. Even if it was getting AI data from FSUIPC, there is nothing I can do at the moment as there is currently no way to get multiplayer/group aircraft data via SimConnect. I still think your best bet is to use something like JoinFS or similar. If that (or a similar program) is still buggy and/or under development, they will hopefully get around to fixing those issues at some point - if these issues are being reported...!

How does AivlaSoft's EFB2 get its traffic information? knowing that would help.... FSUIPC's traffic tables just show the AI traffic as received from the FS and there is no way to receive multiplayer/group traffic, unless they have also been injected as AI traffic... John

You should always use letters to prevent possible issues when the joy ids change, that is why this is now mandatory. I will update the documentation, as I said. Thanks, John

@kingm56Sorry for the late reply - missed your post for some reason... I am not sure what you mean.... offset 0x3110 is a general facility for sending events/controls to the FS. You can't read them as there is nothing to read - you write to them to send any control to the FS, including PMDG custom events, which I believe use the Rotor Brake control (with the parameter indicating the actual control/event to be used) in the MSFS version. Why do you think that you cannot send these PMDG events using this offset? They are the same as any other event... John

No - you should not run the sim as admin, or FSUIPC7, unless you have a need to do so. All programs communicating to MSFS should be ran at the same priority level, so if you are running MSFS without admin privileges, make sure FSUIPC7 is also ran without admin privileges. Ither than that, I have nothing more to say on this issue that I haven't already said (many times...!_...please see the following posts: Read those posts and check your EXE.xml. If that file is in the correct format and in the correct location then I have no idea why MSFS is not starting FSUIPC7. You can go back to the older method of having the MSFS.bat file start FSUIPC7 - details on how to do this are in those posts I referenced. I will create a FAQ topic on this issue and put all relevant information there....when I get time! John

I don't think it is possible to get information via simconnect on any other aircraft apart from the users' aircraft and AI aircraft at the moment. However, if the multiplayer aircraft are injected into MSFS as AI aircraft they can be seen. I believe some programs such as JoinFS do this. See the following thread: https://forums.flightsimulator.com/t/vatsim-ivao-lnm-etc-all-need-their-simconnect-injected-aircraft-to-show-labels/362824/73 John

I've checked this and it is not possible. I will enquire about this with SimMarket. John

Maybe also worth checking the MSFS assistance options - maybe the copilot is setting this...