`sc2reader` vs `s2protocol`?
Closed this issue · 3 comments
Hello,
I would like to understand the relationship between this project here and blizzards own https://github.com/Blizzard/s2protocol
It seems both sc2replay and s2protocol use mpyq in order to open the replay files and both are able to decode the binary contents into Python structures.
From s2protocols acknowledgements it seems to me sc2reader was there first.
From my personal point of view the difference is that sc2reader is actually usable by normal people, while s2protocol is missing even the most basic examples explaining how to use the project and how to understand the replays file contents. Also sc2reader seems to have more contributers.
But it seems maintaining two different binary decoders for one and the same data is quite some overhead. And having blizzard as a company maintaining the "ugly" binary part sounds quite nice to me.
So my question would be, has there ever been a try to merge these two projects in some way? maybe by just importing s2protocol for the binary parsing part and then "just" providing a much nicer user facing interface?
s2protocol came a few years after sc2reader. s2protocol was very useful because when Blizzard changed/changes the format of the replay file, they would push an update to s2protocol so we could see what had changed. Much better than trying to reverse-engineer things.
sc2reader does more than s2protocol — it's been a while so I'm fuzzy on the details, but I clearly recall that sc2reader coalesced and organized the information in the replay in a useful way, whereas s2protocol does the bare minimum to put the raw replay data into data structures, but these raw data structures do not directly answer any of the questions you would have about a replay, and without a library like sc2reader you would essentially need to replicate it if you weren't using it.
If s2protocol had already existed when sc2reader was being built, I bet @GraylinKim would have built sc2reader as a layer on top of s2protocol. Or at least use their data-structures in some declarative way to guide the parsing.
Sneaking s2protocol in now under the dishes must be possible, but I have no idea how much work it might be.
To answer your question, I'm not aware of any attempt to merge the projects.
Thanks David for this background information.
sc2reader coalesced and organized the information in the replay in a useful way, whereas s2protocol does the bare minimum
this was also my impression. While what you say below is indeed a good point:
Sneaking s2protocol in now under the dishes must be possible, but I have no idea how much work it might be.
Maybe in addition to the question of cost, also the question of cost benefit ratio might be interesting: Looking at the update frequency of the s2protocol versions folder, one can see that they seem to pump out a new version every 2 weeks or so....
Looking at the update frequency of the s2protocol versions folder, one can see that they seem to pump out a new version every 2 weeks or so....
s2protocol has an automated system, so they basically generate the mappings file for particular SC2 build regardless of the fact whether it has changed or not.
It can be clearly seen here:
$ fd proto -e py -x md5sum {} | sort -k 2,2
0cb6a92b083aa540daa74d9020f10d64 protocol15405.py
893d585a62ec30cc99c342c7fd62f60e protocol16561.py
893d585a62ec30cc99c342c7fd62f60e protocol16605.py
893d585a62ec30cc99c342c7fd62f60e protocol16755.py
893d585a62ec30cc99c342c7fd62f60e protocol16939.py
1b4a676349f142e5b9ea1c449d706282 protocol17266.py
1b4a676349f142e5b9ea1c449d706282 protocol17326.py
1b4a676349f142e5b9ea1c449d706282 protocol18092.py
698379e589071440c5a499b635bd50a5 protocol18468.py
698379e589071440c5a499b635bd50a5 protocol18574.py
d1f6a76d6c47335c6b045fd717b2f706 protocol19132.py
36cdc7060fea9891bc4c2c4b781005a7 protocol19458.py
36cdc7060fea9891bc4c2c4b781005a7 protocol19595.py
36cdc7060fea9891bc4c2c4b781005a7 protocol19679.py
36cdc7060fea9891bc4c2c4b781005a7 protocol21029.py
417ddbd683450898f7bcf433933b52e4 protocol22612.py
c463e993f2ee53350dc8ad52f0a8e430 protocol23260.py
82917253340c608fcf756151d97d01c7 protocol24944.py
306150a7dc39939efa7b6937bde2108c protocol26490.py
d214700274248426917158ea570cfb6f protocol27950.py
d214700274248426917158ea570cfb6f protocol28272.py
d214700274248426917158ea570cfb6f protocol28667.py
8e6d4ed77129a5fc2f181e756eee6ee4 protocol32283.py
a879d668143ea701b667b3dd998968bd protocol51702.py
a879d668143ea701b667b3dd998968bd protocol52910.py
a879d668143ea701b667b3dd998968bd protocol53644.py
7be3bd7e2248fe7335395bdd173cb0f9 protocol54518.py
9aceaddfa97b2389784e2715316a725f protocol55505.py
9aceaddfa97b2389784e2715316a725f protocol55958.py
9aceaddfa97b2389784e2715316a725f protocol56787.py
9aceaddfa97b2389784e2715316a725f protocol57507.py
9aceaddfa97b2389784e2715316a725f protocol58400.py
42d84c44f3d7818de27037e3a13f78b4 protocol59587.py
42d84c44f3d7818de27037e3a13f78b4 protocol60196.py
42d84c44f3d7818de27037e3a13f78b4 protocol60321.py
42d84c44f3d7818de27037e3a13f78b4 protocol62347.py
42d84c44f3d7818de27037e3a13f78b4 protocol62848.py
42d84c44f3d7818de27037e3a13f78b4 protocol63454.py
8b19ff4dc47470f4e8c0291cc55551f4 protocol64469.py
8b19ff4dc47470f4e8c0291cc55551f4 protocol65094.py
8b19ff4dc47470f4e8c0291cc55551f4 protocol65384.py
3a8adf2f7710326400e67e31ac2a6d40 protocol65895.py
3a8adf2f7710326400e67e31ac2a6d40 protocol66668.py
3a8adf2f7710326400e67e31ac2a6d40 protocol67188.py
3a8adf2f7710326400e67e31ac2a6d40 protocol67926.py
3a8adf2f7710326400e67e31ac2a6d40 protocol69232.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol70154.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol71061.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol71523.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol71663.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol72282.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol73286.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol73559.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol73620.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol74071.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol74456.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol74741.py
d0d651a484c04d2cb87b1af8e96c9fa9 protocol75025.py
protocol70154 (4.7.0 released 9 months ago) is the first one that actually introduced some changes (some very minor stuff).
Game is basically stable at this point, and Blizzard has no plans for future expansions. So things are changed only if they're really needed, for instance in protocol70154 they basically just changed one field from int8 to int16.