Skip to content

Test#56

Closed
zhangbo8418 wants to merge 18 commits intomasterfrom
Test1
Closed

Test#56
zhangbo8418 wants to merge 18 commits intomasterfrom
Test1

Conversation

@zhangbo8418
Copy link
Copy Markdown
Owner

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.

…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.
…cale

## Summary

- Refactored `mod-playerbots` so that all **active** bot-to-player messages (TellMaster, TellError, TellMasterNoFacing, Say, Whisper, Yell) now go through `PlayerbotAI::GetLocalizedBotTextOrDefault(...)` or a locale-aware text lookup.
- Added and wired new entries in `ai_playerbot_texts` (and the `2026_02_18_00_ai_playerbot_tell_chinese.sql` update) for previously hardcoded English strings, including quest messages, combat/aoe warnings, PvP stats, RPG and arena messages, release/ghost texts, emote quips, and various debug/status outputs.
- Updated existing usages that relied on `PlayerbotTextMgr::GetBotText(...)` / `GetBotTextOrDefault(...)` to use locale-aware lookups where the text is sent to a specific master player.

## Details

- **Quest / RPG / Movement**
  - Localized all quest-related bot messages (accept/fail, progress, rewards, item requirements) in `QuestAction`, `TalkToQuestGiverAction`, `DropQuestAction`, `NewRpgAction`, and `RpgSubActions`.
  - Localized AOE-avoidance messages and disperse-distance commands in `MovementActions`.

- **Chat shortcuts / release / battlegrounds**
  - Localized shortcut feedback such as following/ staying / fleeing / running / grinding and BWL strategy notifications in `ChatShortcutActions`.
  - Localized spirit-release related texts in `ReleaseSpiritAction` (including “I am not dead, will wait here”, “I am already a spirit”, “Releasing…”, and “Meet me at the graveyard”).
  - Localized LoS repositioning text in `BattleGroundTactics`.

- **Trading / mail / PvP / misc**
  - Localized trade, WTS / WHO, and whisper-based system feedback in `TradeStatusAction`, `SendMailAction`, `WtsAction`, `WhoAction`, and `RevealGatheringItemAction`.
  - Localized PvP currency and arena team status messages in `TellPvpStatsAction`.
  - Localized casting feedback including the “(x N left)” suffix in `CastCustomSpellAction`.
  - Localized join-group and join-raid invitation lines in `InviteToGroupAction`.

- **Emotes and fun texts**
  - Localized all active emote-based Say/Yell lines in `EmoteAction`, including the “stay/follow” TellMasterNoFacing flavor texts.
  - Left purely commented-out flavor lines unchanged, as they are not compiled or executed.

- **Debug / tools**
  - Localized debug quest/item progress lines and node management feedback in `DebugAction`, while keeping internal-only debug plumbing (e.g. `HandleRemoteCommand` return strings) intact.

## Notes

- Commented-out lines (inside `/* ... */` or `// ...`) that contain English text were intentionally left unchanged, as they are not compiled or executed.
- No function signatures, includes, or external dependencies were modified; changes are limited to message construction and SQL text entries.
Fix Build
@zhangbo8418 zhangbo8418 closed this Mar 9, 2026
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