Vanilla List Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[VANILLA-L:778] Distributing my cambot patches..
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.)
Most of the changes required to implement cambot were done in socket.c.
To be precise, I made a shit load of changes in socket.c ..
Most of these changes involved adding a new layer of modularity.
Previously, socket.c had three layers for sending packets:
A top layer ( function UpdateClient() ), which called the
UpdatePlasma/Phaser/Ships/etc routines;
a middle layer (functions UpdatePlasma/Torps/Ships/Self/etc ),
which determined when a packet was appropriate, and
determined if the client required an update;
the lowest layer (function sendClientPacket() ), which updated the
client by writing the new packets to the socket.
I introduced a new layer by splitting the middle layer into two
layers. One layer to determine when a packet is appropriate, and another
layer to determine if the clients information is outdated.
This was necessary to allow cambot to grab packets for all the players,
all the planets, all the messages, etc..
Along the way, I also removed the Short Packet #ifdef references from
socket.c, cleaned up the indentation using emacs auto-indent, and split
socket.c into two files. (Socket.c was getting too unwieldy at
>150K). I created a new file genspkt.c which contains the new middle layers.
Now that I've said all that... I need to know what the best way of
distributing these changes is. Obviously, major changes to the source
code (and especially major changes to critical areas like socket.c)
need to be thoroughly tested before an official release should occur.
However, I think cambot is ready for a wider testing/examination effort.
I'm hoping the members of this list will give it a work-out.
The new files socket.c, and genspkt.c are both about 80K. There is
no way to diff them, so they have to be sent from scratch. I could
break them up and send them over this list, but I'm not sure it is
wise to fill everyone's mail account with 160K of code. Would it be
more appropriate to upload it to an FTP server somewhere?
Later,
-Kevin
--
------------------------------------------------------------------------
| Kevin O'Connor "BTW, IMHO we need a FAQ for |
| koconnor@acsu.buffalo.edu 'IMHO', 'FAQ', 'BTW', etc. !" |
------------------------------------------------------------------------
+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com