mirror of
https://github.com/liyunfan1223/mod-playerbots.git
synced 2026-06-20 23:49:25 +02:00
13 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
NoxMax
|
66d41e1d79
|
Feat: Selective reset to default of combat or non-combat strategies (#2365)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Adds the commands `co !` and `nc !`, which would reset either the combat or non-combat strategies of a follower bot, without affecting the other strategies or any other values. Also ChangeStrategyAction.cpp was refactored for duplicate code by introducing the helper function `HandleStrategyCommon`, that gets called by `ChangeCombatStrategyAction` and `ChangeNonCombatStrategyAction` ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. `reset botAI` already resets strategies back to default, but it resets ALL strategies and wipes values such as formations, stances, and everything else under the `value` key in playerbots_db_store>value. The new commands don't run across many bots, only on the bot the command is run on. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Run either `co ?` and `nc ?` to see current list of combat and non-combat strategies the bot has. 2. Add and remove strategies to both `co` and `nc`. 3. Confirm your changes with `co ?` and `nc ?`. 4. Run `co !` only. 5. Run `co ?` to confirm combat strategies have been reset to default, and `nc ?` to confirm it has not been affected. Then run `nc !` to reset it as well. 6. Do another test [inside an instance](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#raid-specific-strategies). Remove a bunch of `nc` strategies, including the strategy for the raid itself. 7. Run `nc !` and check that the defaults have been reset, but that the instance strategy has been re-added as well. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Technically it adds a new case to ChangeCombatStrategyAction, but it's straightforward. ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> Review only in case I was missing something, and then to easily refactor duplicate code with HandleStrategyCommon. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> [Commands wiki](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#strategies) need to be modified to read: --- You can query the bot to report what strategies are currently being used: ``` co ? nc ? ``` You can reset either of the bot's strategies back to defaults: ``` co ! nc ! ``` --- Tangentially I also recommend [this section](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#non-combat-strategies) to be edit to this for more accuracy: --- General strategy | description :---|:--- ``food`` | enable bot's ability to eat/drink ``pvp`` | enable bot's ability to engage in PVP combat. Note: PVP mode wouldn't appear active until the bot starts combat ``loot`` | enable bot's ability to loot. Note: adding or removing that strategy for randombots requires GM level |
||
|
kadeshar
|
19249e90a0
|
Pull strategy migration (#2310)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Pull strategy migration from cmangos for tank specializations
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
1. Invite bot tank
2. Use `reset boAI` or `nc +pull,+pull back` + `co +pull,+pull back`
3. Order bot to pull using command `pull my target` or `pull rti target`
4. Bot should run to mob, use ranged skill and back to point where he
started pull
Without `pull back` strategy bot run to mob, use ranged skill and wait
on mob until he come to bot
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Help with migration and solving some problems
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [ ] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
Stability test after randomize new bots
<img width="465" height="172" alt="obraz"
src="https://github.com/user-attachments/assets/6e39a8c0-f23b-47cc-852a-71fa98044a31"
/>
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
|
||
|
Crow
|
a34681bd7e
|
Modify UpdateAI to Allow Future Methods to Interrupt Bot Spells (#2295)
Note: Resubmitted because the prior PR had master for the source
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This PR adds to PlayerbotAI::UpdateAI a boolean variable,
pendingCastInterrupt, and a public function, RequestCastInterrupt(),
that toggles the variable and would then call InterruptSpells in
UpdateAI. This lets an external script hook into UpdateAI to interrupt a
spell that is in the process of being cast. This should allow
raid/dungeon strategies to actually interrupt spells, such as for
avoiding hazards, as you cannot do so by calling InterruptSpells() or
Reset() or anything else with a raid/dungeon action method.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
There is no processing cost from this PR itself since it just adds a
simple boolean check that will always return false unless other methods
are implemented to call RequestCastInterrupt().
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
This PR doesn't do anything by itself, but confirmation of no
performance impact can be tested by just playing with the PR merged. I
tested this by introducing scripts that called RequestCastInterrupt()
for Archimonde (included in the Hyjal PR now) and for Auchenai Crypts
(built on the strategy from flashtate's PR just for test purposes), and
spells were interrupted as intended.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [ ] No
- - [x] Yes (**explain below**)
I'm not sure if it counts as "yes" here, but this PR opens up the
ability for scripts to be added that would add real checks to UpdateAI.
The impact of such scripts will depend on how they are implemented,
however. It is possible (and intended) for the external calls to be
highly limited in scope (e.g., only bots in a particular circumstance in
a particular boss fight).
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Claude Sonnet 4.6 was used to brainstorm different possibilities to
allow external scripts to interrupt spells. I considered different
options before settling on this one due to it not requiring core
changes, being easily usable in boss strategies, and not having any
performance impact on its own.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
|
||
|
bashermens
|
4bcf8fd2c4
|
Performance(Core): Some activity sec to ms init fixes, global activity loop check and some additional minor fixes (#2288)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
1. Corrected the init activity times; Since ive changed (previous) the
calc from seconds to ms to increase more scope for the offset execute
jitter (removed timer(), 0 is correct way todo now with MS) (also broke
self-bot)
2. Global loop checks in activityAllowed instead vs multiple loops, this
function is called very often so we better optimize it.
3 Fixed the broken 'HasManyPlayersNearby' function and then deleted it
:O To fragile due various edge cases and rather expensive call, besides
lets activeAlone deal with this situation which is way more controlled.
4. Some additional small fixes that where unnoticed overtime.
5. Added/Changed inline comments which makes more sense and explains
what it does.
6. Removed dead code freeze bots during init.
7. self-bot fix
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [x] Moderate impact (**explain below**)
When playing with larger amount of real players makes the allowed
activity perform better.
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
bashermens
|
c0390a24fd
|
feat(Performance): BotActiveAlone activity interval fixes and default settings for avg player (#2250)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
- Bugfix the jittering on/off of botAlone activity
- BotActiveAlone activity duration configurable
- Updated the default config values for general user for a smoother
experience
- Added offset jittering for the check allowedActivity and check next AI
delay to prevent cpu spikes
(disabled WhenIsFriend can cause race conditions)
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing 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, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [x] Moderate impact (**explain below**)
In a positive way, bots in your zone and 150 radius will always be
active, meanwhile other bots will be active 40%
of the time with intervals for 60 seconds per bot. With much lower
latencies. All configurable without say.
40% and 60 seconds for more balance for those who seek bots create world
feel more natural and live vs bots leveling without killing the server
performance. Why not 50 due activity of bots itself 40% will result more
into 45-50% like behavior and 50% prolly more 55%-60%. This it not
something we want incorporate when calculating the value since it
depends on various config and situation. But 40% is good base with
default config.
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
- Does this change add bot messages to translate?
- - [x] No
- - [ ] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
| | |
| | |
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
- Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
## 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 (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
|
||
|
kadeshar
|
76dd91c4fa
|
Hand of Freedom support (#2233)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description Added Hand of Freedom action for paladin. Related with: #2002 ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> - invite paladin bot to party - start fight (can use dummy target) - apply some snare effect to bot or yourself (for example `.aura 1715`) - bot should use hand of freedom ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Yes, paladin bots start using Hand of Freedom - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## Messages to Translate <!-- Bot messages have to be translatable, but you don't need to do the translations here. You only need to make sure the message is in a translatable format, and list in the table the message_key and the default English message. Search for GetBotTextOrDefault in the codebase for examples. --> - Does this change add bot messages to translate? - - [x] No - - [ ] Yes (**list messages in the table**) | Message key | Default message | | --------------- | ------------------ | | | | | | | ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> - Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> OpenCode, as helper to create and review code ## 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 (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> <img width="424" height="93" alt="obraz" src="https://github.com/user-attachments/assets/3cac4454-35af-474d-8ea0-67c462973c79" /> |
||
|
Keleborn
|
957eca0263
|
Feat. Enable multi node flying, and refactor into travel manager (#2156)
# Pull Request Feature - Enable multi node flying for bots - Bots currently only do node to node flying. This PR makes it so they can connect multiple noted. -- This is enabled by sending a vector containing the node sequence instead of a single destination node -- To minimize the run-time cost of searching for available nodes and connection, a cache of all possible connections is prepared at start up using a BFS search algorithm. Refactor - Move all world destination logic (cities, banks, inns) to existing Travel manager - Eliminate flightmastercache and integrate to new manager - replace SQLs calls with in-memory data search by core - Add in new map that stores creature areas by template. Clean up - Move other rpg files to related folder. (Next steps) The selection for where bots fly to should be smarter than it is. Instead of trying to determine where a bot can go, it should first decide where it should go, and then identify the correct way to get there. --- ## 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? - - [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**) The call itself is fairly infrequent, and although now there are a greater number of paths available for the bots, I dont think it would be significant. ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] 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? - - [ ] No - - [x] Yes (**explain below**) Gemini first suggested the use of a BFS algorithm. This was rewritten by me to actually work as intended. Verification by additional logging not present in final code. Claude code converted the SQL filtering to the atrocious if statements found in PrepareDestinationCache, but after verifying them it works. If there are better ways to do this Im open to it. --- ## 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 --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. |
||
|
Crow
|
be2cf436ea
|
Implement Tempest Keep: The Eye Strategies (#1943)
Edit: Descriptions of methods are out of date right now. To be updated. This one comes with the same caveats as SSC about requiring ownership from somebody with C++ knowledge, except I think the matter is even more acute here because these strategies incorporate a novel approach proposed by Timberpoes. By redeclaring the entire bossai class for Kael’thas, it was possible to add new member functions to the class in order to access its private member variables. This allows bots to have visibility into boss mechanics beyond what they could do with ordinary techniques and is similar in approach to what was done by the Naxx strategies, except that this approach does not require any modifications to the core. I used it for only one mechanic, which was to detect Kael’thas’s phase. That was very helpful because the fight is divided into 5 phases, and distinguishing between them with traditional techniques requires lookups of a dozen NPCs and comparisons of their various unit states, react states, and auras; by accessing his bossai, this can all be avoided. However, there is far more potential beyond this if the approach is an acceptable one. On with the (shit)show. ### Trash In a perfect world, there would be many strategies for TK trash, which is easily more difficult than two of the bosses. It’s a real pain to do though because to solve the biggest issues properly, each pack would have to be handled a little differently. So the only thing I’ve included is for Mages to cast polymorph on the Crimson Hand Centurions when they are channeling Arcane Flurry. The purpose is not to actually keep them CC’d but to interrupt their channel. ### Al’ar This fight sucked so much to write a strategy for. The only silver lining is that being the post-nerf version, the boss moves between only 4 platform locations (instead of 6), and movement between them is on a fixed rotation (interrupted by Flame Quills) instead of being random. Thus, a strategy can be consistently replicated, and the fight can be done with only 3 tanks (2 on the platforms for the boss and 1 below for adds). **Phase 1:** I’m going to call the platform that Al’ar lands at after the pull “platform 0” because that reflects the indices in the code. In a clockwise direction, the remaining platforms will be referred to as platforms 1, 2, and 3, respectively. The best way to pull is to first put all ranged, as well as tanks other than your main tank and first assistant tank, on nc +stay below platform 0. Then, go up the ramp to platform 0 with your main tank, first assistant tank, and melee dps following you, then hit Al’ar with any ranged attack or spell to start the fight. - Your main tank will start at platform 0, and your first assistant tank will immediately move to platform 1. When Al’ar moves to platform 1, your main tank will move to platform 2. When Al’ar moves to platform 2, your first assistant tank will move to platform 3. When Al’ar moves to platform 3, your main tank will move back to platform 0. This assures a tank is available to receive Al’ar after every platform movement (every 30 seconds). - Melee DPS will follow Al’ar as it moves between platforms. - Each platform is mapped to a corresponding ground location below it. Ranged DPS and healers will follow Al’ar by moving to the corresponding ground location as it flies between platforms. - After each platform move, an Ember of Al’ar will spawn. Your second assistant tank will pick up the Ember and move it to the point that is 25 yards away from the ground position corresponding to Al’ar’s platform (on an invisible line between such ground position and the middle of the room). Ranged DPS will then focus down the Ember before switching back to Al’ar (this positioning is so that ranged are not hit by the Ember Blast explosion that happens whenever an Ember dies). - Each time Al’ar leaves a platform, it has a chance to instead fly up high in the middle of the room to perform Flame Quills, which will one-shot anybody on the upper level or ramps. When Al’ar begins the Flame Quills sequence, all bots on the top level will jump off. FYI, Al’ar’s usage of Flame Quills is not entirely random: there is a 20% chance for it to do so after the first platform move, and the chance increases by another 20% after each subsequent platform move that does not trigger Flame Quills (reset after each Flame Quills sequence). - After Flame Quills, Al’ar will randomly land at either platform 0 or 3. To prepare for this, bots will move to assigned positions during the Flame Quills sequence: - Ranged and the second assistant tank will wait in the middle of the room. - Melee DPS will wait at a point that is between the base of each ramp. - The main tank will wait at the base of the ramp to platform 0. - The first assistant tank will wait at the base of the ramp to platform 3. - Once Al’ar lands, the regular Phase 1 strategies resume. - When Al’ar “dies,” it disappears and moves to the center of the room, where it casts Rebirth and returns to full HP. Bots will wait outside of the radius of the Rebirth explosion for Phase 2 to start. Phase 2: - Your main tank will tank Al’ar initially. When Al’ar casts Melt Armor, your first assistant tank will taunt Al’ar and take over. The tank swaps will continue back and forth every time Melt Armor is cast. - Bots will avoid Flame Patches. FWIW, the standard co +avoid aoe strategy does work for Flame Patches, but avoid aoe provides no buffer distance so as you’ve probably noticed, it doesn’t provide for preemptive avoidance. Also, avoid aoe does not consider multiple hazards together so it can be an issue when movement needs to take into account more than one hazard, plus when a strategy requires particular bot movement, it’s better to account for the hazards within that movement strategy instead of relying on separate methods that can create conflicts. - When Al’ar takes to the sky to perform Dive Bomb, bots will spread out (and continue to avoid Flame Patches). After the Dive Bomb, Al’ar does another Rebirth explosion. I have tried a million different things to properly detect this full sequence (even accessing the bossAI like I did with Kael’thas) and cannot get it to work properly. Ultimately, all I’ve been able to get to work at all with respect to the final explosion is for bots to detect the 2-second cast of the Rebirth and run out. It is not enough time for bots that are too close when the cast happens so some bots may get hit, but if you have adequate gear, they should survive. - After each Dive Bomb, 2 Embers will spawn. Your second assistant tank will tank one Ember, and either the main tank or first assistant tank, whichever one is not tanking Al’ar at the time, will tank the other Ember. They will both move the Embers away from bots, and ranged DPS will focus both Embers down before switching back to Al’ar. - Because the room is so large, it is possible for bots to get too far away from active combat (particularly if they are thrown across the room by Ember Blast) so there is also a method for them to run back toward the center if they get too far away. ### Void Reaver Ironically, what was often considered the easiest boss in 25-player content in TBC is the only boss with an ability (Arcane Orb) that I do not believe can be avoided by bots, even with access to Void Reaver’s boss script. Therefore, every single Arcane Orb is going to hit its target, so the strategy can only try to limit the damage by spreading ranged bots in two rings around Void Reaver (one for healers and one for ranged DPS, to try to ensure sufficient distribution of healers). The tanks will all fight for aggro (necessary due to Knock Away) and try to keep Void Reaver in the middle of the room. Bots that can wipe aggro or otherwise gain invulnerability are directed to use the applicable abilities as soon as they pick up aggro (e.g., Soulshatter). He’s still easy, but if you have IP nerfs, it’s a little bit of a gear check. ### High Astromancer Solarian No boss was hit harder by nerfs in TBC than Solarian, whose encounter went from a totally unique fight that required arcane resistance to a fight that is kind of just an easier Baron Geddon. IMO, she is the easiest boss in TBC 25-player raids. - Ranged bots stack up at a distance from Solarian; this leaves all bots with plenty of space to run away from other bots when they get Wrath of the Astromancer. - When Solarian vanishes, all bots will stack to AoE down the Solarium Agents that spawn. - When Solarian returns with two Solarium Priests, melee will divide into two groups, with one focused on each Solarium Priest. I think this method is not working correctly right now because when one Priest dies, the bots still on the second Priest are leaving it. I’ll need to decide whether I want to figure it out or just get rid of it because this fight is so easy regardless. - Priest bots will cast Fear Ward on the main tank to block the Psychic Scream during the final tank-and-spank Voidwalker phase, and the main tank will pick up Voidwalker Solarian as soon as she transforms. Note that the bots will not be knocked into the air by Wrath of the Astromancer. The issue is due to the presence of a check for knockbacks in Playerbots that causes bots to ignore knockbacks that would launch them at a velocity beyond a hardcoded value. I’ve increased that velocity limit on my own fork, and it does allow Wrath of the Astromancer (and other knockbacks that otherwise don’t work) to work on bots. But that’s obviously a broader issue and not addressed in this PR, and bots don’t take fall damage in any case. ### Kael’thas Sunstrider So this strategy has 23(!) action methods. But like in retail, this is actually an easy fight once it is learned because it is highly scripted. Unlike in other strategies I’ve done, the bots probably cannot do this fight by themselves unless they are way overgeared. This is because there are a few windows during which bots need to position themselves properly based on dynamic factors. But no RTSC is needed—you just need to have bots follow you to the right locations. Also note that the gear check for this strategy is higher than in retail because you have to get all of the legendary weapons down and looted before the advisors aggro in Phase 3, or it’s going to be an absolute shitshow (with human players, you can deal with there still being a couple of weapons up). For a point of reference, when I was first working on this strategy with damage reduced to 50% and bots pretty close to T4 BiS, I had almost no margin of error (I would usually get the weapons down with barely a second to spare). You will need at least 2 tanks, but 3 is better. Your main tank will need to be able to equip the legendary shield so you must use a Warrior or Paladin. However, it is ideal for the first assistant tank to be a Druid because they can equip the legendary staff. **Phase 1:** Fun fact—when you “kill” the advisors in this phase, they don’t actually die but get an aura applied called “Permanent Feign Death” (nice oxymoron). - _Thaladred_: You’re supposed to kite him, and bots can’t really kite, so the method is a poor man’s method of having the bot move away from him in a straight line when fixated. You want him to die in the far Southern part of the room. If he dies in a bad location, you may as well call a wipe and restart. What will work best for you will depend on your DPS since you don’t want to kill him before he gets to the location you want but also don’t want bots to be trapped up against a wall since they can’t properly kite him. The way that works best for me is to have bots stay back while I aggro the boss, and wait until right before Thaladred switches to his second fixate target before attacking. Note that if you do put bots on stay, when you put them back on follow, the bot that is then being fixated will remain on stay (because they need to disregard movement orders other than running away from Thaladred). So after Thaladred dies, make sure to manually type /follow or the bot that was fixated when you took the bots off of stay will not rejoin the fight. - _Sanguinar_: He will be tanked by your main tank, who will be targeted by your Priests for Fear Ward. Bots will wait to engage him; I made it a very generous time (12 seconds) because there is absolutely no rush in Phase 1. There’s no sense in being aggressive. During that time, the main tank will drag Sanguinar to the West wall. - _Capernian_: This is the first make-or-break part of the fight. Phase 1 Capernian was the most frequent cause for wipes for me. - She should be tanked by a Warlock. If you want to pick your Warlock tank, you can do so by the assistant flag, but if you don’t, the strategy will just pick your highest HP Warlock. If you raid without a Warlock, then you’re insane, but at least there’s a guard so your server won’t crash? - You do not need to add the tank strategy to your Warlock. There is a method that will automatically switch your selected tank Warlock between DPS and tank strategies at appropriate times because you need to squeeze out every drop of DPS you can get, particularly for Phase 2, where you’ll need your Warlock to be blowing up weapons with Seed of Corruption instead of spamming Searing Pain. You’ll want your Warlock to start with a DPS strategy as usual (since they should be DPSing Thaladred). - To engage Capernian, start running East right before Sanguinar dies. She will activate quickly, and you want to try to get in front of her (but not too close) before she aggros. - When Capernian aggros, your Warlock tank will immediately switch to the tank strategy and attack. Your main tank will run toward Capernian but not actually attack; their purpose will be to bait her Conflagration to reduce the chance that it hits your Warlock tank. Other melee will not engage Capernian. Ranged DPS will be idle for 12 seconds; during this time, you should run South to make sure they are not in range of Capernian. After 12 seconds, your ranged DPS will activate, move into range and spread out, and attack (it doesn’t seem possible to outrange Conflagrate, so if bots don’t spread, she will annihilate the entire ranged group with a single cast). Ideally, you kill her not too far from her starting position. If she ends up in the middle of the room, you should probably wipe and start over. - _Telonicus_: He is very easy in retail but actually is a big risk for wipes with respect to bots because his bombs will one-shot any non-tank, and bots will stupidly stand in front of him without a proper strategy. You should keep some distance from him before he aggros. Your first assistant tank will pick him up and move him to the West wall near Sanguinar. Again, there is a 12-second delay before DPS starts. Your melee DPS are coded to stay directly behind him and not get too close so they don’t get hit by bombs. **Phase 2:** Kael’thas will summon all weapons immediately after Telonicus is down. Just before Telonicus is down, you should move to the platform where the advisors originally were—you’ll be in better position for the raid to AoE down the weapons. - Your main tank will pick up the axe and move it away from the group. The axe is the biggest threat during this phase and can easily one-shot casters if not pulled away. - One of your Hunters will attempt to get aggro on the bow and move away from the group (as a hacky way of trying to turn the bow away from the group because you can’t really get a bot to do that directly). This method is hit or miss, but it shouldn’t be that big of a deal if your Hunter doesn’t pull it off properly. - Everybody else will prioritize weapons in the following order (but most damage will come from AoE, which is what you want or you will not beat the timer): staff, mace, sword, dagger, axe (ranged only), bow, and shield. - As weapons are defeated, bots will loot and equip them. If you have not disabled bot announcements in your config, you get to see your entire raid go nuts because they looted legendary items. - Here is what weapons bots will loot and equip. I don't know anything about DKs, having never played WotLK, so tell me if anything is wrong for them. - _Healers:_ Mace (if a healer normally uses a staff, it's best if they keep an OH in their bags for this fight) - _Tanks:_ Shield and sword for Paladins and DK, shield and dagger for warriors, staff for Druid - _Offensive_ casters: Staff - _Rogues:_ Sword and dagger if Combat or Subtlety, dagger only if Assassination - _DPS Death Knights, Retribution Paladins, Arms Warriors_: Axe - _Fury Warriors_: Dagger. I understand that due to Titan Grip, they should also have the Axe for best DPS; however, Fury Warriors have awful DPS (we’re talking barely above Prot-level) at this stage. Thus, my view is it is better to give them only the dagger so they will MH it and help break MC in Phase 4, since they will contribute hardly any DPS regardless. - _Cat Druids_: Staff - _Enhancement Shamans_: Dagger - _Hunters:_ Bow and dagger. Note that I do NOT have them loot the sword because they need the dagger in their mainhand to use to break MC in Phase 4; whatever marginal benefit they get from the sword as a stat stick is not worth losing this capability. If your Hunter uses a 2H, it is best to have them carry a 1H in their inventory so they can put something in the OH after they equip the dagger. - After looting weapons, bots with the staff will use it (once) to activate the Mental Protection Field. Hunters will use the bow to generate the legendary arrows and equip those (and will continue to do so during the fight if they use up the arrows). - If you wipe from this point forward, everybody will lose their legendary weapons, and by default, most bots will not automatically reequip their own weapons until a loot event occurs. This was extremely annoying, and therefore there is a noncombat method implemented that causes everybody to equip upgrades when they get within 150 yards of Kael’thas. I considered applying this to the whole instance, but I’m not sure if some people would not like that so I decided to limit things to the Kael’thas encounter. **Phase 3:** I highly recommend you have your Shamans drop Tremor Totems (co +tremor) during this phase. Doing so is not coded because I wanted to leave flexibility, but I think it is very helpful for Sanguinar. After the weapons die, you want to move your bots to a central location between the advisors. If Thaladred died closer to the middle of the room, ideally you position to the side of Thaladred so when he fixates he will not chase bots North into the other advisors. - Shamans will immediately use Heroism/Bloodlust. - Your melee tanks will bring Sanguinar and Telonicus to their tanking positions (same as Phase 1). If your first assistant tank is a Druid, they will be immune to Telonicus’s Remote Toy due to having the legendary staff’s aura activated and will also make your main tank immune. - One healer will stay by the Sanguinar and Telonicus tanking positions to heal the tanks. Once IsHealAssistantOfIndex() is fixed, you will be able to select this healer with the assistant flag. Right now, this will just be the last healer that joined your raid (per standard AC logic). - DPS priority will be Thaladred, Capernian (ranged only), Sanguinar, Telonicus. As with retail, the most chaotic period will be before Thaladred is killed, particularly if he chases bots into other advisors. I don’t have a great solution for this, but Capernian is significantly less dangerous during this phase thanks to the legendary staff. This is the last true breakpoint—if you get Thaladred down with your raid mostly intact, you are very likely to get the kill. **Phase 4:** Kael’thas will aggro immediately after all advisors are dead. - Your main tank will position Kael’thas at his original position. - Bots will move out of Flame Strikes. - Assist tanks will pick up Phoenixes. Since they die over time anyway, bots will not waste time attacking them. When Phoenixes die, they turn into an Egg—at that point, bots will switch to the Egg to destroy it before the Phoenix is reborn. - When Kael’thas puts up Shock Barrier and starts casting Pyroblast on your main tank (a one-shot), all bots will focus DPS on him (even if there is an egg up). You have 4 seconds to break the barrier (80K HP) and interrupt his Pyroblast. It is likely that you will not be able to if you are playing with IP nerfs and are in T4 gear. However, the main tank will use the legendary shield’s ability, which will allow them to absorb one cast, giving you 8 seconds to break the barrier and interrupt Pyroblast. Bots will put top priority on interrupting Pyroblast as soon as the barrier is down. - If a bot (or player) is mind controlled, bots with the legendary dagger (other than tanks) will move to MC’d players and use the following attacks to break MC: Shiv (Rogues), Hamstring (Warriors), Wing Clip (Hunters), and Stormstrike (Shamans). **Phase 5:** At 50% HP, Kael’thas enters a long RP sequence. This is a good time to kill any remaining Phoenixes and/or Eggs. - Kael’thas stops casting Pyroblast and Mind Control. - His main new ability is Gravity Lapse, and it doesn’t work properly on bots... He sucks in the entire raid then knocks everybody back in a different direction. What is supposed to happen is that players will end up floating in midair in different directions and at different heights. However, bots will immediately fall to the ground after getting knocked back. They will not actually hit the ground though and instead remain in a flying state right above the floor. - If you could move in 3D space, Netherbeam would be very easy to deal with. However, because that is not available to bots, they can spread only in 2D space and thus need to move farther to get properly spread, and they waste the first moments falling straight down. As a result, the damage from Netherbeam can be quite high, and the beginning of Gravity Lapse requires a lot of healing. I don’t really have a better way of dealing with this. - FWIW, I don’t think there is any existing method to make bots disperse in 3D anyway. - Kael’thas is supposed to use Nether Void when players are in midair, which creates clouds that reduce your max HP and thus make it more challenging to maneuver, but AC is bugged and he doesn’t use the ability at all (there’s been an open issue about this forever). For fuck's sake, that's all. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> |
||
|
Keleborn
|
441f9f7552
|
Warnings PR 1: Event warnings and headers (#2106)
# Pull Request
This is the first in a series of PRs intended to eliminate warnings in
the module. The design intent is to eliminate the calling event when not
needed in the body of the function. Based off of SmashingQuasars work.
---
## 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?
- [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:
- [ ] 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
---
## 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>
|
||
|
kadeshar
|
79fb3a5bbc | - Fixed Oculus drake mounting | ||
|
bashermens
|
13fff46fa0
|
Improper singletons migration to clean Meyer's singletons (cherry-pick) (#2082)
# Pull Request
- Applies the clean and corrected singletons, Meyer pattern. (cherry
picked from @SmashingQuasar )
Testing by just playing the game in various ways. Been tested by myself
@Celandriel and @SmashingQuasar
---
## 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
- [x] Added logic complexity is justified and explained
- [x] 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.
---------
Co-authored-by: Nicolas Lebacq <nicolas.cordier@outlook.com>
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
|
||
|
Crow
|
378254af3f
|
Fix Assistant Assignment Functions (#1930)
IsHealAssistantOfIndex() and IsRangedDpsAssistantOfIndex() are supposed to iterate through the group and first return members with the applicable role that have the assistant flag, and then iterate through non-assistants only if there are not enough assistants for the designated index. They are not written properly and actually completely ignore the assistant flag. I rely on these functions for significant roles in SSC and TK (which I have decided I'll PR in the same way as SSC, as a long-term draft). I have them fixed on my own fork, but it is problematic for testers if these functions do not work. So I've done three things here: 1. Fixed the functions to prefer members with the assistant flag. 2. Added a third parameter for ignoreDeadPlayers, like IsAssistTankOfIndex() has. Note that the parameter is by default false for IsAssistTankOfIndex(), meaning dead players are _not_ ignored. This is not my preferred design choice--I think the default should be to ignore dead players, but I have not changed the default and have made the default the same for IsAssistHealOfIndex() and IsAssistRangedDpsOfIndex(), since I don't know the intent of the pre-existing boss strats that use the functions. 3. Changed the names to IsAssistHealOfIndex() and IsAssistRangedDpsOfIndex() so they parallel IsAssistTankOfIndex(), and made corresponding changes in the few boss strats that use the functions. Also, note that the functions _do _not_ exclude real players. I think there are arguments for and against excluding real players. A fourth parameter for this could be useful, but I've not made any change in that regard. |
||
|
bashermens
|
41c53365ae
|
[HOT FIX] MS build issues regarding folder / command lenght usage or rc.exe (#2038) |