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

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:

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

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

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

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.