-
Notifications
You must be signed in to change notification settings - Fork 792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tab-delimited data file format for tabular data (using Experience.txt as an example) #6399
Conversation
Got it far enough to actually load from a file alongside assets, but it needs to be written with the correct includes etc to actually compile on non-msvc compilers... I'm also not sure if burying files under the assets directory is desirable or we'd rather have another asset include directory specified in the Cmake files so text files can be easier to discover. Something to think about later :) |
Don't beat your self up like that, it also compiled successfully on GCC 13.1... specifically |
I have been thinking that maybe it would be wroth it to move the whole assets folder out now that there is a lot more going on in it and things are getting more data driven in general. |
So, uh, can we move to C++17? 😄 The ParseInt helper glebm has in #6175 would be usable but the way from_chars returns a pointer indicating the end of parsing even in out_of_range failure cases is useful. Ultimately it doesn't matter if I scan over fields twice since it's only loaded once when the app starts. |
52602d9
to
a7909c8
Compare
e3ccb3e
to
894cac2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use the .tsv
file extension so that files are displayed as tables on GitHub.
Ah I see, yeah, let's use |
Was meaning to comment on this earlier as well, I originally used the exact naming convention used by D2 text files (TitleCase.txt) thinking that was gonna be less controversial 😄 . Using .tsv for nicer formatting on GitHub is a good reason to go with that extension (even though the files don't actually comply with text/tsv). |
c44c9df
to
d30a1cf
Compare
d30a1cf
to
dd28f39
Compare
Forgot to comment on this one too. |
dd28f39
to
7927173
Compare
cb9ed79
to
80e4206
Compare
No real need to persist this value
Also added an iterator based API, though it's not useful for this use-case. Might be nice in the future? The field/record iterators is single-pass input iterators with shared state. To avoid rescanning fields unnecessarily parseInt currently can only be called once, it would be possible to make these iterators bidirectional with a bit of extra state (holding onto the start pointer) Co-authored-by: Gleb Mazovetskiy <[email protected]>
Intended to support #211, this documents a loose Tab-delimited format similar to IANA TSV and Linear TSV with the following key differences:
\
t
byte sequences to a tab character). Existing Diablo 2 data files use paths with backslash characters that frequently precedet
,n
,r
characters like "act5\nihlathakmusic.wav" which would conflict with using this type of extension across the board.\N
sequence used by Linear TSV for this purpose commonly appears in paths like "Act5\Nihlathak\nih_act5_q3_after.wav".This allows effectively streaming through files with generic code similar to what DakkJaniels posted in discord: Try it online!
or with more specific parsing like: Try it online!