Refactor paladins buff strategie #7
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change centralizes paladin blessing decisions to avoid duplicated logic, reduces unnecessary work in Sanctuary handling, and removes temporary allocations when selecting designated roles. The behavior is unchanged, but the logic is now simpler, more consistent, and slightly cheaper at runtime. No tests were run.
Quick fix for a very annoying error identified by SmashingQuasar. In WSG, bots will camp the opposing graveyard if up 2-0. This is supposed to exclude the flag carrier, but a logical error has resulted in the flag carrier being excluded for Alliance camping only, meaning the Horde flag carrier will camp the GY with the rest of the team if up 2-0 and thus refuse to end the game.
# Pull Request Some logic was changed but differs from the original code, certain edge cases so not result in same behavior. This returns the original code with only the singleton chances. @Wishmaster117 Reviewed the hotfix and noticed the different code paths. ps: reverted an removed placeholder since its ongoing issue/research.
…eport its current Arena Points, Honor Points, and Arena Teams (mod-playerbots#2071) # Pull Request This PR adds a new whisper command "pvp stats" that allows players to ask a bot to report its current Arena Points, Honor Points, and Arena Teams (name and team rating). Reason: Due to a client limitation in WoW 3.3.5a, the inspection window does not display another player's Arena or Honor points , only team data. This command provides an easy in-game way to check a bot’s PvP currencies without modifying the client or core packets. --- ## Design Philosophy Uses existing core getters (GetArenaPoints, GetHonorPoints, GetArenaTeamId, etc.). Fully integrated into the chat command system (ChatTriggerContext, ChatActionContext). Safe, no gameplay changes, purely informational. No harcoded texts, use database local instead --- ## How to Test the Changes /w BotName pvp stats Bot reply: [PVP] Arena Points: 302 | Honor Points: 11855 [PVP] 2v2: <The Fighters> (rating 2000) [PVP] 3v3: <The Trio> (rating 573) ## Complexity & Impact - Does this change add new decision branches? - [x] No - [ ] Yes (**explain below**) - Does this change increase per-bot or per-tick processing? - [x] No - [ ] Yes (**describe and justify impact**) - Could this logic scale poorly under load? - [x] No - [ ] Yes (**explain why**) --- ## Defaults & Configuration - Does this change modify default bot behavior? - [x] No - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - [x] 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? - [x] No - [ ] Yes (**explain below**) --- ## Final Checklist - [x] Stability is not compromised - [x] Performance impact is understood, tested, and acceptable - [x] Added logic complexity is justified and explained - [x] Documentation updated if needed --- Multibot already ready Here is a sample of multibot when merged: <img width="706" height="737" alt="image" src="https://github.com/user-attachments/assets/5bcdd9f8-e2fc-4c29-a497-9fffba5dfd4e" /> --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
Convert PlayerBots tables to InnoDB (disable strict mode during
conversion)
# Pull Request
### This change converts the PlayerBots-related tables from MyISAM to
InnoDB.
**Why this is beneficial (even without fixing a specific bug):**
- Crash safety & data integrity: InnoDB is transactional and uses redo
logs; it provides automatic crash recovery, unlike MyISAM which can
require manual repairs after unclean shutdowns.
- Row-level locking: InnoDB reduces write contention and improves
concurrency under bot-heavy workloads compared to MyISAM’s table-level
locks.
- Consistent reads: InnoDB supports MVCC, enabling stable reads while
writes are happening—useful for mixed read/write access patterns.
- Operational robustness: Better behavior under backup/restore and
replication scenarios; fewer “table marked as crashed” style issues.
Strict mode handling:
The migration toggles innodb_strict_mode off only for the session to
prevent the conversion from failing on edge-case legacy definitions,
then re-enables it immediately after.
---
## How to Test the Changes
- Step-by-step instructions to test the change
Run the SQL script in the Playerbot database.
- Any required setup (e.g. multiple players, bots, specific
configuration)
No
- Expected behavior and how to verify it
All tables should now have been converted from InnoDB to MyISAM.
This script should return nothing:
```
SELECT
t.TABLE_SCHEMA AS db_name,
t.TABLE_NAME AS table_name,
t.ENGINE AS storage_engine
FROM information_schema.TABLES t
WHERE t.TABLE_SCHEMA = DATABASE()
-- With phpMyAdmin, use the following and insert your database name, e.g., “acore_playerbots.”
-- WHERE t.TABLE_SCHEMA = 'YOUR_PLAYERBOT_DB'
AND t.TABLE_TYPE = 'BASE TABLE'
AND t.ENGINE = 'MyISAM'
ORDER BY t.TABLE_NAME;
```
## Complexity & Impact
- Does this change add new decision branches?
- [x] No
- [ ] Yes (**explain below**)
- Does this change increase per-bot or per-tick processing?
- [x] No
- [ ] Yes (**describe and justify impact**)
- Could this logic scale poorly under load?
- [x] No
- [ ] Yes (**explain why**)
---
## Defaults & Configuration
- Does this change modify default bot behavior?
- [x] No
- [ ] Yes (**explain why**)
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [x] No
- [ ] Yes (**explain below**)
---
## Final Checklist
- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [ ] Documentation updated if needed
- [x] I tested this script on a server with 2000 bots for 6 days
(running 24/h) and had no issues with it.
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.