Fix GM group invite: bots not responding and stuck "already in group"

[zhangbo8418]

Problem

• When a GM invites an online bot to a group, the bot does not respond and no party list appears.
• After that, other players cannot invite the same bot and get "already in group" (or similar).
• Normal (non-GM) invites work as expected.

Root cause

• AcceptInvitationAction used ObjectAccessor::FindPlayer() to resolve the inviter. FindPlayer() requires the player to be IsInWorld(). GMs in certain states (e.g. observer, phase, or other GM modes) may not satisfy that, so the inviter was null and the bot never accepted.
• The bot kept a pending group invite, so the server correctly reported "already in group" for new invites.
• No packet empty/size checks before reading from event packets could lead to undefined behavior on malformed or empty packets.

Changes

1. AcceptInvitationAction

   • Use FindConnectedPlayer() for the inviter so GMs are found regardless of IsInWorld().
   • Clear the invite with UninviteFromGroup() when the inviter is not found, so the bot is not stuck and others can invite later.
   • Add packet empty/size check before reading flag and name.

2. PetitionSignAction

   • Use FindConnectedPlayer() for the petition inviter (same GM case).
   • Add packet size check before reading petitionGuid and inviter.

3. PlayerbotAI::GetGroupLeader()

   • Use FindConnectedPlayer() for the group leader so a GM leader is returned even when not IsInWorld().

4. Packet safety

   • GuildAcceptAction, ArenaTeamActions: check packet empty before reading.
   • LeaveGroupAction (PartyCommandAction and UninviteAction): add empty/size checks before reading from the packet.

No other changes are required for this fix.

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:

• Describe the minimum logic required to achieve the intended behavior?
• Describe the cheapest implementation that produces an acceptable result?
• Describe the runtime cost when this logic executes across many bots?

---

How to Test the Changes

• Step-by-step instructions to test the change
• Any required setup (e.g. multiple players, bots, specific configuration)
• Expected behavior and how to verify it

Complexity & Impact

Does this change add new decision branches?

• • No
• • Yes (explain below)

Does this change increase per-bot or per-tick processing?

• • No
• • Yes (describe and justify impact)

Could this logic scale poorly under load?

• • No
• • Yes (explain why)

---

Defaults & Configuration

Does this change modify default bot behavior?

• • No
• • Yes (explain why)

If this introduces more advanced or AI-heavy logic:

• • Lightweight mode remains the default
• • More complex behavior is optional and thereby configurable

---

AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change?

• • No
• • Yes (explain below)

If yes, please specify:

• AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
• Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation)
• Which parts of the change were influenced or generated
• Whether the result was manually reviewed and adapted

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

• • Stability is not compromised
• • Performance impact is understood, tested, and acceptable
• • Added logic complexity is justified and explained
• • Documentation updated if needed

---

Notes for Reviewers

Anything that significantly improves realism at the cost of stability or performance should be carefully discussed
before merging.

---

Note

Medium Risk
Touches invite/leave flows and packet parsing for multiple playerbot actions; behavior changes are small but affect core grouping/guild/petition interactions and could alter how bots respond to edge-case packets or disconnected leaders.

Overview
Fixes bots getting stuck on GM-issued group invites by resolving inviters/leaders via ObjectAccessor::FindConnectedPlayer() (instead of FindPlayer()) in AcceptInvitationAction, PetitionSignAction, and PlayerbotAI::GetGroupLeader().

Adds defensive WorldPacket empty/size checks across several accept/leave actions (group, guild, arena team, petition, uninvite/party command) and explicitly clears a pending group invite (UninviteFromGroup()) when the inviter cannot be resolved, preventing bots from remaining in a blocked “already in group” invite state.

^{Written by Cursor Bugbot for commit 0186d51. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

This is the final PR Bugbot will review for you during this billing cycle

Your free Bugbot reviews will reset on March 26

Details

You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Missing UninviteFromGroup on packet validation early return

Medium Severity

When the packet validation fails at the new early return, bot->UninviteFromGroup() is not called, even though bot->GetGroupInvite() was confirmed non-null on line 17. This leaves the bot stuck with a pending group invite — the exact "already in group" problem this PR aims to fix. The inviter-not-found path (line 31) and the security-check path (line 40) both correctly call UninviteFromGroup(), but this newly added path does not.