• This is a read only backup of the old Emudevs forum. If you want to have anything removed, please message me on Discord: KittyKaev

Written Explaining TrinityCore's Logging define directives

Tommy

Founder
Hello, this is just going to be a simple tutorial explaining how to use the define directives on TrinityCore's logging system.
Things you should know:


  • [*=1]This is case sensitive (caps only)

The logging define directives are:


  • TC_LOG_TRACE
  • TC_LOG_DEBUG
  • TC_LOG_INFO
  • TC_LOG_WARN
  • TC_LOG_ERROR
  • TC_LOG_FATAL

The arguments are the same as using "sLog->". Example:

Code:
TC_LOG_WHATEVER(filterType, "Msg", ..);

String FilterTypes
  • Replace LOG_FILTER_NETWORKIO with "network" (with quotations)
  • Replace LOG_FILTER_GENERAL with "misc" (with quotations)
  • Replace LOG_FILTER_PLAYER_LOADING with "entities.player" (with quotations)
  • Replace LOG_FILTER_CHARACTER with "entities.player.character" (with quotations)
  • Replace LOG_FILTER_PLAYER_DUMP with "entities.player.dump" (with quotations)
  • Replace LOG_FILTER_PLAYER_ITEMS with "entities.player.items" (with quotations)
  • Replace LOG_FILTER_LOOT with "loot" (with quotations)
  • Replace LOG_FILTER_SERVER_LOADING with "server.loading" (with quotations)

(There's more filter types, but I only linked the ones that people get errors on all the time..)

Example of using the log directive (without extra args):

Code:
TC_LOG_ERROR("misc", "Error!");

Example of using the log directive (with extra args):

Code:
uint32 number = 15;
TC_LOG_INFO("misc", "The number is %u", number);

Pretty simple, huh? Pretty much the conclusion. Can't see if I even left anything out, seeing all you're using is the define directives, anyway, enjoy this small explanation! Need any help just ask.
 
Last edited:

Rochet2

Moderator / Eluna Dev
What is for LOG_FILTER_SQL - and what is for TC_LOG_DEBUG?
Not sure what you are asking here.

TC_LOG_DEBUG is just a logging level. They go from fatal errors to lower and lower severity of error.
TC_LOG_DEBUG would indicate that what you log isnt really something anyone needs to know unless they are debugging the application. Lets say for example that it would log specific values of a function call - you dont need to log those in normal use of a server. In a normal run of the server you would mostly want to know the most severe errors such as fatal errors, errors and warnings.
Im sure the original function was sLog->outDebug(..); in the old versions.

LOG_FILTER_SQL would be the "sql.sql" logger
 
Last edited:
Top