Remove duplicate messages in middle of the screen + remove lowest average from anticheat global command
Changes Proposed:
Removes the duplicate message that appears at the middle of the screen alerting a countermeasure against a fly hacker even if you had the Anticheat.CM.ALERTSCREEN setting disabled.
Same with jump hack
Same with advanced jump hack
Same with ignore-z hack
Remove the "lowest average" section from the .anticheat global command. It is a silly thing to be seeking for.
Added the following areas to the excluded Ignore-Z hack detection.
Gnomeregan, some corridor inside the instance, .go xyz -466.640076 260.263092 -208.009796
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.
Remove duplicate messages in middle of the screen + remove lowest average from anticheat global command
Changes Proposed:
Anticheat.CM.ALERTSCREEN
setting disabled..anticheat global
command. It is a silly thing to be seeking for.Added the following areas to the excluded Ignore-Z hack detection.
Issues Addressed:
Tests Performed:
How to Test the Changes:
Anticheat.CM.ALERTSCREEN
setting!Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.