John Dowson

The script is working but only for airplane axes controls - offset 0x310A does not currently disable any of the helicopter specific axes. I will look into updating this to handle the helicopter-specific axes as well. Also, offset 0x310A resets itself after 10 seconds, so the script will need updating to handle this as well.

Also, change this: to this: (the first two entries are redundant) That will match all Bell 407 variants. When you create or add an aircraft to a profile, the full name if the aircraft is used. You should always then edit/shorten the aircraft name in your [Profile.xxx] section to a substring to match all variants. This saves you having to add the aircraft to the profile when you use a different variant or livery.

Please also attach your FSUIPC7.log file - that is file that tells me what is happening, To diagnose any issue, I need to see both your ini and log files from the same session, and always only attached AFTER FSUIPC has exited. Did you remove any assignments in MSFS? What aircraft/helicopter are you using?

Just an update - I haven't seen anything in the SDK that can reliably be used to determine if the user object is a helicopter. I also asked on the Asobo SDK forums a few weeks ago and have yet to receive a response. So it looks like this is not possible. Maybe you could check to see if one of the helicopter-specific simvars is being used (i.e. non-zero) - see https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Helicopter_Variables.htm. Also not reliable though, for example they would all be 0 when cold and dark. I will let you know if I ever receive a response on this question in the Asobo forums. Cheers, John

Please try this lua script: disableInDrone.lua Save that to your FSUIPC7 installation folder. You then need to auto-start this lua plugin - you can do this by adding the following to your FSUIPC7.ini file: John

So, these are your presets: To be honest, that looks overly complicated to me...! It does work, but I am not sure why...the *_INC and *_DEC B:vars must both just return the value of SF50_LIGHTING_INSTRUMENT_LIGHTS for that to work.... I would set this up this way: 1. Add the Input Event SF50_LIGHTING_INSTRUMENT_LIGHTS to a free/spare FSUIPC offset. You do this by adding an [InputEventOffsets] or [InputEventOffsets.xxx] section (where xxx is a profile name) to your FSUIPC7.ini file, or a [InputEventOffsets] section to your profile ini file (when using profiles-in-separate-files). e.g. That adds the input event to offset 0xA040 as a 2-byte int (unsigned word). 2. Assign your buttons to inc/dec that offset as follows: Just another way of doing this, FYI. Doing it this way, you also always have access to the current value of the input event which can be useful in some circumstances (but probably not needed for this one). Cheers, John

No problem. I will release FSUIPC6 v6.2.2 later today anyway. This version will just add the AIAboveGroundLimit ini parameter to FSUIPC6, which was added to FSUIPC7 in v7.4.18. However, in FSUIPC6 the default value for this parameter will be 100 so there will be no functional change for existing installations, whereas in FSUIPC7 the default for this parameter is (now) 0 (as this is needed when using MSFS AI traffic, which is the default). Cheers, John

Offsets are hex values, and need to be preceeded by an x when entered in that field. If you don't, it will be treated as a decimal value and converted to hex. So 5301 is x1485 (or 0x1485( in hex. If you mean offset 0x5301, enter x5301. John

Your log does show some issues: i.e. your rudder pedals are continually disconnecting and reconnecting. Check the USB connections, hubs are properly powered, usb3 devices connected to usb3 ports and usb2 connected to usb2. Also check that you have the allow sleep/disable power option disabled on your USB hubs/ports (in Device Manager).

No, not necessarily.

Ah, ok. Ah, sorry - it is not mapped to throttle, but to prop-pitch. It is the specific helicopter throttlr axes that are mapped to throttle calibration. From the changes.txt file (or FSUIPC history document) for 7.4.1: I should really add that information to the calibration section of the user guide (not that many people actually consult the documentation...!). Well, I also mentioned this method several times above... I will send you a lua to try for this functionality later today (hopefully) or over the weekend. Cheers, John

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,

What version of FSUIPC are you using? Have toy installed via the DLL.xml or add-on.xml method? Do you actuallu have multiple copies of FSUIPC installed, or are these multiple copies being started from the same location/folder? Check your DLL.xml to see if there is an FSUIPC entry there, and also check your P3D add-ons folder to see what add-ins are being started there. You should only use one start-up method - either the DLL.xml or add-on.xml method, not both. Maybe try uninstalling FSUIPC - run the uninstaller, if present, and then run P3D. Do you still have FSUIPC running? If so, there is a second installation.

Ok, but could you elaborate please? O would be interested to know the cause of this issue. Thanks, John

Yes - you can pass the value as a parameter to the axis control/event.

That was what I was asking you...aren't they the same? I would have thought that P3D populates the ATC MODEL simvar from the atc_model entry in the aircraft.cfg. So they are the same and there is no point adding atc_model. In MSFS I thought (but didn't check) that icao_type_designator would be distinct from ATC MODEL, and so added it, but it also may be the same as ATC MODEL...but I thought that would maybe match icao_model... I will re-check this in MSFS/FSUIPC7, but still don;t think its worth adding this in FSUIPC6 unless it is actually distinct from offset 0x3500,

But isn't that also stored in the ATC MODEL simvar held in offset 0x3500?

I should have checked before adding.... The ICAO information doesn't seem to be available in the aircraft.cfg files in P3D. I've checked several aircraft and can't see any ICAO entries anywhere (in MSFS they are in the [General] section). So it won't be possible to add this - I will remove. John

I will check this. If FSUIPC sees them as two distinct axis, then the calibration for each should be separate, regardless of how they are seen in windows game controllers - although that also surprises me. Could you show me / attach your current FSUIPC7.ini file so I can check your current assignments. You should be able to calibrate that control, including reverse, in the Throttle calibration tab. Try that first. Otherwise you can reverse any axis by adding a scaling factor of -1 to the axes assignment entry in your FSUIPC7.ini file. There is a section entitled Additional parameters to scale input axis values on page 42 of the Advanced User guide on how to do this. By default, anything calibrated in FSUIPC's calibration tab also affects axes assigned with 'Send to FS as normal control', it just happens in a different order. When assign with 'Send direct to FSUIPC calibration', the axes values are calibrated before being sent to the FS. When assigned with 'Send to FS as normal control', the uncalibrated value is sent to the FS, the FS then sends back the event with the value, which FSUIPC then masks (i.e. blocks), calibrates the value with that event and re-sends it. Its rather technical, but its easier to first always try with 'Send direct to FSUIPC calibration' if the axis is available there and also calibrate. If not, or if this causes any issues/doesn't work, switch to using 'Send to FS as normal control'. And when using this method, you can try calibration but if that causes issues then remove/reset the calibration and use axis scaling if you need to reverse. The specific helicopter axes are mapped to the equivalent aircraft calibration panels, so you should be able to calibrate "Axis Collective Set" in the Throttle calibration panel. Try that - if you can't calibrate there, then you can reverse via axis scaling. Those are slightly different. The first is for button/key assignments, which can easily be handled via offset conditions (although that is an old post and the Camera State offset wasn't available then and so wasn't mentioned explicitly). The second was to disable flight controls when AP is active, which is possible via the solution provided, In fact, that second post provides another solution for your issue. You could have a lua script running that monitors the camera state offset, and when that changes to 4 it can update offset 0x310A to disable the flight control axes, and when changed away from 4 to reset. Should be a pretty simple script - I can provide you one to try if you like (over the weekend).

Upload limits are restricted for new uses - your limit will increase the more you post. You can compress the file, but if still to large you will have to use one of the (free) file transfer services, such as https://filetransfer.io/. Sorry, but I have no idea what that is - are you actually using the WebSocketServer? Does the FBW Remote Tool use the WebSocketServer? This is confusing...the myOffsets.txt file is for adding simvars to offsets, not lvars. And I have no idea what the "legacy LVAR Interface" is. As this is from the "FBW Remote Tool ", you should contact them to see what this means and what you need to do to correct this. Please post/update here if/when you have further information. John

Are you sure? Mine are two distinct axes - X and R. If they are distinct axes, you can assign and calibrate distinctly, including reverse. You can also reverse without calibrating, by adding a scaling factor of -1 to the assignment in your in - see the Advanced User guide for details. (Note you need to click Rescan to pick up a second axis after the first has been assigned). If they are both are on the same axes, then I can only assume that one trigger controls the +ve values and the other the -ve. If thats the case, then you can assign your trigger (either one!) to both controls (or all three -throttle, left brake and right brake) and then calibrate the throttle on the left trigger for one set of values and for left/right brake on the right trigger for the other ser of values. You can assign to Axis Collective Set, but only when assigning with 'Send to FS as normal control'. You should also be able to calibrate this axes in FSUIPC when assigned like this, if needed, although calibrating when assign with 'Send to FS as normal control' can sometimes cause issues (but usually not). Hmm, yes - I can see that would be an issue.... FSUIPC knows nothing about the modes. However, it does hold the camera state in offset 0x026D, which will be 4 when in Drone Mode. You can configure button and key assignments to be dependent on offsets, so they can trigger one action when an offset holds one value and another (ir none at all) when it holds a different value. So this would work for button/key assignments, but unfortunately this is not possible with axes assignments. Se the Advanced User manual, section Adding offset conditions, on how to use this functionality. So, the only way you could currently handle this with FSUIPC would to use a lua script instead. The way this works is that you configure your trigger to write its axis value to an FSUIPC offset. You then have a lua script running that picks up changes to this offset, and when it gets a new value it can then calibrate it and decide what to do with it, i.e. send it on to the FS if in normal mode, or ignore (or send a different control) if in drone mode. I will have a think to see if I could add something simple to handle this - maybe another ini parameter that, when set, would instruct FSUIPC to not send on axes controls if in Drone mode. This would be pretty blunt though and suppress all axes, although I could maybe allow a parameter to specify the axes letters to ignore. I will take a look when time permits, but it may take me a while to get around to this (I am pretty busy at the moment!). John

@pointy56 and other users who are using the 6.2.2-beta version. I am going to release 6.2.2 soon with this fix, but I am going to release with the default value for the new AIAboveGroundLimit ini parameter set to 100, so as to not affect current functionality. Therefore if you need this to be 0, make sure you have this set in your ini file. John

Many presets for MSFS2020 aircraft won't work for the same aircraft in MSFS2024, and unfortunately there is no current way to know if they work or not except by testing. In MSFS2024, many functions have switched to use Input Events, or B vars, which are equivalent and can be used in preset calc code in MSFS2024 whereas it couldn't in MSFS2020. Note that there are some MF presets that are specifically labeled for MSFS2024 aircraft, but there is no general mechanism yet to know if a preset is for MSFS2020, MSFS2024 or both. There have been some discussions on the MF forums on how to handle this, but i don't think anything has been decided yet. Once something has been implemented, I will updated FSUIPC7 to handle this - hopefully by only loading the presets flagged as working for the version being used. Yes. There are two ways of doing this. You need to determine the parameter values for the input event (you can use FSUIPC's Input Event logging for this), and you can then assign directly to the input event by checking the relevant checkbox and selecting the Input Event in the drop-down. Alternatively, you could define a preset to trigger the B-var. The following article shows how you can discover B-vars: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ That article also shows you how to use the b-var in MobiFlight, but for use in FSUIPC7 you would create a preset for the calc code in your myevents.txt file instead of configuring MF. Note that using Input Events directly would be the preferred option. However, not all B-vars are mapped to the Input Event interface, and so if there is a B-var available but no corresponding Input Event you would have to use the b-var via calc. code or a preset. John

Use one of the free file transfer services, such as https://filetransfer.io/. Also include your FSUIPC7.log file.

Also, if assigning in FSUIPC you should remove/delete the assignment in MSFS. If you don't, both the FSUIPC and MSFS assignments will be triggered. You can mix and match assignments between FSUIPC and MSFS if needed, but if assigning in FSUIPC only you should create a new empty profile for your controller in MSFS.