Fix random bots stuck in group on player logout; add leader transfer …#2130
Fix random bots stuck in group on player logout; add leader transfer …#2130zhangbo8418 wants to merge 19 commits intomod-playerbots:test-stagingfrom
Conversation
…and delayed leave ## Summary - Prevents random bots from staying in a group when their master logs out, which made them uninvitable on re-login. - When a real player leaves a party that still has other real players, the party is kept: leader is transferred to the next real player and bots get a new master. The party only breaks when the last real player leaves. - When no real player remains in the party, random bots leave after a configurable delay (default 180s) so brief disconnects don’t disband the group. - After a server crash/restart, groups are restored from DB; if a random bot logs in and its group has no connected real player, that group is scheduled for delayed leave so bots don’t stay stuck. ## Changes - **OnPlayerLogout**: For each random bot that had the logging-out player as master, either assign a new master (first connected real player in the group) and transfer party leader to that player, or schedule delayed leave and clear master. If the core did not remove the player on logout (`LeaveGroupOnLogout=0`), transfer leader when possible, then remove the player from the group. - **Delayed leave**: New config `AiPlayerbot.BotLeaveGroupDelayWhenNoRealPlayer` (default 180 seconds). Groups with no real player are scheduled; each tick `ProcessScheduledGroupLeaves` re-checks for a connected real player and, if still none, only **random bots** in that group are forced to leave (alt/addclass bots are not kicked). Delay 0 means leave on the next tick. - **OnBotLoginInternal**: When a random bot logs in and is in a group with no connected real player, schedule that group for delayed leave (avoids stuck/uninvitable bots after crash). - **Scope**: Only 5-man parties are handled; raid, LFG, and battleground are skipped. Logic applies only to random bots managed by RandomPlayerbotMgr. ## Config - `AiPlayerbot.BotLeaveGroupDelayWhenNoRealPlayer` (default: 180) — seconds before random bots leave the group when no real player remains. ## Notes - If `LeaveGroupOnLogout` is enabled in the core, the core removes the player and broadcasts first; bots may leave immediately via `PartyCommandAction(PARTY_OP_LEAVE)`, so the delay does not apply in that case. When `LeaveGroupOnLogout` is disabled, we transfer leader and remove the player ourselves, and the delay applies. - Defensive checks added: `FindFirstRealConnectedPlayerInGroup` validates `GetSession()` and skips logout/invalid members to avoid crashes.
|
Please make sure your PR targets the test-staging branch, not master. |
|
Can that be selected when submitting PRs? |
|
Yeah of course, it just defaults to the default branch. 
|
|
Okay, about the PR itself. The core issue at hand "Fix random bots stuck in group on player logout" How does that happen to you right now? Unless I am misunderstanding the intent here, RND bot groups already disband when human master leaves, no? Things are handled in LeaveGroupAction This is screenshot is for my bot group, taken at the exact moment I clicked logout |
|
So on logout they wont leave and just wait around forever for you to come back. Edit: doing a quick read through, im not sure that I agree fully with the scheduling leaving group this way. Need to think about it more. |
If you don't need to wait, you can set AiPlayerbot.BotLeaveGroupDelayWhenNoRealPlayer to 0. |
|
No offense but try to fill in the PR form, esp when using AI in this extend. |
Master update from Test-staging: Fix ObjectAccessor retrieval, optimize EquipActions, and implement RaidBossHelpers
This reverts commit c86032f.
Master update from Test staging
|
The code has multiple thread safety issues and potential crash hazards. |
| // When CONFIG_LEAVE_GROUP_ON_LOGOUT is true, the core removes the player from the group before this hook | ||
| // and sends group updates; bots may then leave immediately in LeaveGroupAction::PartyCommandAction (PARTY_OP_LEAVE). | ||
| // When it is false, we transfer leader / remove player ourselves below and set bot master to nullptr before | ||
| // RemoveMember, so bots do not leave in PartyCommandAction and the scheduled delay applies. |
There was a problem hiding this comment.
This code taking into consideration AiPlayerbot.KeepAltsInGroup config?
Update master from Test staging and Core Update
Test staging to master
Test staging to master
…and delayed leave
Summary
Changes
LeaveGroupOnLogout=0), transfer leader when possible, then remove the player from the group.AiPlayerbot.BotLeaveGroupDelayWhenNoRealPlayer(default 180 seconds). Groups with no real player are scheduled; each tickProcessScheduledGroupLeavesre-checks for a connected real player and, if still none, only random bots in that group are forced to leave (alt/addclass bots are not kicked). Delay 0 means leave on the next tick.Config
AiPlayerbot.BotLeaveGroupDelayWhenNoRealPlayer(default: 180) — seconds before random bots leave the group when no real player remains.Notes
LeaveGroupOnLogoutis enabled in the core, the core removes the player and broadcasts first; bots may leave immediately viaPartyCommandAction(PARTY_OP_LEAVE), so the delay does not apply in that case. WhenLeaveGroupOnLogoutis disabled, we transfer leader and remove the player ourselves, and the delay applies.FindFirstRealConnectedPlayerInGroupvalidatesGetSession()and skips logout/invalid members to avoid crashes.Pull Request
Describe what this change does and why it is needed...
Design Philosophy
We prioritize stability, performance, and predictability over behavioral realism.
Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and
long-term robustness.
Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all
participants. Because every action and
decision tree is executed per bot and per trigger, even small increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead.
Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the default configuration must remain the lightweight decision
model. More complex behavior should only be
available as an explicit opt-in option, clearly documented as having a measurable performance cost.
Principles:
Stability before intelligence
A stable system is always preferred over a smarter one.
Performance is a shared resource
Any increase in bot cost affects all players and all bots.
Simple logic scales better than smart logic
Predictable behavior under load is more valuable than perfect decisions.
Complexity must justify itself
If a feature cannot clearly explain its cost, it should not exist.
Defaults must be cheap
Expensive behavior must always be optional and clearly communicated.
Bots should look reasonable, not perfect
The goal is believable behavior, not human simulation.
Before submitting, confirm that this change aligns with those principles.
Feature Evaluation
Please answer the following:
How to Test the Changes
Complexity & Impact
Does this change add new decision branches?
Does this change increase per-bot or per-tick processing?
Could this logic scale poorly under load?
Defaults & Configuration
Does this change modify default bot behavior?
If this introduces more advanced or AI-heavy logic:
AI Assistance
Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change?
If yes, please specify:
AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest
about what they do and do not understand.
Final Checklist
Notes for Reviewers
Anything that significantly improves realism at the cost of stability or performance should be carefully discussed
before merging.