Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Item] Dragonwrath, Tarecgosa's Rest #989

Merged
merged 28 commits into from
Oct 25, 2024
Merged

[Item] Dragonwrath, Tarecgosa's Rest #989

merged 28 commits into from
Oct 25, 2024

Conversation

InDebt
Copy link
Contributor

@InDebt InDebt commented Aug 30, 2024

This is the implementation PR for Dragonwrath, Tarecgosa's Rest.
Implements #946 for further information.

Note

This is an early draft encouring early feedback and participation. Class specific implementations are highly encouraged as I don't know how much time I have a week to get this finished.

Current status

  • Implement baseline handling
    • Proper (Fluent?) API missing to add custom handlers from class folders
  • Add Shadow support
  • Add Discipline support
  • Add Elemental support
  • Add Balance support
  • Add Affliction support
  • Add Demonology support
  • Add Destruction support
  • Add Arcane Mage support
  • Add Fire Mage support
  • Add UI disclaimers

Open topics

On retail Spells instantiate casts which carry a lot of meta information on the actual circumstances and values used during their instantiation. Like base spell power when cast, attackpower and so on. Most importantly casts know the meta data for their calculations. I.e. The pulse lightning capaciatotor knows the charges it was triggered with or Fulmination the lightning shield stacks it was triggered with. In theory DRT copies casts not spells. Therfore the meta data is the same and the same calculations will be used causing fulimnation and capacitator to use the same aura charges for damage calculations. This is something rather tricky to realize right now in our backend and we have to see if all instances can simply "missuse" the BonusSpellDamage field for such things.

return
}

// make sure the same spell impact can only trigger once per timestamp (AoE Impact spells like Arcane Explosion or Mind Sear)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might prevent multiple Chain Lightning Overloads from being duplicated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be right. Trigger/Proc systems are always the hardest to get right even when I was working on p-servers as they heavily depend on how blizz actually implemented stuff.

I suppose we have the following:

  • TARGET_UNIT_TARGET_ENEMY - proc per target even chain targets
  • TARGET_UNIT_DEST_AREA_ENEMY and TARGET_UNIT_SRC_AREA_ENEMY - per cast no matter how many targets
    • Usually those are spells like concecrate, blizzard, arcane explosion or mind sear.

Obviously we don't have access to the target enums for the spells but I guess we need to be able to configure those spells in the class setup. I'll take a look to provide a clean API.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant more because of 2 different overload proc. You chain lightning on 3 targets, 2 of those hits procs CL Overload and both of those overloads can be duplicated, they're 2 different spells with same id happening at the same time. As to how the duplicated spell will work (only first target, new chain, 1 hit per target), i guess there is no way to know

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I more and more wish we had a differenitation between spells and casts i guess xD

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I refactored spell configuration a bit and added some hopefully nice to use APIs around it. What you described should now be the default case and can be configured to be handled otherwise easily.

* Also adds a custom handler for the script effect of Conflagrate
@InDebt
Copy link
Contributor Author

InDebt commented Aug 30, 2024

@1337LutZ Do you have the time and would want to look into how we could display a, perferably spec specific disclaimer for DTR in the UI? Right now I have desigend the staff's implementation that allows us to implement it spec by spec. So the accuracy may very from spec to spec.

@1337LutZ
Copy link
Contributor

@1337LutZ Do you have the time and would want to look into how we could display a, perferably spec specific disclaimer for DTR in the UI? Right now I have desigend the staff's implementation that allows us to implement it spec by spec. So the accuracy may very from spec to spec.

Sure thing!
Would this just be coded in the the sim.ts config? (I assume yes)
I'll have time this weekend to look into this.

Comment on lines 8 to 11
func init() {
cata.CreateDTRClassConfig(proto.Spec_SpecBalanceDruid, 0.072).
AddSpell(8921, cata.NewDragonwrathSpellConfig().SupressImpact()). // Moonfire
AddSpell(93402, cata.NewDragonwrathSpellConfig().SupressImpact()) // Sunfire
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consider having a spell proc chance override. It seems like there are spells with very low proc chance, like Mushrooms and Typhoon - https://www.mmo-champion.com/threads/967211-FAQ-Dragonwrath-Tarecgosa-s-Rest-and-you-a-Balance-Druid

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now I assume the 'low' proc chance reported is due to the fact that both typhoon and shrooms only get a single proc rool per 'cast' which hits serveral targets, which is to be expected.

Adding a custom proc chance later on would be very easy. I can just add a proc chance overwrite on the SpellConfig for the class if testing should confirm this.

@1337LutZ 1337LutZ mentioned this pull request Sep 1, 2024
@1337LutZ
Copy link
Contributor

Just merged master into this branch since there were quite some conflicts

Marcel Ellermann added 3 commits October 1, 2024 15:06
* Add proper implementation of flat crit scaling for lava burst abstraction
* Add new class support
* Add more DTR framework methods
@1337LutZ
Copy link
Contributor

1337LutZ commented Oct 10, 2024

@InDebt Would it be an idea to for now only enable DTR under the Experimental flag?
That way it allows "hardcore" Sim users to play around with it, whilst the "click-and-go" users will see it as a stat stick when comparing to other classes. I believe otherwise all Class Discords will get a bunch of questions on "Why spec XXX does so much more DPS, this is unfair".

if targetCount > 1 {
mage.FlamestrikeBW.Cast(sim, target)
}
// if targetCount > 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this commented code be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I moved the Improved Flamestrike logic into the talent and commented the previous code during testing. Will remove it, as it seems to work as I want.

@InDebt
Copy link
Contributor Author

InDebt commented Oct 12, 2024

@InDebt Would it be an idea to for now only enable DTR under the Experimental flag? That way it allows "hardcore" Sim users to play around with it, whilst the "click-and-go" users will see it as a stat stick when comparing to other classes. I believe otherwise all Class Discords will get a bunch of questions on "Why spec XXX does so much more DPS, this is unfair".

Right now damage gains are close together. Do we even get the 'experimental' flag with the proto request so I could disable / enable class support on the backend? Because otherwise we'd need to thide the staff alltogether behind that flag.

@1337LutZ
Copy link
Contributor

@InDebt Would it be an idea to for now only enable DTR under the Experimental flag? That way it allows "hardcore" Sim users to play around with it, whilst the "click-and-go" users will see it as a stat stick when comparing to other classes. I believe otherwise all Class Discords will get a bunch of questions on "Why spec XXX does so much more DPS, this is unfair".

Right now damage gains are close together. Do we even get the 'experimental' flag with the proto request so I could disable / enable class support on the backend? Because otherwise we'd need to thide the staff alltogether behind that flag.

As discussed in Discord let's wait with merging for now 👌

@github-actions github-actions bot removed the Paladin label Oct 22, 2024
Marcel Ellermann added 3 commits October 23, 2024 12:02
* Reduce latency to process on same sim tick
* Update eclipse behaviour for Druids to match live (proc on cast complete, remove on damage done)
* Update Wild Mushrooms spell implementation to properly work with DTR
* Update some spells to not proc off procs properly
* Update Volcano Trinket to count as a Weapon Proc correctly
* Remove certain impact supressions that have now been validated
* Update proc chances
* Add AoE proc chance supression for AoE abilities
@InDebt
Copy link
Contributor Author

InDebt commented Oct 25, 2024

@1337LutZ and others of course. I think we're in a state where we could give this out for preliminary testing.
I've updated the discliamer for the weapon. Checked I think all the reported interactions and adjusted accordingly after the PTR.

There will certainly be minor things I will inevitably have missed, so I think it's a good point to let others help out find those things 😁 .

Lutz already went and did some math and at least the current gains from DTR seem to be within expectations.

@1337LutZ
Copy link
Contributor

@1337LutZ and others of course. I think we're in a state where we could give this out for preliminary testing. I've updated the discliamer for the weapon. Checked I think all the reported interactions and adjusted accordingly after the PTR.

There will certainly be minor things I will inevitably have missed, so I think it's a good point to let others help out find those things 😁 .

Lutz already went and did some math and at least the current gains from DTR seem to be within expectations.

Super awesome, and thanks for all your hard work on making a extensible implementation. ❤️
I've shared some Local builds with DTR implemented with some of the Discord big brains and most see it in line and have already provided feedback for some changes that I relayed to you. 👍

@InDebt InDebt merged commit c01c223 into master Oct 25, 2024
2 checks passed
@InDebt InDebt deleted the feature/dtr branch October 25, 2024 10:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants