Page 1 of 1


Posted: Wed Jul 18, 2007 6:58 pm
by gnu-sense
This is continued from . Because of the nature of the post, I don't think it belongs there anymore. I posted there about wanting to create indexes for replay files, where the index allows you to search using various criteria to find files and index points.

I have spent several hours with RecordReplay.cxx now, and have a strategy for proceeding, but since the modifications I need to make are rather substantial I wanted to post for advice about proceeding. First, the following things are clear:

(1) As a meteorite pointed out, the current plugin API cannot handle the needed modifications, since they would require intercepting (network) packets either at load time or at send time, and doing something else with the data. This could be cured with changes to the API, but it is not celar what to request, as the API seems to have no way of handling packets directly. I'm reluctant to make such a request, because it looks like a big modification to me, and it's probably not anyone's priority but mine.

(2) The RecordReplay.cxx file is a masterful 53 page (yes I printed it to appreciate it in its full glory) tangle of C header, and C/C++ code. It records games by brute force (putting network packets into files), and plays them back by reading the packets and sending them out again. This actually has its advantages, but aspects of the design might be due to be re-thought. For one, it's a feature of every server that is turned on or off, by configuration, so it will be there whether it is used or not. The whole interface with record/play and the rest of the server might be simplified if most of it could be moved to the plugin environment, say by providing an API function or two for handling packets as they are sent. This would permit other kinds of plugins to be written to make recodings, e.g. that are anonymized or something. Low-level packet packaging would have to be kept out of the plugin environment, and this may be challenging. All of this would be a fairly major re-factoring, and I wonder what people think of the merit of it as an undertaking.

(3) The best way forward for me at the present moment appears to be to attempt a more modest revision of RecordReplay.cxx, along the following lines: (a) create a new command "/replay makeindex" or the like, whcih accepts a filename for indexing, (b) borrow code from the replay file loader and loadPacket to accomplish parsing of the file, (c) borrow other parts of the code to write the packets in indexed form. Actually, I just need to make the packet contents readable at this point, until I can make some decisions about what the indexes need to look like.

Does anybody have any reactions to any of the above?

Thanks in advance,


Posted: Tue Jul 24, 2007 8:15 am
by AAA
The whole idea of the plugin API is to make it simple to interact with server events, and if by plugins alone you cannot create phantom tanks (or bots for that matter) you at least should have all the resources available to record a file that record/replay can read.
I do not do very much plugin programming, but it is a feature I am very close to in my work with BZFlag, and will prepare a report on it sometime soon.

Posted: Thu Jul 26, 2007 3:41 am
by gnu-sense
Thanks for the response. I'll definitely look forward to the report.

I'm leaning a slightly different direction with this right now. I've found it pretty straightforward to modify bzadmin (it being relatively lightweight and uncluttered) to output the information I want. I can then set up a private server and bzadmin client and transcode the replay files into indexes in real time (not the best solution, but hey).

On the other hand, I am still looking at different approaches to hacking the server. This might end up requiring edits in several files, and possibly at least splitting out the function protos in RecordReplay.cxx into a RecordReplay.h file. It's reasonably clear where to cut, I'm just a little hesitant about operating, because if I don't plan it right, I will certainly screw it up.

I'm also considering the efficacy of using SWIG to get a little more flexible access to RR.cxx (e.g via Perl or PHP). The idea here is that the RR functions become a library for the scripting language, and I write my program in that to do the transcoding/indexing. I think that will work too, but I get uncertain about the long-term utility, and that makes me hesitate a bit as well.

I expect to be working on this in the near term, so I'll try to post again when I have something worth discussing.


Posted: Sat Aug 11, 2007 6:56 am
by AAA
I am still working on recording server session data with a plugin with a meteorite. The big problem is that plugins are not provided with the same data (in the same way at least) as servers.

I can connect my PHP Bot to a server, give it admin privileges, and it can gather more types of data that way then a plugin.
Things the server sends clients that it does not send plugins include:
  • * Player positions as they are updated
    * Flags being
    * A good timer. Without a timer, you would not know when to play back data.
    * Ways to interact with the map
The biggest blocker is you/meteorite pointed out is that plugins can't handle packet-level data. (Yet they can be called into action when a client sends invalid data... Biggest mistake ever, implementing that "feature")

My PHP BZFS server (Who knew PHP could do nonblocking sockets?) and client classes have a neat way of adding features, each function that handles a packet also returns all the parsed data that packet contained. It separates it, ect, then delivers it in an object or array. By default, the returned data is not looked at, but if you extend the class, you can overload functions, which look at the returned data and handle it the way they want to.

More coming later, I am still reading source code and documenting BZProto (the BZFlag protocol).

Posted: Sun Aug 12, 2007 4:40 pm
by gnu-sense
This is all very interesting, so definitely keep us updated.

FWIW, I'm still working on extracting information from recorded game files, working with the GU match files that quol has on his website. Initially, I was working on modifying bzadmin to simply report the contents of each packet as the file is played. Not the cleanest approach, but bzadmin is easy to modify and it works well enough in the main. The one issue I have right now is a difficulty in extracting the interesting player state information from the MsgPlayerUpdate and MsgPlayerUpdateSmall packets (the vast majority of packets I see are this latter type). I'm still burrowing through code to get this information out, but if you know a specific place I should look, that could help. Right now I am thinking that if I can figure out how to use MsgStrings.cxx (from bzfs) that might be the best way to do what I am trying to do. This might also make the indexing/translation easier to accomplish within bzfs, once I get around to doing it right.