Drawing-independent event timer

Hello all, Is there any drawing-independent (in other words, which will
trigger regardless of the frame rate) WASM timer or event firing which can be
used for systems processing? I realized there’s the 6Hz event which can be
triggered but I wonder if a faster timer/event callback exist or will be
implemented? Ricardo

Bumping this please. We have multiple projects hinging on such a timer being
(or being made) available.

- Use SimConnect_AddToDataDefinition and add all the variables you need at
that update rate. If you don’t need any variables, just add any one that might
(or might not) be useful, in order to trigger the update. - Use
SimConnect_RequestDataOnSimObject, with SIMCONNECT_PERIOD_SIM_FRAME as the
“period” parameter., which is independent from the visual frame rate.

Thanks for your reply @virtuali. Will test it out.

@Virtualy I tested your solution but it seems that the update ratio is
directly tied to the visual frame ratio. I lowered my frame rate using V-Sync
On and frame rate limited and the measured time is close to the refresh rate.
The screenshot below was taken when V-Sync was on and frames limited to 30

This is what sets up the
callback for the measurement function:


I get the same results even if I change SIMCONNECT_PERIOD_SIM_FRAM E to
SIMCONNECT_PERIOD_VISUAL_FRAME. This is what I get when I also rig the 6Hz
timer measurement (which doesn’t change regardless of the frame rate lock
used) and an unconstrained frame rate:

You can see that the update
frequency is very close to the frame rate.

@ricarenado maybe it would be best if someone from Asobo would confirm if this
is by design, or if something that needs to be fixed. Historically, the
SIM_FRAME period used to be a fixed 18hz, because that’s how the flight model
used to be calculated, most likely in FSX or even before that. Then, at a
certain point, not sure if it happened with FSX or P3D, the flight model
started to be updated together with the fps so, perhaps that’s the main reason
why the two periods are now working the same. In fact, it would be nice if we
could have extra periods in addition to 6hz, I’d say a fixed 18hz and a fixed
30hz might be useful. This way, we won’t end up in the issue of, the higher
fps we get, the more traffic we generate on Simconnect. In fact, I even forgot
my own code and, since in P3D the issue is the same, to handle reads that need
frequencies higher than 6hz and not risk spamming Simconnect with too many
commands, we subscribed to the VISUAL_FRAME, with with a frame rate cap when
the event is received, like this:

if ((gTickCount.QuadPart - gLastTickCount.QuadPart) * 1000.0 / gPerformanceFrequency.QuadPart >= (1000.0 / 30.0))
  gLastTickCount = gTickCount;

I’m using the QueryPerformanceCounter Windows API, because it’s the most
precise timer in Windows ( less than 1ns precision ) and here I’m capping
updates at 30 hz. For semplicity, the gTickCount and the gLastTickCount and
gPerformanceFrequency are all LARGE_INTEGER type, which is required to hold
the extremely large numbers returned by the QueryPerformanceCounterCall. Note
that, to enable the timer, you need to put this call somewhere in the startup


Of course, the above solution will only work with an external out-of process
.EXE, which can access the Windows API. If you are using WASM, it’s likely
very different depending if you are writing a WASM Gauge or a WASM Stand-alone
module. With gauges, you can probably set one of your gauges to act as a
“ticker” for the whole airplane code, by processing updates during its
PANEL_SERVICE_PRE_UPDATE (or POST) cycle which ( at least in FSX ) would be
always called even if the Gauge wasn’t visible on screen. But I don’t know if
this is tied to the visual frame rate, or it’s still fixed at 18hz. Note that,
in a Gauge, you can use the gauges API to read the value of the TICK18 “Token”
variable so, for example, if you want to process updates at 18hz, you might
just check if the TICK18 changed value from the last time, and do updates only
if it did, otherwise skips the routine. But again, I haven’t tested if this
variable still works they way it used to in MSFS. With Stand-Alone WASM
modules, that might tricky. I’d use a POSIX timer_gettime but, checking the
comments on the time.h include file from the MSFS SDK, I can see comments like
“/* WASI has no timers */”, which doesn’t bode very well for this approach.

@Virtuali thanks for your reply and considerations. I will try the TICK18
Token variable thing you mentioned. Grazie!

where do I get SIMCONNECT_OBJECT_ID_USER ? for my C# SIMCONNECT app? I need it
to create waypoints , I think.