question

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

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

hr = SimConnect_RequestDataOnSimObject(hSimConnect, REQ_DATA, DEF_DATA, SIMCONNECT_OBJECT_ID_USER, SIMCONNECT_PERIOD_SIM_FRAME);

I get the same results even if I change SIMCONNECT_PERIOD_SIM_FRAME 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:

QueryPerformanceCounter(&gTickCount);
if ((gTickCount.QuadPart - gLastTickCount.QuadPart) * 1000.0 / gPerformanceFrequency.QuadPart >= (1000.0 / 30.0))
{
  gLastTickCount = gTickCount;
  // DO YOUR STUFF
}

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

QueryPerformanceFrequency(&gPerformanceFrequency);

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!