fix: wg war team and lifecycle - #178
Conversation
With an empty zone and trickle joins the first accepter latches a 1/0 census, whose floored fair share (1+0)/2 = 0 made every majority joiner flip: three same-faction players ended up 0v3 on the wrong side. The fair share is now a ceiling, so the lone first accepter counts as fair share and stays native, and past the fair share a majority joiner flips only when his real side currently outnumbers the other in the live war sets; on a tie he stays native.
Core keys the war vacancy gate, kick and invite bookings and the Players[] insert on GetTeamId(), which for a war-locked flipped player returning to the zone is still the REAL team until the join-war hook re-fakes him. That mis-keyed him against the wrong side's cap: a wrongful 10s battlefield-full kick when his real side was full, or overfilling a side past Wintergrasp.PlayerMax. Handle the enter-zone hook, which core fires before any of those containers are consulted, and re-fake a war-locked player there. Also stop fresh assignments from flipping into a side already at Wintergrasp.PlayerMax; stored locks are honored unchanged.
EndBattleground restores every player's real identity, but a cross-faction player who dies at the victory screen and reclaims within the WAIT_LEAVE window went through the resurrect reconciliation, which re-faked him for the rest of the window. Early-return on WAIT_LEAVE exactly; entry-time calls run at WAIT_JOIN or IN_PROGRESS and the in-progress resurrect reapply is unaffected.
Disabling CFBG.Enable and running .reload config early-returned out of LoadConfig, stranding every online faked player cross-faction until relog and orphaning the Player*-keyed store entries, which can corrupt a later Player object reusing the same address. On a true to false transition, restore every online faked player and wholesale-clear all four Player*-keyed stores without dereferencing stored keys (a faked player who logged out mid-war may have left a dangling key). Also give _IsEnableSystem an initializer so the transition read is well-defined on the first load; startup never runs the sweep.
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
1 participant
No description provided.