- Logging System is asyncronous to improve performance.
- Each msg and Logger has a Log Type and Log Level assigned. Each msg is assigned the Logger of same Log Type or "root" Logger is selected if there is no Logger configured for the given Log Type
- Loggers have a list of Appenders to send the msg to. The Msg in the Logger is not sent to Appenders if the msg LogLevel is lower than Logger LogLevel.
- There are three (at the moment) types of Appenders: Console, File or DB (this is WIP, not working ATM). Msg is not written to the resource if msg LogLevel is lower than Appender LogLevel.
- Appender and Console Log levels can be changed while server is active with command '.set loglevel (a/l) name level'
Explanation of use with Sample config:
Appender.Console.Type=1 (1 = Console)
Appender.Console.Level=2 (2 = Debug)
Appender.Server.Type=2 (2 = File)
Appender.Server.Level=3 (3 = Info)
Appender.Server.File=Server.log
Appender.SQL.Type=2 (2 = File)
Appender.SQL.Level=1 (1 = Trace)
Appender.SQL.File=sql.log
Appenders=Console Server (NOTE: SQL has not been included here... that will make core ignore the config for "SQL" as it's not in this list)
Logger.root.Type=0 (0 = Default - if it's not created by config, server will create it with LogLevel = DISABLED)
Logger.root.Level=5 (5 = Error)
Logger.root.Appenders=Console
Logger.SQL.Type=26 (26 = SQL)
Logger.SQL.Level=3 (2 = Debug)
Logger.SQL.Appenders=Console Server SQL
Logger.SomeRandomName.Type=24 (24 = Guild)
Logger.SomeRandomName.Level=5 (5 = Error)
Loggers=root SQL SomeRandomName
* At loading Appender SQL will be ignored, as it's not present on "Appenders"
* sLog->outDebug(LOG_FILTER_GUILD, "Some log msg related to Guilds")
- Msg is sent to Logger of Type LOG_FILTER_GUILD (24). Logger with name SomeRandomName is found but it's LogLevel = 5 and Msg LogLevel=2... Msg is not logged
* sLog->outError(LOG_FILTER_GUILD, "Some error log msg related to Guilds")
- Msg is sent to Logger of Type LOG_FILTER_GUILD (24). Logger with name SomeRandomeName is found with proper LogLevel but Logger does not have any Appenders assigned to that logger... Msg is not logged
* sLog->outDebug(LOG_FILTER_SQL, "Some msg related to SQLs")
- Msg is sent to Logger SQL (matches type), as it matches LogLevel the msg is sent to Appenders Console, Server and SQL
- Appender Console has lower Log Level: Msg is logged to Console
- Appender Server has higher Log Level: Msg is not logged to file
- Appender SQL has lower Log Level: Msg is logged to file sql.log
* sLog->outDebug(LOG_FILTER_BATTLEGROUND, "Some msg related to Battelgrounds")
- Msg is sent to Logger root (Type 0) as no Logger was found with Type LOG_FILTER_BATTLEGROUND (13). As Logger has higher LogLevel msg is not sent to any appender
* sLog->outError(LOG_FILTER_BATTLEGROUND, "Some error msg related to Battelgrounds")
- Msg is sent to Logger root (Type 0) as no Logger was found with Type LOG_FILTER_BATTLEGROUND (13). Msg has lower LogLevel and is sent to Appender Console
- Appender Console has lower LogLevel: Msg is logged to Console
Note: The default config file action for clients failing the checks can be changed for each check via the characters.warden_action table
Credits to TOM_RUS
The new format for the middle section is a 3-letter upper case abbreviation of the sql command being executed (select -> SEL, update -> UPD, etc.)
{DB}_{SEL/INS/UPD/DEL/REP}_{Summary of data changed}
- Added missing space to 'if', 'for', 'while' and 'switch' when it's followed by '('
- Added missing space after a comma and remove space before comma (with some exceptions)
- Remove trailing spaces
- Convert tab to spaces
Note: Only affects files with extension "cpp" and "h" under /src/server
NOTE: Initially I just wanted to fix some warnings, but noticed that there is no common method for percentage calculation and various formulas are used many time in the code making it difficult to read and understand what the code actually does. So, I introduced several template methods for calculating percent values and adding those values to the original base. I replaced all the raw calculations throughout the code where found, but I could have missed something or could have made a mistake. So, please report any strange behaviour after this commit.
If you ask me why I did it: for the sake of consistency and exact understanding what code means. If you see CalculatePct method, you clearly understand, that it find the value of x percent of y. And you can easily express, for example, spell behviour "reduces smth by x%" by the means of a method instead of recalling school maths.
--HG--
branch : trunk
- Replace many magic numbers with constants
- Use enum for vehicle flags/seat flags
- Correct structure for ItemRandomSuffixEntry
--HG--
branch : trunk
- Rewrite Field class to be able to store both binary prepared statement data and data from adhoc query resultsets
- Buffer the data of prepared statements using ResultSet and Field classes and let go of mysql c api structures after PreparedResultSet constructor. Fixes a race condition and thus a possible crash/data corruption (issue pointed out to Derex, basic suggestion by raczman)
- Conform PreparedResultSet and ResultSet to the same design standards, and using Field class as data buffer class for both
* NOTE: This means the fetching methods are uniform again, using ¨Field* fields = result->Fetch();¨ and access to elements trough fields[x].
* NOTE: for access to the correct row in prepared statements, ¨Field* fields = result->Fetch();¨ must ALWAYS be called inside the do { }while(result->NextRow()) loop.
* NOTE: This means that Field::GetString() returns std::string object and Field::GetCString() returns const char* pointer.
Still experimental and all that jazz, not recommended for production servers until feedback is given.
--HG--
branch : trunk
* Rename QueryResult class to ResultSet
* Rename QueryResult_AutoPtr to QueryResult
* Declare ACE refcounted auto pointer for PreparedResultSet class
--HG--
branch : trunk
- Allowed Security Level will be set at server load or with 'server plimit reset' command (before it was read each time someone tried to join)
- If Security Level is updated to a more restrictive value all people under that level will be autokicked
--HG--
branch : trunk
- All "'xxx' will be initialized after 'yyy' when initialized here"
- Some "unused variable"
- Some "enumeration value 'xxx' not handled in switch"
--HG--
branch : trunk
* Removed the misdesigned on_events script/hooks.
* Lots of related cleanups and assertions.
* The interface is now fully object-oriented.
** Scripts no longer use function pointers.
** Scripts no longer use the general-purpose Script struct for everything.
** Script types are split into separate classes which must be inherited depending on what functionality is desired.
* Several script types have been added to allow extending functionality in a code-only manner (some script types require
assignment in the recently added ScriptName columns in the database, though).
** SpellHandlerScript: Wrapper around spell scripts (returns new SpellScript objects (`spell_script_names`.`ScriptName`)).
** ServerScript: Allows scripting events that occur in the network layer.
** WorldScript: Allows scripting certain world-global events.
** FormulaScript: Allows hooking and interfering with core formulas.
** *MapScript: Allows hooking different map types (including world, instance, and battleground maps (`instance_template`.`ScriptName`)).
** ItemScript: Allows scripting of items (like the old interface (`item_template`.`ScriptName`)).
** CreatureScript: Allows scripting of creatures/AI (like the old interface (`creature_template`.`ScriptName`)).
** GameObjectScript: Allows scripting of gameobjects (like the old interface (`gameobject_template`.`ScriptName`)).
** AreaTriggerScript: Allows scripting triggered area triggers (like the old interface (`areatrigger_scripts`.`ScriptName`)).
** OutdoorPvPScript: Script which should return OutdoorPvP objects for use by OutdoorPvPMgr (`outdoorpvp_template`.`ScriptName`).
** CommandScript: Allows extending the in-core command table.
** WeatherScript: Allows scripting of weather changes (`game_weather`.`ScriptName`).
** AuctionHouseScript: Allows scripting of auction events.
** ConditionScript: Allows scripting of conditions (`conditions`.`ScriptName`).
** DynamicObjectScript: Allows scripting of dynamicobjects.
** TransportScript: Allows scripting of transport events (`transports`.`ScriptName`).
* OutdoorPvP objects are now created through scripts. This effectively means that they'll need to be moved to scripts
before the they're functional again.
* The whole idea with this new interface is to allow expanding core functionality without touching core code. If further
hooks are needed to expand functionality of the core, let us know; we'll add them, if we agree that it is appropriate
to do so.
*** NOTE: The scripts project will _not_ build before it has been adapted to the new interface.
*** Thanks to everyone who helped out with related preparations and suggestions!
--HG--
branch : trunk
