fix(Core/Entities): reduce visibility range in Dalaran for performanc…#25695
fix(Core/Entities): reduce visibility range in Dalaran for performanc…#25695sudlud wants to merge 6 commits intoazerothcore:masterfrom
Conversation
…e improvements Co-authored-by: Kitzunu <24550914+Kitzunu@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Reduces server-side visibility/sight distances while players are in Dalaran (Northrend) to improve performance in a high-density city zone.
Changes:
- Add
WorldObject::IsInDalaran()helper (zone-based check). - Clamp
WorldObject::GetVisibilityRange()for gameobjects in Dalaran toVISIBILITY_DISTANCE_SMALL. - Clamp
WorldObject::GetSightRange()for players in Dalaran toVISIBILITY_DISTANCE_SMALL(with existing Wintergrasp/override handling).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/server/game/Entities/Object/Object.h |
Adds IsInDalaran() helper for zone detection. |
src/server/game/Entities/Object/Object.cpp |
Applies Dalaran-specific sight/visibility distance reductions. |
Comments suppressed due to low confidence (1)
src/server/game/Entities/Object/Object.cpp:1717
GetVisibilityRange()only applies the new Dalaran reduction forIsGameObject(). Calls that useGetVisibilityRange()on players/units (e.g., ranged messaging and various range-based searches) will still use the full map visibility in Dalaran, which makes the Dalaran-specific optimization inconsistent. Consider applying the Dalaran check to the non-gameobject path as well (and, if intended, also aligningGetGridActivationRange()for players so grid activation matches the reduced visibility).
else if (IsGameObject())
{
if (IsInWintergrasp())
return VISIBILITY_DIST_WINTERGRASP;
else if (IsVisibilityOverridden())
return GetVisibilityOverrideDistance();
else if (IsInDalaran())
return VISIBILITY_DISTANCE_SMALL;
else
return GetMap()->GetVisibilityRange();
}
else
return IsInWintergrasp() ? VISIBILITY_DIST_WINTERGRASP : GetMap()->GetVisibilityRange();
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (IsInDalaran()) | ||
| return VISIBILITY_DIST_DALARAN; | ||
| else if (IsInWintergrasp()) | ||
| return VISIBILITY_DIST_WINTERGRASP; | ||
| else | ||
| return GetMap()->GetVisibilityRange(); |
| #define DEFAULT_VISIBILITY_DISTANCE 100.0f // default visible distance, 100 yards on continents | ||
| #define DEFAULT_VISIBILITY_INSTANCE 170.0f // default visible distance in instances, 170 yards | ||
| #define VISIBILITY_DIST_WINTERGRASP 175.0f | ||
| #define VISIBILITY_DIST_DALARAN 84.0f // visible distance in dalaran due to the city's dense/compact layout |
| #define DEFAULT_VISIBILITY_DISTANCE 100.0f // default visible distance, 100 yards on continents | ||
| #define DEFAULT_VISIBILITY_INSTANCE 170.0f // default visible distance in instances, 170 yards | ||
| #define VISIBILITY_DIST_WINTERGRASP 175.0f | ||
| #define VISIBILITY_DIST_DALARAN 84.0f // visible distance in dalaran due to the city's dense/compact layout |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…e improvements
Changes Proposed:
This PR proposes changes to:
AI-assisted Pull Requests
Important
While the use of AI tools when preparing pull requests is not prohibited, contributors must clearly disclose when such tools have been used and specify the model involved.
Contributors are also expected to fully understand the changes they are submitting and must be able to explain and justify those changes when requested by maintainers.
Issues Addressed:
SOURCE:
The changes have been validated through:
Tests Performed:
This PR has been:
How to Test the Changes:
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.