fix(Unit/ProcessTerrainStatusUpdate): prevent removal swimming auras if swimming #18902
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:
azerothcore-wotlk/src/server/game/Entities/Unit/Unit.cpp
Line 4223 in ef6db03
Current logic to decide if swimming is based on
GetLiquidData().Status
. However, in the coilfang tunnel some parts areLIQUID_MAP_NO_WATER
which allows the player to breathe underwater.Should swimming/noswimming logic be based on
MOVEMENTFLAG_SWIMMING
flags? Similar to howIsFlying()
is handledIssues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
.tele coilfang
.learn 1066
aquatic formbreath timer indicates which areas are breathable, no liquid
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.