Welcome to
Microsoft Flight Simulator’s SDK Q&A Platform!
Please take a moment to read the platform’s guidelines before you get started!
Good day all,
When I use the SetDataOnSimObject function from the SDK at a high frequency, for example at every frame (through a SIMMCONNECT_RECV_ID_FRAME event for instance) , after a few minutes, SimConnect crashes with the following message:
I/O Error! (2, 80004004).
This does not happen though on lower frequencies (like 6Hz or every second).
Is this something known ? And if yes, is there a workaround ?
Hi
Yes, it might be the problem or a part of the problem.
Most of the struct returned by SimConnect don't have padding. So if on your side, your struct has padding, you will try to read more memory that you should which leads "in the best case" to random and false data in your sruct, and to a crash in the worst case.
So for those struct you should use:
// C++
#pragma pack(push, 1)
struct MyStruct
{
// ...
};
#pragma pack(pop)
// C#
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 1)]
struct MyStruct
{
// ...
}
Does it solve the crash even in "high frequency"?
Best Regards
Maxime / Asobo
Hi,
There is no such limitation. Even if you use SetDataOnSimObject at "high frequency", the sim (and the client) should be able to handle that.
Note that you external app has (in general) a higher frame rate than the sim.
I'm afraid that there is no workaround for now but I would be interested by your project and a good way to repro, so I can investigate.
Best Regards
Maxime / Asobo
Hi
As documentation says:
IOException is the base class for exceptions thrown while accessing information using streams, files and directories.
In our case, the problem comes from the reading of messages sent by server in the client part. As depayns said, it might be linked to "reading to much data" because of padding issues.
Best Regards
Maxime / Asobo
Bonjour Maxime,
Happy to provide some info about that.
Roughly:
I am interfacing a non visual simulator ( PSX 744 ) to MSFS to have a scenery generator.
I want to control the plane through external variables (lat, long, pitch, bank angle) provided by PSX.
In order to do so:
0/ Disable ALT LAT, LONG and ATT via: EVENT_FREEZE_ALT, _ATT, _LONG_LAT
1/ I fetch the external variables from PSX in a struct.
2/ I Subscribe to the system event EVENT_FRAME
3/ In my callback function, if the EVENT_FRAME is triggered, I update MSFS via a call to SetDataOnSimObject.
But as I mentionned, if I run the update for example in the 6Hz system event, there is no such error.
Hi,
Can you provide me with your source code (or a sample which reproduces the problem)?
As you said and as Kaiii3 said, this issue happens randomly/after a few time... so this is not something linked to the function itself but this is a side effect of something else.
Basically, without a sample, the only thing I can try is the calls mentioned in your point 0, 2 and 3. The PSX part is missing and every thing else is missing too. So there is no way i can track a side effect with that.
You can send it in private by following the third section of this link:
https://devsupport.flightsimulator.com/articles/5483/how-to-report-a-bug-or-crash.html
Best Regards
Maxime / Asobo
And just wondering... does the struct packing have a potential effect here ?
My struct size was 224 bytes, and that caused the problem.
Reducing the size to an aligned struct seems to solve it (but I am still testing)
Hi guys,
Sorry to get back on this topic, but actually now I found the real cause of those crashes.
Padding the structures improved a lot, but after some heavy testing it still occasionally crashed.
It turns out actually that SetDataOnSimObject is not thread safe. And in some occasions this might cause a crash of SimConnect with the above mentioned error.
The solution was to MUTEX the access to SetDataOnSimObject and this indeed solved totally the issue.
Hope this might help other people having a similar problem.
This leads to the following question: are all functions in the SDK thread unsafe ?
5 People are following this question.
