fix(Core/Pet) Remove unnecessary Pet Class reassignments #20614
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes Proposed:
This PR proposes changes to:
Make the pets use the database classes instead of overwriting through code.
Mage: Water Elemental, Imp
Paladin: Succubus, Felhunter, Voidwalker, Felguard
Rogue: Ghoul
Warrior: Hunter pets (unchanged, some tameable beasts are not warriors before taming)
Issues Addressed:
SOURCE:
The changes have been validated through:
Use the current Database values
Pally Power works with those values
Tests Performed:
This PR has been:
How to Test the Changes:
The spells to summon them are in brackets
/dump UnitClass("target")
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.