* Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
-> This argument is passed by value, it makes no sence so set it to null here.
* Member variable 'instance_violet_hold_InstanceMapScript::bWiped' is not initialized in the constructor.
(cherry picked from commit 433bc289c2c82b7377ad0189e415a3ca070d220f)
* Possible inefficient checking for 'list' emptiness.
* Variable '_scheduledScripts' is assigned in constructor body.
Consider performing initialization in initialization list.
* Variable 'Text' is assigned in constructor body.
Consider performing initialization in initialization list.
* Possible inefficient checking for 'm_loadedScripts' emptiness.
(cherry picked from commit 9a61049f88835fd6bdb75905f042583d038d0667)
Conflicts:
src/server/game/Server/Packets/TicketPackets.cpp
* Either inefficient or wrong usage of string::find(). string::compare() will
be faster if string::find's result is compared with 0, because it will not scan the whole string.
If your intention is to check that there are no findings in the string,
you should compare with std::string::npos.
* C-style pointer casting detected. C++ offers four different kinds of casts as replacements:
static_cast, const_cast, dynamic_cast and reinterpret_cast.
(cherry picked from commit 8882a6ca78e90d2980a3cd8d53acea9d2137f8b8)
Fix Vote Kick started with party in queue breaking the whole LFG queue. The status of Vote Kick is now storing in a bool variable in LfgGroupData, separated from LfgState of the group/members.
If a Vote Kick started with party in queue, the members were not removed from queue correctly and would cause LFG matching system to match these "broken" players but not allowing to start a dungeon.
Closes#10191
Suggest everyone attempt to remember this:
TC_LOG_TRACE = extreme debugging (debuginfo with packetstructures/data)
TC_LOG_DEBUG = debugging (detailed activity of functions and activites inside core)
TC_LOG_INFO = normal runstate (regular info like logins/logouts/levelups/passwordchanges etc)
TC_LOG_WARN = possible issue with config/data etc - things that are not how they should be)
TC_LOG_ERROR = actual error that has been either caought or must be fixed at some point
TC_LOG_FATAL = crash or data corruption imminent
Using the right logmech also helps distinguishing between 'regular runtime info' and stuff that might lead to a pissy situation later on... :)
Naios