[VANILLA-L:1171] Thoughts on INL stats

["Kevin O'Connor" <koconnor@cse.Buffalo.EDU>]

On Fri, Dec 18, 1998 at 04:55:41AM -0500, Jeffrey Nowakowski wrote:
> James Cameron <cameron@stl.dec.com> wrote:
> > Sure, I have some time to devote to this, but I still don't know what is
> > wrong with what we have already.   I need someone to tell me, in detail,
> > what the INL server does that the Vanilla server INL robot does not,
> > before I can have any hope of fixing it.
> 
> Stats, stats, and more stats.  There's been some question as to how to
> implement them.  There's been work done (mostly complete?) by Kurk
> Siegl using a log parsing method.  Dave Ahn was working on putting it
> into the daemon or ntserv (I forget which), but has never submitted
> any patches.  Kevin O'Connor had another idea using short packet
> messages, which would keep INL specific code out of the main engine.

For the record, I thought I would pass on my experience with trying to
parse stats via message logging.

I hated it.

That is not to say that it can't be done.  It is just that the method is
prone to so many errors and oversights that I doubt it will ever be fully
stable.

As an example, my last attempt had a hack that outputed a players ticks in
the death() routine.  The idea was to catch every player dying, and then
store how many seconds he was in the game since he was last resurrected.
(This information is necessary for calculating a player's normalized
stats.)  Unfortunately, this is a "stop-gap" method at best.  What happens
when a player's slot crashes unexpectedly - is death() still called?  What
happens if his slot is freed?  What happens if he is still alive when the
robot exits?

Another problem has to do with calculating base stats vs. normal stats.
There is currently no method to distinguish a base dying from a normal ship
dying in the message logs.  Of course, one could extend the output
messages, but this kind of defeats the message logging method anyway.


A similar, earlier idea that Jeff mentions above, is the Short packet
parsing method.  The idea here was to have the inl robot look for SP
messages, and then produce the stats internally.  I abandoned this method
for a couple of reasons:
    There is nothing in the short-packet messages that isn't in the actual
        text output.  (So there is nothing that can't be done via message
	parsing that can be done via SP parsing.)
    I would prefer to write perl/python code to C any day.  Also, the
        external parser script could then be easily modified/updated
        without having to recompile, or having to "re-play" games..

The one advantage of the SP packet method is that it can "peek" at the
player's global table and check if he's an sb or not, but this could become
error prone (due to synchronization problems - what happens if a player
kills a ship, and then changes to an SB "real quick"?  The robot might
inappropriately record the kill as an SB kill.).

Also, if the SP parsing method is still attractive, it may be worthwhile
looking at the idea of parsing a cambot recording - cambot recordings store
all the player information and all the messages..


So, in conclusion, if I really wanted to code this now, I'd probably just
sit down and spend the three or four hours hacking the stuff into the
daemon.  It wouldn't be as clean, and it wouldn't be as "slick" - but
considering the state of the netrek source code at the present, it would
probably be the most stable and easiest to maintain.

-- 
 ------------------------------------------------------------------------
 | Kevin O'Connor                     "BTW, IMHO we need a FAQ for      |
 | koconnor@cse.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