Plugin question: record and replay plugin(s)

gnu-sense · Post by **gnu-sense** » Sat Jul 14, 2007 8:46 pm

I had a recent experience with using a replay server, which I found really useful (if you care about that see http://my.bzflag.org/bb/viewtopic.php?p=112310#112310)

The only thing lacking I could see is a good way of indexing the replay files. These could rapidly get to be very very large in number, e.g. if one follows the policy of Divibox, logging every game, so searching these would not be trivial. Once you have the correct file, it may be hard to find the point of interest. It is possible to cue the file using /replay skip, but with hundreds or thousands of potential cue-points to choose from, it can be hard to get what one wants. Finally, it would be nice to be able to search by things like user name (what are all the games I was in on this server), tactical situation (list all the files/cue-points where a ST is killed by GM; list all the files/cue-points where two specific players are within X units of each other, etc.).

Would anyone else would be interested in seeing such modifications to record/replay come to be? My guess is that they could be kept relatively simple. If indexing is done off-line (e.g. by a script or separate program) no changes to record would be needed. Minor changes would be needed to replay so that modified search queries could be issued, and so that a replay file could be cued immediately to a desired cue-point. Finally, replay files would need to be indexed appropriately to support the desired queries.

I have enough background in IR that I believe I could tackle the indexing part (which I also think would be the hard part of this). The only thing I lack to get started on this would be a set of replay files, so that I could explore their structure and figure out a good way to index them. I'm not C++ coding-literate right now, and my bzf compile skills have not panned out yet, so I don't think I could do the plugin mods myself. If anyone would like to assist me, either with locating suitable replay files, or on the plugin side, please let me know. I'm eager to make a good thing even better, if there's a way to do it.

gnu-sense

A Meteorite · Post by **A Meteorite** » Sun Jul 15, 2007 1:45 am

Quite simply, a plugin can not do this alone. Something like this would require a new record format with BZFS mods and more plugin API functionality.

It's a good idea nonetheless.

gnu-sense · Post by **gnu-sense** » Sun Jul 15, 2007 3:55 am

My thinking was to have an off-line process (e.g. script or separate program) process the files after they are recorded, storing a searchable index in a separate file or files, format to be decided. The replay server would have to be able to see and read/parse the index file, which is where the plugin would come in. Is this what would not be possible with the plugin API?

I was also thinking that a proof-of-concept could be done simply making a web-based search engine for replay files that would return hit-lists of file+cue-point for a given search query. That would be well within my abilities, and could serve to stimulate further discussion.

gnu-sense

A Meteorite · Post by **A Meteorite** » Sun Jul 15, 2007 4:00 am

gnu-sense
Ah, I see how you want to do it.

Sure, that's very well possible, but good luck parsing the recorded file.

brad · Post by **brad** » Sun Jul 15, 2007 8:03 am

http://quol.bzflag.bz/gumatches

gnu-sense · Post by **gnu-sense** » Tue Jul 17, 2007 4:05 pm

brad wrote:http://quol.bzflag.bz/gumatches

Thanks. I grabbed the first page of files and am studying them now (alongside the bzfs source). One thing that is clear is that the format is a little, um... inefficient. All of the variables in effect (tank speed, shot velocities, etc.) are dumped repeatedly, in text form (names and values). Does this demarcate the beginning/end of (at least some) "packets" by any chance?

I'll probably be posting more questions later.

gnu-sense