Plugin question: record and replay plugin(s)

Questions, comments, and news on the server side plug-ins and it's API
Post Reply
User avatar
gnu-sense
Private First Class
Private First Class
Posts: 78
Joined: Wed Nov 22, 2006 1:21 am

Plugin question: record and replay plugin(s)

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
Last edited by gnu-sense on Sun Jul 15, 2007 3:57 am, edited 2 times in total.

User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

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.
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com

User avatar
gnu-sense
Private First Class
Private First Class
Posts: 78
Joined: Wed Nov 22, 2006 1:21 am

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

User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

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. :)
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com

brad
Private First Class
Private First Class
Posts: 689
Joined: Sun May 08, 2005 12:26 pm
Location: UK
Contact:

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


User avatar
gnu-sense
Private First Class
Private First Class
Posts: 78
Joined: Wed Nov 22, 2006 1:21 am

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

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

Post Reply