Sneak peek: mew-yawning-experimental branch.
Yawning Angel
If you ever wondered what DPS looks like on a fight that spawns 5 adds
that live for 30 sec every 60 sec, now you can find out. It's far
more generic than that naturally, and it's entirely script driven so
you can do a lot with it.
The downside is that for add fights it produces a report that's
positively gigantic, but it was that or not allow you to mouse over
Feral FF adds when Swiping.
Things you can do in the branch:
* Spawn targets other than "Yawningstraza"[0].
* Set the name, level, time to die, and if the new target should have
a Blood in the Water range.
* Swap to any target (that's alive) at will.
* Any of the single target DPS abilities will work correctly, unless
I screwed up.
* Swipe for Massive Damage.
* Clever script writers now have a utility timer hook. You can use
it to spawn adds at set intervals without cluttering up the action
list for example, *but* you cannot take actions from within the
callback. I'll probably add a method to force stop the swing timer so
that I can move the air phase handler there.
Things you can't do in the branch:
* Use the Cat Formulation code. It's been deprecated.
Things that would be nice but probably won't be in the next build[1]:
* Using Feral charge on target swap.
* Spawning targets a set distance away from Yawningstraza.
* Randomizing add facing to force a certain number of parries.
(Probably something like pAddIsFrontalFacing on each Swipe cast.)
So the next public release will have:
* Fine control over trinkets.
* Multi-target Cat support.
* A few minor bug fixes.
Regards,
Yawning
[0]: No, I'm not going to rename that, and no, I'm not going to add a
option for it. Bask in the glory of Yawningstraza, scratching post
par excellence and destroyer of Bears.
[1]: What, don't complain, I went and rewrote the bulk of the sim code
for this AoE stuff. :(
Yawning Angel
> Since I'm getting closer to merging this back into /trunk......
And done as of r825. trunk Cat code is multi target aware now. Yay.
I had a minor bug in my Swipe implementation that was applying the 80%
refund on miss/dodge/parry which was totally screwing up numbers (And
to make matters worse, I was doing it per target which was hilarious),
but that's fixed now.
Note that some profiles will show increasing Mastery to be a net DPS
loss if you are doing a lot of AoE. This amusingly is not a bug.
Think about what stats are valuable, and proceed to glare really hard
at the stupid Ragnaros trinket. Yes, this makes stats *extremely*
encounter sensitive, but I don't care because I don't play and the
tool will support modeling whatever you want it to assuming you take
the time to modify the script.
Regards,
Yawning
Leafkiller
putting in the multi-target support. I read through the script example
code you created and it is very straightforward.
I know your life would not be complete without my asking for a few
improvements (ducks), so here goes:
Let's say I want to do a Magmaw emulation. Using setTarget I can make
sure that all attacks are on a specific target - so I can deal with
the big add spawns along with the exposed head phase, making sure the
proper target is being attacked. Swipe is iffy since I cannot specify
that some targets (Magmaw/Exposed head) are out of melee range at
times. Ideally the Exposed head would be alive for the length of the
fight and only in range for portions of it. The exposed head needs to
use Magmaw's health though - so I need a way to tie an add's health to
the primary target (more to the point,the mob's health percentage so I
could deal with BitW). I also need the ability to change the damage
multiplier on a mob (exposed head takes 100% more damage after all).
I am assuming that DoTs put on an add will continue to tick even if
the add is being not targeted or currently attacked.
The melee range per target would be useful on other fights such as
Beth'tilac. If you are on spider duty (which I have been the last
couple of weeks) you are going up to the web to dps Beth'tilac,
jumping down and swiping a few spiderlings, doing some single target
dps on a drone, going bear for a quick growl, hitting a swipe or two
on some spinners and then heading back up to dps Beth'tilac again,
followed by the final burn phase when Beth'tilac comes down to play.
The swipes will be on different targets (which will be handled by
having them die) but they will never touch Beth'tilac. The drone is
likely to have about 20-30% health left and maybe 10-15 seconds from
dying when first attacked (BitW support + starting with a specific
health percentage).
Yawning Angel
> Let's say I want to do a Magmaw emulation. Using setTarget I can make
> sure that all attacks are on a specific target - so I can deal with
> the big add spawns along with the exposed head phase, making sure the
> proper target is being attacked. Swipe is iffy since I cannot specify
> that some targets (Magmaw/Exposed head) are out of melee range at
> times. Ideally the Exposed head would be alive for the length of the
> fight and only in range for portions of it. The exposed head needs to
> use Magmaw's health though - so I need a way to tie an add's health to
> the primary target (more to the point,the mob's health percentage so I
> could deal with BitW). I also need the ability to change the damage
> multiplier on a mob (exposed head takes 100% more damage after all).
Let's see, BitW is currently time based for all targets (and always
has been), though there's an option to disable it entirely (which the
example uses to reduce log clutter somewhat). So for something like
Magmaw's head, you can just do something like:
status.newTarget("Yawningstraza's Exposed Head", 88, (int)
status.getTimeRemaining(), true);
in the initialization hook, and BitW will kick in at the expected
time. Rake/Rip uptimes will look low since it's based off time the
target was alive, but if I were to change it to active time based
uptimes could exceed 100% which would also look weird, so I think this
is a matter of taste more than anything else.
As far as target specific vuln multipliers, I could do that. It's
probably relatively uninteresting if it's only relevant for one fight
though, so unless a compelling case is made I'm somewhat disinclined
to do so.
> I am assuming that DoTs put on an add will continue to tick even if
> the add is being not targeted or currently attacked.
Sure. I could have made the example code tab Rake, but face rolling
Swipe is so much more satisfying.
> The melee range per target would be useful on other fights such as
> Beth'tilac. If you are on spider duty (which I have been the last
> couple of weeks) you are going up to the web to dps Beth'tilac,
> jumping down and swiping a few spiderlings, doing some single target
> dps on a drone, going bear for a quick growl, hitting a swipe or two
> on some spinners and then heading back up to dps Beth'tilac again,
> followed by the final burn phase when Beth'tilac comes down to play.
> The swipes will be on different targets (which will be handled by
> having them die) but they will never touch Beth'tilac. The drone is
> likely to have about 20-30% health left and maybe 10-15 seconds from
> dying when first attacked (BitW support + starting with a specific
> health percentage).
Hmmm, I'll probably do this with something like
status.setTargetAttackable(String name, boolean isAttackable); which
would make it so that you can't setTarget it, and it's excluded from
the list of Swipe targets. Along with another constructor that gives
a override for BitW time (absolute relative to the target's life), and
this should be trivial to implement.
Eg: status.newTarget("Yawningstraza's Spiderling Nr. 0", 87, 15 /*
Dies in 15 sec */, true, 10 /* 10 sec of BitW time */);
If it isn't obvious I'm trying to move specific fight
environmental/targeting stuff into the init and utility timer hook as
much as possible since it's considerably cleaner that way. It's still
a WIP though, and some calls that are needed are clearly missing, but
I'll be adding onto it as time goes on.
Regards,
Yawning
Yawning Angel
On Fri, Jul 22, 2011 at 9:09 PM, Yawning Angel <yawni...@gmail.com> wrote:
> Hmmm, I'll probably do this with something like
> status.setTargetAttackable(String name, boolean isAttackable); which
> would make it so that you can't setTarget it, and it's excluded from
> the list of Swipe targets. Along with another constructor that gives
> a override for BitW time (absolute relative to the target's life), and
> this should be trivial to implement.
>
> Eg: status.newTarget("Yawningstraza's Spiderling Nr. 0", 87, 15 /*
> Dies in 15 sec */, true, 10 /* 10 sec of BitW time */);
I did the second half of this in r830.
> If it isn't obvious I'm trying to move specific fight
> environmental/targeting stuff into the init and utility timer hook as
> much as possible since it's considerably cleaner that way. It's still
> a WIP though, and some calls that are needed are clearly missing, but
> I'll be adding onto it as time goes on.
And I did some of this in r830/831.
I went and rewrote your Atramedes code to use the new infrastructure,
and I think it's a improvement, though I may change it again once I
add the notion of unattackable targets. However, the base
implementation probably isn't going to change that much. And hey, as
an added bonus scheduleIdleTime() is useful.
I should have put the generic script timer in a long time ago.
TODO before snapshot:
* setTargetAttackable() in some incarnation.
* setTargetFacing() in some incarnation.
* Add a few more interesting encounters to the script (Maybe). I do
have the timers for heroic Rag, but it needs the preceding stuff to
work.
* Optimize the script side of the targeting routines (Maybe). Target
switching and queries are somewhat expensive because target naming is
String based (Yes, names have to be unique). The Sim will be rather
slow if you try to model ping ponging between 2 targets keeping DoTs
up for example. Not sure if it matters since the code is reasonably
fast as is.
Would be nice, but non-trivial:
* Introduce the notion of target position relative to player apart from facing.
* Port the multi-target code to the bear model. (I would need to
branch for this since it's rather involved, and it would be a UI
nightmare.)
* Move the encounter specific stuff off into it's own module. (Maybe
not needed.)
* Unify the bear/cat models. Theoretically there's nothing stopping
me from merging them and allowing for Bear for a portion, Cat for a
portion and similar things, but this would entail scrapping both sim
modules and rewriting them, so this is extremely unlikely to happen.
As it stands, even with the code as is, the number of encounter types
it can model has increased dramatically so I'm fairly happy about how
the branch worked out.
Regards,
Yawning