Alignment of data _after_ a `STRINGV` in tagged data is incorrect

[MSFS 2024] Bug Reports SimConnect
1

Version: 1.3.1

Frequency: Consistently

Severity: High

Marketplace package name: N/A

Context: SimConnect API

Similar MSFS 2020 issue: N/A

Bug description: If a SIMCONNECT_DATATYPE_STRINGV element, including its terminating zero, has a length of a multiple of 4 (a.k.a sizeof(DWORD) or sizeof(int32_t)), an extra 4 bytes of zeroes is inserted. Since 0 is a valid value for DatumID (the default is SIMCONNECT_UNUSED) this could be misinterpreted as a value with that DatumID or an unknown one.

Repro steps:

For example, If I have the Cessna 404 loaded:

		SimConnect_AddToDataDefinition(hSimConnect, AircraftData, "TITLE", "", SIMCONNECT_DATATYPE_STRINGV, 0, static_cast<DWORD>(Datum::Title));
		SimConnect_AddToDataDefinition(hSimConnect, AircraftData, "is user sim", "Bool", SIMCONNECT_DATATYPE_INT32, 0, static_cast<DWORD>(Datum::IsUser));
		SimConnect_AddToDataDefinition(hSimConnect, AircraftData, "atc id", "", SIMCONNECT_DATATYPE_STRINGV, 0, static_cast<DWORD>(Datum::AtcId));
		SimConnect_AddToDataDefinition(hSimConnect, AircraftData, "atc model", "", SIMCONNECT_DATATYPE_STRINGV, 0, static_cast<DWORD>(Datum::AtcModel));
		SimConnect_AddToDataDefinition(hSimConnect, AircraftData, "aircraft agl", "feet", SIMCONNECT_DATATYPE_INT32, 0, static_cast<DWORD>(Datum::AircraftAGL));
		SimConnect_AddToDataDefinition(hSimConnect, AircraftData, "plane altitude", "feet", SIMCONNECT_DATATYPE_INT32, 0, static_cast<DWORD>(Datum::Altitude));

		SimConnect_RequestDataOnSimObject(hSimConnect, DataReq, AircraftData, SIMCONNECT_OBJECT_ID_USER_AIRCRAFT, SIMCONNECT_PERIOD_ONCE, SIMCONNECT_DATA_REQUEST_FLAG_TAGGED);

I get:

Welcome to my first SimConnect app.
Successfully connected to MSFS.
Connected to 'SunRise' version 12.1 (build 282174.999)
  using SimConnect version 12.1 (build 0.0)
Received SimObject data for request 1, object 39403520, defineId 1, entry 1 out of 1, 6 times 8 bytes of data, remaining message size 112 bytes.
  - Data is in the TAGGED format.
Raw data:

0x0000  0x01 0x00 0x00 0x00 0x34 0x30 0x34 0x20 0x54 0x69 0x74 0x61 0x6e 0x20 0x41 0x69  ....404 Titan Ai
0x0010  0x72 0x20 0x41 0x6d 0x62 0x75 0x6c 0x61 0x6e 0x63 0x65 0x00 0x02 0x00 0x00 0x00  r Ambulance.....
0x0020  0x01 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x50 0x48 0x2d 0x44 0x44 0x47 0x00 0x00  ........PH-DDG..
0x0030  0x04 0x00 0x00 0x00 0x41 0x54 0x43 0x43 0x4f 0x4d 0x2e 0x41 0x43 0x5f 0x4d 0x4f  ....ATCCOM.AC_MO
0x0040  0x44 0x45 0x4c 0x20 0x43 0x34 0x30 0x34 0x2e 0x30 0x2e 0x74 0x65 0x78 0x74 0x00  DEL C404.0.text.
0x0050  0x00 0x00 0x00 0x00 0x05 0x00 0x00 0x00 0x5e 0x00 0x00 0x00 0x06 0x00 0x00 0x00  ........^.......
0x0060  0x51 0xff 0xff 0xff 0xfd 0xfd 0xfd 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00  Q...............

Aircraft title is '404 Titan Air Ambulance'.
This IS the user's aircraft.
Aircraft ATC Id is 'PH-DDG'.
Aircraft ATC Model is 'ATCCOM.AC_MODEL C404.0.text'.
Skipping 32 unused byte(s).

The Id 0 is not used and causes the code to stop retrieving data after the ATC model. This field starts at 0x0034 and ends at 0x004e, with the terminating zero at 0x004f. The next 4 bytes are zeroed. The aircraft is parked at EHGG which is below sea level BTW.

If I remove the “break at unknown DatumID”, I get:

Aircraft title is '404 Titan Air Ambulance'.
This IS the user's aircraft.
Aircraft ATC Id is 'PH-DDG'.
Aircraft ATC Model is 'ATCCOM.AC_MODEL C404.0.text'.
Aircraft is 94 feet above ground level.
Aircraft is 175 feet below sea level.

Attachments:

Private attachments:

2

Hello @BenkeiBuddy

This is the expected behavior, variable length strings are 4 byte aligned when read through SimConnect.
I’ll make sure a mention is added in the documentation.

Regards,
Sylvain

3

Hmmm, ok.

What I thought as the correct alignment:

  size_t len = strlen( &(buf[offset]) ) + 1;
  if ( (len % 4) != 0 ) { // need alignment
    len += 4 - (len % 4); // add 1-3 if needed
  }
  offset += len; // Next field

But it should be:

  size_t len = strlen( &(buf[offset]) ) + 1;
  offset += len + 4 - (len % 4); // add 1-4 as needed
4

Hello @BenkeiBuddy

I am sorry, I misread your post completely.
There is indeed a problem with the returned ATC_Model string.
I think the string size takes the TT: prefix into account even though it’s not returned.
I will investigate this further.

Regards,
Sylvain

5

Ah, this has to do with the returned value not being the actual ATC Model, but a reference to an aircraft.cfg field that hasn’t been provided? I see the returned string is actually longer than the 10 characters the docs say this value will be limited to.

AFAIK the model code is not commonly used for “smaller” aircraft addons, but according to the ICAO it should be C404 or C04T. (if equipped with turbine engines) Better tell Carenado.

6

@FlyingRaccoon Do you have any update on this? Is a STRINGV value of a length ((x * 4) + 3) (not counting the terminating zero) consistently padded with 4 zeroes or only in this case? SimConnect_InsertString appears to work correctly (in that it does not add the spurious 4 bytes), so it must be some code that does not use this helper.

7

Hello @BenkeiBuddy

A fist fix was introduced with the first version of SU3 beta to address the incorrect alignment.
So it’s still 4 bytes aligned but you shouldn’t have padding when the string size is already a multiple of 4.

The issue with localization is not fixed yet however.

Regards,
Sylvain

1 Like
8

@FlyingRaccoon just FYI-
the documentation mentions that these variables (ATC MODEL etc) are maximum 10 characters. This leads people to believe a SIMCONNECT_STRING32 is sufficient length to receive them. However, tests show that there can be any length string coming back (I had one for a Caravan that was 33 characters long).

I think the documentation needs amending and a sample on how to retrieve those is necessary…

9

I will have this reviewed.

Regards,
Sylvain

1 Like