* Unlooted items / money persist across player sessions
* Loot inside items is tied to the item rather than the player so if trading
partially looted items becomes possible, this implementation will still work
* New tables added:
characters_database.sql (first time users)
characters_create_item_loot.sql (existing users)
Implementation Can be tested with:
Watertight Trunk [21113]
Bulging Sack of Gems [25422]
Fat Sack of Coins [11937]
Closes#2048
There are still some issues that need to be fixed, for more info see CalendarHandler.cpp TODO part.
Some unblizzlike behaviour possible, we don't have a lot of sniffs.
Big thanks to @Warpten, he joined my project and helped a lot.
IMPORTANT NOTE: Read / append packed time functions in ByteBuffer.h are not correct, they need to be fixed in order to have event times accurate
Signed-off-by: Nay <dnpd.dd@gmail.com>
- Send correct events when modifiying Ranks (Add, modify, delete)
- Store money/slots withdraw, not remaining slots. This will update remaining slots/money properly.
- Reset daily slots/money withdraw for all members at same time, configurable
- Better debug messages
- Fully parse CMSG_GMTICKET_CREATE, use GmTicket::GetChatLog() to access the reporters chat log from this session (unused atm, possible useful to detect chat harassment)
- Simplify SMSG_GMTICKET_GETTICKET and fix "category" field (renamed it same as in blizz LUA files)
- Store response in DB
Changed multiple lines to a simple format:
- Logger.name=Type,LogLevel,Flags,AppenderList
- Appender.name=Type,LogLevel,Flags,optional1,optional2
* Type = File: optional1 = File name, optiona2 = Mode
* Type = Console: optional1 = Colors
Created a default set of loggers and appenders.
- Root logger defaults to Error, that means you will see nothing on console by default (not even loading)
- You need to add the loggers to Loggers options if you want to enable them, otherwise Root logger will be used for all types
Restored outSQLDriver (LOG_FILTER_SQL_DRIVER), outSQLDev (LOG_FILTER_SQL_DEV), outArena (LOG_FILTER_ARENA) and outChar (LOG_FILTER_CHARACTER) functionality by creating new types (LOG_FILTER_CHARACTER is a rename of LOG_FILTER_DELETE.
Note: You need to update your config file... again (yeah sorry... trying to make it simpler)
- 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
* Fixed Professor Putricide Tear Gas stunning himself
* Fixed visual of Unstable Experiment
* Fixed oozes not picking new targets after hitting old
* Fixed Gas Cloud not using melee attack
* Removed ooze summon position hack
Closes#4301Closes#2726Closes#5119Closes#4464Closes#2874Closes#4407Closes#2421Closes#4899
Cleaning databases for old/deprecated and expired quests should never be a
developers choice specifically. This should be done by admins, not developers,
through the use of the already existing paramters found in the worldserver config :
CleanCharacterDB / PersistentCharacterCleanFlags
An adjustment to the respective questloader prepared statement has been done to
accomodate for the earlier change (by not loading such quests into memory at all).
Documentation for how this cleanup-procedures work already exists in the core :
doc/CharacterDBCleanup.txt.
Example:
==8753== Possible data race during read of size 8 at 0x2e803e60 by thread #8
==8753== at 0xDD0FFC: PreparedResultSet::operator[](unsigned int) const (QueryResult.h:83)
==8753== by 0x131D82D: WorldSession::HandleCharEnum(Trinity::AutoPtr<PreparedResultSet, ACE_Null_Mutex>) (CharacterHandler.cpp:217)
==8753== by 0x118F8C3: WorldSession::ProcessQueryCallbacks() (WorldSession.cpp:1087)
{..}
==8753== Address 0x2e803e60 is 0 bytes inside a block of size 16 alloc'd
==8753== at 0x4C28B75: operator new(unsigned long) (vg_replace_malloc.c:261)
==8753== by 0x137D515: __gnu_cxx::new_allocator<Field*>::allocate(unsigned long, void const*) (new_allocator.h:92)
==8753== by 0x137D378: std::_Vector_base<Field*, std::allocator<Field*> >::_M_allocate(unsigned long) (in /home/aokromes/bin/bin/worldserver)
==8753== by 0x137CEC6: std::vector<Field*, std::allocator<Field*> >::_M_fill_insert(__gnu_cxx::__normal_iterator<Field**, std::vector<Field*, std::allocator<Field*> > >, unsigned long, Field* const&) (vector.tcc:416)
==8753== by 0x137CB27: std::vector<Field*, std::allocator<Field*> >::insert(__gnu_cxx::__normal_iterator<Field**, std::vector<Field*, std::allocator<Field*> > >, unsigned long, Field* const&) (stl_vector.h:944)
==8753== by 0x137C964: std::vector<Field*, std::allocator<Field*> >::resize(unsigned long, Field*) (stl_vector.h:632)
==8753== by 0x137BFCA: PreparedResultSet::PreparedResultSet(st_mysql_stmt*, st_mysql_res*, unsigned long, unsigned int) (QueryResult.cpp:98)
==8753== by 0x137A12B: MySQLConnection::Query(PreparedStatement*) (MySQLConnection.cpp:493)
==8753== by 0x137F663: PreparedStatementTask::Execute() (PreparedStatement.cpp:412)
Have a feeling this is a false positive, though. Nevertheless good to get rid of.
- Remove redundant locking in PingOperation. Since these are delayed to async threads with their own MySQL connection, no concurrent access here either.
- Codestyle cleanup
- Documentation refining
Most of the cores queries have been converted to prepared statements now. If your code contains queries, please either use the exiting or implement new statements.
The only exclusions are one-time queries (e.g. for core startup) and queries that can't be prepared due to limitations.
