Pull Request

This PR aligns mod-playerbots database handling with AzerothCore’s standard database pipeline and folder conventions.

What this change does

• Migrates the module SQL layout to match the AzerothCore SQL structure (base/, create/, custom/, updates/, archive/).
• Ensures module-specific tables that live in core databases (e.g. characters/world) are created through the normal update system, in a deterministic order, instead of relying on ad-hoc “base” execution.
• Removes redundant/legacy module-side update toggles and database bootstrapping logic so database lifecycle is handled centrally by the core (same model as Auth/Characters/World).
• Introduces “manual rebuild” scripts for destructive operations (DROP/REBUILD) so existing servers are not broken by an update pull.

Why it is needed

The previous module layout and execution order could lead to:

• updates running before required tables exist (ordering mismatch),
• destructive “base” scripts re-applying over an existing installation,
• different behavior between fresh installs vs existing servers.

This change makes the database workflow predictable, reproducible, and consistent with AzerothCore’s expectations.

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:

Minimum logic required

• Ensure playerbots DB + module SQL are treated like any other AC database/module: consistent directories, deterministic ordering, and core-driven update application.

Cheapest acceptable implementation

• Reuse the existing AzerothCore DBUpdater/UpdateFetcher mechanism by exposing playerbots SQL through the same structure and relying on the core’s loader/update flags.

Runtime cost

• No new per-bot/per-tick logic. This is startup/update-time only.
• Database updates are applied using the same workflow as existing AC databases.

How to Test the Changes

A) Fresh installation (empty databases)

1. Start from a clean MySQL instance (no existing characters/world/playerbots DBs as configured).
2. Configure worldserver.conf with:

• PlayerbotsDatabaseInfo
• PlayerbotsDatabase.WorkerThreads
• PlayerbotsDatabase.SynchThreads
• Ensure Updates.EnableDatabases includes the Playerbots DB mask (where applicable in the core).

3. Start worldserver.

4. Expected results:

• Playerbots DB is created if missing (same behavior as other DBs).
• Base tables are created in correct order.
• Updates are applied without “missing table” errors.
• Module loads normally and bots function.

B) Existing server upgrade (databases already populated)

1. Take an existing working install with live data.
2. Apply this PR changes and start worldserver.
3. Expected results:

• No destructive rebuild is triggered.
• Update scripts run safely (idempotent / guarded where needed).
• Existing data is preserved.
• No forced DROP/CREATE operations occur automatically.

C) Manual rebuild scripts (only when explicitly needed)

1. Stop the server.
2. Run the SQL scripts from _manual/... deliberately (only for full rebuild scenarios).
3. Start the server and verify normal update flow resumes afterward.

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)

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

Why some files were created

Some SQL had to be converted into dated update files to guarantee ordering and safety:

• Base “DROP+CREATE+INSERT” scripts can overwrite existing installs if re-applied.
• Updates must be idempotent and executed in chronological order.
• Module-specific tables living inside core DBs (characters/world) must be created before later updates that ALTER/convert engines/etc.

Why some SQL was moved to _manual

Certain legacy scripts are effectively full rebuild operations (DROP tables / re-seed large datasets / one-shot rebuild logic).
Automatically applying those via the update system would be risky for existing servers.
They were moved under _manual so operators can:

• intentionally rebuild when needed,
• avoid accidental destruction during normal update runs.

What should focus on

• Folder structure consistency with AC conventions.
• Update ordering correctness (tables created before ALTER/engine conversion).
• Safety of updates on existing installs (no destructive operations in auto-updates).