Author Topic: Feature Request: Additional machine-readable logging for commands, chat, connects  (Read 11662 times)

sk89q

  • Global Moderator
  • Autococker
  • Posts: 1049
Additional machine-readable logging (like StdLog) for:
* Commands (display_commands)
* Chat messages
* Connects

jitspoe

  • Administrator
  • Autococker
  • Posts: 18801
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

  • Global Moderator
  • Autococker
  • Posts: 1049
That would destroy all our work! :(

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

webhead

  • Committee Member
  • Autococker
  • Posts: 1185
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

  • Global Moderator
  • Autococker
  • Posts: 1049
Compressing them makes processing a computational chore.

jitspoe

  • Administrator
  • Autococker
  • Posts: 18801
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

  • Autococker
  • Posts: 1362
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

  • Administrator
  • Autococker
  • Posts: 18801
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

  • Global Moderator
  • Autococker
  • Posts: 1049
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

  • Committee Member
  • Autococker
  • Posts: 1185
sure, binary sounds good. but what does my opinion matter - i don't run a server.

jitspoe

  • Administrator
  • Autococker
  • Posts: 18801
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

  • Global Moderator
  • Autococker
  • Posts: 1049

XtremeBain

  • Developer
  • Autococker
  • Posts: 1470
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

  • Administrator
  • Autococker
  • Posts: 18801
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

  • Developer
  • Autococker
  • Posts: 1470
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

  • Global Moderator
  • Autococker
  • Posts: 1049

jitspoe

  • Administrator
  • Autococker
  • Posts: 18801
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).