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

how to free SC structs?

Messages
19
Country
poland
Hello FS Devs.

SC sends responses to all kinds of requests in the form of various structs like SIMCONNECT_RECV_SIMOBJECT_DATA. The way I understand this SC needs to allocate a memory segment every time to populate such a struct with whatever data was requested. My question is how and when this memory is freed? Is it that if I request values of a hundred of vars every simframe for a longer period of time I may run out of mem ? Or perhaps the struct is valid only until my dispatch callback returns ?

Any help, guys ?
 
What language? C/C++ and you would have to manage the memory yourself I think. Managed languages like C#/VB.NET do garbage collect automatically but it is still sensible with this sort of thing to dispose of objects yourself when they go out of scope.
 
I think the memory is cleared (re-used) on the next RequestDataOnSimObjectType
 
Well since it's the SC runtime that is maintaining that data buffer I don't suppose I can just free() it.

My question is whether the sc library ever invalidates the pointer to that buffer or is the struct kept in memory for the life time of the program ?
 
Hello FS Devs.

SC sends responses to all kinds of requests in the form of various structs like SIMCONNECT_RECV_SIMOBJECT_DATA. The way I understand this SC needs to allocate a memory segment every time to populate such a struct with whatever data was requested.

AFAIK memory is allocated in a previous step, with a call to SimConnect_AddToDataDefinition. Afterwards the updating frequency, amongst other process, is defined in SimConnect_RequestDataOnSimObject when SC starts. Finally, with SIMCONNECT_RECV_SIMOBJECT_DATA it is possible to fill a predefined data structure with the data contained in the portion of memory allocated by AddToDataDefinition, which is being constantly refreshed with the frequency selected. (once/frame;once/second; etc).

My question is how and when this memory is freed? Is it that if I request values of a hundred of vars every simframe for a longer period of time I may run out of mem ? Or perhaps the struct is valid only until my dispatch callback returns ?

Memory can be freed by different ways; for example:

-Issuing a SimConnect_ClearDataDefinition with the proper DEFINITION enum.
-Closing SimConnect with SimConnect_Close(handle) function.

Tom
 
Thank you for the reply Tom!

I must say I can't agree with what you say about the data buffer being reserved by adddatadefinition calls.

First, you can request data form different objects based on the same data definition.

Second, when you request the data in tagged format the size of data returned can be different on every period. At the time you create the definition it's not even known if the data will be requested in tagged or plain format.

For those two reasons alone the buffer has to be completely separate from the def.
 
First, you can request data form different objects based on the same data definition.

All of sim variables grouped in a unique data definition are treated as elements of a unique memory structure. For example, if you have DEFINITION_1, and add to this definition "Kohlsman setting hg","Plane Altitude","Plane Latitude" and "Plane Longitude" AVars, Simconnect will reserve a memory block taking into account their data types (FLOAT64 by default). Data block will be received and typecasted according to the structure you had created previously for that matter:

struct Struct1
{
double kohlsmann;
double altitude;
double latitude;
double longitude;
};

and

Struct1 *pS = (Struct1*)&pObjData->dwData;

See the Request Data example from the SDK.

At the time you create the definition it's not even known if the data will be requested in tagged or plain format.

When you create the definition you must indicate whether a tagged format might be required instead of the default plain format:

From the SDK:

DatumID
[in, optional] Specifies a client defined datum ID. The default is zero. Use this to identify the data received if the data is being returned in tagged format (see the flags parameter of SimConnect_RequestDataOnSimObject). There is no need to specify datum IDs if the data is not being returned in tagged format.


Examples:

Plain format:
Code:
	hr = SimConnect_AddToDataDefinition(hSimConnect, DEFINITION_1, "Plane Longitude", "degrees");

Tagged format:

Code:
       hr = SimConnect_AddToDataDefinition(hSimConnect, DEFINITION_PDR, "Pitot Heat", "Bool",SIMCONNECT_DATATYPE_FLOAT32, 0, DATA_PITOT_HEAT);


See Request Data and Tagged Data examples from the SDK.


Tom
 
Just because you specify TagID during data definition doesn't mean you will have to request the data in tagged format. You can still request it in plain format depending on what flags you pass whet requesting data on sim object.

But that's not what I was asking for. Let's assume I have one definition with several vars. Then I request the data specified by that definition on user aircraft every frame in plain format all the data every frame (not only changed). And also I request data on each and every AI plane around based on the same data definition I used to request data on user plane but this time in tagged format and only if the data is changed.

This means that I'll be receiving several responses during every frame with pointers to different data even though it'll be defined by this same definition. My original question was for how long will those buffers hold valid data. Is it only until my dispatch proc returns?
 
I believe that data structures passed to a simconnect client are cleared up by the client simconnect library.

I base this on my previous observation that if you copy the pointer passed to a global and then check the contents after subsequent simconnect callbacks, you'll see the contents are corrupted.

Therefore I assume that the memory is cleared once control returns from the callback to the calling code within the simconnect.lib.

If this weren't the case, I don't think MS would have neglected to document the required for manual clean-up or miss it out of all their examples.

Si
 
Back
Top