veitR/mod-playerbots
1
0
Fork 0
mirror of https://github.com/liyunfan1223/mod-playerbots.git synced 2026-06-20 15:39:25 +02:00
Code Issues Packages Projects Releases Wiki Activity
2,564 Commits 9 Branches 0 Tags
Commit Graph

8 Commits

Author SHA1 Message Date
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>
 2026-04-17 14:07:47 -07:00
Keleborn
53a607e147
Enable bots to do Outdoor pvp (#2217) 
## Pull Request Description
Bots will now engage with outdoor pvp targets when in an area with them.
I carved this out of the guildrpg system Im working on since it should
work just fine as a standalone. Note this requires a core update
https://github.com/azerothcore/azerothcore-wotlk/pull/25103

## Feature Evaluation

Its not expensive. the status checks are fairly light and simple. Should
be on par with current rpg system actions

## How to Test the Changes

You can try to use selfbot to enable this while in EPL, or set the
probability of all other rpg actions to 0.


## 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
    - [x] Minimal impact (**explain below**)
    - [ ] Moderate impact (**explain below**)

There is some impact, but should be minimal overall. 

- Does this change modify default bot behavior?
    - [ ] No
    - [x] Yes (**explain why**)
It will activate automatically based on default config. 


- Does this change add new decision branches or increase maintenance
complexity?
    - [ ] No
    - [x] Yes (**explain below**)

## AI Assistance
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.
-->
Nothing beyond search functionality and autocomplete. 


## 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: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
 2026-04-10 22:16:58 -07:00
kadeshar
a87999bef5
Berserker Rage support (#2261) 
<!--
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 -->

Added Berserker Rage usage (in combat and outside combat) for Warrior
(all specs)

Related with: #1755 

## 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 warrior to party
- [optional] start combat (for example with dummy)
- use command `.aura 6215`
- bot should cast Berserker Rage

## 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**)

Warriors use Berserker Rage when they got fear, sleep or sap

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

Copilot CLI to review

## 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="324" height="125" alt="obraz"
src="https://github.com/user-attachments/assets/e502f1c1-88f4-42a1-b07b-fc9ef3fd318b"
/>

[Berserker Rage performance
test.txt](https://github.com/user-attachments/files/26333365/Berserker.Rage.performance.test.txt)
 2026-04-03 22:32:32 -07:00
kadeshar
6db44b5296
Will of the forsaken (#2231) 
<!--
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 -->
Added Will of the Forsaken support. 
Made structure fix for affected files.

Partially resolves: #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.
-->
- create/invite undead bot
- start fight (you can use dummy target)
- use `.aura 6215` to fear bot
- bot should use "Will of the Forsaken" to remove debuff


## 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**)

Undead bot use now "Will of the Forsaken" to remove charm, fear or
sleep.

- 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 to review changes


## 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="325" height="77" alt="obraz"
src="https://github.com/user-attachments/assets/729cfdf8-3742-457c-9278-7fcce824e6d0"
/>

---------

Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
 2026-03-27 11:53:53 -07:00
kadeshar
bbd9d3e37a
Wait for attack strategy migration (#2211) 
## Pull Request Description
Migration of "wait for attack" strategy from cmangos playerbots.

Resolves: https://github.com/mod-playerbots/mod-playerbots/issues/990

## Feature Evaluation
Optional strategy for bots which are in party with real player. 

## How to Test the Changes
- add strategy to bot "nc +wait for attack" and "co +wait for attack"
- set time via command "wait for attack time x" where x is time which
they wait in seconds (you should get response from bot)
- attack any target (for example dummy in main city)(bot should wait
with attack)

## Impact Assessment
    - [ ] No, not at all
    - [x] Minimal impact (**explain below**)
    - [ ] Moderate impact (**explain below**)

Performance wise only bots having this optinal strategy have additional
cost in multiplier which check every attack action that should be
execute.

- 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
Does this change add bot messages to translate?
- [ ] No
- [x] Yes (**list messages in the table**)

| Message key  | Default message |
| --------------- | ------------------ |
1740 | Please provide a time to set (in seconds)
1741 | Please provide valid time to set (in seconds) between 0 and 99
1742 | Wait for attack time set to %new_time seconds

## AI Assistance
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.
-->

Copilot CLI - help with migration



## 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.
-->
 2026-03-27 10:38:46 -07:00
kadeshar
c6a07ad012
Every Man for Himself racial support (#2198) 
# Pull Request

Added Every Man for Himself racial support
Partially resolves:
https://github.com/mod-playerbots/mod-playerbots/issues/2002

---

## How to Test the Changes

- when human bot is in combat apply aura via command `.aura 20066`
- bot should use "Every Man for Himself" to remove aura

## 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?
- - [ ] No
- - [x] Yes (**explain why**)

Human bots now using "Every Man for Himself" by default where in combat

If this introduces more advanced or AI-heavy logic:
- - [x] Lightweight mode remains the default
- - [x] 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**)

Copilot CLI to review changes

---

## 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

Test result:
<img width="358" height="97" alt="obraz"
src="https://github.com/user-attachments/assets/66044a93-d73b-4706-ae2f-ea8ae6e25438"
/>
 2026-03-20 20:41:22 +01:00
Crow
cba6af27ad
Fix Assassination Rogue Finishers and add Cold Blood (#2215) 
<!--
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 -->

**Note for reviewers**: The Rogue files are very confusing, so for
background, there is DpsRogueStrategy, which is for all Rogues and
represented by the “dps” strategy in game, and there is also
AssassinationRogueStrategy, which is for Assassination and Subtlety
specs and represented by the “melee” strategy in game. So Combat has
only the dps strategy, while Assassination and Subtlety have the dps and
melee strategies.
- The main focus of this PR is to fix an issue with Assassination Rogues
that caused them to use Eviscerate instead of Envenom about 1/3 of the
time they should have been using Envenom, which was significantly
reducing their DPS. See the bottom of this post for an explanation for
why this was happening and why the fix works. Well, LMK if you think
it's wrong, but this is how I am understanding things, and my
back-of-the-envelope math (also below) supports it.

- After this PR, Assassination Rogues will use Eviscerate only if they
are unable to use Envenom (don't have the ability learned or no Deadly
Poison on the target) or if they don’t have Rank 3 in Master Poisoner.

- Additionally, Assassination Rogues previously would use
Envenom/Eviscerate at 3 or more combo points. This is suboptimal so I
created a new “combo points 4 available” trigger that will fire at 4 or
5 combo points only. They will still use the finisher at 3 combo points
if the mob is almost dead (via the existing “target with combo points
almost dead” trigger).

- I then added Cold Blood, which Rogues previously would not use at all.
Now there is a ColdBloodAction(), and Cold Blood is used when a Rogue
has at least 4 combo points, right before using Envenom (or Eviscerate).
I implemented it as a standard BuffTrigger so they’ll just use the
ability off cooldown.

- While looking at the combo point triggers, I thought it was confusing
that the “combo points available” trigger actually meant 5 combo points
(presumably because the default parameter for combo points in
ComboPointsAvailableTrigger() is 5). I changed the string to “combo
points 5 available” so it’s less confusing going forward. This
necessitated some changes in the Druid files too.

- Next, I cleaned up DpsRogueStrategy a bit. Not a lot to say, just some
duplicative or useless logic was removed. There shouldn’t be any impact
on gameplay from the changes.

- In the process of making the edits in the Druid files, I noticed that
the trigger for Tiger’s Fury in OffhealDruidCatStrategy was “low
energy,” which does not exist (there is a “light energy available,” but
the EnergyAvailable triggers are for when energy is AT LEAST the
designated level, not AT MOST the designated level). So I replaced the
trigger with the already-existing “tiger’s fury” trigger, which I think
is just a generic BuffTrigger so I don’t actually know why it exists
(i.e., Druid will use the spell off cooldown). But this particular
change is just a quick fix and not intended to be thoughtful (that would
be outside the scope of this PR).


## 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 should be no relevant impact on performance. This PR adds one new
action triggered by the standard BuffTrigger. Otherwise, these are just
fixes to existing logic.

## 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.
-->

The easiest way to test is to fight a boss that doesn't tend to result
in downtime (since downtime can lead to the loss of deadly poison
stacks, in which case Eviscerate will (and should be) used by
Assassination Rogues). You can use a damage meter such as Skada to track
ability use. You should see:
- Assassination Rogues don't use Eviscerate at all, or very few times.
- Assassination Rogues use Cold Blood.
- Offheal Cat Druids use Tiger's Fury.
- Otherwise, Rogue and Cat Druid behavior should remain the same.


## 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**)


Default behavior for Assassination Rogues was broken, as explained
above.


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

I had Claude help me diagnose the initial issue and help me understand
the queue system. And I had it implement the changes that were just
busywork (like combo point triggers).


## 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.
-->

The reason for why Assassination Rogues were using Eviscerate so
frequently is due to the fact that Envenom and Eviscerate were part of
the same TriggerNode. When actions are part of the same TriggerNode,
they're processed together, and the actions are queued by priority. When
the higher-priority action is executed, the lower-priority action is not
cleared--it remains in the queue for expireActionTime from the config,
which is 5 seconds by default. Then, as soon as the lower-priority
action can be executed (without regard for triggers because it is
already triggered, just sitting in the queue), it will execute.

This pattern of code works fine ingame if (1) you are actually trying to
queue actions, like what I did with Cold Blood -> Envenom, (2) there are
other guards like IsUseful() and IsPossible() that keep unwanted actions
from executing, or (3) the trigger is just constantly firing so the
higher-priority action is always evaluated. But TriggerNode isn't really
the right way to implement action priority--that's through ActionNode.
AssassinationRogueStrategy had Envenom and Eviscerate in the same
TriggerNode, and then the corresponding ActionNode had Rupture as a
fallback. Now, I changed it so Eviscerate is instead a fallback in the
Envenom ActionNode (and Rupture is removed entirely because
Assassination Rogues just shouldn't be using it, except maybe on very
high-armor targets that are immune to poison, but that is very niche).

~

I did some back-of-the-envelope math to check this pattern. Say we're in
a situation where Deadly Poison is up so ideally the Rogue should use
Envenom 100% of the time. Through the old system, what would happen when
the trigger fired?
- Rogue uses Envenom since it's the higher-priority action.
- Due to the Ruthlessness talent, Rogue has a 60% chance of having 1
combo point after the finisher, 40% chance of 0 combo points. If it has
1 combo point, it uses Eviscerate immediately.
- If it has 0 combo points, it uses Mutilate. Mutilate grants 2 combo
points, unless it crits, in which case it grants 3 due to Seal Fate. If
Mutilate doesn't crit, the Rogue has 2 combo points, and it uses
Eviscerate. If Mutilate does crit, the Rogue has 3 combo points, and it
uses Envenom.
- So let's assume Mutilate has a 55% crit chance (very reasonable for a
Rogue in entry-level raid gear with raid buffs due to Opportunity giving
+20% crit chance to Mutilate). Mutilate hits twice, and if either hit
crits, Seal Fate Procs. The chance of at least one crit with two hits at
a 55% crit chance is ~80%. That means if Ruthlessness doesn't give a
combo point, there is an 80% chance that Envenom will be used and a 20%
chance that Eviscerate will be used.
- Combine the above, and the result of one trigger firing is you get 1
guaranteed Envenom + 0.6 Eviscerates (Ruthlessness proc path) + 0.32
Envenoms (No Ruthlessness proc but Seal Fate proc path) + 0.08
Eviscerates (No Ruthlessness proc and no Seal Fate proc path) = 1.32
Envenoms to each 0.68 Eviscerates, or a 1.94:1 ratio of Envenoms to
Eviscerates. That is basically identical to what I saw in practice of
roughly a 2:1 ratio of Envenoms to Eviscerates.
- I understand the above is simplistic and it assumes that the Rogue
gets a combo point within 5 seconds following using Envenom (very
likely) and that there are not two opportunities to use Envenom or
Eviscerate in the 5-second queue period after using Envenom (it can
happen but is uncommon). That's all at the margins and isn't going to
impact the math very much.

---------

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>
 2026-03-20 20:40:59 +01:00
bashermens
41c53365ae
[HOT FIX] MS build issues regarding folder / command lenght usage or rc.exe (#2038) 2026-01-19 22:45:28 +01:00