Implementing: LogWrite()

[John Adams]

Did you smoke some good stuff today? If it's bitwise, the base value is:

1 = console
2 = file
4 = chat
8 = sms (lol)

3 = console/file
5 = console/chat
6 = file/chat
7 = console/file/chat

Am I missing something? And who cares how complex it is. Read the docs, or don't mess with it

[Scatman]

FINE!

[Eradani]

There's 10 kinds of people. Those who understand binary and those who don't.

hehe

[John Adams]

Code: Select all

01010100011010000110000101110100001001110111001100100000011001100111010101101110011011100111100100100001

(decode here)

[Scatman]

Code: Select all

0101010001101000011000010111010000100000011001000110111101100101011100110110111000100111011101000010000001100011011011110110111001110110011001010111001001110100001000000111010001101111001000000110000101101110011110010111010001101000011010010110111001100111001000000011101000101000

[John Adams]

soz... went off the side of the screen apparently. lame.

[Eradani]

01101100011101010110110001111010

[Scatman]

thats funny.

[John Adams]

Ok, I have accepted the fact that Windows/Linux uses lame-ass codes for Colors (0,1,2...etc) so here's the next question

What's the "code" for making the text BOLD? Or background color changes?

Because "white" seems to be the plain ol dull white of the command line, which is actually almost a grey. If you BOLD the white, it comes out pure-ass bright white, which I'd like to use for the category labels (brighter color than the log text itself, which is plain).

If anyone can point me to how to manage bold/normal command prompt coloring (because I am simply too busy at work today to do it myself), I will worry about implementing it. We'll definitely utilize CONST for all these color options, of course so no one has to memorize WHITE_BOLD color Id's.

[Eradani]

a long time ago, in a o/s far far away, dos used the high bit for bright.

iirc, if 0=white, 16=bright white, or maybe it was 8=bright white

and i know this is unix u'r talking, but it sounds similar

[John Adams]

OK Scatman! Necro'ing this thread because I think there's a bug, but didn't feel like making a major issue out of it

In the code, I have DATABASE__QUERY set to DISABLED (no output).

But in the log_config.xml, I override it with Enabled="True".

I step through the XML loader, and everything looks enabled just fine.

But in the LogWrite() function, when it hits a DATABASE__QUERY() log entry, the log_type_info[type].enabled = False, thus no log output.

I've stared at this for an hour, and can't figure out why it's doing that.

Btw, I've added a bunch of colors, and thanks to Scat's help, I got "normal" and "intense" (bold) colors working. Soon as I test a bit more, I'll commit my changes. Logging is a HUGE task, as it's taken me most of the afternoon just to figure out where to place logging in a few startup functions This'll be fun.

[John Adams]

Update!

I have changed the Logging System somewhat to suit my own personal wants and desires The LogWrite() command now has a new param:

Code: Select all

LogWrite(LogType type, char *cat_text, const char *format, ...)

"cat_text" is something I wanted to put in to offer a custom (at the coders disgression) tag to send to the log. Example:

Code: Select all

LogWrite(WORLD__INIT, "WorldInit", "World", "Initializing EQ2Emu Server...");

This will now print out a very pretty log entry like I always wanted! (looks are everything, afterall...)

logColors.jpg

With the time of day, the type of log (normal, debug, error, etc), the new TAG, and the log text.


I'm updating this thread because this of course means my 1200+ log entries i've already added to the 3 projects have to be modified... so my next commit is going to be frightening. Be prepared

[John Adams]

Hmm, the further I get into this logging, the less I am liking my INIT ideas.



I am thinking of adopting this concept, taken from an idea posted on the web:

• SEVERE, severe errors that require program exit (e.g., in an application, you ran out of disk space).
  
  ERROR, error messages that can't be recovered from but the program can continue to run (e.g., in a server application, client sent through bad data but other clients can continue to run).
  
  WARNING, recoverable problem that you should be notified about (e.g., invalid value in a configuration file, so you fell back to the default).
  
  INFO, informational messages.
  
  ENTRY, log entry and exit to all functions.
  
  PARM, log entry and exit to all functions with parameters passed and values returned (including global effects if any).
  
  DEBUG, general debugging messages, basically useful information that can be output on a single line.
  
  DETAIL, far more detailed debugging messages such as hex dumps of buffers.

...still allowing for some custom stuff, like QUERY, RESULT, ROWS or something for Data logging... dunno. Thought I'd throw it out there to get feedback.

[Scatman]

The INIT is the extra string you put in there?

[John Adams]

No, I had CATEGORY__INFO, WARN, ERROR, DEBUG and TRACE initially.

Then I added CATEGORY__INIT, __INIT_WARN, __INIT_ERR and __INIT_DBG thinking I would use those for initialization processes... but, it got too confusing just trying to decide what was an INIT process, and what was normal operation.

So, __INIT* loses. Fired. Gone. Forget you ever heard of it. This is not the logger you're looking for...


The "cat_text" stays.

Now, you can use (example), LogWrite(WORLD__INFO, "Thread", "Starting console command thread..."); and in the console/logs, you will see the tag "Thread", or any other custom, free-form text you feel like putting in there to identify the log entry.

LogWrite(WORLD__WARN, "Poop", "Scatman just took a poop!");

...on the world.

etc.