John Dowson

But @C.Schaffhausen said he re-assigned his buttons using the custom controls for the B777. not the presets for the B737, which will be using the custom controls (for the B737). It is the axes configuration that is the same, not the buttons. Presets for the PMDG aircraft are just an easier way of using the custom controls. As nobody has yet added presets for these to HubHob, you need to use the custom controls. I posted a link above on how to use these. John

That sounds very strange...What are you using? For the G1000, there are presets for the heading bug for both the PFD and MFD: Have you tried those?

License sent. @dimafly, @DogAgent & @Dami3n83 - there are only a few days left on the trial license I sent you. If you require more time, reply to the DM I sent and I will send you a new one, once the current one expires.

What axis controls did you try? The best way to see what controls are being used is to use FSUIPC's logging facilities. Activate logging for Axes Controls (Log -> Axes Controls), open the logging console window (Log -> Open Console) and move the axis in the VC. If any standard controls are being logged, then try using them. If nothing is logged, and Input Events are available, try logging Input Events (Log -> Input Events) and again move the axis in the VC. Other than that, as I don't have the 777 (at the moment) I cannot really advise on how to set this up. There will be no update of FSUIPC7 for the PMDG 777 to get the axes controls working - the current facilities provided by FSUIPC should be sufficient. I will update FSUIPC7 for the 777 to add the PMDG 777 specific offsets, if these are available. I have asked PMDG about this and for details on the SDK, but have yet to receive any information. John

Ok - my response was a bit late! Sorry about that - I don't check Paul's forum often. If its not a specific question on Paul's dll, better to also tag me in the question and I also be notified. Cheers, John

For PMDG aircraft, maybe also check the specific PMDG offsets. For example, the MCP Altitude is held in offset 0x65CE, and there are various offsets for the FMC cruise/landing/transition altitudes. Also some air display altitudes are available (AIR_DisplayFltAlt and AIR_DisplayLandAlt) as strings. But I have just checked the indicated altitude in offset 0x03324 (and 0x0590 - indicated altitude calibrated) via FSUIPC logging (as suggested by Paul) and those offsets do seem to be working in the PMDG 737 and hold the correct value. John

Strange its the PropPitch1 calibration and not the Throttle1 calibration...although I seem to remember the prop pitch was linked to the throttle somehow in the TBM... Be aware that the default calibration section will apply to ALL aircraft that do not have a profile-specific calibration set. Generally it is better to have a profile-specific calibration section for each aircraft, but if you have set-up a general calibration section and this gives issues with an aircraft, then create a profile-specific calibration section for that aircraft and then reset the calibration. Alternatively, once the profile-specific calibration section has been created, you can delete all the entries in the section (best done when FSUIPC7 is not running). The TBM throttle is quite strange in the way it operates. It was working in earlier releases but then the throttle animation stopped working for some reason in early 2022. I have just checked again and now there are some Input Events that can possibly be used to control the throttle: ENGINE_Throttle<;FLOAT64>=100.000000 ENGINE_Throttle_Feathering<;FLOAT64>=0.000000 ENGINE_TOGA_1<;FLOAT64>=0.000000 ENGINE_Starter_1<>=1.000000 ENGINE_Ignition_1<;FLOAT64>=0.000000 FUEL_Manual_Override<>=52.684355 However, the ENGINE_Throttle Input Event moves the throttle, but only between TAXI (parameter 0) and Full throttle (any non-zero value) when Manual Override is off (or below 50). When Manual Override is > 50, setting any non-zero value to ENGINE_Throttle moves the throttle across to the feather position. The ENGINE_Throttle_Feathering Input Event doesn't seem to do anything when Manual Override is < 50, and at >=50 it moves the throttle across to feather and fully down when set to 1, and back across to the power range, at its previous position, when set to 0. In summary, it is still not possible to assign the throttle for the TBM930 in FSUIPC if you want the visuals working, and I am not sure how you would assign a regular joystick or throttle axis in MSFS to control the throttle through its power AND feather/toga range. You can control the manual override lever using the FUEL_Manual_Override input event (values 0-100). I think I also need to read up on the TBM930 to see how the throttle/manual override are working together,,, John

👍

Yes, strange. I think this is a windows issue, where it is occasionally returning a null/zero size/position when asked for the window coordinates. Anyway, I have added a check to both FSUIPC6 and FSUIPC7 to not write the ConsoleWindow entry if the size (width and height) is below a certain value. But this is a very occasional issue I think. A more common issue is having the window positioned off-screen, which can also happen, and the fix is the same - remove the ConsoleWindow entry.

You should be able to use the PMDG custom controls for the PMDG 777 in the same way as for the PMDG 737. See the following FAQ entry on this subject: The PMDG-specific offsets for the 777 are not yet available (they are for the 737). I will enable these at some point (i.e. if/when PMDG provide me with the relevant information or a license to investigate this). John

For preset requests, you should use the MobiFlight discord server (MSFS2020 channel). It is MobiFlight that are leading the community-driven effort to discover presets and make them available via their HubHop site. But what aircraft are you talking about? The title says 'msfs 777' - there is no Asobo/MSFS 777 as far as I am aware. If you mean the new PMDG 777, then you should be able to use the custom controls as you can in the 737. See the following FAQ entry:

Yes - thats why its a good idea to use logging to see what is actually being used. Especially for helicopters - although the specific helicopter controls were added quite late so quite a few of the older ones don't use these, but I would expect newer models to use the these helicopter-specific controls: AXIS_CYCLIC_LATERAL_SET -> calibrate as Aileron AXIS_CYCLIC_LONGITUDINAL_SET -> calibrate as Elevator AXIS_COLLECTIVE_SET -> calibrate as Prop-pitch AXIS_HELICOPTER_THROTTLE_SET -> calibrate as Throttle HELICOPTER_THROTTLE_SET -> calibrate as Throttle AXIS_HELICOPTER_THROTTLE1_SET -> calibrate as Throttle1 HELICOPTER_THROTTLE1_SET -> calibrate as Throttle1 AXIS_HELICOPTER_THROTTLE2_SET -> calibrate as Throttle2 HELICOPTER_THROTTLE2_SET -> calibrate as Throttle2 John

Sure - license sent.

👍

License sent. Auto-save is still a bit flaky - some people seem to be able to use it quite well while others have issues. Seems to be aircraft dependent, and probably because the aircraft developers have not fully implemented the save state for the panels. I have been meaning to compile a list of aircraft where the auto-save is known to work or not, but still haven't gotten around to this. Try it anyway and let me know how you get on. License sent. John

@Fragtality You can trigger Input Events via offset 0x7C50. It is not possible to trigger B-events via calculator code. You need to use the equivalent Input Event. John

Best just to accept the defaults when re-installing, unless you have a good reason not to!

Yes - it only occurs when FSUIPC7 is started when MSFS is still booting to the main menu. I did report this issue to Asobo quite a while ago but have yet to receive a response: https://devsupport.flightsimulator.com/t/phantom-xbox-controllers-detected-during-msfs-start-up/8745 I have also now reported this to Steam. John

Ah... I think this is the same issue reported previously (as a phantom xbox controller). You can add the following to the [JoyNames] section of your FSUIPC7.ini file to get FSUIPC7 to ignore this fake steam device: IgnoreDevice=0x28DE,0x11FF When you do this, also revert your [JoyNames] section to the original, i.e. John

Do you have an attachment added to your Alpha? Both HID scanning and your registry show an additional device (different vendor/product ids) but with the same GUID as your Alpha: Vendor ID of 28DE is 'Valve Software' - no idea who they are, and cannot find a product matching that product ID. We could remove that registry entry, but if it is also being detected via HID scanning it will probably just get re-added. Does your Alpha get recognized and work with the changes I proposed? Did you change or install anything that could cause this issue? e.g. maybe some additional software for use with the Alpha? P.S. Valve Software do gaming software and also Steam. Have you changed or enabled some functions in Steam?

You may have a registry issue. Please show me / attach your FSUIPC7.JoyScan.csv file and I will take a look. It finds the name in the device scan but not when matching to the registry: Your JoyScan file will tell me why. No. The matching on GUID and name is there for a reason, and has been like this for 10+ years. I am not going to revise the code for this now. Windows does occasionally create new entries for devices sometimes, maybe when disconnecting and re-connecting to a different hub, or on windows updates. It can also change the GUID of devices. Any such changes in the registry usually require a simple update of the ini to get it working again, or a cleaning of the registry entries. I can help with both, but there is nothing I can or am prepared to do about this in the way that devices are scanned and acquired by FSUIPC. John

1. You attached your FSUIPC7.log file when FSUIPC7 was still running. Please exit FSUIPC before attaching files (log and ini). 2. You trim is NOT assigned in FSUIPC. Your ini file shows no button or key assignments, and you only have axis assignments to set the Flaps: FSUIPC can only disable the trim if/when assigned in FSUIPC. John

It did not. D was created to match device 0, which has GUID DA65E8F0-62FA-11EB-8001-444553540000 A has GUID 90950270-68C6-11EB-8001-444553540000 What has happened is that your Alpha Flight Controls name now seems to be missing: Even though the GUIDs match, the names dont and so a new letter entry is created: I don't know why the name (in the registry) for your Alpha is now missing. You can either correct that, or go with the blank name by changing that section to: John P.S. This is not a bug, but something that changed in your system. I will remove [Bug Report] from the title of this post.

Add-ons -> WASM -> List Lvars If you do not have that menu entry, then the WASM has not been installed.

I just fired up SPAD with the C172 loaded. It connected, I selected the default profile for the aircraft, and both my Saitek Switch Panel and Multi panel seem to work, although the display seems to be not working on the Multi Panel at the moment - its blank, but the buttons are working. Not sure why - I haven't used this for many years. This is using version 0.5.1. I don't want to install and test with 0.5.0 as this would remove my current (working) installation. Sorry, but I have no idea why it isn't working for you - are you using 0.5.1?