Sitelet https://github.com/mod-playerbots/mod-playerbots/pull/2887
Skip to content

fix(text): replace longer placeholders first - #2887

Draft
avirar wants to merge 1 commit into
mod-playerbots:test-stagingfrom
avirar:fix/text-placeholder-order
Draft

avirar wants to merge 1 commit into
mod-playerbots:test-stagingfrom
avirar:fix/text-placeholder-order

Conversation

@avirar

@avirar avirar commented Oct 3, 2026

Copy link
Copy Markdown
Contributor

Pull Request Description

Bot texts substitute placeholders with plain string replacement, iterating the std::map of placeholders in lexicographic key order, so a short placeholder corrupts every longer placeholder that starts with it.

Live example from the qgo diagnostics added in a companion PR:

zone=190.428one              (%z ate %zone)
skillByLockType=0ByLockType  (%skill ate %skillByLockType)
maxcount=2count              (%max ate %maxcount)

Texts should not depend on their placeholder names; this fixes the shared replacement for every current and future text.

Feature Evaluation

Minimum logic: the three paths that apply placeholders (GetBotText(name, placeholders), the GetBotTextOrDefault fallback and the chat-reply path) now share a helper that sorts the placeholder keys by descending length before the existing replaceAll loop.

Processing cost: one small sort over a handful of keys, only when a text with placeholders is produced. No per-tick cost.

How to Test the Changes

  • With the qgo companion PR, qgo output shows zone=<id>, maxcount=<n> and skillByLockType=<n> intact instead of the corrupted values above.
  • Sanity check: texts with non-overlapping placeholders (%target, %item, %gameobject, ...) are unchanged; without a prefix pair the replacement order cannot matter.

Impact Assessment

  • Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots?

      • No, not at all
  • Does this change modify default bot behavior?

      • No
  • Does this change add new decision branches or increase maintenance complexity?

      • No

AI Assistance

Was AI assistance used while working on this change?

    • Yes (explain below)

    opencode (model deepseek-flash) wrote the change and this description. The author reviewed it; the corruption was reproduced and fixed live on a local realm via the qgo command, and the translation unit compiles warning-free.

Code Provenance / Attribution

Was any code in this PR copied or adapted from a sister / upstream project?

    • No, all code in this PR is original

Final Checklist

    • Changes are understood and tested for server stability and performance impact.
    • Any new bot dialogue lines are translated.
    • New source files use the GPLv2 header.
    • Documentation updated if needed (Code comments, Conf comments, WiKi commands).
    • New and modified files do not introduce new compiler warnings.

Notes for Reviewers

  • Found while testing the qgo localization companion PR; that PR also renames its own colliding tokens, this is the general fix.
  • The three call sites are the only places in the module that apply placeholder maps.

Bot texts substitute placeholders with plain string replacement in map
order (lexicographic). A short key therefore corrupts any longer key that
starts with it: %max is eaten by %maxcount, %z by %zone and %skill by
%skillByLockType, which qgo's diagnostics showed as "maxcount=2count",
"zone=190.428one" and "skillByLockType=0ByLockType".

Apply placeholders longest key first in all three replacement paths, so
texts no longer depend on their key names.
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