John Dowson

👍

It is not obsolete - the Rotor Brake controls still function as explained in this post, but the Rotor Brake control has now been deprecated, which means they you should move away from using this as it may be removed in a future update, although I doubt very much that this will actually happen. For clarity, instead of using the Rotor Brake control, you should now use the provided custom controls, which work in the same way as they did in P3D. Note that these are also more powerful, as they can be used with proper parameters as well as mouse codes (where appropriate). I will therefore keep this topic, but will now lock it. John

👍 Thanks for checking, John

Ok thanks - when I get it I will update the downloadable zips, but there will be no version change. Not sure, but its in the latest installer and attached here. It hasn't change for a while now. John Offset Mapping for PMDG 737-700.pdf

I have just released 7.3.12 which contains a fix for using custom controls - available from the usual places. Note that FSUIPC7, the WASM and the WAPI have also all been updated to VS2022 and the latest platform toolset. If you are using the WAPI then please update your application. John

I have just released 7.3.12 which contains a fix for using custom controls - available from the usual places. Note that FSUIPC7, the WASM and the WAPI have also all been updated to VS2022 and the latest platform toolset. If you are using the WAPI then please update your application. @Paul HentyWill the websocketserver need an update for this?

There's a trial license available in a sticky post at the top of this forum if you would like to try the full version first. I've looked into this further and it seems that the way the MSFS SDK handles custom controls has changed, and I suspect this is since the SU10 update. Currently it is not possible to send these custom controls, but I will update FSUIPC7 to handle this and post a new version. You can use the Rotor Brake control, but you can only send mouse operations to buttons/switches/rotaries/etc using this method, and not other parameters (such as heading). Not sure why the PMDG SDK doesn't mention this - maybe because the Rotor Brake control is deprecated now in the MSFS SDK.

I've looked into this further and it seems that the way the MSFS SDK handles custom controls has changed, and I suspect this is since the SU10 update. Currently it is not possible to send these custom controls, but I will update the code to handle this and post a new version. It looks like you can still use the Rotor Brake control, but you can only send mouse operations to buttons/switches/rotaries/etc using this method, and not other parameters (such as heading). Not sure why the PMDG SDK doesn't mention this - maybe because the Rotor Brake control is deprecated now in the MSFS SDK, so you should move away from using this and use the custom controls instead. I'll try and get a new version out in the next few days. John

How strange.... But it seems to have resolved itself....still no idea what caused this though, very puzzling... Anyway, glad is all now working - thats now one weird issue of my list! Regards, John

So that would be this one (from the SDK header): #define EVT_MCP_HDG_SET (THIRD_PARTY_EVENT_ID_MIN + 14504) // Sets new heading, commands the shortest turn Neither do I... There should be no changes between FSUIPC6 and FSUIPC7 when using custom controls, if supported by the aircraft, but maybe MSFS handles these differently to FSX/P3D. I will check this and report back (will be tomorrow now though at the earliest). Cheers, John

I am going to remove this option, due to difficulties confirming whether MSFS actually has the focus or not. I will still allow negative values (for backwards compatibility) but they will be treated the same as positive values.

This is not correct - all 3 axis were recognised, but the order was R, then U, then V - and according to your assignments, these are assigned to elevator (R), rudder (U) and aileron (V) - so that must have been the order you rotated them in: Not that important, just wanted the order so that I know what to look for...Maybe better to refer to the axis by its letter rather than the assignment (or both!) so we don't get confused...! Ok, so they are working and recognised in FSUIPC7....can you go back and try again in FSUIPC6 please. No need to attach logs, just see if the axes are recognised and if you see any movement... it gets even more puzzling if they are recognised in FSUIPC7 but not in FSUIPC6 as the code for device handling is the same. if this is the case, then there must be something else going on when you run FSUIPC6/P3D... John

Can you confirm that you did not see the device number and axis letter recognised in the assignments box when you did this test (i.e. they stayed blank), and that the in/out numbers didn't change? Your latest log shows the rudder trim axis (U) went from 0 -> 65535 -> 0, the aileron trim axis (V) the same, but no movement at all on the elevator trim (R). I would have expected the first two to have been recognised.... John P.S. Will keep using FSUIPC7 to investigate this, so you can reset your system back to its original state so that you can continue to use it, and any tests for this issue will no longer interfere with that system. You can also try assigning the trim axis/pots with SPAD.next...if you do, let me know how that goes, especially with the elevator trim...

Your installation now looks fine. Note that your ACARS program will not connect until you have an aircraft loaded and ready-to-fly - it will not connect when MSFS is still in the main menu system. You can check your FSUIPC7.log file to see if any errors are reported, but you probably need support from the ACARS client provider(s) if the client isn't connecting. You can also try searching this forum as such issues have been reported many times. John

👍

I've just looked into this a bit further...it is not possible to restore this functionality completely, due to the change from an embedded process to a separate application. When using a non-negative number (i.e. 0-100), a windows flag is set when instructing windows to play the sound with "Global Focus", and this is not set when a negative number is used, and so it is windows itself that controls whether you hear the sound or not, but the sound file is played regardless. What this means if that if you play a sound using a negative number, the sound file is still played and if you change the focus to/from the FS then the sound will be played/muted as you change the focus. Now that FSUIPC7 is a separate application, this is no longer possible. However, I could add a check on the existing focus, and if a negative number is used and the FS (or FSUIPC) does not have the focus, then I can just not play the sound file. The result would be similar but not identical, as it would be FSUIPC7 not playing the sound file, rather than windows playing the file and muting when the requested application does not have the focus. Do you think this is still useful and worth implementing, or should I just remove this option?

At the moment, yes - but really its a bug, a hangover from FSUIPC6 which is an embedded dll, so the FS has the focus when FSUIPC has the focus. I will take a look at this an either restore the correct functionality (i.e. only play the sound if the FS has the focus) or remove this option - I don't think it worth keeping if it only plays when FSUIPC7 has the focus. John

That is playing with a volume of 100 on sound device 0 - but only when the FS has the focus. I haven't checked this (i.e. using negative numbers)....maybe it only plays when FSUIPC7 has the focus? Can you check this? And does it work with sound.play("paxsign.wav",0,100) ?

If you had checked your log file, you would have seen this: 47 *** FSUIPC WASM module not detected - not adding WASM menu This is because the installer has detected that you are using a Steam installation, and has installed the WASM here: Installing FSUIPC7 WASM module in C:\Users\Adam Poincon\AppData\Roaming\Microsoft Flight Simulator\Packages\Community\. But FSUIPC7 is detecting an MS Store installation, and is checking for the WASM under C:\Users\Adam Poincon\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Community Are you using a Steam or an MS Store installation? Why do you have a UserCfg.opt file in two locations: Steam: C:\Users\Adam Poincon\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt MS Store: C:\Users\Adam Poincon\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt ? Have you switched from Steam to MS Store (or vica versa)? If you have switched from Steam to MS Store, you should uninstall FSUIPC7 completely by running the uninstaller (or from the windows app management panel). Then remove/delete or rename the following file: C:\Users\Adam Poincon\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt (although I suspect this file is no longer present, which is why FSUIPC7 thinks you have an MS Store installation) Then re-install FSUIPC7 and try again. John

Yes. And the latest log shows you now have those offsets being monitored: That is the log of the initial state of the offsets, which shows them empty, which is normal. However, there are no other log entries, which indicate that no PMDG client data is being received. For comparison, this is what I see: i.e. the offsets being updated when the data is received from the aircraft. So, I am pretty syre that you have not enabled data broadcasts in the aircraft. I see you tried with the 737-800 - can you try the 737-700 and use thar instead as I don't have the 800 (although they should be near-enough the same). I don't think those paths are correct....as with your UserCfg.opt file, they should be under your user AppData folder - this doesn't change with your MSFS installation. Try activating data broadcasts in the following locations: C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\Packages\pmdg-aircraft-737\work\737_Options.ini C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\Packages\pmdg-aircraft-738\work\738_Options.ini AND check the name of your 738_Options.ini file - previously you posted two 737_Options.ini files and no 738_Options.ini file - is it badly named? If so, the broadcasts will not be enabled. So, in summary, your issue is with data broadcasts in the PMDG aircraft still not being enabled. That is a mobiflight error - I cannot support MobiFlight, you need MobiFligjy support. There should be no difference in behavior with FSUIPC if you start FSUIPC manually or if it is auto-started with MSFS. John

Hi Jason, your files show that you are using an unregistered version, so I presume you are sending these events by writing the control numbers to offsets, using MobiFlight or some other software. The controls you are trying to send have control numbers 70166, 70167, 70168, 70172, 70173 and 70174 - all with a parameter of 536870912 what are these controls? If they are custom control numbers, as used with the P3D version, then you need to change these to use the Rotor Brake control instead (control number 66587), with an appropriate parameter. See the link I posted earlier on how to calculate the parameter for the Rotor Brake control for control of the PMDG 737 in MSFS. Alternatively, you can use Event logging to log the event (usually Rotor Brake) and parameter used when the switch/rotary/button is operated in the VC, and then use that. John

No, sorry - you have to store the ref and use that to stop sounds playing. Even killing the lua will not stop the sounds playing... John

Ok, thanks, Then the batteries are always on - that should be ok... I think the next step is to compare the PFCcom64.log files generated for the Fenix with one for another aircraft where the avionics are working. As well as logging for Log all decoded received data checked, can you also check Log COM data sent. Comparing the two files should show any differences between the data being received and what is being sent to trigger the Avionics to come on.

That is the location (well, the Packages folder at that location) shown in the latest log file: Your UserCfg.opt file is still under C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\ - this does not change, regardless of the installation location. Did you correct them? Are they in the correct location? If you activate event logging, you will see the events logged. However, I do not see those in the log file you posted, and event logging is also not activated in the ini you posted. However, your ini file shows that monitoring is activated for those offsets, but there is no logging on the file - are you sure that they are from the same folder/run? I cannot see how those cannot be logged when requested - do you see those offsets logged in the console window (shown in your screenshot)?

It is a stand-alone application and not a full installer, so no documentation. FSUIPC7 sits in your system tray when running - you can access the main window from there. Once the main window is open, you can access the functions through the menus. John