new tool: gui/export-world-map - #1606
Conversation
1ecec90 to
8e88b02
Compare
|
58f77d0 to
109cc47
Compare
SilasD
left a comment
SilasD
left a comment
There was a problem hiding this comment.
No red flags in the GUI script. Some quibbles and some questions, but nothing to hold up accepting the PR.
I'll do the other scripts later, I have to go grocery shopping.
SilasD
left a comment
SilasD
left a comment
There was a problem hiding this comment.
no red flags, it all looks reasonable. another question and a quibble or two.
|
|
||
| for _, geo_biome in ipairs(df.global.world.world_data.geo_biomes) do | ||
| for _, layer in ipairs(geo_biome.layers) do | ||
| out:write(('%s;%s;%s;%s;%s\n'):format( |
There was a problem hiding this comment.
why semicolons when the output is named as a CSV file? Comma-separated values
(later) I see you're using this for most/all output files. I'm not going to comment on each occurance.
as an aside, I've never understood why people use the idiom
("a format string"):format(val, val)
instead of
string.format("a format string", val, val)
treating it as a sprintf-alike
if the format string is already defined, it makes sense, sure. but that's so seldom the case with string.format.
There was a problem hiding this comment.
why semicolons when the output is named as a CSV file? Comma-separated values
(later) I see you're using this for most/all output files. I'm not going to comment on each occurance.
This is a case of Europeans doing European things: https://discord.com/channels/793331351645323264/1340358673003712654/1540610890192134195
However, I agree that this should be documented for the benefit of others.
There was a problem hiding this comment.
BTW, the rule for when you use a semicolon is "if the decimal separator is a comma, then the CSV separator is a semicolon, otherwise it's a comma". Microsoft's locale processing does this for you (they have a ListSeparator element in their locale library which is inferred using this rule) but in POSIX (and thus in the C++ standard, which is heavily POSIX-leaning) you have to do it yourself.
Most CSV libraries will accept either. Arguably, the best approach is to grab the current locale, identify its decimal separator, and from that infer whether a comma or a semicolon is most appropriate.
std::locale current_locale = std::locale{""};
auto const& numeric_facet = std::use_facet<std::numpunct<char>>(current_locale);
char decimal_sep = numeric_facet.decimal_point();
char list_sep = decimal_sep == ',' ? ';' : ',';There was a problem hiding this comment.
I really would prefer if output of the world export tools would not depend on the user's locale. As far as I know, no other behavior of DFHack depends on it. If only you knew how much grief Microsoft's locale-dependent interpretation of CSV has caused on this side of the Atlantic...
Moreover, while semicolons do not naturally occur in our data, commas very much do
plant_pops.csv:736;Grass;BAMBOO, GOLDEN;10000001;10000001
plant_pops.csv:737;Grass;BAMBOO, ARROW;10000001;10000001
plant_pops.csv:746;Grass;BAMBOO, HEDGE;10000001;10000001
sites.csv:1434;-1;-10000;-1;lair;Emanomba Etrujulosm;Birdsrivers the Earthen Crab;NONE;NONE;NONE;NONE;NONE;POLYGON((84336 -52896,84384 -52896,84384 -52944,84336 -52944,84336 -52896))
The commas inside the WKT geometries obviously affects all layer files, including those generated by the C++ plugin.
Currently, all exports get away without doing any escaping. If you want commas, you also will get escaping.
There was a problem hiding this comment.
＜meme＞ Um, ackchyually, ＜/meme＞
We've got a couple of locale-specific numbers. The trade overlays format prices per locale, and the notifications floating overlay formats time-since-last-save per locale.
Which is just quibbling really.
Commas crop up in the exported data; I think that's a good enough reason to go with semicolons. All good.
|
looks great. |
3 participants
Depends on DFHack/dfhack#5376 to be merged first.