how is whitespace interpreted in .2da tables?

[subtledoctor]

Take a table like weapprof.2da or mxsplwiz.2da.  They both have a total of n columns.  They have one row with n-1 columns, and then a bunch of rows with n columns.  It looks like this:

     A    B    C
Y    1    0    0
Y    1    1    0
Z    1    1    1

Now, when doing things like SET_2DA_ENTRY, my understanding is that it treats column #0 as (A,X,Y,Z) and column #1 as (B,1,1,1) and column #2 as (C,0,0,1).  In other words the whitespace in front of "A  B  C" is ignored.  Also, I'm pretty sure that doing something like PRETTY_PRINT will remove that whitespace and just line up the columns like I just described:

A    B    C
X    1    0    0
Y    1    1    0
Z    1    1    1

Now, the question is, is there any difference in how those two tables work in the game?  My assumption was the answer is "no."  There is still the same number of columns in every row, and everything is oriented the same... it is only missing some whitespace in that first row.  Is this assumption wrong?  I just had a bug report imply that the whitespace there matters, and Jarno acted like his usual trolly self, saying "duh, of course that's broken" without pointing to an actual explanation of how it works.  Can anyone set the record straight once and for all?  (If those two tables are functionally different, it's a bit of a problem because AFAICT Weidu treats them as functionally the same, and can have the effect of mangling them in ways that won't be obvious to the modder using it.

[Sam.]

Have you read the 2DA file format spec?  My impression (although I haven't done much in terms of working with 2DAs) is that if the first two rows are missing, the top row is treated as the headings row.  I think the headings row is there for human convenience and not needed by the engine.  You could try replacing it with randomly spaced junk and see if the engine chokes, but I don't think it will.

 

[DavidW]

PRETTY_PRINT_2DA is actually cleverer than that. It lines up all the columns, but it knows to indent the third line one step. (You can actually give it a variable if you want it to indent a different line.)

I am reasonably confident that the engine has no interest in how the whitespace is arranged, but it doesn't do any harm to throw a PRETTY_PRINT_2DA in there, if only as a courtesy to people viewing modded files in Near Infinity.

[subtledoctor]

Thanks for confirming that.  It's probably worth making this absolutely clear, especially since the IESDP doesn't.  The IESDP says this:
 

Quote

2DA files should always contain at least four rows;

The first row contains the file signature, "2DA V1.0", which may be preceeded by white space.
The second row contains the "default value" for the file.
The third row contains column headings.
Subsequent rows consist of row data.

Any cell (i.e. row/column intersection) which does not contain a value is assumed to have the "default value".

A sample file appears below.

2DA V1.0
1234
        NAME    VALUE   WEIGHT
A       alpha
B
C       beta    2345    123

 

It speaks about "row/column intersections" but doesn't make clear that all whitespace is counted as the space between two entries, not matter how large or small.  So contrast the above table with this:

2DA V1.0
1234
        NAME    VALUE   WEIGHT
A                       alpha
B
C       beta    2345    123

Here, the "alpha" entry appears to be in the same column as "WEIGHT" and "123."  But it is not.  In both of those tables the value "alpha" is under the "NAME" column, and in both tables, row A equates to

A    alpha   1234   1234

They are identical, in other words; the default value is only inserted in any blank "row/column intersections" to the right of existing entries.

The bug reports about column headings had me worried that whitespace to the left of the first entry somehow mattered; and the IESDP is silent as to whether that counts as a "row/column intersection."  But even if it were, inserting a default value there would be contrary to the way the game generally handles insertion of the default value (i.e. only to the right of existing entries, as I described above).  So my confidence is renewed that if some Weidu operations shift the placement of the header row entries by reducing or even eliminating the whitespace on the left side, it should have no impact on gameplay.

Edited July 7, 2020 by subtledoctor