• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

dwDefineCount always increasing in simconnect

Dear all,

I've been having a problem with the sim frame rate slowly decreasing over the course of 45 mins or so and have been trying to figure it out.

Visual Studio says the CPU is executing external code and using trial and error (and disabling bits until it works properly) I've found that it's something to do with simconnect.

Everything seems to work as normal, all I can see is that when I receive data (in the SIMCONNECT_RECV_SIMOBJECT_DATA struct) the dwDefineCount is always increasing. I know the SDK isn't always quite as complete and accurate as we would like but I was fairly confident that this was just saying how many 8 byte elements are in the array. The data I'm expecting to receive seems fine, everything runs as expected, it's just that, over time, the sim gets bogged down, I'm guessing by transmitting ever increasing amounts of data.

I'm expecting about 50 odd variables (all FLOAT64) but the dwDefineCount keeps increasing, at about 215000, the frame rate is down to about 10.

I want to check I'm not being a numpty, is there some 'release' or 'free' command that I should be using after I've received the data, at the moment I just memcpy it to the local structure and carry on.

I've checked I'm not repeatedly calling SimConnect_AddToDataDefinition and I'm not, just the once to set it up.

Data added to the definition with:
SimConnect_AddToDataDefinition(hSc, DEF_FSX_SIM_DATA, "GENERAL ENG MIXTURE LEVER POSITION:1", "percent");
Obviously there's lots of them but they all look like the above.

The data request is called once:

When received, the data is copied with:
memcpy(&sc_fsx_sim_data, (_SIMCONNECT_FSX_SIM_DATA*)&pObjd->dwData, sizeof(_SIMCONNECT_FSX_SIM_DATA));

The data received is all correct, I don't really know what it's padding it with, does anyone know why it's doing this and how I can stop it?

Many thanks,

P3Dv4 and 5.
It normally takes about 10 mins to notice the fps being lower than usual, after 20 it's noticably choppy and by 45 it's unflyable. For a long time I thought the choppyness was just due to my constantly stopping and starting it in the debugger but more recently I've noticed it happening when I'm not debugging.


Resource contributor
I asked because the slowdown was a known problem in P3Dv5.1 but has been fixed since. I see that you are using the reference operator to grab the incoming data, so just one thing possibly stands out on this:

- are you cleaning sc_fsx_sim_data with memcpy() before accepting the data?

Just FYI, this is a brief outline of how I collect recip engine data into a struct (DEFINES and REQUESTS assumed):-
// Recip engines
struct recip_engine
    double antiIce;
    double alternateAir;
    double brakingPower;
    double carbTemp;
    double combustion;
    double coolantResv;
    double cowlFlaps;
    double cht;
    double egt;
    double genActive;
    double genSwitch;
    double hydPressure;
    double hydQty;
    double magLeft;
    double magRight;
    double manifoldPressure;
    double mixtureLever;
    double mixtureRatio;
    double masterAltSwitch;
    double primer;
    double radiatorTemp;
    double rpm;
    double rpmMax;
    double rpmReached;
    double starter;
    double starterActive;
    double starterTorque;
    double throttle;
    double tit;
    double tcFail;
    double vibration;
    double wastegate;
    double masterMag;
    double oil_burn;        // Amount of oil burned per hour. Not part of simconnect. See (usually) startup.cpp for applied burn rate
recip_engine pRecip1;
recip_engine pRecip2;
recip_engine pRecip3;
recip_engine pRecip4;

** Received by a SimobjectData call **

// Reciprocating engines - struct in simconnect_recip_engines.h
    if (pObjData->dwRequestID == REQUEST_ENGINE1_RECIP)
        recip_engine* pRecipEngine1 = (recip_engine*)&pObjData->dwData;
        pRecip1 = *pRecipEngine1;

    if (pObjData->dwRequestID == REQUEST_ENGINE2_RECIP)
        recip_engine* pRecipEngine2 = (recip_engine*)&pObjData->dwData;
        pRecip2 = *pRecipEngine2;

    if (pObjData->dwRequestID == REQUEST_ENGINE3_RECIP)
        recip_engine* pRecipEngine3 = (recip_engine*)&pObjData->dwData;
        pRecip3 = *pRecipEngine3;

    if (pObjData->dwRequestID == REQUEST_ENGINE4_RECIP)
        recip_engine* pRecipEngine4 = (recip_engine*)&pObjData->dwData;
        pRecip4 = *pRecipEngine4;

It's not efficient but my whole Simconnect setup was written as modular WORM code (write once read many).
Last edited:
Thanks for your reply, I finally nailed it down after much debugging...
I had a stray AddToDataDefinition in a random bit of code in the main timer function, probably a Ctrl-V mistake that I didn't notice, meant that as time went on the data requested increased in size.
Feeling a bit silly but was unlucky my Ctrl-V mistake happened in a piece of code that just happened to have full knowledge of all the variables required to succesfully compile and process the errant instruction. On the upside I've now fully tested the logging and simconnect connection for this project...
Thanks again,