replay.frames clarification

[Eddie Yan]

I've noticed that replay.frames (supposed to store the number of frames in a replay) seems to store the last frame number in the game instead of the actual number of frames. For example, a replay with replay.frames = 16852 has events at both frame 0 and 16852. Seems like it could lead to some potential off by one issues. Any thoughts?

[Graylin Kim]

I've always treated frame 0 events as pre-game setup with frame #1 being the first actual frame in the game. I can see how someone might take it differently though I'm not exactly sure when checking values against replay.frames would be useful. I'm not inclined to change it since anyone actually using replay.frames right now would get out of bounds type errors if we bump it. Maybe the documentation could be improved.

~Graylin

On Wed, Sep 24, 2014 at 12:08 AM, Eddie Yan <lose...@gmail.com> wrote:

I've noticed that replay.frames (supposed to store the number of frames in a replay) seems to store the last frame number in the game instead of the actual number of frames. For example, a replay with replay.frames = 16852 has events at both frame 0 and 16852. Seems like it could lead to some potential off by one issues. Any thoughts?

--
You received this message because you are subscribed to the Google Groups "sc2reader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sc2reader+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eddie Yan]

I actually ran into this issue when trying to use event.frame ;). I'm doing some segmentation of replays into time chunks, say 5 seconds each and counting the number of relevant events in each segment. So I started off using a list of length ceil((replay.frames/fps)/5). I would run into a problem where an interesting event happens exactly at the last frame such that it would have been in another 5 second segment. I didn't see this happen until I went through a good number of replays since the last frame number needs to be evenly divisible by 16 and there needs to be a relevant event in the last frame for this to happen.

So here's where there might be a bit of an inconsistency. replay.frames is used to calculate the length of the game in seconds by dividing the number of frames by 16. Event.frame is also used to calculate the time of the event in the same way. Then, the last event will have a time value of exactly the same length of the game but I'm confused here. Since setup happens at frame 0 and by the current definition second 0, does it make sense to say the game length is replay.frames/16? A toy example is a game with replay.frames = 16 (or any multiple of 16), where the replay is 1 second long, but there's also an event happening at the 1 second mark. I don't drop the decimal point when computing time, so in practice my interpretation of replay length might be off by (1/16)/1.4 seconds depending on the interpretation.

Thanks,

Eddie

[Eddie Yan]

Would it make sense to compute the timing of each event using (event.frame - 1) if we assume events at frame 0 are just setup events? That is, events at frame 0 happen before 0:00.00, and events at frame 1 happen at 0:00.00.