* 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 433bc289c2)
* 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 9a61049f88)
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 8882a6ca78)
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... :)
