Hi! Thank you for this awesome project!
I'm using the lateset released version(191007), testing human rogue.
Without any gear or buff, my stats shown in Classicsim are:
STR 81
AGI 133
STA 81
INT 35
SPI 50
AP: 374
Crit: 4.59%

In game, they are:
80/130/80/35/52
310AP, 5.68%Crit.

There seem to be an extra 60AP after extra stats, and less than 1% missing crit.

Background

Items are available in .xml files under the following directory. Some items have the wrong patch availability, such as Onslaught's Girdle which is currently marked as available in patch 1.0.0, but should be available first in 1.5.0 (?). In this case this is simply done by changing the <patch name="1.0.0"> to <patch name="1.5.0">.

Unrelated background: the reason files have patch entries in this way is to support the item progression between patches (see e.g. Bonereaver's Edge).

Expected implementation

Investigate which items need to have their patch value changed (the powerful MC items are particularly suspect, the rest are likely fairly accurate but feel free to glance over them).

Definition of Done

An investigation with a few MC items having their patches updated has been concluded.

Background

Some settings should be more transparent and configurable via the GUI.

Task

Make settings configurable via the GUI. Store the configured settings in the GUI save. Note that this issue will only mention trivial settings that does not require much internal work to be able to expose as a configurable setting.

• Execute threshold
• Target level
• Target magic school resistances

Definition of Done

The proposed settings are configurable and visible in the GUI, and saved/loaded on exit/boot.

When I am on the Buff tab. I go to select multiple buffs on the left hand side, but only 1 will stay selected. I tried using the CTRL button, but this does not work properly. Using CTRL allows me to select multiple on the right column.

Also, when I use shift it will select all between the two selections, as expected.

Background

While leveling the main attire of characters is going to be of green quality for the large majority of the playerbase. These items can often spawn with random affixes. The available set of affixes depends on patch (e.g. +spell damage/+healing which was not available in 1.0.0), and the stat values depend on item level and slot. Because they are ubiquitous for players, especially during leveling, the support for them needs to be smooth.

Note: there are a handful of very powerful items (different +spell damage/healing items) that could explicitly be added without the general support for random affixes. This issue aims to solve the general case of random affix items, which includes these powerful endgame items.

Note: make the assumption initially that all affixes are available in the first content phase.

Expected implementation

XML representation

Items that have a set of random affixes tied to them should be marked as such in the xml-files. The easiest thing is to let each item that has a set of random affixes name both affix name and the stat value changes they bring. ItemFileReader (and Weapon) need to be able to parse these affixes.

<RANDOM_AFFIXES> <RANDOM_AFFIX name="of the Moon" description="+Sta/+Int"><!-- stat values --></RANDOM_AFFIX> <RANDOM_AFFIXES>

GUI representation

When selecting an item with random affixes there needs to be some dropdown from a model that displays the available random affixes for the item. Exactly where this dropdown should be placed must be investigated after the criteria how intuitive it is to use versus how difficult it is to implement.

Definition of Done

• Possible to select items with random affixes and be able to select a specific affix.

I have a high power computer that can burn through iterations super fast. Also, 10k iterations still introduces a lot of error in stat weights. Can I set a higher number please, like 100000 or 1 million? I'm fine with waiting for a long sim to complete, I just want more reliable stat weights.

Also looking forward to custom combat rotations.

Hi

Not sure if this is planned for the future, or already in the sim, but I can't seem to find it.

I'm looking at what difference weapon dps and weapon speed makes on the stat weights.

For dual wielding classes, this would need to be split between main hand and off hand too.

Thanks
Gratch

Hi,

Very nice tool, really good job.

But i think felstriker's PPM should be 1 in vanilla. And Flurry Axe's PPM is 1.85.

After i adjusted the proc chance i simulated the gear with felstriker,but it was still way too strong.

So i doubt that its proc didnt calculate the chances of dodge and glancing blows.

Check the Proc Rate sheet in the attachment, it might help.

Please let me know if i was wrong.

Cheers.

DPSWarrior_Classic (1).xlsx

Background

The majority of Paladin talents and abilities are implemented. The ones left are either mechanically unclear, only valid versus Undead, no impact in PvE, or not used as part of a damage rotation.

Missing abilities / talents

Note that this does not list all missing abilities/talents, only those that are currently being considered as "will be in the sim at some point".

Seal of Righteousness / Improved Seal of Righteousness

The damage bonus from SoR was at the time of implementation unclear how it should scale with weapon speed (one such question: is there ever a breakpoint where if attack speed is further reduced the bonus damage from SoR is not decreased?). Further, when consulting popular "mainstream" Paladin guides SoR was not mentioned as a valid alternative. There are mentions of SoR and Manual Crowd Pummeler with heavily proc based gear being competitive, but it seemed to the author it relied on potentially broken private server proc scaling mechanics.

Holy Wrath / Exorcism

Only available versus Undead.

Seal of Light / Seal of Wisdom

Not a part of a typical damage rotation.

Definition of Done

• All the listed spells and relevant talents for these spells have been added.

Title, this dagger is missing :)

I’m requesting a command line interface. This would be useful (required?) should csim eventually be used with raidbots or other third party tools.

Please add Skull Splitting Crossbow.

Rare BOE
Crossbow
52 - 79 Damage Speed 2.60
(25.2 damage per second)
+3 Strength
Equip: +14 Attack Power.
Requires Level 43
Item Level: 48

Background

The current set of buffs and debuffs are not complete as there are dozens and dozens of more or less usable buffs and debuffs. The goal in this issue is not to completely implement every single possible buff and debuff, but implement some important and fairly common ones (at least for hardcore raiding).

Missing Buffs

• Battle Squawk (added in ff40498)
• Silithid buff
• Warchief's Blessing
• list not complete yet

Missing Debuffs

• Curse of Recklessness
• Thunderfury (x2) (for debuff limit purposes)
• Judgement of Wisdom
• Curse of Elements
• Curse of Shadows
• Gift of Arthas
• Winter's Chill
• Improved Scorch
• Shadow Weaving
• Demo Shout (for debuff limit purposes)

Debuff limit on target

It is important that the debuffs are implemented such that they afflict a marker debuff on the target whenever it is up. This is to accurately take up slots on the debuff table, pushing weaker priorities off the table.

Future SharedDebuff implementations

Note that for now these buffs should only be available as ExternalBuffs. In the future some shall also be available as SharedDebuffs. These are:

• CoR/CoE/CoS (when warlocks are implemented)
• Winter's Chill / Improved Scorch (when mages are implemented)
• Shadow Weaving (when priests are implemented)
• Demo Shout (maybe implemented for warriors in the future)

Definition of Done

The listed buffs and debuffs have been implemented.

Background

There are several major set bonuses that are important to model to accurately calculate the value of certain items. Supporting set bonuses have so far been low priority since the initial efforts were aimed towards supporting warrior DPS where set bonuses for the most part are irrelevant. With the implementation of Rogue and Hunter the priority of supporting set bonuses increases drastically since both classes have very powerful set bonuses that are right on the common gear path.

Expected implementation

This issue requires making a few larger changes, as described below.

Set bonus information in .xml files

The data for the set bonuses should be at least partially data-driven. Add set bonuses as a separate element on the following format:

<set name="Bonescythe Armor">
    <item_id value="001"/>
    <item_id value="002"/>
    <item_id value="003"/>
    <item_id value="004"/>

    <set_bonus value="2">
     The tooltip text for 2 piece.
    </set_bonus>
    <set_bonus value="4">
     The tooltip text for 4 piece.
    </set_bonus>
</set>

Make a new SetBonusFileReader class that can handle reading set bonus data.

SetBonusControl

There needs to be a controlling structure that whenever an equipment changes it activates / deactivates set bonuses as appropriate. This structure must be Character-specific because it will reside around Equipment (inside or next to). Name this controlling structure SetBonusControl.

How to track current set bonuses

Assume the following: the class will be invoked on each gear change to determine set bonus activations/deactivations. The function call provides the next item_id and the current item_id can be found out by checking what is currently equipped. We have previously parsed a set bonus file that contained which item IDs are part of which sets.

QMap<int, QString> possible_set_items; // contains *all* <item_id> in *all* <set>
QMap<int, QString> current_set_items; // contains current equipped item ids known as part of sets

With the knowledge in current_set_items we first check if current item_id is in this map. If it is then remove it. Evaluate if the change caused a set bonus to deactivate by counting the number of occurrences its set in current_set_items that remains (i.e. iterate the keys).

Then attempt to equip the next item_id. If successful then evaluate if the change caused a set bonus to activate by again iterating the number of keys in a similar fashion above. Take special care for weapons, rings, and trinkets where equipping an item can un-equip the other slot. This should not be a problem because set items in these slots are always unique (e.g. T3 rings).

How to perform modifications per set bonus

The SetBonusControl class must contain a translation table for what modifications to make in order to glue together the partially data-driven set bonuses with the Character modifications. Use set bonus name and a value and perform the modifications necessary.

void activate_set_bonus(const QString& set_name, const int num_pieces)
and
void deactivate_set_bonus(const QString& set_name, const int num_pieces)

e.g.

if (set_name == "Bonescythe Armor") {
    switch (num_pieces) {
    case 2:
        // not supported
        break;
    case 4:
        // modify spells
        break;
    }
}

Side notes

• What is data-driven is essentially only what items a set consists of and the tooltips to display. The rest (e.g. set item name) is known both in .xml files and C++.
• The closest talent equivalent would be the TalentTree class.

Spell modifications via SetBonusRequirer

Equipping enough set items must activate set bonuses such that Characters are modified accordingly. Certain set bonuses changes spells (e.g. rogue t3 4/8). Implement a SetBonusRequirer in the same way that TalentRequirer is implemented, such that spells that are modified by set bonuses can be modified via a common SetBonusRequirer interface by the SetBonusControl instance.

This allows e.g. Backstab to inherit SetBonusRequirer such that it implements the function that causes it to gain energy on criticals.

Showing set bonuses in GUI

• Make it possible to show set bonus data in GUI. How? Via item tooltip is the most natural but likely also the most difficult. Note: requires both showing active set bonuses and possible set bonuses.

Definition of Done

Bonescythe 4/8 is:

• Possible to equip.
• Changes the relevant spells with energy gain displayed under Statistics.
• Active set bonuses (2/8 and 4/8) are shown in GUI.
• Inactive set bonuses (6/8 and 8/8) are shown in GUI and clearly distinct from the active set bonuses.

I used the version from the latest release and i chose to simulate my mage.
But i could not find the ring 'Songstone of Ironforge'. The item id is 12543, which can be obtained from a quest from Princess Moira.
The only similar ring in rings.xml is Magni's Will, whose item id is 12548.
I do not know whether the mutex function is working correctly, but i got no spell damage bonus when i choose the ring.
Thank you very much for this issue

Thanks for your hard work the sim is great.

As a warrior and just generally it would be great if you could choose to deselect certain parts of the rotation. For example It would be good to be able to sim without Overpower/Hamstring as while they may be slight dps gains in practice I rarely if ever use them, things like simming without reck/deathwish as you don't always have them.

I understand all this is editable by just changing the rotation config files manually but its abit of a hassle to edit every time. Also Warchief's Blessing is needed asap under buffs

Class and gear doesn't matter. During the sim, the application will crash if using Sulfuras.

Crash is in EnableBuffs.cpp, line 98:

buff->disable_buff();

As much as I like to sim dps, sometimes it would be nice to be able to sim your damage as a tank or a healer for even more min-maxing, would it be possible to add these gear types to the gear already so that we can work towards a potential better setup than BIS lists say?
I've already found several BIS lists to be incorrect for DPS, so it would be nice.

Not just that, but actually adding all pieces of end-game gear for any class.
Currently you are not able to Simulate Spelladins 'cos you can't get any of the gear with spell power for them.

Background

There is no Fury rotation that uses Slam.

Task

Add a 2h fury rotation that uses Slam instead of HS.

Definition of Done

• There is a 2h fury rotation with Slam.

Background

Warriors have most of the available relevant abilities implemented but the following abilities have been low priority for a while:

• Cleave
• Shield Slam

They will have to be added at some point as both of these are intended to be able to be simulated in the future (Cleave for multi-target/low threat, Shield Slam for tanking).

Expected implementation

Cleave

The implementation for Cleave is dependant on whether or not it is implemented before or after supporting multi-target simulation. The issue will have to be updated with information if multi-target support is added before this issue is solved.

If this issue is solved before multi-target support then implement it just like Heroic Strike. Note that if threat is added it needs to have a lower threat than Heroic Strike.

Shield Slam

Implement as a regular attack spell such as Whirlwind. Some extra additions need to be made available as well:

• Stats need to be able to get/increase/decrease shield block value. Remember to include it in Stats::add()/Stats::remove().
• In CharacterStats helper functions to get the current shield block value to modify the base damage with will be necessary.
• In Item parsing being able to parse shield block stat is necessary.
• ItemFileReader likely needs new support to parse shields.
• Adding a few shields will be necessary. This issue can skip shield enchants.

Definition of Done

• Cleave with tests are added.
• Shield Slam with tests are added. The damage of Shield Slam is modifiable by Shield Block Value. There are a few shields available to equip.

At the moment was looking at valuing the Shadowcraft 6 set piecce bonus. However havent seen any set in the xml that had proc chance effect on them implemented and was curious how to make my own definition of 6 set piece in xml, and if it is not possible atm how hard would it be to implement procs on sets?

Background

In order to facilitate an exchange of character setups (either for debugging or for knowledge exchange) it would be a good addition to add a possibility to import other character strings and be able to export the current character string (much like how WeakAuras can import/export individual WeakAuras).

Expected implementation

Exporting character string

There is already a way to dump the current character setup which is used to initialize worker threads with GUI character setup. Note however that this is at the time of writing in plain text. Use this class to dump the character string via GUI. Also note that only the current selected setup shall be dumped, ignore the setup choices that are not currently selected.

Importing character string

There is already a way to load character data. Load the current selected setup choices with the data (e.g. if user has Gear 3, Talent 2, Buffs 3 then load the import string into these setup choices).

Other GUI considerations

Import/export should be an immediately visible element from top-level (like class choice, etc.).

Definition of Done

It is now possible via GUI to import and export character strings.

I'm guessing you wrote and build this regularly on Windows with cl. I don't know how you're getting round, std::round and pow in many of these files, but on Darwin the build fails outright for nearly every invocation of round.

The change was as simple as adding #include <cmath> to all those files, but I figured there might be something in the build system that does this that I'm not aware of as I don't know qmake or qt.

Background

CSIM currently stores no user state between sessions. Each time a user boots up CSIM it starts "from scratch" with no talents enabled, a default class, zero gear equipped, etc. The goal of this issue is to change this such that the user state can be stored and loaded on boot in order to enable the user to continue where they left off the last time.

Expected implementation

How to dump and load data

There is already a way to dump and load the current character setup which is used in order to initialize the worker threads with the same data as displayed in the GUI thread.

This is not quite sufficient as it only dumps and loads a single setup (at the time of writing there are three choices of setups for Gear, Buff, Talents respectively). Therefore the solution should use the classes above but dump all setup choices, as well as information as to which setup choice is currently active (e.g. if user has Gear setup 1, Buff setup 3, Talents setup 2 enabled).

When to dump and load data

When to load the data is clear: at boot of GUI.

When to dump the data (i.e. when to save user state) is less defined in this issue and is instead at the discretion of the implementer (being able to argue for the chosen implementation is important). Suggestions are as follows:

1. After each change that changes any of the setups above (requires multiple insertion points in GUI).
2. Upon exiting the event loop that is started in main (but I am unsure if this is possible).

Suggestion (1) has (unlike (2)) the side effect of allowing the user to load the exact point where the program was if the program exited abnormally. This is not necessarily a good thing as it could potentially immediately lead to further crashes. It also requires many insertion points and making sure each new vector that changes setup in some way has another insertion point.

Suggestion (2) has a single insertion point, and has the (probably positive) side effect of not saving the user state on an abnormal exit. The only downside is that I am unsure if it is possible to hook the event loop exit in order to perform the character dump (no objects can be deleted as we need to read them in order to be able to dump them).

Handling errors when loading data

In order to not let a faulty setup (some permutation of setup choices may lead to an undected failure) not completely disable the user experience the user state must be removed if any errors are encountered while loading the data. Since assertions can immediately halt a program without allowing the possibility to clean up afterwards this could be implemented in a sure-fire way by:

• Always deleting the available user-state file after reading it into memory before attempting to load the character setups with the file content.

Handling errors when dumping data

If the file is read into memory and deleted such that no user state file actually exists while CSIM is running, and if single-point storage suggestion (2) was chosen then it is trivial to handle errors when dumping data: simply let the program exit without creating any user state file. This makes sure an abnormal exit on failing to dump data leads to a reset of user state data.

Any other implementation will have to be investigated by the implementer if it is reasonable to attempt to handle it gracefully.

Definition of Done

The following user state is now available between sessions and loaded on boot:

• All the setup choices (Gear, Talents, Buffs), with the selected setup choice being the one that the user had selected on exiting program (i.e. do not default to e.g. Gear 1, Talents 1, Buffs 1 unless that is what the user had selected).

Further work / bonus points if included in this issue

The scope of this issue is such that the following can be excluded and be implemented at a later point if the user so chooses:

• Values that are editable under Settings (num iterations for Quick Sim and Full Sim, Scale options, etc).
• Current window (Talents, Buffs, Equipment, Settings, Statistics, etc.) which decides which window should be opened at boot.

Background

Thaddius is a boss in Naxxramas that, after some initial mechanics, yields a massive damage increase as part of the encounter. The importance is to be able to suss out the impact of the damage increase. For many classes it is irrelevant as it is just a damage multiplier that, other than increasing the damage output, does not affect the scaling of abilities. For warriors the increased rage gain does have an impact that is measurable.

Suggested implementation

First implementation can be basic enough where the damage buff is 100% uptime rather than on 80%, off 20% (roughly). Choose a reasonable damage increase and add a new buff that is managed by RulesetControl.

Definition of Done

• Thaddius ruleset is available as a 100% uptime damage buff with a suitable modifier.

The bashguuder mace weapon has wrong stats. it is not a MH, it is a 1H. It is also not unique. It also has +9 strength on it.

Attack speed proc (Eskhandar's Right Claw, Empyrean Demolisher) does not show up in tooltip and never procs.

Background

The majority of Rogue talents and abilities are implemented but a few have been left by the wayside as they are low impact for PvE, while being non-trivial to implement.

Missing abilities / talents

Note that this does not list all missing abilities talents, only those that are currently being considered as "will be in the sim at some point". Other missing talents are those that either do not have any impact in a target dummy environment, or would have an impact if there were external systems like incoming damage as part of the simulation.

Cold Blood

Skipped because it has a fairly low (but not insignificant) impact on longer encounters. If it was straight-forward to implement this talent/ability it would have been a part of the early rogue releases, but Cold Blood is the first one of its kind which is always more difficult.

The difficult property of Cold Blood is that it has an activatable portion where the cooldown is not started on activation, but rather on buff consumption. The current primitives does support this behavior but it is not particularly straight-forward. The following is an example of how it can be implemented using 2x Spells and 1x Buff:

• Cold Blood is derived by Spell, has internal spell that is the actual cooldown. Has "internal" buff (that is available for the relevant spells) to check if outcome should be modified into a critical (probably best to have the dependencies in that direction).
• The "interface" spell uses is_ready_spell_specific in order to check if the internal spell is ready.
• The buff consumption of Cold Blood should activate the internal spell via friend class.

It would also be possible to use 1x Spell, 1x Buff, 1x Proc, etc. in a similar fashion.

Deadly Poison, Rupture, Garrote, Dirty Deeds

Skipped because BlizzCon demo and subsequent Classic information dumps had 16 debuff slots, which mostly renders these spells (and by extension talents that modify them) practically useless in a 40-man raid setting, although they will be added to be able to properly support smaller raid sizes.

Preparation, Premeditation, Ambush, Improved Ambush

Skipped because of low impact on longer encounters.

Vanish

Skipped until it is decided to implement Ambush / Garrote, or threat is simulated.

Initiative

Skipped until it is decided to implement Ambush / Garrote.

Ghostly Strike

Skipped because it is mostly unused.

Definition of Done

All the listed spells and talents have been added.

In its current form, ClassicSim expects you to always downrank SoC to rank 1, since no other ranks are currently implemented. Seal of Crusader however always uses the highest rank. While the latter may be fine, I think it's important to have all SoC ranks, especially for using Judgement on CD as discussed in #58.

Druid gets 2 AP per 1 Strenght. The program uses 1 AP.

Following #54, I wanted to report this, as I had noticed this issue too. I think it simply boils down to the current rotations (both of them) not using Judgment at all except for putting up the Seal of the Crusader debuff. Hence there's no Judgment of Command damage in the breakdown, which one should probably be using on CD.

Also, while we are at it, Exorcism is missing from the rotation if the target is an undead or demon.

Background

The Spell base class and its many children have unit tests under the Test directory.

Categories of spells have a test base class that define a set of mandatory tests, e.g. damaging spells are tested in classes that inherit from TestSpellDamage to make sure that some basic properties of the spell functions as expected.

Furthermore, each (WoW) class can add another level of inheritance to add mandatory tests that are class-specific, such as TestSpellWarrior inheriting from TestSpellDamage in order to add (at the time of writing) test_stance_cooldown() to enforce writing tests that verify spell behavior when it comes to stance cooldown (whether or not it observes it), as well as adding a number of helper functions that are specific to Warrior.

Description of problem

• The set of mandatory tests that are defined at the different levels can be improved to cover more cases.
• The current tests could be improved in quality as suggested below.

Expected implementation

Improving current tests

All implementations of test_resource_cost should not only test that with a given amount of resources the spell can be cast. They should also test if spell is cast when pchar has given_amount_of_resource + 1 then the resulting resource level should equal 1 (i.e. no overspending of resources occur). They should also test that if a spell misses/parries/etc. that resources are spent/refunded as appropriate.

See the Sinister Strike tests (scroll down to TestSinisterStrike::test_resource_test) for an example of where overspending of resources is indeed tested.

Adding more mandatory tests

The following are a few examples that are non-WoW-class specific for damaging spells (i.e. those inheriting TestSpellDamage). Test that:

• With 100% hit abilities DO hit and hit effect check is run and that no crit effect check is run.
• With 100% crit abilities DO crit and crit effect check is run and that no hit effect check is run.
• With 100% miss abilities DO miss and no crit/hit effect check is run. Only applicable if spell can miss.
• With 100% dodge abilities DO dodge and no crit/hit effect check is run. If spell cannot be dodged then the test should exist but test the inverse.
• Damage is affected/not affected by target armor.
• Damage is affected/not affected by player damage increasing effects.
• Damage is normalized/non-normalized if source is weapon damage.

Helper functions to support tests above

Add test procs with 100% proc rate that either assert(false); in proc_effect() or let the test fail when asserting whether proc happened afterwards. These procs should be able to take a ProcInfo::Source in the constructor argument in order to be able to add multiple different procs for different proc sources. Add helper functions to enable said procs easily.

Subclassing TestSpellDamage into physical specific test class

In order to be able to add more mandatory tests that are specific to spells dealing physical damage as the ones previously described; subclass TestSpellDamage.

Also, consider changing the naming pattern to make it more obvious: e.g. TestDamagingSpell, TestDamagingPhysicalSpell.

Subclassing TestSpellDamage into magic-specific test class

In order to be able to add more mandatory tests that are specific to spells dealing magical (i.e. non-physical) damage subclass TestSpellDamage.

Test that:

• spells are affected roll on spell table (i.e. spell hit applies)
• spells correctly take partial resistance into account (i.e. 25% damage on 75% resist, etc.).

Class-specific improvements

Rogue tests

Consider subclassing TestSpellRogue into Spender and Finisher to be able to define a set of mandatory tests for each of those.

Test that:

• Combo point spenders should be able to proc Ruthlessness.
• Combo point spenders should set Relentless Strike proc rate based on current combo points.
• Combo point generators should test that Seal Fate procs extra combo points with 100% crit.

Warrior tests

Test that:

• Heroic Strike deals zero damage if HS buff is not active when it is cast.
• Deep Wounds only procs on crit for all damaging spells.
• Deep Wounds dot damage not invoked by damaging spells (only the application is).
• Flurry not applied on anything other than a crit.

Definition of Done

All of the examples above are implemented or discarded with a good reason.

Background

All spells are at the time of writing hardcoded to use max spell rank. In order to be able to remove this restriction spell rank data for all spells needs to be made available (among other things).

Expected implementation

Adding new spell ranks

Look at Execute.cpp and its spell_ranks vector populated in the constructor. To solve this issue a similar spell rank data format is expected: a vector holding a data format suitable for keeping the data necessary to completely describe the spell rank (in the case of Execute it is a pair of integers; one for the flat bonus damage; one for the excess rage-to-damage conversion value).

This needs to be done for all spells. Make sure to also include the level requirement of the spell rank. The gold cost can be skipped.

Modifying existing spell rank data

All spell ranks that already exist (such as Execute.cpp) need to be enhanced to also include the level requirement of the spell rank. The gold cost can be skipped.

Definition of Done

This issue is scoped such that only adding a spell_ranks vector with accurate spell data is sufficient (for all spells). The spell rank data must contain the damage/resource information to accurately model each individual rank, as well as the level requirement of the spell rank (i.e. when it is available to train).

The spell itself is still expected to be hardcoded to max level (this will be solved at a later point when further dependencies are solved).

Further work

The spell rank data introduced by solving this issue is likely to be refactored into a spell rank class similar to TalentRequirer that handles incrementing and decrementing spell ranks, disabling/enabling spells based on character level, etc.

Maybe I misunderstood the iterations. I was under the impression that increasing the iterations would increase the precision of stat weights. However, it seems that the stat weights iterations is static, so I still get a huge amount of variation in stat weights between each sim, even at 1M iterations. Is it possible to change the amount of iterations done for stat weight calculations?

After further testing, the iterations setting in both full simulation and quick simulation seem to do NOTHING. If I put 100 or 1 000 000, it doesnt matter. The speed of the sim is exactly the same, and statistics -> internal engine does not reflect additional events that should occur from more iterations. Seems there is a bigger problem here and needs another look at it.

I read from the reddit that you have the plan to do the Linux release but no plan for macOS mainly because you don't have the macOS device to begin with. I personally would love to help but unfortunately I'm not very familiar with the development using Qt.

I did try to download Qt, download the project, configure, build and run but application crashed because of the following

Cannot read file: "No such file or directory"
"/path/to/build-directory"

I've searched for the error message and found out that a few lines of code try to load files from some XML files such as in EquipmentDb. My guess is those XML files are not copied to the build directory where the application runs, so cannot find those necessary files.

I'm wondering if there's anything can be done to make those XML files relative to the application directory? I've found the following link, but not sure whether that helps or not.

https://doc.qt.io/qt-5/resources.html

Background

Auto-shot has a charge-up time where the bow-drawing animation starts playing. If a shot occurs during this charge-up time, the drawing animation and charge-up time is effectively reset. This is typically visually displayed in Hunter Auto-shot timer addons, but is not implemented in the sim where the only clipping that occurs is the Aimed Shot cancelling and suppressing auto-shot.

This was skipped during the initial implementation because in the actual rotation used we make sure to never clip the rotation, so any resolution in this issue should have a minor impact at best on the resulting damage output (assuming the current rotation, where AS/MS are only allowed within a short interval after a shot, so the type of clipping described in this issue should never apply to that rotation).

Suggested implementation

Add AutoShot::clip_shot() that updates its expected use if necessary. "Necessary" is defined as whether (next_expected_use + 0.5) < engine->get_current_priority(). If true, set the new value of next_expected_use to engine priority + 0.5 and invoke HunterSpells::add_next_ranged_attack().

Consider adding HunterSpells::clip_shot() that invokes AutoShot::clip_shot() for the sake of interface usage from other spells.

Definition of Done

• Spells cast within 0.5 seconds of the next Auto-Shot now clips the shot.

Background

The quiver bonus is currently a hardcoded 15% Ranged Attack Speed increase for Hunters. This should be modifiable via the GUI.

Suggested implementation

• Remove the hardcoded 15% Ranged Attack Speed bonus for Hunters
• Add available quivers: new item model and XML parser.
• Add another equipment slot in Equipment.qml that is only visible for Hunters. Let this new slot select the quiver item model.

Definition of Done

• Quiver bonus is no longer hardcoded and quivers are available for selection for Hunters

Hey, any way you can make some tool or script for excel to add items in the right syntax?

I have been close to all a lot of the stuff I'm missing when siming my mage, but if I do so I might as well share it and it would be way faster if there was some kind of tool/script

Background

The majority of Hunter talents and abilities are implemented. The ones left are either no impact in PvE, melee abilities/affects melee abilities, or are typically not used due to debuff slot limits.

Missing abilities / talents

Note that this does not list all missing abilities talents, only those that are currently being considered as "will be in the sim at some point".

Serpent Sting

Typically not used in hunter rotations in raid environments due to debuff slot limits.

Arcane Shot

Typically not used in hunter rotations due to it having a poor damage to mana ratio, among other reasons.

Raptor Strike

Priority was to add the typical range rotation for hunters first. Adding melee rotations will happen, but is low priority for fairly obvious reasons.

Mongoose Bite

Is a melee ability (see Raptor Strike) and it also requires external incoming damage systems as part of the adventure simulation concept, which is far in the future.

Definition of Done

All the listed spells and relevant talents for these spells have been added.

From theory crafting we know that hitcap is key (9%). Going far beneath hitcap in classic sim as a hunter, e.g. replacing it with crit for instance, barely changes calculated dps.

Is there any way we can make sure hit is correctly calculated?

Hi,
Thanks to the tool!
And I find some problems in Release191027, in the simulator the stats weighting for Paladins is still 1Str=1AP and 1Agi=1AP
Actually it is 1Str=2AP, 1Agi=0AP (like Warrior)

and can`t find ‘Judgement’ in the Damage Breakdown, although it exists in the Rotation

Looking forward to fix these problems.

For example running a frost mage simulation with Elemental Mage Staff equipped gives the same results as with no weapon equipped. This seems to apply to all +frost or +fire gear.

As far as i can tell quiver currently affects Aimed Shot casting speed, this messes with the rotation and make faster ranged weapons give better results than they should.

This file is right next to the source file in the source tree but obviously not in the built binary. I don't see a "package-all-xml-files-and-put-them-next-to-the-built-binary" step in the build, but this is the first time I've ever looked at qmake so I couldn't really tell.

please check these in DWFury

<cast_if name="Heroic Strike">
		variable "time_remaining_execute" greater 3
		and resource "Rage" greater 50
                //and resource "Rage" greater 70//
</cast_if>

<!-- Switch to Battle Stance -->
	<cast_if name="Battle Stance">
		variable "time_remaining_execute" greater 5
		and buff_duration "Overpower" greater 2
		and spell "Bloodthirst" greater 3
		and resource "Rage" less 50
		<!-- and variable "dumping_rage_before_stancing" is false -->
	</cast_if>

<!-- Whirlwind only if Bloodthirst on cooldown and not in Execute phase. -->
	<cast_if name="Whirlwind">
		spell "Bloodthirst" greater 1.5 
               //and resource "Rage" greater 50//
		and variable "time_remaining_execute" greater 0
	</cast_if>

Changing the stance when "rage" >25 is not good i think because the talent only retain up to 25rage.
However, DW fury in good gear just keep "Berserker Stance" is fine.
"Hamstring" for DWFURY is useless, "overpower" is the same.
So i just delete "Switch to Battle Stance" part and the "Hamstring" part.
Then cast HS when the rage >70 and cast "Whirlwind" more than 50.

After i changed rotation, i improved about 1%-2% DPS.

2H Maces are missing, polearms are available even though they can't be used by Druids (not added til TBC or later).

It would be very nice to able to do

war = Warrior()
war.talents = Warrior.Talents.templates.dualWieldFury
war.mainHand = Weapons.oneHandSwords.viskagTheBloodletter
war.buffs = 
...
engine = Engine()
engine.addDps(war)
results = { "withoutSongflower" : engine.runLoatheb() }
war.addBuff(Buffs.world.songflower)
results["withSongFlower"] = engine.runLoatheb()
...
numpy.doSomeFancyPlotWithAllThisDataToShowAnalytics()

etc and then be able to use that data with numpy, scipy, pandas etc to do typical data science analytics. Have you thought about this? You could even embed the state of the character in the results structure and cache it and only lazily reevaluate upon request.

It probably would be more usable even for non-programmers than any GUI could given that all they'd have to do would be install VSCode, open an example.py, install the MS python plugin and click play. Saving would be trivial since it would just be ctrl + s to save EVERYTHING that the user did.

Any thoughts?

Background

The current available hunter rotation is an AS/MS rotation that assumes the hunter remains at range. There is potential for extra damage for a skilled hunter by weaving melee auto attacks between shots whenever AS/MS are on cooldown.

Requirements

Run speed

Find out how fast a player without run speed effects can run 3 yards.

Related issues

The improvements to the correctness of Auto Shot that should be introduced in this issue is useful for a more truthful assessment of the strength of the melee auto weave, as any melee weaving auto rotation would otherwise be more forgiving than is actually the case.

Suggested implementation

New Movement spell

Introduce a Movement spell that inherits from SpellCastingTime. Have the cast time be affected by movement speed increases. The spell effect should be to change the current rotation mode to whatever is applicable (in this case to Melee if entering the hitbox, and to Ranged if exiting the hitbox).

Note that the rotation mode implementation will likely require rework since it was implemented on the assumption that no one would ever change between melee and ranged within the span of a single combat iteration.

Note that the SpellStatus for the Movement spell should override is_ready_spell_specific() to be able to signal that for example exiting melee range is only available if the player is actually in melee range.

Consider also how to reduce the skill at which the sim will play since it is potentially quite difficult to implement human reaction times in this case. One potential way is to have the cast time for the movement spell consist of actual_time_it_takes_to_cover_N_yards + human_reaction_time_to_start_and_stop_move. Let movement speed effects then only work on the actual_time_it_takes_to_cover_N_yards variable.

The last option is to accept that the sim does it in a fairly unhuman way since in practice a skilled hunter will be able to melee weave just as well as the sim since there is quite a margin for error.

New melee weave rotation

Make a new rotation "AS/MS Melee Weave" that:

• uses the movement spell to enter melee on the conditions AS/MS on long cooldown and
  Auto-Shot just fired.
• uses MainhandAttack without conditions (see note regarding rotation mode rework).
• uses the movement spell to exit melee.

Definition of Done

• Melee weave rotation for hunters is available and fully functional
• Movement is affected by speed increasing effects

gutgore ripper and corehound tooth are missing from daggers

https://classic.wowhead.com/item=13348/demonshear

I'd create a pull request myself, but I have no idea about the proc rate.