Feature Request: Additional machine-readable logging for commands, chat, connects

[sk89q]

Additional machine-readable logging (like StdLog) for:
* Commands (display_commands)
* Chat messages
* Connects

[jitspoe]

http://dplogin.com/dplogin/featurevote/feature.php?id=10015

I think I need to ditch the old stdlog system and implement something like this from scratch.  It would also include the global login id's like Bain wanted.

[sk89q]

That would destroy all our work!

But it's probably for the better. The StdLog spec itself is bad to begin with.

[webhead]

hmm ... might it be a good idea to save the logs as compressed files, like gzipped or something? cuz as plain text, such logs could accumulate quickly and take up lots of space, i'm guessing.

[sk89q]

Compressing them makes processing a computational chore.

[jitspoe]

Also, I prefer plain text logs so I can search for IP's and such.  They can always be gzipped at a later time via other scripts on the server (or manually).

Edit: Though what are your thoughts on a binary format?  This would cut down the file size a lot as well as reduce writing, reading, and parsing time.  Basically a player id (local to the server) could be stored in 1 byte, as well as different game events (grabs, caps, eliminations, etc.).

[Cobo]

Also, I prefer plain text logs so I can search for IP's and such.  They can always be gzipped at a later time via other scripts on the server (or manually).

Edit: Though what are your thoughts on a binary format?  This would cut down the file size a lot as well as reduce writing, reading, and parsing time.  Basically a player id (local to the server) could be stored in 1 byte, as well as different game events (grabs, caps, eliminations, etc.).

Someone would have to write a parser to human readable text though.

[jitspoe]

Someone would have to write a parser to human readable text though.

That's what the regular console log is for.  This is designed to be parsed anyway, for generating stats and whatnot.

[sk89q]

Whether it's binary or not doesn't really matter to me. It works either way, and space is a non-issue for me.

But anyway, implementation wise, binary or not, I am thinking we should throw up a spec before anything gets done.

[webhead]

sure, binary sounds good. but what does my opinion matter - i don't run a server.

[jitspoe]

Well, here's my line of thought, you'd have a preset list of events, something like:

1 = connect,
2 = kill,
3 = suicide,
4 = global login,
5 = respawn,
...

Then the first field would be the client id (on the server), so you might have something like:
2|1|12.34.56.78|JoeBlow|20 (JoeBlow connected)
2|4|56789 (JoeBlow logged in)
2|5 (JoeBlow respawned)
1|2|2|1 (Some other player eliminated JoeBlow with a trracer (weapon id 1))

[sk89q]

Draft?
http://sk89q.therisenrealm.com/uploads/pblogspec.pdf

(not binary yet)

[XtremeBain]

glsclanid can be added to PlayerEnter
is_adminkill can be added to Suicide or Kill
I think the Respawn event is a bit much, especially on the dm and koth gamemodes.

I'll think of a couple others, I'm sure.

[jitspoe]

Bain: Respawn is necessary for keeping track of players spawning mid-round.  It'd be useful for recording time alive and other things.  I don't know that I like the idea of putting the ping in the kill event.

Suicide could probably stand to have some kind of cause associated with it (grenade, trigger_hurt, lava, etc.)  I'm not sure if it would make more or less sense to merge it with "kill" (and just have a player id of -1 or 0 for worldspawn kills).

[XtremeBain]

There's other ways to track the respawns if you're provided with the elim and koth_elim values.  I think that they would just be a waste of space taking up an entire line in the log.  I guess it's not that bad though, since there'll always be more kills than respawns.

[sk89q]

http://digitalpaint.therisenrealm.com/downloads/pblogspec.pdf

[jitspoe]

Bain: That's true at the moment, but there was some discussion of letting players decide when to respawn (after the elim limit) so they aren't forced to spawn into bad situations.  Plus it's good to be sure you're 100% in sync, as the server settings may have changed, etc.  If this is a binary format, it would probably only take 2 bytes anyway, and it's not like respawns happen so often that they'd take up a lot of space otherwise (on servers with proper elim settings, anyway).

[Cobo]

http://digitalpaint.therisenrealm.com/downloads/pblogspec.pdf

What about setting change?