How do I get the actual current flaps angle?

There does not appear to be anything in the SDK to actually get the true flaps
angle, even though MSFS itself clearly knows this value. For example, in-game
the Maule has the following degrees-for-position when you look at the reported
values in the HUD:

  • 0 = -7 degrees
  • 1 = 0 degrees
  • 2 = 24 degrees
  • 3 = 40 degrees
  • 4 = 48 degrees

However, when I ask for the TRAILING EDGE FLAPS LEFT ANGLE variable using SimConnect, I get:

  • 0 = 0 radians, i.e. 0 degrees
  • 1 = 0.15 radians, i.e. 9 degrees
  • 2 = 0.42 radians, i.e. 24 degrees
  • 3 = 0.70 radians, i.e. 40 degrees
  • 4 = 0.84 radians, i.e. 48 degrees

How does one get the actual flaps angle, so that -7 degrees flaps is actually -7 degrees flaps,
as known to the sim in-game?

Hello @TheRealPomax The HUD flaps levels are defined in the cockpit.cfg:
cockpit.cfg
(flightsimulator.com)

However, the flaps position used for the flight model calculations are the
ones defined in flight_model.cfg and that is what’s returned by the simvar you
are referring to. As to why the two differs, that’s something you want to
discuss with the plane creator. Regards, Sylvain

1 Like

I don’t have the Maule so cannot check, but maybe also take a look at the
following simvars: TRAILING EDGE FLAPS0 LEFT ANGLE TRAILING EDGE FLAPS1 LEFT
ANGLE LEADING EDGE FLAPS0 LEFT ANGLE LEADING EDGE FLAPS1 LEFT ANGLE

Otherwise, if you know the flaps extension goes from -7 to +48, you could
maybe use the simvar TRAILING EDGE FLAPS0 LEFT PERCENT and calculate the angle
based upon this. John

I used the Maule as example but I don’t actually know which plane is loaded
until SimConnect tells me what the title is, and I don’t have access to any
data except for what SimConnect can report, so unfortunately airplane config
files are a no-go. (I’ll see if I can find another plane with negative flaps
to see if that has the same problem) Apparently TRAILING EDGE FLAPS0 LEFT ANGLE does not exist according to the docs, and Simvar Watcher won’t let me
query it, so no luck there either. I’ll contact the folks who make the Maule
to see if they forgot to add the values to the correct files though, thanks.

Apparently TRAILING EDGE FLAPS0 LEFT ANGLE does not exist according to the
docs, and Simvar Watcher won’t let me query it, so no luck there either.

That is strange - it does exist and you can request these. You could install
FSUIPC7 (free version, no license required) and use its logging facilities to
monitor the offsets that hold these and other flap simvars (offsets 0x30E0 -
0x30FE). John

Not according to
https://docs.flightsimulator.com/html/Programming_Tools/SimVars/Simulation_Variables.htm
unless you’re using a different SimConnect? The only TRAILING_EDGE_FLAPS
variables listed are:
TRAILING_EDGE_FLAPS_LEFT_ANGLE
TRAILING_EDGE_FLAPS_LEFT_INDEX
TRAILING_EDGE_FLAPS_LEFT_PERCENT
TRAILING_EDGE_FLAPS_RIGHT_ANGLE
TRAILING_EDGE_FLAPS_RIGHT_INDEX
TRAILING_EDGE_FLAPS_RIGHT_PERCENT

Oh interesting… digging around a little more, it turns out that
TRAILING_EDGE_FLAPS0_LEFT_ANGLE and TRAILING_EDGE_FLAPS0_RIGHT_ANGLE are
considered WASM vars rather than SimConnect vars, even though you can indeed
query them through SimConnect.
https://docs.flightsimulator.com/html/Programming_Tools/WASM/Gauge_API/Token_Vars/Token_Variables.htm
Having said that, it looks like even those report 0 when the in-game value is
-7 (at least using the https://github.com/Pomax/msfs-simconnect-api-wrapper
package I’m writing), I tried FSUIPC7 but I’m not sure where it’s logging to,
and there does not appear to be a “view current log” option under either
“file” or “log”.

 I tried FSUIPC7 but I'm not sure where it's logging to, and there does not appear to be a "view current log" option under either "file" or "log".

You can select where to log the offsets. Check the Normal log file option to
log to the FSUIPC7.log file, and you can then use Log → Open Console to
view the log in real-time.

Sorry for the delay in response - just seen this and didn’t get notified for
some reason…

John

There’s a trick with SimConnect which you don’t seem to be using - or maybe
I’ve misunderstood what you are trying to do. Although the return valuefor
SimConnect is listed as ‘radians’, if you tell it to return in ‘degrees’, that
is what you will get. This becomes especially useful for those awful ‘percent
over 100’ returns - just tell SimConnect to give you the answer in ‘percent’.
Alternatively, the radians to degrees conversion is

180/PI

where PI can be of any accuracy that you need. I use two versions:

PI = 3.141592


LARGE_PI = 3.1415926535897932384626433832795

The full formula is

degrees = radians*(180/PI)

@HammerStall that’s not the issue (the first post shows both the radians and
corresponding degrees).

@JohnLDowson cheers, I picked “log” → “offets” and added those two values as float64, with “normal log” checked:

Then opened the console, and with MSFS loaded and the Maule sitting on the runway I changed the flaps through the entire range. However, the console just says “Console Started …” and doesn’t show any output. I also tried it without the hex checkboxes, but still nothing in the console.

Hmmm, I’m looking at the default 208, and it displays the flaps angles on the
HUD, but there’s no [FLAPS_LEVELS] section in cockpit.cfg? Is there some other
place these are defined?

Why FLT64? The offsets are 2-byte each, not 8 bytes which is what a 64-bit
float would use. Try U16 for offset 30E0, and probably the same for 30FE. Also
try with an Asobo-included aircraft for comparison, as maybe the Maule isn’t
using these. Any further issues, let me know which Asobo aircrfaft you have
tried and I can take a look…

No idea why I picked 64, that should indeed have been 32, but that doesn’t
solve the question of where to actually see those values: no matter which
datatype I pick, if I check “normal log” and I open the console, I don’t see
any log entries. It just says “Console Started …” with a blinking cursor,
and nothing happens when I adjust flaps.

One thing that might be happening is that FSUIPC7 is doing things that a normal user account isn’t allowed to do. My Windows user account is set to “standard user” (for very obvious reasons), which is also not the Windows default for user accounts (for reasons not even MS can explain). As such, programs that my normal user account runs do not run with admin rights, and are absolutely not allowed to write anything to system-protected locations like the “Windows” or “Program Files” folders.

So, there’s a bit of a problem here… > The text files produced by the logging facility are called
FSUIPC7.LOG (or FSUIPC7.n.LOG files where ‘n’ is a sequence number) and are located in the installation folder The problem being that this is an illegal operation for non-admin user accounts =) Those files writes will silently fail, as the “Program Files” and “Program Files (x86)” folders have been off-limits to regular users since Vista (although iirc the last service pack for XP retrofitted it too?) which is why each Windows user account folder has its own hidden “AppData” folder with “Local” and “Roaming” subfolders. Applications then create their own folder inside either (typically “Local”) which gives them a place where they can write and modify application-specific files such as logs, inis, confs, etc. without needing any sort of special user rights, with the %LOCALAPPDATA% location automatically resolving to the current user’s “Local” folder. So, FSUIPC7 for instance would use something like%LOCALAPPDATA%/FSUIPC7 as its data location and that should be the job done, everything should work peachy (and yes, that’s a forward slash: Windows has supported those since version 1, they never not worked =)

If I run FSUIPC7 as admin (something I really don’t want to do because this application should not have system-modifying power, even if it has no code in it that would abuse that power, but since we’re testing anyway…) then I do suddenly see a log file getting written to the application’s folder. So that definitely needs fixing, no admin privileges (after installing) should be required.

With that said, monitoring the offsets as admin still doesn’t show any activity when change the flap lever in-game. The console shows the 127188 line with “starting everything now”, the .log file shows that as its last line, too, and the offsets are being monitored (I see “72484 Monitor IPC:30E0 (FLT32) = 0.00000000” and “72484 Monitor IPC:30F0 (FLT32) = 0.00000000”) but flap changes don’t log new values.

@TheRealPomax Sorry for the delay (I am not
getting notifications through for some reason).Fot a quicker response on
anything FSUIPC related, please use the FSUIPC7 support forum. You need to log
the offsets as U16 - they are documented as 2-bytes, not 8 which is what
is needed for a FLT64. I can check with the maule again later and let you know
what I see.

FSUIPC shows that it, too, does not see the same value that the MSFS HUD
shows:

What aircraft are you using? As I said, can you please try with a
default/standard aircraft and I can check here. I cannot check in the Maule as
I do not have this aircraft.

So at 0% flaps it reports the same 0 degree angle as everything else, even
though in-game the angle is -7, unfortunately.

I am suggesting that you use the % if the reported angle is wrong. If you know
that 0% is -7 degrees, and 100% is 48 degrees, you hould be avle to calculate
the current angle from the %age deflection.

That said, I’m only using FSUIPC on your suggestion specifically for this
thread, so I’ll probably not use the support forum, although if you have a
separate issue/bug tracker where folks can just submit a bug report without
signing up for joining an entire community, I’d be happy to repeat the above
findings there.

A bug report for what? If the angle is reported incorrectly by MSFS. then you
need to raise a bug reported with MSFS/Asobo - or the aircraft provider for an
add-on. FSUIPC just reports the values as received from the FS.

I have checked in a few default aircraft and get the correct angle with
TRAILING EDGE FLAPS0 LEFT ANGLE, but the aircraft have a no-flaps angle of 0
and not a negative number. Do you know of any default aircraft that also have
a negative flaps angle so that I can check? I suspect that this isn’t working
correctly for the Maule due to this negative angle. Maybe try listing the
available lvars to see if there is an lvar that holds the correct angle.
Otherwise, you should ask about this with the aircraft providers, Or, as I
said, if you know the minimum and maximum deflection angles, you should be
able to calculate the angle from the TRAILING EDGE FLAPS0 LEFT PERCENT simvar.

What aircraft are you using? As I said, can you please try with a
default/standard aircraft and I can check here. I cannot check in the Maule
as I do not have this aircraft. As mentioned, the Maule M7. I don’t know of
any Asobo planes that have negative flaps. > I am suggesting that you use
the % if the reported angle is wrong. If you know that 0% is -7 degrees, a> What aircraft are you using? As I said, can you please try with a default/standard aircraft and I can check here. I cannot check in the Maule as I do not have this aircraft.

As mentioned, the Maule M7. I don’t know of any Asobo planes that have negative flaps.

I am suggesting that you use the % if the reported angle is wrong. If you know that 0% is -7 degrees, and 100% is 48 degrees, you should be able to calculate the current angle from the %age deflection.

My code has no idea what plane it’s dealing with, it’s universal based on the surface properties it can query simconnect for. Which is why it’s going wrong on this particular airplane (and I’m not going to bake in per-plane exceptions, that’s a losing proposition)

A bug report for what?

For FSUIPC erroneously writing into its program files folder, which windows programs are not allowed to do (because if programs can edit files in program files, they can edit other programs in the program files folder too, the holy grail for any worm/virus/etc. Which is why only admins are allowed to perform file operations in protected locations like program files or the windows dir), instead of the user’s local appdata, which every windows program is allowed to do.

If the angle is reported incorrectly by MSFS. then you need to raise a bug reported with MSFS/Asobo

that is what this is

This was a bug report for Asobo to respond to, because this is where it’s telling people to file bug reports: I never intended this to be a community discussion, even if the discussion is appreciated: this was first and foremost a bug report about simconnect reporting the wrong values for Asobo to respond to.nd

100% is 48 degrees, you hould be avle to calculate the current angle from
the %age deflection. My code has no idea what plane it’s dealing with, it’s
universal based on the surface properties it can query simconnect for. Which
is why it’s going wrong on this particular airplane (and I’m not going to
bake in per-plane exceptions, that’s a losing proposition) > A bug report
for what? For FSUIPC erroneously writing into its program files folder,
which windows programs are not allowed to do (because if programs can edit
files in program files, they can edit other programs in the program files
folder too, the holy grail for any worm/virus/etc. Which is why only admins
are allowed to perform file operations in protected locations like program
files or the windows dir), instead of the user’s local appdata, which every
windows program is allowed to do. > If the angle is reported incorrectly by
MSFS. then you need to raise a bug reported with MSFS/Asobo that is what
this is
This was a bug report for Asobo to respond to, because this is
where it’s telling people to file bug reports: I never intended this to be a
community discussion, even if the discussion is appreciated: this was first
and foremost a bug report about simconnect reporting the wrong values for
Asobo to respond to.

For FSUIPC erroneously writing into its program files folder, which windows
programs are not allowed to do (because if programs can edit files in
program files, they can edit other programs in the program files folder
too, the holy grail for any worm/virus/etc. Which is why only admins are
allowed to perform file operations in protected locations like program files
or the windows dir), instead of the user’s local appdata, which every
windows program is allowed to do.

FSUIPC should not be installed under Program Files, or under any other
windows-protected folder, for this reason. I have thought about
updating/changing to use the AppData folder for FSUIPC writeable files, but
have decided against this for many reasons, but mainly due to the large user
base that already know where to locate the needed files.

Which is why it’s going wrong on this particular airplane (and I’m not going
to bake in per-plane exceptions, that’s a losing proposition)

Yes, I understand this and encounter the same issue a lot with MSFS and have
so far been reluctant to implement specific code for certain aircraft… John