#1 Array handling for data values

[Hielor]

Orb:Connect can push arrays of data elements, such as with:
Doors: List of ints
DoorsPos: list of int/double pairs
SysStatus: list of ints?
Engines: list of structs of the xr engine type
RCSDockingMode:
StatusMsgs: list of strings

Suggested implementation:
I don't think there's an easy general-case solution to a csv of heterogenous values, other than having it be a string. I think our best bet is to have a struct type for any complex structures (like a DoorPos struct or a an Engine struct). If the MFD or Display wants a semicolon-separated set of a comma separated values (as in the DoorsPos or Engines messages), they request, for example an std::vector<engine> by DATATYPE_STDVECTOR | DATATYPE_ENGINE.</engine>

Allowing multiple different return types is a real PITA. Say, for example, you have a message which returns two vectors (like the RelPosVel will). If you treat this as two VECTOR3s, you logically want the first set of 3 doubles to be index 0 and the second set of 3 doubles to be index 1. If, however, there's another display treating that same return value as six doubles, it's using a completely different indexing system and you'll end up with either VECTOR3 index 1 being doubles indexed <1, 2, 3> or double index 3 being returned for index 1.

How about: A display can specify two indices for a value--a major index and a minor index. A "major" value is anything separated by semicolons; a "minor" value is anything separated by commas. Then, while a major value is being parsed (say, a display which has requested a vector of all the Engine replies), it can check to see if there are any minor values within that major value and dispatch those too. So if we had a struct Foo which was two ints and a double, and a mesage GetFoos which returns a semicolon-separated list of Foos, a possible reply would be:

1001=0,1,2.0;3,4,5.0;6,7,8.0;9,10,11.0

You could then have a display requesting the message as a DATATYPE_STDVECTOR | DATATYPE_FOO (with major index 0 and minor index 0), which would receive a (std::vector<foo> ) (as a void ) thusly:
std::vector
0: Foo {0, 1, 2.0}
1: Foo {3, 4, 5.0}
2: Foo {6, 7, 8.0}
3: Foo {9, 10, 11.0}</foo>

Simultaneously, you could have a display requesting major index 1, minor index 0 as a DATATYPE_FOO, which would receive a (Foo ) (as a void ) of Foo {3, 4, 5.0}. You could also at the same time have a display requesting major index 2, minor index 1 as a DATATYPE_INT, and it would receive an (int ) (as a void ) of int (7), and these wouldn't interfere with each other.

Then you have an issue where if you had a message returning six doubles ("0,1,2,3,4,5") and you tried to get it as two vector3 values, they would be at major index 0, minor index 0 (for <0,1,2>) and major index 0, minor index 3 (for <3,4,5>). That, however, is at least consistent and explainable, even if it's not 100% intuitive.