Been having a lot of fun reading an SC2Replay collection through nom parsers, serializing into Arrow files so that pola.rs can read them and perform data analysis with jupyter lab, plotly or interact with SQL operations, etc.
Looking for feedback and ideas on what to progress on.
For example, "through history, are my timings getting better?". etc. Also would love to have ideas on what libraries to use to perform forecasting.
I may be the only one not familiar, but nom refers to https://github.com/rust-bakery/nom which looks like a pretty handy way to parse binary data in Rust.
I may be the only one not familiar, but nom refers to https://github.com/rust-bakery/nom which looks like a pretty handy way to parse binary data in Rust.
It's a pretty handy way to parse any sequence of things in Rust! I'm using it to write a compiler for a toy language and it's been a delight
I've also been impressed with the amount of data in SC2 replay files given the size, although I'm more interested in Broodwar (SC1) as a game. If I'm not mistaken Broodwar replay files contain a lot less information. They mainly contain player actions, i.e. you don't even know when a marine died -- the game has to literally be replayed to get that information.
I may be the only one not familiar, but nom refers to https://github.com/rust-bakery/nom which looks like a pretty handy way to parse binary data in Rust.
It's a pretty handy way to parse any sequence of things in Rust! I'm using it to write a compiler for a toy language and it's been a delight
Could you share the repo? I've been curious what nontrivial parsers look like woth nom, I always lose the overview pretty quickly.
I've also been impressed with the amount of data in SC2 replay files given the size, although I'm more interested in Broodwar (SC1) as a game. If I'm not mistaken Broodwar replay files contain a lot less information. They mainly contain player actions, i.e. you don't even know when a marine died -- the game has to literally be replayed to get that information.
The Broodwar replays were really cursed -- I remember that hilarious (perfectly reproducable) bugs of quickly replaying a game which resulted in a completely different replay then the actual game, apparently because the replay missed to integrate all replay information correctly and ended up in a different game state.
I've also been impressed with the amount of data in SC2 replay files given the size, although I'm more interested in Broodwar (SC1) as a game. If I'm not mistaken Broodwar replay files contain a lot less information. They mainly contain player actions, i.e. you don't even know when a marine died -- the game has to literally be replayed to get that information.
Is there a general name to the way the data is compressed/serialized in SC2 Replays? Yesterday somebody was talking about other ways to serialize/pack data with borsh but not sure it's at all similar...
Is the SC1 broodwar replay format similar with byte-alignment and bit "packing"?
BTW I call the parsers "bitpacked" or "byte-aligned", but I'm not sure what the right name for them is...
The DSL supports comparison operators, '&&', '||' and nested expressions, while preventing mixing of '&&' and '||' without making precedence clear using parentheses. This DSL should fit 'non-trivial', but it still should be simple enough to easily understand it.
I may be the only one not familiar, but nom refers to https://github.com/rust-bakery/nom which looks like a pretty handy way to parse binary data in Rust.
I've also been impressed with the amount of data in SC2 replay files given the size, although I'm more interested in Broodwar (SC1) as a game. If I'm not mistaken Broodwar replay files contain a lot less information. They mainly contain player actions, i.e. you don't even know when a marine died -- the game has to literally be replayed to get that information.
The Broodwar replays were really cursed -- I remember that hilarious (perfectly reproducable) bugs of quickly replaying a game which resulted in a completely different replay then the actual game, apparently because the replay missed to integrate all replay information correctly and ended up in a different game state.
Most of game corruption wasn't the result of faulty replay save / generation. Most of game corruption was the result of replays only recording user actions, and when the game engine was patched and rules were changed, re-playing the same user action could go wrong: imagine the cost of Probe getting increased from 50 minerals to 60. You load a replay that contains a "Build Probe" command when the user had 50 minerals. In the new game engine no probe will be built as the player does not have enough minerals. If this new probe was used to build other buildings, those also will not be built in the new game engine. Butterfly effect.