Skip to content

Conversation

@Nyeriah
Copy link
Member

@Nyeriah Nyeriah commented Dec 6, 2025

Changes Proposed:

This PR proposes changes to:

  • Core (units, players, creatures, game systems).
  • Scripts (bosses, spell scripts, creature scripts).
  • Database (SAI, creatures, etc).

Issues Addressed:

  • Closes

SOURCE:

The changes have been validated through:

  • Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
  • Sniffs (remember to share them with the open source community!)
  • Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
  • The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

  • Tested in-game by the author.
  • Tested in-game by other community members/someone else other than the author/has been live on production servers.
  • This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

  • This pull request can be tested by following the reproduction steps provided in the linked issue
  • This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

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.

@github-actions github-actions bot added CORE Related to the core file-cpp Used to trigger the matrix build labels Dec 6, 2025
@kissingers
Copy link
Contributor

Players also should not enter these maps until they have completed the prerequisite quest:
269 The Black Morass
560 Old Hillsbrad Foothills
585 Magisters' Terrace
and might some other maps

@Tereneckla
Copy link
Contributor

Only LFG_LOCKSTATUS_RAID_LOCKED is ignored. That status is used by the disable manager and already completed instances.

Other blockers have different statuses

@TheSCREWEDSoftware
Copy link
Contributor

@amed80 can you test this when you've time?

Copy link
Contributor

Copilot AI left a 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 GetCompatibleDungeons signature to accept randomDungeonId parameter instead of boolean isRDF
  • Added enum LfgRandomDungeonIds with constants for normal (259) and heroic (260) random dungeons
  • Refactored DisableMgr::IsDisabledFor to support non-Player unit checks via the flags parameter
  • 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))
Copy link

Copilot AI Dec 7, 2025

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.

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CORE Related to the core file-cpp Used to trigger the matrix build Ready to be Reviewed Waiting to be Tested

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants