John Dowson

Very strange - I (and probably almost everybody) use Windows Defender, I am up-to-date with the latest anti-virus definitions and do not see this. Download again form fsuipc.com and try again. If you get the same error, it will be a false positive, but I do not understand why I don't get that here. When this happens with Defender I report to Microsoft and they are usually pretty quick in rectifying this. John

Which is? Please can you post the solution for others that come across this post. It is quite annoying when people find a solution to an issue they have posted about but don't share the solution....

Then it should have been obvious that ipc.control does not (yet) support more than one parameter to the control. There is only one way: "1 7 (>K:2:FUELSYSTEM_PUMP_SET)" Did you try assigning to the Input Event? I will take a look later (or tomorrow), if/when I have time... John

That log shows the lua exited16ms after it was started. How are you starting/stopping this lua? The lua didn't actually run and was killed during start-up... Also, the lua scrip is incorrect. As I said, 0ffset 0x0350 is in BCD format. Do, as an example, if the NAV1 frequency is 123.45, then that offset holds 0x2345, so when you read that as a decimal you will get 9029. Add 100, you get 9129, which is 0x23A9, i.e. a frequency of 123.A9, which is incorrect. There are also other issues. For speed you should have this lua auto-started and wait for the parameter event to be triggered, but you need to get the current value and increment it within the callback/handling function. You are not doing this and are just sending the same value in each parameter event... If you want further help, please attach the lua script, and your FSUIPC4.log and FSUIPC4.ini files. Please turn off log lua separately, and turn on logging for lua plugins and Buttons & Switches before generating the log file. John

Why would you expect that to work? Please consult the documentation - ipc.control only accepts 1 parameter for the control: I will look into allowing two parameters for this, and once this is done the documentation will be updated to reflect this. Please don't guess on lua functions and parameters - consult the documentation. I provide that for a reason. The only way to yse a control with multiple parameters at the moment is using calculator code, and in lua you can use the ipc.execCalcCode function. Here's the MSFS documentation on this (from https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Simulation_Variables.htm#SimVars😞 However, the log extract you posted shows the Input Event FUEL_PUMP_FWD_2 is used. Try assigning to that first instead. There may also be some B-vars (also called input events) available that can be used via calc. code (not all b-vars are available/mapped as Input Events). The following tutorial shows how to discover and use B-vars, although once discovered you would use to define calc. code for a preset (and don't have to use MobiFlight!): https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ I may take a look at the 747 in MSFS2024 later to see how it works, but if you find anything before that then please update. John

The previous disableInDrone.lua only disabled for 10 seconds, and in the previous FSUIPC7.exe all main flight axes (including the helicopter specific ones) were disabled except for the collective. There is always some latency with these type of things (nothing to do with resources) and it won't be instantaneous - nothing is! However a second seems way to high and it should be a couple of hundred ms at the max. Appropriate logging would give more exact times, from FSUIPC's point-of-view (i.e. it only knows, for example, that drone mode is activated once it receives an update of the CAMERA STATE simvar which is going to take time getting from the FS to FSUIPC). As I said it does work when not calibrated. You can calibrate this in the prop pitch panel (on page 2 of the calibration screens, not the separate ones in page 5) but if you do this it stops working, As I said previously, you can post-calibrate (i.e. calibrate when assigned with 'Send to FS as normal axis') most axes for most aircraft, but this can cause issues with sine due to priority levels. If this is the case, you cannot calibrate in FSUIPC's calibration tabs and would have to use the scaling functionality (or lua) instead. John

It does work, but not if calibrated (in prop pitch calibration panel). Try the attached please: FSUIPC7.exe

Does the Axis Collective Set axis work for you with the Bell then? Tried it here and that axis doesn't work - I have to use the throttle axis. Can you try this attached version please: FSUIPC7.exe That disables most of the helicopter axes via offset 0x310A, but I am not sure about the collective as the calibration for this is mapped to prop pitch which isn't suppressed by that offset, and I cannot test here as that axis isn't working in the Bell for me anyway. Here is an updated lua script which keeps updating offset 0x310A until drone mode has exited: disableInDrone.lua John

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?