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
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