Let's say, that there is a list of all territories with sizes. Let's even say, that you are given a list of all 3200 territories of Europe Huge with sizes. How then realistically will you calculate "the total delta in armies saved from a hospital upgrade over all remaining territories"?
You loop over the list of territory sizes and apply as much of the hospital savings as possible to them, then sum all those numbers together. Example:
Hospital saves: 1M -> 2M
Territories: [500k, 1M, 1.5M, 5M, 10M]
500k: 0 (already free)
1M: 0 (already free)
1.5: +500k
5M: +1M
10M: +1M
Total delta = 2.5M
This is still a slight underestimate because it doesn't account for territories close to hospitals where they're more effective, and taking care of that would require
also having the adjacency information for the territories... but I don't feel too bad about handwaving that.
These pages are benevolently generated by pkmx from my original table (without the need for me to redo the code for table generation). What for exactly do you want to parse the source of the table?
For example, in the posts above, the Idle style numbers like 25k and 1M need to first be converted to actual numbers (25000 and 1000000, respectively) before they can be added together. If you only want to display the numbers and not do any numerical operations on them, then it doesn't really matter, but this thread found a new use for this data where it does matter.
Another possible case would be if you wanted to sum up all of the resources required to buy the techs (so you could answer questions like, "How many total Nails do I have to craft on EH?" and "How many Iron and Tin Bars do I have to buy for the aforementioned Nail crafting?"). That would require parsing out the substrings for each item/bar and then also the count for them, and similar for the recipes.
In a more data oriented format, you wouldn't need to
parse the data out, but merely look up the relevant keys. Having only a single CSV representing mixed data makes that a lot more difficult though. If we used JSON instead to represent this line in the CSV:
2,Huruey's Castle,Tech Recipe,!MS: Faster Smelters,"Requires: Tin Bar x184, Copper Bar x747",,
...it might look something like this:
2: {
"name": "Huruey's Castle",
"techs": {
/* other techs... */
"faster-smelters": {
"copper-bar": 747,
"tin-bar": 184
}
},
"recipes": {
/* recipes */
},
/* other level data */
}
Whether "faster-smelters" is a market strat tech or not would ideally be defined in a separate data structure so it doesn't need to be repeated. Similarly, the level name and ID don't need to be repeated many times (once per line in the CSV). But, most importantly, you can now just loop over data[2]["techs"] to find all the tech requirements without having to parse them out of strings. How you ultimately present this information to a human is up to your presentation layer, but it allows for a lot more flexibility for new use cases and/or desire to change presentation format (both of which tend to be fairly common).
