Vanilla List Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VANILLA-LIST:2237] xsg stuff
Jonathan Ellis <ellisj@cs.byu.edu> wrote:
>
> Interesting. Unfortunately, the only reference to cambot in the archives
> (according to altavista, since the archives themselves don't seem to have
> search capability) is an oblique one, and tells me nothing.
The continuum archives are in a poor state, which is a shame because
they were a great resource.
Dave Ahn has an archive at
http://www.vec.wfubmc.edu/~ahn/netrek/vanilla-l/maillist.html that
goes back far enough to include the cambot stuff.
Anyways, I dug up from my local copies some relevant messages,
included below (snipped out some tech info, see Dave's site for the
full text).
> The disadvantages are that (a) cambot's recording is larger (according
> to a non-scientific test I just ran with a single ship :)
I'm in possesion of a 17 meg cambot recording that when gzipped at the
default level goes to about 9.5 megs (though it takes forever on my
little 486). I don't know what the comparable xsg would be.
> (b) no playback,
> so what's the point,
There's a patch to COW for playback (it does reverse too). Presumably
your favorite client can be modified to use these recordings.
> (c) it doesn't automatically die when the daemon
> does, which I imagine could be bad.
Seems like a minor issue. I would like to see a command in the INL
Robot that let you record games, so it would start and stop
automatically.
-Jeff
* To: vanilla-l@real-time.com
* Subject: [VANILLA-L:646] Removal of SHORT_PACKETS ifdef variable
* From: koconnor@acsu.buffalo.edu
* Date: Sat, 13 Sep 1997 16:53:17 -0400 (EDT)
_________________________________________________________________
I've decided to write a robot capable of recording games - 'CamBot'.
The recording format will record only essential data(data that has
recently changed), record data in a system independent format, and
record the data in a format already understood by clients.
Put simply, CamBot will use the already existing mechanisms
in socket.c to create 'packets' and record them to a disk file.
This 'packets' file will then be able to be read by clients
to replay the game.
* To: koconnor@acsu.buffalo.edu
* Subject: [VANILLA-L:647] Re: Removal of SHORT_PACKETS ifdef
variable
* From: James Cameron <cameron@ogg.stl.dec.com>
* Date: Wed, 01 Oct 1997 07:11:21 +0000
* Cc: vanilla-l@real-time.com
_________________________________________________________________
koconnor@acsu.buffalo.edu wrote:
> I've decided to write a robot capable of recording games - 'CamBot'.
Kevin,
I agree that short packets can be made permanent.
I don't agree with your proposed recording solution ... I would have
taken the code in XSG and seperate it into a set of functions for
recording and playback. The playback would use a minimal ntserv that
read and applied the playback function before delivering packets to
the client. We've talked about this before. Archives may have it.
You see, packets sent to the clients aren't everything, they are only
the recording as seen by one client. And if you record all client's
packets, you're going to get massive duplications. Please consider.
;-)
* To: [7]cameron@ogg.stl.dec.com
* Subject: [VANILLA-L:648] Re: Removal of SHORT_PACKETS ifdef
variable
* From: [8]koconnor@acsu.buffalo.edu
* Date: Wed, 1 Oct 1997 23:09:15 -0400 (EDT)
* In-Reply-To: <[9]3431F799.64A645FF@ogg.stl.dec.com> from "James
Cameron" at Oct 1, 97 07:11:21 am
* MBOX-Line: From koconnor Wed Oct 1 23:09:15 1997 remote from
xena.acsu.buffalo.edu
* Reply-To: [10]koconnor@acsu.buffalo.edu
* Sender: [11]owner-vanilla-l@real-time.com
_________________________________________________________________
The message you responded to was a remail of a message I wrote when
this mailing list was in limbo - Cambot is already completed, and I'm
now centering my work around getting COW to work with the packets file.
So I guess it is too late for reconsidering.. :-)
> I don't agree with your proposed recording solution ... I would have
> taken the code in XSG and seperate it into a set of functions for
> recording and playback. The playback would use a minimal ntserv that
> read and applied the playback function before delivering packets to
> the client. We've talked about this before. Archives may have it.
I wasn't aware there was even a discussion of a game recording robot -
I will have to look through the archives..
However, I still see some major drawbacks to using the xsg method.
Currently, xsg records games by dumping the shared memory segment
every update to a disk file(via gzip).
The major disadvantage to this, is that the recording file is system
dependent. That is, there is no standard for alignment, or
byte ordering. Using the above system of a modified ntserv, each server
that recorded games would also have to be available to play those games
back - There would be no reliable means of implementing a playback server,
and no reliable means of playing back locally.
The other major disadvantage, is data is written even when it has
not changed.. So, even if a ship is dead, or hasn't moved in a long
time, data on it's status is written every update! (gzip helps with
this, but gzip takes up precious cpu cycles..)
> You see, packets sent to the clients aren't everything, they are only
> the recording as seen by one client. And if you record all client's
> packets, you're going to get massive duplications.
True, but I've already accounted for this. Cambot wont record one
connection's packets, and it wont record the packets of all the
connections - It will generate packets specifically to it's needs.
That is, it will generate torp packets as if every torp were owned by
CamBot, phaser packets as if all phasers were owned by CamBot, player
location packets as if all players were CamBot, planet packets as if
CamBot were on every team, message packets as if CamBot were the recipient
of every message, etc.
Using this method, CamBot will record all the information in it's most
accurate form, and not record any duplicates or less accurate info.
There are some pitfalls to the above -
The SP_2 torp_packet, and the SP_2 player_packet were specifically
designed around one player(they send addresses of torps/players relative
to the current player). Solution - Dont use these packets, use the older
SP_1 and non-SP packets that provide this data.
Currently, there are no packets which transfer planet/player locks,
and tractor/pressor locks. Solution - I introduced a new sp_s_youself
packet. (My youself is 4 bytes smaller, and it sends t/p locks & pl/p locks.)
This new youself packet will also improve observer support. (We'll finally
be able to see how erik t/p's out of those 8-man ogg waves. :-) )
Currently, clients are designed around only receiving certain information
- Pipe all this extra info into them and they break. Solution - Still
working on this one.. ;-)
If I can get a working copy of COW going, I will send out some preliminary
patches, and we can put the code to the real test!
* To: vanilla-l@us.netrek.org (VANILLA-L)
* Subject: [VANILLA-L:778] Distributing my cambot patches..
* From: koconnor@acsu.buffalo.edu
* Date: Sat, 31 Jan 1998 18:34:24 -0500 (EST)
_________________________________________________________________
Hello,
Well, I finally decided to clean up the 'CamBot' code that I wrote
last semester. I have done so, and am ready to distribute them.
CamBot is an architecture independent game recording utility. It
utilizes the standard packets used in the client/server communication,
to produce a 'mega-packet' file. This mega-packet file contains a recording
of all changes to player positions/status/weapons/messages/etc.. Because
it does this in a method already familiar to current clients, upgrading
the clients to accept this mega-packet-file should be trivial.
Some random observations on cambot:
- A quick comparison of cambot and xsg showed cambot uses roughly 2 times
less disk space. (This could vary significantly in a real game.
However, I believe the savings will increase during real use.)
- Although I haven't done a comparison on cpu usage, I suspect cambot
will be alot more efficient. Aside from not having to interact
with X, cambot doesn't use gzip. Also, Cambot is fairly simple - it
is essentially a less complicated version of an ntserv process.
- The context sensitive diff required to upgrade COW to accept the
mega-packet file was only about 10K. The changes centered around
allowing COW to understand multiple you_spackets.. (However, it
should be noted, I wrote the underlying record/playback code for COW,
and wrote it with cambot in mind. I dont know how other clients
record/playback. If they do things significantly differently,
upgrading to accept cambot recordings might be more difficult.)