Extract some player attributes to data files

[glebm]

No description provided.

[glebm]

@ephphatha The header parsing function allows the columns to be in any order but do we actually need it?
I think a skipHeader() function would be fine for most of these files. I can add one in a follow-up PR

[ephphatha]

@ephphatha The header parsing function allows the columns to be in any order but do we actually need it? I think a skipHeader() function would be fine for most of these files. I can add one in a follow-up PR

You can call parseHeader() with an empty range (even nullptr, nullptr), so skipHeader could be a simple wrapper for that. e: see https://github.com/diasurgical/devilutionX/blob/b6d1dff7378491e69e8af0d390b42bcd2105c94f/test/data_file_test.cpp#L203C3-L203C3

The column heading order isn't as important in a transposed table like this PR. As a followup to #6530 I was going to effectively lift and shift the arrays to tab-separated files, which would make it more useful (one of the things commonly seen in d2 text files are comment columns which we would want to skip anyway, allowing reordering wasn't particular difficult to achieve once that was implemented).

I would be interested in seeing a fixed point equivalent to std::from_chars() for float so we don't have to get people to specify raw values, I haven't had time to dig into that myself but that was really the only thing I was considering a blocker before loading life/mana bonuses from files.

[glebm]

Thanks, I've added a simple skipHeader function based on the parseHeader one but much simpler.

As for having floats in data files, I think it's fine to just have ints. Floats introduce a whole other layer of complexity.

[glebm]

Perhaps we can simplify it further by mandating the field order as well (with validation). There isn't any need to reorder them and mods can add values to the end. What do you think?

[glebm]

Pushed the code mandating the field order in a separate commit

[ephphatha]

Perhaps we can simplify it further by mandating the field order as well (with validation). There isn't any need to reorder them and mods can add values to the end. What do you think?

Part of the aim of having arbitrary column ordering was to allow mods to group related columns to make files easier to read/modify. I can see the reason for transposing the tables and having a per-class split however I must admit I'm even less keen about having a strict row order. That said it doesn't matter what my preference is, it matters more what modders find easy to use :D

[glebm]

The mods would have to add code that reads the new values, and it's much simpler to write code that expects the values in the particular order. In the order-independent code I had a map and a variant, it was rather complicated compared to this version. So this might actually be easier for modders, though I'm also not sure.

[ephphatha]

Fair enough, I'm happy to go with this approach. It'll conflict with the initial scope of #6530 since you've used a slightly different API for exposing the PlayerData struct but I can rebase that work easy enough. I finished off the class-per-row parsing as an example of how that would be used but it's really not that much different to this approach, just means that the file structure is slightly different and the boilerplate to handle columns shifts to strict row order.

Only real hesitation I have is that I would really prefer allowing decimal representations of fixed point numbers instead of the raw 1/64 values. The fixed point parsing turned out to be fairly simple to implement so I've added that to my PR, I can cherry pick it for use here if you'd like.

[glebm]

Yeah, the fixed point parsing turned out simpler than I thought, sounds good

[glebm]

What would be the best way to merge the 2 PRs?

As I understand:

1. Fixed point 👍
2. Fixed order of fields / columns 👍
3. Files per class vs all classes in the same file -- undecided?

[glebm]

One advantage of having per-class files is that it makes it easier to add a new class -- simply copy the directory of another class and modify the values. If all classes are in the same files, one needs to then figure out which files relate to classes and manually add a row in each

[ephphatha]

What would be the best way to merge the 2 PRs?

As I understand:

1. Fixed point 👍
2. Fixed order of fields / columns 👍
3. Files per class vs all classes in the same file -- undecided?

Files per class sounds fine to me. Regarding merging the PRs the only thing we're "missing" from this PR is the extracted toHit values and starting items, it's easy enough to roll back the scope of the one I had opened and rebase it on what you've done here.

[glebm]

Done!

[AJenbo]

Nice :)