Skip to content

fix: close the remaining dual-faction paths from #166 - #174

Merged
FrancescoBorzi merged 3 commits into
masterfrom
fix-166-identity-corruption
Jul 2, 2026
Merged

fix: close the remaining dual-faction paths from #166#174
FrancescoBorzi merged 3 commits into
masterfrom
fix-166-identity-corruption

Conversation

@FrancescoBorzi

@FrancescoBorzi FrancescoBorzi commented Jul 2, 2026

Copy link
Copy Markdown

Summary by CodeRabbit

  • Bug Fixes
    • Improved handling of battleground faction and appearance state so players are restored more consistently after certain state changes.
    • Fixed logout behavior for temporary battleground-related player records during active war time, preventing stale fake-player data from persisting.
    • Ensured charm effects are fully cleared when removing a fake player state, reducing cases where player control or visuals could remain incorrect.

@coderabbitai

coderabbitai Bot commented Jul 2, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

Modifies CFBG faction consistency repair to resync faction for non-GM players with mismatched race factions, adds charm aura removal in ClearFakePlayer, introduces a new DropFakePlayerRecord method that erases fake player records without state restoration, and wires it into WG logout handling during war time.

Changes

CFBG fake player and faction repair

Layer / File(s) Summary
Faction resync on foreign template mismatch
src/CFBG.cpp
EnforceBGTeamConsistency reapplies faction via SetFactionForRace when a non-GM player's race faction diverges from current faction and no MOD_FACTION aura is present.
Charm removal and new erase-only record drop
src/CFBG.cpp, src/CFBG.h
ClearFakePlayer now removes charm auras before restoring real state; a new DropFakePlayerRecord method is declared and implemented to erase the fake record without restoration.
WG logout wiring for war-time record drop
src/CFBG_SC.cpp
OnPlayerLogout calls DropFakePlayerRecord for WG battlefields during war time instead of ClearFakePlayer, keeping the prior clear behavior for non-war time.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Player
  participant CFBG_Player
  participant CFBG
  Player->>CFBG_Player: OnPlayerLogout
  alt WG battlefield not in war time
    CFBG_Player->>CFBG: ClearFakePlayer(player)
    CFBG-->>Player: restore real race/morph/faction
  else WG battlefield in war time
    CFBG_Player->>CFBG: DropFakePlayerRecord(player)
    CFBG-->>Player: erase fake record only
  end
Loading

Possibly related PRs

  • azerothcore/mod-cfbg#168: Both PRs modify CFBG::EnforceBGTeamConsistency(Player*), with this PR extending its foreign-template/faction repair logic.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title matches the main change: fixing remaining dual-faction/faction-consistency paths linked to #166.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix-166-identity-corruption

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/CFBG.cpp`:
- Around line 335-339: The faction repair in CFBG::SetFactionForRace should also
respect active charm state, not just Game Master or SPELL_AURA_MOD_FACTION.
Update the guard so that when player->IsCharmed() is true, this recovery path is
skipped and does not overwrite the faction currently controlled by the charm.
Keep the existing race/faction comparison logic intact, but add the charm check
alongside the existing IsGameMaster and aura condition near the
SetFactionForRace call site.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 7f90ff49-465f-46f2-bdea-7600ecf473e6

📥 Commits

Reviewing files that changed from the base of the PR and between 902f3af and 7fe3759.

📒 Files selected for processing (3)
  • src/CFBG.cpp
  • src/CFBG.h
  • src/CFBG_SC.cpp

Comment thread src/CFBG.cpp
Comment on lines +335 to +339
if (!player->IsGameMaster() && !player->HasAuraType(SPELL_AURA_MOD_FACTION))
{
ChrRacesEntry const* raceEntry = sChrRacesStore.LookupEntry(player->getRace(true));
if (raceEntry && player->GetFaction() != raceEntry->FactionID)
SetFactionForRace(player, player->getRace(true), player->GetTeamId(true));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Treat active charm as a legitimate faction writer here.

ClearFakePlayer now documents charm as owning/restoring faction state, but this repair path only skips GM and SPELL_AURA_MOD_FACTION. If a native player is actively charmed, this can overwrite the charm-owned faction before the charm ends; skip this repair while player->IsCharmed().

Proposed fix
-        if (!player->IsGameMaster() && !player->HasAuraType(SPELL_AURA_MOD_FACTION))
+        if (!player->IsGameMaster() && !player->IsCharmed() && !player->HasAuraType(SPELL_AURA_MOD_FACTION))
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
if (!player->IsGameMaster() && !player->HasAuraType(SPELL_AURA_MOD_FACTION))
{
ChrRacesEntry const* raceEntry = sChrRacesStore.LookupEntry(player->getRace(true));
if (raceEntry && player->GetFaction() != raceEntry->FactionID)
SetFactionForRace(player, player->getRace(true), player->GetTeamId(true));
if (!player->IsGameMaster() && !player->IsCharmed() && !player->HasAuraType(SPELL_AURA_MOD_FACTION))
{
ChrRacesEntry const* raceEntry = sChrRacesStore.LookupEntry(player->getRace(true));
if (raceEntry && player->GetFaction() != raceEntry->FactionID)
SetFactionForRace(player, player->getRace(true), player->GetTeamId(true));
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/CFBG.cpp` around lines 335 - 339, The faction repair in
CFBG::SetFactionForRace should also respect active charm state, not just Game
Master or SPELL_AURA_MOD_FACTION. Update the guard so that when
player->IsCharmed() is true, this recovery path is skipped and does not
overwrite the faction currently controlled by the charm. Keep the existing
race/faction comparison logic intact, but add the charm check alongside the
existing IsGameMaster and aura condition near the SetFactionForRace call site.

@FrancescoBorzi
FrancescoBorzi merged commit f7d4faf into master Jul 2, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant