26 Jun, 2009, Banner wrote in the 1st comment:
Votes: 0
A recent awesome thread brought up a topic that piqued my curiosity. MUD Logging. SWR logs everything into one giant log, which starts at 1000.log and is incremented when the MUD is started up again. I'm, at this time, not entirely sure if it makes a new log each copyover or not. I orginally thought this idea was very cool, but as my MUD grew, I realized how much digging you have to do to find what you want in one log that could be thousands of lines long. Eventually, I expanded into another log that put player connections into a separate log, but it still logs to my main log. My question is, how do you handle logging in your game and what have you found to be the best way to handle logs? IE, do you just log the line or do you rotate logs every few hours/days/lines, how many files do you have/what do you log in them and so on and so forth?

Also, dare I say it, do any of you log every command typed by players/immortals to a file?
26 Jun, 2009, Davion wrote in the 2nd comment:
Votes: 0
I used to use a system that split up the logs into different files. It should be available in the MUDCon V codebase. Look in comm.c near the bottom. Also, should be a table somewhere in ther (tables.c maybe? I can't remember :P)
26 Jun, 2009, Kayle wrote in the 3rd comment:
Votes: 0
I handle logging the same way any Smaug mud does, until I rewrite my mud from scratch, at which point, I don't know how I'll handle it.

Probably something like the ####.log files would have things like the startup spam, and any miscellaneous logs that I forget about. :P
{date}-build.log would hold all the build spam for the day.
{date}-bugs.log would log all bug messages for the day.
{date}-connections.log would log all connections for the day, be it players, or MSSP Crawlers.
{date}-imc.log would log all imc logs for the day.

But I dunno, not putting a lot of thought into this as I don't even have any kind of descriptor/socket/connection handling yet. :P
26 Jun, 2009, Metsuro wrote in the 4th comment:
Votes: 0
Would there be an actual benefit to working logs into some sort of database, or would different files for each type of log be better? What would the advantages be of doing it in different files vs that of a database?
26 Jun, 2009, Runter wrote in the 5th comment:
Votes: 0
Davion said:
I used to use a system that split up the logs into different files. It should be available in the MUDCon V codebase. Look in comm.c near the bottom. Also, should be a table somewhere in ther (tables.c maybe? I can't remember :P)


Speaking of which…when's mudcon? :P
26 Jun, 2009, David Haley wrote in the 6th comment:
Votes: 0
We log things to one file the standard way (i.e. based on command flags). I have plans to split it up more or less along the lines that Kayle mentioned.

We also have trace logs that record the last 200 commands, flag or no flag, exactly as typed. This helps when debugging as you have a record of the sequence of commands that were typed. But, to preserve privacy of communication, certain commands get scrubbed, namely anything involving communication. So if Fred typed "tell bob hi", the log would just say "Fred: tell bob …".

One thing that has always annoyed me is that a command typed can resolve to many different things. For example, "purge sw" will look up an object using the text "sw", but the log will only show "purge sw". The new codebase I'm tinkering with fixes this by having the command construct its own string to log, so that it can give a better representation of what actually happened in addition to what was typed. For instance, it might log "purge sw" to a trace, and then "Object 'sword (#456)' purged by Fred at room 123".

Metsuro said:
Would there be an actual benefit to working logs into some sort of database, or would different files for each type of log be better? What would the advantages be of doing it in different files vs that of a database?

A database would let you more easily run analytics on events. But it would be quite hard IMO to set up a schema that actually made interesting analytics possible; the advantage to plain text logs is that you can say whatever you want. Having a database that just stored the time and text wouldn't be interesting IMO.
27 Jun, 2009, Banner wrote in the 7th comment:
Votes: 0
Kayle said:
I handle logging the same way any Smaug mud does, until I rewrite my mud from scratch, at which point, I don't know how I'll handle it.

Probably something like the ####.log files would have things like the startup spam, and any miscellaneous logs that I forget about. :P
{date}-build.log would hold all the build spam for the day.
{date}-bugs.log would log all bug messages for the day.
{date}-connections.log would log all connections for the day, be it players, or MSSP Crawlers.
{date}-imc.log would log all imc logs for the day.

But I dunno, not putting a lot of thought into this as I don't even have any kind of descriptor/socket/connection handling yet. :P

That's what I was thinking. My current system is the ####.log and a separate connect log. Where would be the best place to drop code that would tell it to start a new day, and at what time? 12amish? Would you make it turn into {date}-blah.log.2 if the log reached a set number of lines or size that specific day? Also, I like the strucuture you gave me, but I'm thinking I'll put startup spam into a file too.

David Haley said:
We also have trace logs that record the last 200 commands, flag or no flag, exactly as typed. This helps when debugging as you have a record of the sequence of commands that were typed. But, to preserve privacy of communication, certain commands get scrubbed, namely anything involving communication. So if Fred typed "tell bob hi", the log would just say "Fred: tell bob …".

Is this so you can tell what happened leading up to a crash, and why such a arbitrary number? Do you just have it kill the top line each time it updates?
27 Jun, 2009, David Haley wrote in the 8th comment:
Votes: 0
Banner said:
Is this so you can tell what happened leading up to a crash, and why such a arbitrary number? Do you just have it kill the top line each time it updates?

Yes, it's to diagnose crashes in particular, but also anything, really, such as occasional gameplay problems. As for why 200, why not? And yes, it just kicks out the oldest command when a new command comes in.
27 Jun, 2009, Kayle wrote in the 9th comment:
Votes: 0
Banner said:
That's what I was thinking. My current system is the ####.log and a separate connect log. Where would be the best place to drop code that would tell it to start a new day, and at what time? 12amish? Would you make it turn into {date}-blah.log.2 if the log reached a set number of lines or size that specific day? Also, I like the strucuture you gave me, but I'm thinking I'll put startup spam into a file too.


12am for sure. As for where to put the code. I dunno, hadn't thought of that. Like I said, Elysium doesn't even have socket capabilities yet. So I'm not real worried about logging. :P
27 Jun, 2009, quixadhal wrote in the 10th comment:
Votes: 0
I used a database, and gave it the option to emit to log files as well (or instead). Using a standardized format, it's easy to use awk and grep to find what you need.

In my case, different classes of messages get different tags, so KILL, ERROR, AUTH, are all types.

select * from logfile where log_date >= now() - interval '1 day' and log_type == AUTH order by log_date desc limit 20;

or…

bzcat log*.bz2 | grep '09062[67].' | grep 'AUTH ' | head -20

an example:
Quote
<: 20090626.055103.338 - RESET - : Zone Reset - Grasslands (16000-20072)
<: 20090626.055103.338 - RESET - : Zone Reset - Cemetary of Shylar (25201-32000)
<: 20090626.055111.339 - INFO - (weather.c;update_time_and_weather,369)
: Time update.
<: 20090626.055111.339 - INFO - (weather.c;update_time_and_weather,376)
: Weather update.
<: 20090626.055132.837 - INFO - (interpreter.c;nanny,1063)
: Got Connection from: aa.9.be.static.xlhost.com
<: 20090626.055151.339 - INFO - (comm.c;process_input,1002)
: EOF encountered on socket read.
<: 20090626.055203.088 - RESET - : Zone Reset - Shylar (2947-3099)
<: 20090626.055302.839 - RESET - : Zone Reset - Necromancer's Tower (3500-4699)
<: 20090626.055926.089 - KILL - ch "Karrn, the Legendary Black Dragon of Despair" [#20950] victim "A large bat" [#20950]
: A large bat killed by Karrn, the Legendary Black Dragon of Despair at Dense fog
27 Jun, 2009, kiasyn wrote in the 11th comment:
Votes: 0
28 Jun, 2009, aidil wrote in the 12th comment:
Votes: 0
On Way of the Force and the *wpr intermud 3 router, I use a logging system that was inspired by syslog.
Ofcourse, those are lpmuds, but the idea might still be useful to most people here.

To log something, code can call the following method:

void log_message(string channel, string message, varargs int loglevel)

Channel is an indentifier, the message is whatever has to be logged, and the loglevel is an indication of how important the message is, it uses the same levels as syslog

The logging service splits messages by channel and loglevel, and can send them to zero or more destinations based on the channel and level. A destination can be a file, another object or service on the mud, an online player, or a remote unix syslog daemon.

Normally, debug level log messages on all channels are configured to get voided, but it is a simple change to a config file to send them somewhere. This change can be made from outside the mud and is immediately active.

The logging service also allows setting a global max loglevel which works as a filter on all channels.

This allows me to have very detailed logs with anything you'd ever want, and at the same time have very terse logs with only specific information.

Especially on the intermud 3 router that is very useful. At times it is useful to look at connects that don't get anywhere, but 99.9% of the time it isn't, and I don't want that info to flood the log of muds that actually try to make an intermud 3 connection.
28 Jun, 2009, Chris Bailey wrote in the 13th comment:
Votes: 0
I am somewhat interested in logging the commands of each player. It seems like it would be difficult to manage, but what about creating a log for EACH player? This isn't well thought out or anything but what about a logging structure like so.

/logs/today.log ( A normal log )
/logs/players/bob.log ( Everything bob has done in the past.. 2 days?)
/logs/players/john.log ( Everything john has done in the past.. 2 days?)
/logs/last200.log (The last 200 commands issued for debugging?)

Edit:
I can certainly see the usefulness of logging the commands of individual player's on certain muds. I know I was once busted due to command logging for
shoving a player into an aggressive mobile in a non pk area. ( I thought the code would prevent me from doing it ) :P
28 Jun, 2009, aidil wrote in the 14th comment:
Votes: 0
Chris Bailey said:
I am somewhat interested in logging the commands of each player. It seems like it would be difficult to manage, but what about creating a log for EACH player? This isn't well thought out or anything but what about a logging structure like so.

/logs/today.log ( A normal log )
/logs/players/bob.log ( Everything bob has done in the past.. 2 days?)
/logs/players/john.log ( Everything john has done in the past.. 2 days?)
/logs/last200.log (The last 200 commands issued for debugging?)

Edit:
I can certainly see the usefulness of logging the commands of individual player's on certain muds. I know I was once busted due to command logging for
shoving a player into an aggressive mobile in a non pk area. ( I thought the code would prevent me from doing it ) :P


I don't directly log player commands, but I do store the last 200 commands of each player together with the rest of the persistent data for them. The first purpose of this is to provide serverside command history, and letting players themselves review what they did, but it is also a very useful 'forensics' tool.
0.0/14