John Dowson

April 1

20 minutes ago, imperial321 said:

I have just updated FSUIPC to 7.4.11 but on opening the ini file for the DetectToConnectDelayAuto etc the entries do not seem to be there to adjust.

You need to add them - use a value of 185.

John

April 1

1 hour ago, DaveSCUSA said:

As far as the coding of >K: and >A:, I was using events.txt for examples:

PA24_250_Pitot_Heat_Off#1 (>K:PITOT_HEAT_OFF)
PA24_250_Pitot_Heat_On#1 (>K:PITOT_HEAT_ON)

PA24_250_Primer_Prime#1 (>K:TOGGLE_PRIMER1)

Some events take a parameter (e.g. all *_SET events), others not. If you do not know, check the documentation: https://docs.flightsimulator.com/flighting/html/Programming_Tools/Event_IDs/Event_IDs.htm
Those presets are incorrect as those events do not take a parameter. They will work, but the parameter is not necessary and is ignored.

1 hour ago, DaveSCUSA said:

Please let me know where and how to use ENGINE_Starter_1<;FLOAT64> or ENGINE_Ignition_1<;FLOAT64>. I know how to assign the input events in the Assignment UI to a keypress but don't see how to use the key to press to on and the second press to off.

If you want different/alternating commands to be sent on successive keypresses, you would need to overload the key press assignment (i.e. have both assignments on the same keypress) and then use an offset condition to only send one of these at a time, depending on the state of the offset. So, for the ignition switches, for example, you can use offset 0x02C0 (TURB ENG IGNITION SWITCH EX1:1) for the left switch, and 0x02C1 for the right switch. These offsets will hold 1 when the switch is off/NORM, and 2 when on.

1 hour ago, DaveSCUSA said:

Where else can one manipulate input events, e.g. add or subtract a value to an input event.

You cannot currently read the value of an Input Event- this is something I would like to add. You need to determine if there is something else that also holds the value (a simvar or lvar) and use that - as I showed above with the ignition switch.

1 hour ago, DaveSCUSA said:

The Cockspur C510 input to modify the brightness of the panel light is input event LIGHTING_PANEL_1. The brightness of the Display is input event LIGHTING_POTENTIOMETER_30. Both have values 0 to 100. I have two rotary switches on the keypad left or right rotation. Each click sends a key combination. I want to change the value of the above input events by 10, left - 10, right + 10. Can't figure out how to do it in FSUIPC other than an Lua.

It is easier to use an axis for such controls, and you would assign the axis value to an offset and use a lua script to pick-up changes to the offset value, calibrate this to the required range and then send the input event with the calibrated parameter. If using a rotary, this will use buttons and you need to use button assignments, and you will need to know the current value so that it can be incremented/decremented.

Note that LIGHTING_PANEL_1 is also available as an lvar, so it would be easier to use this. Just add that to a free/spare FSUIPC offset (using the facilities provided), and then you can just assign your rotary buttons assigned to the offset inc/dec controls.

April 1

30 minutes ago, Wray2400 said:

Have followed all steps i.e updated VC++, copied data exactly, tried creating key file manually, turned off antvirus. Still getting invalid message.

Please let me know your order number (do not post your key details) and I will check your key here.

John

April 1

21 minutes ago, PH1133 said:

altitude display is working,

Please post what you have used. This helps others who come across this topic.
If posting for help, you should always post the solution once found.

John

April 1

Try looking at the Offset Stratus documents for the heading - there are several... As I suggested in your other post w.r.t. the altitude, ty logging the offset values.

Writing to thee offset may work (if writeable) to update the heading, but it may not - this can be aircraft dependent, You need to use what works for your aircraft. You should always specify the aircraft for such questions.

John

April 1

52 minutes ago, John Dowson said:

The only possible thing I can do with this issue is to see if I can get the installer to run without admin privileges, as these are not even necessary.

It seems that admin privileges are needed to run the uninstaller.

When the installer is ran, it is windows that either asks for the permissions to be elevated or requests an admin login. The installer code only has access to this user's details, so if you change to an admin login, it is not possible to retrieve the user details from the standard user account.

Therefore you need to follow the instructions in the README.txt. If this is not possible, then you would have to manually install the auto-start component and maybe also the WASM module.

John

April 1

@Capholland Please note that this issue is already documented in the README.txt included in the zip file:

Quote

Problems running FSUIPC7
========================
...
5. If, when running the installer, you are prompted for a password for a user with Admin privileges, then please cancel and do not install as doing so will
install certain items (e.g. documents) in the wrong place. If you have already installed this way, please uninstall using the created uninstaller (or via
the windows App management panel).
This situation occurs when the user account installing FSUIPC7 doesn;t have admin privileges, which Windows automatically requests when running the
installer (even though these are not needed by the installer). The correct way to install in such circumstances is to temporarily grant admin privileges
to the user account under which you wish to install FSUIPC7. Once you have installed, you can remove this elevated privilege.

The only possible thing I can do with this issue is to see if I can get the installer to run without admin privileges, as these are not even necessary. I think I have looked at this before (hence that note in the README on this issue), but I will check again when I get time.

John

April 1

No idea - perhaps @andresb can explain what solved his issue.

Note if using 7.4.11, please tune your connection parameters as described in this post:

If not using 7.4.11, please update and then tune this parameter.

John

April 1

Which aircraft are you actually using? There is no Asobo C510, as far as I am aware. I have the Cockspur C510 Mustang, and for the starter/ignition switches for this aircraft you should use the Input Events, not presets:
ENGINE_Starter_1<;FLOAT64>
ENGINE_Starter_2<;FLOAT64>
ENGINE_Starter_Disengage<>
ENGINE_Ignition_1<;FLOAT64>
ENGINE_Ignition_2<;FLOAT64>
Input Events are used to control the B-type variables, which you cannot use via calculator code.

April 1

Ok - please let me know if/when you hear anything back.

John

April 1

8 hours ago, PH1133 said:

so the display for altitude is in the fmc

But is that the target altitude or the actual altitude, and is that calibrated or not? As I said, FSUIPC has several offsets for altitude, try logging them and see which one matched (with any conversion applied) to the one in the FMC. I suspect you need the AUTOPILOT ALTITUDE LOCK VAR:3 simvar (Selected Altitude in FCU), which is held in offset 0x0798, or AUTOPILOT ALTITUDE LOCK VAR:1 (Autopilot constrained altitude value) in offset 0x07D4. Try logging these, as well as the other offsets, and apply appropriate conversion (i.e. divide by 65536 to get meters then multiply by 3.2808 to get feet) before comparing it to the displayed value.

On 3/31/2024 at 12:57 AM, PH1133 said:

when flying the fbw a320 neo

Are you using the development or stable version of this aircraft?

Note also that the altitude of the FMC also works differently in managed and selected modes - see https://forums.flightsimulator.com/t/altitude-management-with-the-a320-on-autopilot/477984/2 (for example). There should still be an offset that holds the displayed value though...

John

April 1

This has already been reported - see

8 minutes ago, sikorsky77 said:

I asked for Bitdefender support to check it to see if it is maybe a positive false. (I think so)

It will be a false positive. The RefistrationChecker.exe was recompiled with the latest VisualStudio update for this release, no other changes. I do not understand why this is now being flagged by BitDefender. Thanks for reporting this.

John

P.S. You posted in the main support forum - please use the specific FSUIPC7 sub-forum for all issues with FSUIPC7. I will move your post.

April 1

10 hours ago, DaveSCUSA said:

I haven't been able to find how to set an offset using the preset code.

You cannot do this. Offsets are in FSUIPC7 only, and calculator code is executed in the FS. To change an offset that holds a simvar (a-type variable), then you would just set that variable and this would then update the corresponding offset.

10 hours ago, DaveSCUSA said:

I learned how this could be done with buttons in the Appendix but can't find out how with keypress input.

As I said, use the key assignments dialog. And if the key presses are not recognised, you will have to try with a keyboard hook.

17 hours ago, DaveSCUSA said:
I have two activities I want to execute with each key, a key that push on and release off as in the starter button:
C510_Starter1_On#(>A:TAILWHEEL LOCK ON, Bool) 0 == if {  1 (>K:TOGGLE_STARTER1) }

C510_Starter1_Off#(>A:TAILWHEEL LOCK ON, Bool) 0 == if {  0 (>K:TOGGLE_STARTER1) }

Looks like you haven't taken @ark1320's comments into account. You don't need the '>' symbol when reading an simvar (only for setting), and the k event TOGGLE_STARTER1 does NOT take a parameter (at least according to the documentation https://docs.flightsimulator.com/flighting/html/Programming_Tools/Event_IDs/Aircraft_Engine_Events.htm). So they should be:
C510_Starter1_On#(A:TAILWHEEL LOCK ON, Bool) 0 == if { (>K:TOGGLE_STARTER1) }
C510_Starter1_Off#(A:TAILWHEEL LOCK ON, Bool) 0 == if { (>K:TOGGLE_STARTER1) }
but then they are exactly the same!

17 hours ago, DaveSCUSA said:
In another case, I want the key on when pushed and off when pushed again:
C510_Ign1_On#(>A:TAILWHEEL LOCK ON, Bool) 0 == if {  1 (>K:TURBINE_IGNITION_SWITCH_SET1) }

C510_Ign1_Off#(>A:TAILWHEEL LOCK ON, Bool) 0 == if {  0 (>K:TURBINE_IGNITION_SWITCH_SET1) }

If you want a toggle function on a button for this, then you would need to know the current state of the ignition switch. Maybe try TURB ENG IGNITION SWITCH:index or TURB ENG IGNITION SWITCH EX1:index (see https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_Engine_Variables.htm). Also maybe take a look how these work in the presets defined for other aircraft - for example, this is the calc code for the C208 Engine Starter Switch Start preset:

1 s0 (A:TURB ENG IGNITION SWITCH EX1:1, enum) != if{ 
   l0 (>K:TURBINE_IGNITION_SWITCH_SET1) } 
(A:GENERAL ENG STARTER:1, Bool) ! if{ 1 (>K:SET_STARTER1_HELD) }

I can and do help out with preset definitions when I have time, but I am very busy at the moment with various issues and don't really have time for this at the moment. The best place to discuss presets for specific aircraft would be on the HubHop discord server, in the msfs2020 channel. Otherwise I can take a deeper look maybe later in the week (or next week), when things calm down a bit...

If you only want your assignments to work when the tailwheel lock is off, it is better to remove this check from the actual presets and add this as an offset condition to your assignments. So remove this check from your preset code for the time being. Once your assignments are working, you can add an offset condition to your FSUIPC7.ini. To do this, find the assignment, e.g.:
46=PS,14,CPC510_Starter1_On,0 -{Preset Control}-
then add an offset condition for the tailwheel lock which is 0x2A90:
46=D2A90=0 PS,14,CPC510_Starter1_On,0 -{Preset Control}-

John

April 1

If you have updated to 7.4.11, please see this post:

If not using 7.4.11, please update to this version and then follow the instructions in that post to tune the DetectToConnectDelayAuto ini parameter.

John

April 1

But why are you registering again anyway? You only need to do this once, to generate your key file. When you update FSUIPC7 you do not need to re-validate your registration - your previous key details will be shown in the registration page, and you can just Skip.

But if the key won't validate, please see the section Invalid Key Details in the Installation and Registration guide.

John

April 1

13 hours ago, Jaspar11 said:

Pete I downloaded trial licence and filled in the required boxes for registration bit I keep getting an incorrect details sort of an error ( sorry I can’t remember the exact wording )

But as it says in the very first post: Note that time-limited/trial licenses are not validated by the FSUIPC7 installer.
To use the trial license, you just need to download it and copy/move it to your FSUIPC7 installation folder and you are good-to-go.

13 hours ago, Jaspar11 said:

I put in my login name my email address and copy and paste the key for both fsuipc7 and widefs

Sorry, but why are you doing this with the trial license - just use the key file as provided.
If you have purchased a license and it will not validate, please see the section Invalid Key Problems in the Installation and Registration guide.

John

April 1

14 hours ago, fennelda said:

I'm struggling with an issue that I see has come up numerous times in the past, and I wonder if there's a solution? If I start FSUIPC before launching MSFS, it detects my 3 controllers perfectly, as seen in the JoyScan.csv file. However, if I let FSUIPC launch with MSFS, I get 3 extra phantom Xbox controllers added, which all seem to copy the GUID of one of my real controllers (see attached file).

That is interesting! I also used to have the phantom xbox controllers issue but I haven't seen this for a while. I will need to go over the old posts on this subject to refresh my memory...

However, if it is due to FSUIPC7 trying to connect when MSFS is starting-up which is seems like, then could you please try with the latest version of fSUIPC7, 7.4.11. With this version, please tune the DetectToConnectDelayAuto parameter, as described here:

Once you have done that, please try again and see if these phantom controllers have disappeared, If not, try increasing the , DetectToConnectDelayAuto parameter again by 5 (seconds) each time, to see if you can arrive at a value where these controllers disapear.

John

March 31

The RegistrationChecker program was recompiled with the latest version of VisualStudio in release 7.4.10 - this was the only change.

54 minutes ago, PSCH said:

To just bluntly have the virusscanner flag an exception for this .exe is not a very good idea. Please investigate this issue more serious please.

This has happened many times before and is always the result of a false-positive by the anti-virus software, I do not know how to investigate this issue "more serious" - what do you expect me to do? What you can do, as a BitDefender user, is to report this false-positive at the following link and this will be investigated/corrected by BitFinder: https://www.bitdefender.com/business/support/en/77209-343054-resolving-legitimate-applications-detected-as-threats-by-bitdefender.html

From that page:

Quote

Bitdefender strives to reduce false-positive reports to a minimum. However, these reports are commonly due to bad programming practices. For example, some applications change the Master Boot Record, add Run registry entries, change system files without the user’s confirmation, or execute custom macros in Office applications.

The installer does non of those things mentioned, so I do not know why it is being flagged.

John

March 31

2 minutes ago, DaveSCUSA said:

Is there a way to send a keyboard keypress with a preset like you can in Lua?

Yes, by using the key assignments panel, and checking Select for Preset. Are your key presses recognised in that window? It has been reported that some special keyboard-type controllers (i.e. controllers that send key presses but are not actual keyboards) can have issues with key assignments. To fix this, you can use a keyboard hook by setting:
UseKeyboardHook=Yes
in the [General] section of your FSUIPC7.ini file. Don't set this if the keys are recognised without this setting.

8 minutes ago, DaveSCUSA said:

There is an entry to bypass windows with a keypress in the FSUIPC7.ini file.

Not sure what this means...

8 minutes ago, DaveSCUSA said:

May I assume that FSUIPC7 intercept the keypress and sends it directly to MSFS?

FSUIPC7 normally receives key presses from MSFS to trigger its key press assignments. It only sends key presses when configured to do so, and will only get the key presses from windows (not MSFS via simconnect) if a keyboard hook is being used.

I don't have time to look into your other questions at the moment, I will take a look tomorrow. But why are you checking the status of the tail lock before controlling the starter/ignition? And rather than checking this in the preset, you can use an offset condition in offset 0z2A90 (see Advanced User guide for details on how to use offset conditions).

More tomorrow....

John

March 31

What anti-virus software are you using? This is a false-positive and needs to be reported to the provider.
You should add an exception to allow the RegistrationChecker.exe to run. Note this is a known issue with McAfree and has also been reported with other anti-virus software. It is also documented in the provided README.txt:

Quote

Problems installing or registering FSUIPC7
==========================================

If you have problems registering your FSUIPC7 license, then this is caused by one of 3 issues:

1. You have entered your details incorrectly. Please copy and paste the details from your
purchase email or SimMarket account.

2. You do not have the required VC++ redistributables installed. Please download and install
the latest combined (ie. 2015, 2017, 2019 & 2022) redistributable packages, both x64 and x86, from
https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist

3. Anti-virus software is preventing the license validation. Check your anti-virus reports and
either add an exception to allow the installer to run or temprarily disable while installing.

It is also documented in the Installation and Registration guide, under Installation Problems.

Please also note that you do not have to validate your registration each time you update FSUIPC7. This needs to be done once and only once, and a successful validation will generate an FSUIPC7.key file that contains your registration details. On subsequent updates, your details from the FSUIPC7.key file (previously generated) will be used to poulate the fields on the registration page, but you do not need to validate these again - just press on Skip.

John

March 31

See

I now consider this topic closed.

If anyone is still having issues, please create a new topic and describe your issue there and attach your FSUIPC7.log and FSUIPC7.ini files. Make sure that you are using the latest available version (currently 7.4.11) and that you have configured the DetectToConnectDelayAuto and/or DetectToConnectDelay properties correctly for your system, as shown in that topic I referenced above.

John

March 31

See

John

March 31

Background

FSUIPC7 is designed to be able to function whenever it is started - either before MSFS is started, during MSFS start-up or when FSUIPC7 is running, and in any state (e.g. in the main menu, when an aircraft is loaded, or when MSFS is in any other state). However, the recommended setting is to have FSUIPC7 auto-started with MSFS2020.

Due to the variable start-up times of MSFS for each user (mainly due to the number of add-ons it loads, but also related to your PC specification), long start-up times can cause issues when FSUIPC7 is auto-started, or when started during the MSFS initialisation phase. This is because a response is not received from the initial connection request, and this response times-out after a pre-defined (and configurable) time-limit, and a new request is sent. A few re-connection attempts at start-up should not cause any issues, but too many attempts can starve SimConnect of available connections and then prevent other add-ons/simconnect clients from connecting/functioning correctly. It is therefore best to tune FSUIPC so that the connection attempt is delayed until MSFS is ready to accept this connection within a reasonable amount of time.

There are three parameters that you can tune to get FSUIPC7 to connect at the right time and to avoid re-connection attempts. These are:
  DetectToConnectDelayAuto : this is the time/delay used, in seconds, between when FSUIPC7 detects that MSFS is running and when it first tries to connect, and is used when FSUIPC7 is auto-started (by MSFS) only. This has a default value of 60 (seconds), so FSUIPC7 will attempt to connect 60 seconds after it has detected that FSUIPC7 is running. This parameter has a maximum value of 500 seconds,
  DetectToConnectDelay : similar to the above, but used when FSUIPC7 is manually started. This has a default value of 1 (second), which is designed for use when FSUIPC7 is manually started and MSFS is already loaded, i.e. in the main-menu system or with an aircraft loaded and ready-to-fly. You should adjust this to the same default as DetectToConnectDelayAuto if you start FSUIPC7 before you start MFS, or if you start FSUIPC7 during the MSFS start-up process. This has a maximum value of 300 seconds.
  InitialStallTime : this is the time taken between issuing a connection request and cancelling/closing this request when a response is not received,. This has a default value of 30 (seconds), and a minimum value of 15 (seconds) when FSUIPC7 is auto-started. What this means is that FSUIPC7 will close/cancel the connection request and issue another connection request if a response is not received in 30 seconds. You can adjust this time, but it is better to first try and configure the other two parameters mentioned above first. Only adjust/increase this if you have reached the maximum value of the other parameters and are still having re-connection attempts.

All of these parameters should go in the [General] section of your FSUIPC7.ini file. If they are already there, you can adjust them as needed (see below), and if they are not there they should be added. They will not be present by default.

What to do when using Auto-connect (recommended)

First run MSFS and let that load and auto-start FSUIPC7, Ince MSFS fully loads to the main menu, open FSUIPC7 (press Alt + F) and exit (File -> Exit). Then open the FSUIPC7.log file (which can be found in your FSUIPC7 installation folder - note that if you cannot see the file extensions, you need to change your Explorer options to not hide the extensions of known file types). Here is an example extract of the relevant section of a log file:

Quote

...
328 LogOptions=00000000 00000001
328 Auto-started with DetectToConnectDelayAuto=220, InitialStallTime=10
3172 Simulator detected
223172 Trying to connect...
233172 **** SimConnect open event not received in required time limit: Re-connecting now...
233172 Trying to connect...
243172 **** SimConnect open event not received in required time limit: Re-connecting now...
243172 Trying to connect...
253172 **** SimConnect open event not received in required time limit: Re-connecting now...
253172 Trying to connect...
263172 **** SimConnect open event not received in required time limit: Re-connecting now...
263172 Trying to connect...
273172 **** SimConnect open event not received in required time limit: Re-connecting now...
273172 Trying to connect...
283172 **** SimConnect open event not received in required time limit: Re-connecting now...
283172 Trying to connect...
293172 **** SimConnect open event not received in required time limit: Re-connecting now...
...
373172 Trying to connect...
383172 **** SimConnect open event not received in required time limit: Re-connecting now...
383172 Trying to connect...
393172 **** SimConnect open event not received in required time limit: Re-connecting now...
393172 Trying to connect...
396234 SimConnect_Open succeeded
396234 Running in "KittyHawk", Version: 11.0.282174.999 (SimConnect: 11.0.62651.3)
396234 MSFS version = 11.0.282174.999
...

From this log file extract, you can see the current value of the ini parameters being used:

Quote

328 Auto-started with DetectToConnectDelayAuto=220, InitialStallTime=10

and that it is attempting to connect many times before a connection is obtained. The DetectToConnectDelayAuto value of 220 is used here:

Quote

3172 Simulator detected
223172 Trying to connect...

i.e. the difference between detection and connection is 220 seconds. This needs to be adjusted to prevent these sim connection attempts, so find the timestamps of the Simulator detected and SimConnect_Open succeeded log message:

Quote

3172 Simulator detected
...
396234 SimConnect_Open succeeded

then subtract these values and divide by 1000 (to convert from milliseconds to seconds), so (396234 - 3172)/1000 = 393. So for this installation, you would add the following to the [General] section of your FSUIPC7.ini file:
DetectToConnectDelayAuto=393

If you see several 'SimConnect_Open succeeded' messages, this implies that the InitialStallTime is being reached, and FSUIPC7 is still attempting to re-connect. In this situation, use the timestamp of the last 'SimConnect_Open succeeded' message to determine the value of the DetectToConnectDelayAuto parameter - don't adjust the InitialStallTime unless absolutely needed (see below).

If you find that you are still getting re-connection attempts after setting the DetectToConnectDelayAuto parameter, you can adjust the InitialStallTime parameter. Start with a value of 45 and increase (up to a max of 60) until there are no longer any reconnection attempts. If you find that it is not possible to configure this to remove these connection attempts, please post your log file here and I will take a look.

What to do when manually starting FSUIPC7

You should not need to do anything if manually starting FSUIPC7 once MSFS is up and running and either in the menu system or have an aircraft already loaded. If you start FSUIPC7 before MSFS, or early during the MSFS start-up process, you need to configure the value for the DetectToConnectDelay ini parameter in the same way as I showed how to configure the DetectToConnectDelayAuto parameter in the previous section, i.e. look at your logs and determine the time between detection and a stable connection and use that,

John

March 31

What offset are you using? The current aircraft altitude should be available in offset 0x0570 (or 0x6020 for GPS altitude). and offset 0x0590 for the calibrated value. For target altitudes, see 0x0798/0x0818 and 0x07D4, and indicated altitude in offset 0x3324. Try logging those offsets using FSUIPC's offset logging facilities to see which one matches the value you see in the VC.
There are also other offsets holding altitude values - take a look at the offset status document for details on each of these offsets.

John

March 31

15 hours ago, Doc_Z said:

I've attached log.

This log file shows that you are using a very old (and unsupported) version of FSUIPC7 (7.4.5). Please update to the latest and only supported version, 7.4.11. And please configure the DetectToConnectDelayAuto ini parameter as explained here now several times (I will also create a FAQ topic on how to do this).

46 minutes ago, Watsi said:

do we still need the ini file additions with the new version 7.4.11? Or should we remove them?

You should set the DetectToConnectDelayAuto ii parameter to an appropriate value for your system. You shouldn't need to set/change the InitialStallTime - this has now been set to a minimum of 15 (seconds) when FSUIPC7 is auto-started, which should be plenty of time if the DetectToConnectDelayAuto parameter is configured correctly, but you can also adjust/increase this if your log indicates that FSUIPC7 is re-connecting a few times during start-up.

John

Profiles

Forums

Events

Gallery

Downloads

Posts posted by John Dowson

Important Information