-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
fix(Core/LFG): Don't include disabled maps in the LFG queue #24057
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Players also should not enter these maps until they have completed the prerequisite quest: |
|
Only LFG_LOCKSTATUS_RAID_LOCKED is ignored. That status is used by the disable manager and already completed instances. Other blockers have different statuses |
|
@amed80 can you test this when you've time? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR aims to prevent disabled maps from being included in the LFG (Looking For Group) random dungeon queue by adding difficulty-aware map disable checks to the dungeon compatibility filtering logic.
Key Changes:
- Modified
GetCompatibleDungeonssignature to acceptrandomDungeonIdparameter instead of booleanisRDF - Added enum
LfgRandomDungeonIdswith constants for normal (259) and heroic (260) random dungeons - Refactored
DisableMgr::IsDisabledForto support non-Player unit checks via theflagsparameter - Integrated disable checks into the LFG dungeon filtering logic
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| src/server/game/DungeonFinding/LFGMgr.h | Changed function signature from boolean isRDF to uint32 randomDungeonId parameter with default value 0 |
| src/server/game/DungeonFinding/LFGMgr.cpp | Implemented disabled map filtering logic and updated function signature; added difficulty-based disable checks |
| src/server/game/DungeonFinding/LFG.h | Added LfgRandomDungeonIds enum defining random dungeon ID constants for normal and heroic modes |
| src/server/game/Conditions/DisableMgr.cpp | Refactored map/LFG map disable checking to support non-Player callers using difficulty flags parameter |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| bool isDungeonDisabled = dungeon && (sDisableMgr->IsDisabledFor(DISABLE_TYPE_MAP, dungeon->map, nullptr, difficultyFlag) | ||
| || sDisableMgr->IsDisabledFor(DISABLE_TYPE_LFG_MAP, dungeon->map, nullptr, difficultyFlag)); | ||
|
|
||
| if (!isDungeonDisabled && it2->second == LFG_LOCKSTATUS_RAID_LOCKED && randomDungeonId && sWorld->getBoolConfig(CONFIG_LFG_ALLOW_COMPLETED)) |
Copilot
AI
Dec 7, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic change from isRDF && sWorld->getBoolConfig(CONFIG_LFG_ALLOW_COMPLETED) to randomDungeonId && sWorld->getBoolConfig(CONFIG_LFG_ALLOW_COMPLETED) may have unintended consequences. When randomDungeonId is 0 (which happens for specific dungeon selections rather than random), this condition will be false even if the old isRDF boolean would have been true. This could prevent completed dungeons from being allowed in non-random specific selections if that was previously supported.
Consider whether the original isRDF boolean logic should be preserved, or if this change is intentional behavior.
Co-authored-by: Copilot <[email protected]>
Changes Proposed:
This PR proposes changes to:
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.