Closing of the patch133 branch

1 view
Skip to first unread message

Graylin Kim

unread,
May 17, 2011, 11:47:34 PM5/17/11
to sc2rea...@googlegroups.com
Now that sc2reader is successfully parsing all replay files from all versions (as far as our set of test replays goes) I am closing down the patch133 branch. Its been merged into obslibmerge as of tonight.

The next step for me will be prepping obslibmerge for a PyPi release 0.3.0 and merging into master. At that point the library should be fully consolidated and production ready with its limited feature set. There would preferably be docs for the library at that point as well. 

Before things are ready for release I'm thinking the following points are priorities. Feedback appreciated.
  • Support for production and debug modes such that production mode runs clean with no requested output. A logger system might work well here.
  • Nail down an interface to all the available data from the main objects; Replay and Player primarily
    • I've thought about adding a team class as well to better encapsulate related attributes
  • Update the test suite to cover a greater portion of our current functionality
Thoughts and concerns?

~Graylin

Dominic Baranski

unread,
May 18, 2011, 4:53:40 PM5/18/11
to sc2rea...@googlegroups.com
Hey all,

Great work on getting the events parsing again for patch 1.3.3, thanks Blizzard for randomly changing things on us!

As for next steps, I'm not sure sure a debug more is really required.  Technically, you can get access to any of the variables held in an object at any time, and since this is a library it doesn't have a "run time" or a location to record things to.

The way I look at this is that sc2reader is a "library", so it should give it's users (that's the developers) access to content in a simple, uniform, and understandable way.  I do recommend the creation of "Team" classes.  From a developers point of view they would be valuable for pulling and storing information about players (group win/loss for example). even 1v1 players could be placed in teams for consistency.

I also agree with your testing point, with a broad array of sample replays we will be able to come to conclusions faster about how events work in SC2.

Dom

Graylin Kim

unread,
May 18, 2011, 8:33:27 PM5/18/11
to sc2rea...@googlegroups.com
Great work on getting the events parsing again for patch 1.3.3, thanks Blizzard for randomly changing things on us!

Actually, once I re-organized the parsing code a bit, all the changes make a lot of sense. Things seem to get cleaner each time they change things.
 
As for next steps, I'm not sure sure a debug more is really required.  Technically, you can get access to any of the variables held in an object at any time, and since this is a library it doesn't have a "run time" or a location to record things to.

Debug was probably a bad word to use. I mean more a "reverse engineer" mode, that stores additional information related to the byte codes so that we can better figure out the nuances of all the events. Probably a package of utility functions for assisting with that would be great also.
 
The way I look at this is that sc2reader is a "library", so it should give it's users (that's the developers) access to content in a simple, uniform, and understandable way.  I do recommend the creation of "Team" classes.  From a developers point of view they would be valuable for pulling and storing information about players (group win/loss for example). even 1v1 players could be placed in teams for consistency.

I like that view as well. I've learned towards a simple data structure (as opposed to classes with methods) approach from the very beginning. One of the primary issues here is anticipating and creating attributes for all the different usage patterns a user might have. The Team class will definitely clean up a portion of that interface and make things more consistent. If someone wants to spec up a dumb data structure that supports their favored access patterns, it would help a lot. I'll be submitting my own shortly.
 
I also agree with your testing point, with a broad array of sample replays we will be able to come to conclusions faster about how events work in SC2.

I've taken the step of making a folder for each version of Starcraft so far. We especially need replays from the older versions (1.0.x). The test suite needs to be updated to test at least 1 replay from each patch and probably track down and check on various edge cases like observers, computers, ties, odd events.

Pretty much everything here is an open action item, feel free to dig in. :)

~Graylin
Reply all
Reply to author
Forward
0 new messages