Feral Powershifting: macros, thresholds, mana management - Page 3

• Krish · 05/17/08, 3:42 PM

Some results from /fk debug:

BL, OoC, and IT are all detected.
Probability of Bloodlust Proc: 4%
Number of Bloodlust Procs: %d nil <---this one seems like a potential issue
Probablility of Omen Proc: 5.14%
Number of Omen Procs: 6
Probability of Idol of Terror Proc: 84.2%
Number of Idol of Terror Procs: 6

Curiously, when I try typing /fk ps extrapolate, it literally does nothing when I press the return key (the line just stays in the chat box as if I never pressed the return button). I can type /fk ps and it shows "Extrapolate (On)".

I'll download and test the newest version now and report any changes.

raffy · 05/17/08, 3:49 PM

Originally Posted by Krish

Some results from /fk debug:

BL, OoC, and IT are all detected.
Probability of Bloodlust Proc: 4%
Number of Bloodlust Procs: %d nil <---this one seems like a potential issue
Probablility of Omen Proc: 5.14%
Number of Omen Procs: 6
Probability of Idol of Terror Proc: 84.2%
Number of Idol of Terror Procs: 6

Curiously, when I try typing /fk ps extrapolate, it literally does nothing when I press the return key (the line just stays in the chat box as if I never pressed the return button). I can type /fk ps and it shows "Extrapolate (On)".

I'll download and test the newest version now and report any changes.

Ah, thanks for finding that out. I uploaded another new version with a better extrapolate and the error fixed. Sorry for spamming the thread.

• Krish · 05/17/08, 3:50 PM

With the newest version again:

I am now seeing a Bloodlust Procs: 0, despite having gotten several of them.

/fk ps extrapolate still doesn't let me press return (or seem to).

Downloading the even newer version now.

• Krish · 05/17/08, 4:04 PM

One of the two issues is now fixed (I can now type /fk ps extrapolate and have it disable successfully). When I do so, I have no issues.

As for the /fk debug reporting 0 BL procs, that's still happening, and I suspect it's why I stop powershifting when extrapolate is turned on.

raffy · 05/17/08, 4:09 PM

Originally Posted by Krish

Downloading the even newer version now.

When I was cleaning up my code I put in the wrong conditional for SPELL_ENERGIZE and spell = Bloodlust. So it was just constantly accumulating hits and then would fail since it hadn't proced in like a billion hits.

I put up a new version, see if that fixes it. Thanks for helping me debug this.

Edit: you should also get bloodlust notifications through SCT or whatever /fk output is set to now that its properly detecting Bloodlust procs.

1 - (1 - p)^n > c
1 - c > (1 - p)^n
log(1-c) > log(1-p) * n
That should provide better results with large n.

ecopsorn · 05/17/08, 6:05 PM

Originally Posted by raffy

@ecopsorn
I'll localize the addon now. Actually, I think I can use spellID's for most of these, but in the mean time, can you provide translations for:

"Cat Form"
"Bloodlust"
"Omen of Clarity"
"Clearcasting"
"Primal Instinct"
"Dire Bear Form"
"Mangle"
"Cat Form"
"Aquatic Form"
"Travel Form"

Katzengestalt
Kampfeslust
Omen der Klarsicht
Freizaubern
Urinstinkt
Terrorbärengestalt
Zerfleischen
Katzengestalt
Wassergestalt
Reisegestalt

I'm not in game and it's late here ^^ I'll check tomorrow morning if the above translations are 100% correct. So far I'm just 90% sure

Mijae · 05/17/08, 6:19 PM

Sorry, I jumped threads to take the discussion out of other one since it's directly related to powershifting...

Originally Posted by raffy

Assuming 4% proc rate, if you haven't got a proc in the last n hits, then your chance of getting the proc within the next few attacks increases, since over extremely large n, the proc rate must be 4%.

I do see your point as the PPM example would basically do the same thing, so maybe what I really should be modeling, is like the inverse of proc. For example, after you got a few lucky procs, your chance of getting more lucky procs is decreases as your number of hits increases.

On a longer fight, I'm sure that if you modeled the bloodlust proc you could have some success predicting its occurrence. How much energy would you save? Who knows? But why not try to figure it out? ;p Since we're ultimately limited by mana, avoiding shifting near high probability of Bloodlust procs doesn't seem like that bad of an idea.

The problem is that this is only relevant for, as you said, "over extremely large n". Even a 10-15 minute fight does not qualify for this, much less the short time window we're talking about here. You cannot predict with any certainty what the outcome of the next event will be.

Let's take another example... flipping a coin. The chance of heads or tails is 50% each. What you're trying to say is that the chance of the next flip being heads increases dependent on the number of flips since the last heads occurred. It is always 50%.

Originally Posted by raffy

The other logic I use is like, "if within 1.5 seconds you will get another 20 energy from regen, then include that extra 20 energy in the energy calculation."

So it currently looks like:
energy = (current Energy) + (20 energy if energy tick occurs within 1.5 sec) + (20 energy if 1-(1-p)^n > 95%)

I also don't understand this logic. The only time the next tick will occur in less than 1.5 sec is basically in the 0.5 sec following either the previous tick or powershift. If it was a tick, you'll have at least 20 energy. If it was a powershift, you'll be in a GCD and have 40 energy. So, won't this always be true when less than threshold?

raffy · 05/17/08, 9:05 PM

Originally Posted by Mijae

Sorry, I jumped threads to take the discussion out of other one since it's directly related to powershifting...

The problem is that this is only relevant for, as you said, "over extremely large n". Even a 10-15 minute fight does not qualify for this, much less the short time window we're talking about here. You cannot predict with any certainty what the outcome of the next event will be.

Let's take another example... flipping a coin. The chance of heads or tails is 50% each. What you're trying to say is that the chance of the next flip being heads increases dependent on the number of flips since the last heads occurred. It is always 50%.

I also don't understand this logic. The only time the next tick will occur in less than 1.5 sec is basically in the 0.5 sec following either the previous tick or powershift. If it was a tick, you'll have at least 20 energy. If it was a powershift, you'll be in a GCD and have 40 energy. So, won't this always be true when less than threshold?

If a 10-15 minute didn't qualify as "large n" for WoW's RNG then DPS outliers would be far more common than they currently are (if there are any that you can think of, for a 5 minute fight, where someone deviated from their paper doll significantly).

All I'm saying is that, Blizzards RNG has the short-term objective of maintaining its average within certain bounds to provide smooth yet still random performance for short-interval combat (the majority of wow combat).

The scenario is:

[0.0] +20 energy (55)
[0.0] Shred (13), GCD Start
[1.5] GCD Ends
You have 13 energy here so...

*** if you shift ***
[1.5] Cat Form (0), GCD Start
[2.0] +40 Energy (40)
[3.0] GCD Ends
[3.5] +20 Energy (60)
[3.5] Rip (30), GCD Start
[5.0] GCD Ends
[5.5] +20 Energy (50)
You have 50 energy and spent 680 mana.

*** if you wait ***
[2.0] +20 Energy (33)
[2.0] Rip (3), GCD Start
[3.5] GCD Ends
*** shift now! ***
[3.5] Cat Form (0)
[4.0] +40 Energy (40)
[5.0] GCD Ends
[5.5] +20 Energy (60)
You have 60 energy and spent 680 mana.

I guess maybe it should be called mana savings?

Edit: another update of FeralKit
http://oldschoolwow.com/FeralKit.zip
http://oldschoolwow.com/FeralKitReadMe.txt

"/fk ps extrapolate" was removed
"/fk ps predict bloodlust" (turn on/off bloodlust prediction -- code works but needs improvement)
"/fk ps predict ticks" (turn on/off energy tick prediction -- saves you mana, but you shift less)

-- properly localized spell names (as ids) used
-- provides a warning if you enter feral form without Omen of Clarity active
-- fixed dependancies so both Sink and Ace2 are included and referenced properly

Leafkiller · 05/17/08, 9:44 PM

Edited - missed that it was fixed in the previous post.

Mijae · 05/17/08, 9:48 PM

If what you're saying is true, say I had a 50% crit rate. I could then wait for 4 non-crits in a row and then use a trinket because the next 4 must have a higher crit chance to make it even out to 50%. It just doesn't work that way.

I'm not sure you understand how compute-intensive the type of system you are suggesting implies. It might not be too difficult for you to try and mimic the behavior, but imagine doing this in detail for thousands of users while performing all the other server calculations as well. This is precisely why internal cooldowns are used instead. The implementation is a much simpler concept, easier implementation, and faster performance. Otherwise there would be no reason for them to exist.

If the predictions are wrong, it's not just a matter of saying oh-well. Not performing a shift because you're expecting a proc to come and it doesn't will lower your damage. If the proc actually does happen and you shifted, you simply get the energy after the shift rather than instead of it.

Btw, cat GCD is 1 sec, not 1.5. Also, the energy difference you posted is due to the threshold you used for when to shift and starting energy. I don't understand what it has to do with the current discussion.

raffy · 05/17/08, 10:19 PM

Originally Posted by Mijae

If what you're saying is true, say I had a 50% crit rate. I could then wait for 4 non-crits in a row and then use a trinket because the next 4 must have a higher crit chance to make it even out to 50%. It just doesn't work that way.

I'm not sure you understand how compute-intensive the type of system you are suggesting implies. It might not be too difficult for you to try and mimic the behavior, but imagine doing this in detail for thousands of users while performing all the other server calculations as well. This is precisely why internal cooldowns are used instead. The implementation is a much simpler concept, easier implementation, and faster performance. Otherwise there would be no reason for them to exist.

If the predictions are wrong, it's not just a matter of saying oh-well. Not performing a shift because you're expecting a proc to come and it doesn't will lower your damage. If the proc actually does happen and you shifted, you simply get the energy after the shift rather than instead of it.

Btw, cat GCD is 1 sec, not 1.5. Also, the energy difference you posted is due to the threshold you used for when to shift and starting energy. I don't understand what it has to do with the current discussion.

Yes, I would say, if you crit 4 times in a row, you have a reduced chance to crit on your remaining swings, assuming your local average is within some window near the target crit rate. However, 50% is far harder to predict than 4%.

at 50%,
HHHHH HHHHH CCCCC CCCCC = HHHHH CCCCC HHHHH CCCCC == HCHCH CCHCH CHHCH CCCHH
1/.5 = 2 (overall distribution looks like 1H : 1C)

at 4%
HHHHH HHHHH HHHHC HHHHH = CHHHH HHHHH HHHHH HHHHH == HHHHH HHHHH HHHHH HHHHC
1/.04 = 20 (overall distribution looks like 19H : 1C)

So if I get a bunch of H's, I know that to stay within the window, eventually I'll get a C in "small n" time (or a reasonable amount of samples).

You can implement it in a few lines of code:
-- retain a moving average
-- if you deviate too far from the target mean, apply weighting to return to the desired target window

Sorry about the GCD thing, and I think I see your point since 20 energy will always put you over threshold. Let me play with this a bit more.

Valerian · 05/17/08, 11:02 PM

Originally Posted by raffy

Yes, I would say, if you crit 4 times in a row, you have a reduced chance to crit on your remaining swings, assuming your local average is within some window near the target crit rate. However, 50% is far harder to predict than 4%.

at 50%,
HHHHH HHHHH CCCCC CCCCC = HHHHH CCCCC HHHHH CCCCC == HCHCH CCHCH CHHCH CCCHH
1/.5 = 2 (overall distribution looks like 1H : 1C)

at 4%
HHHHH HHHHH HHHHC HHHHH = CHHHH HHHHH HHHHH HHHHH == HHHHH HHHHH HHHHH HHHHC
1/.04 = 20 (overall distribution looks like 19H : 1C)

So if I get a bunch of H's, I know that to stay within the window, eventually I'll get a C in "small n" time (or a reasonable amount of samples).

You can implement it in a few lines of code:
-- retain a moving average
-- if you deviate too far from the target mean, apply weighting to return to the desired target window

Sorry about the GCD thing, and I think I see your point since 20 energy will always put you over threshold. Let me play with this a bit more.

Well the only way what you are saying is correct is if WoW does something that ISNT an attempt at a fully random system. In terms of probability what you stated in your first sentence is EXACTLY the Gambler's Falacy. I cannot see why Blizzard would have a system in place like this when they already have their PPM systems to deal with situations where they want to "limit" procs to reasonable periods of time.

Mijae · 05/17/08, 11:15 PM

Originally Posted by raffy

Yes, I would say, if you crit 4 times in a row, you have a reduced chance to crit on your remaining swings, assuming your local average is within some window near the target crit rate. However, 50% is far harder to predict than 4%.

at 50%,
HHHHH HHHHH CCCCC CCCCC = HHHHH CCCCC HHHHH CCCCC == HCHCH CCHCH CHHCH CCCHH
1/.5 = 2 (overall distribution looks like 1H : 1C)

at 4%
HHHHH HHHHH HHHHC HHHHH = CHHHH HHHHH HHHHH HHHHH == HHHHH HHHHH HHHHH HHHHC
1/.04 = 20 (overall distribution looks like 19H : 1C)

So if I get a bunch of H's, I know that to stay within the window, eventually I'll get a C in "small n" time (or a reasonable amount of samples).

Until you can provide any proof to backup this argument, there is no reason to conclude this is the implementation. While it might have only taken you a few lines to implement, resources and processing time required is more. Sure they maintain logs, but real-time analysis of those logs is another matter. This is especially true if you consider separate analysis would need to be maintained for every ability (used or not) and every proc for every character online. Recalculating and applying a variable weight to a RNG every ability is not easy either.

However, even if it were true I still don't see the benefit of modelling it for powershifting.

raffy · 05/18/08, 12:10 AM

Well, I'll agree to disagree and leave it at that. I'm pretty confident I can model it, but just for kicks I'm going to go log some data from the Blasted Lands.

However, I do agree about the importance of it for powershifting is questionable, a smarter way to completely avoid the issue would be avoiding powershifts that align to the swing timer (and I think that solves the problem entirely).

More to the question before, about the GetEnergyAfter(1.5sec) function, is such logic necessary? I just figured it would be, doing some quick head logic, but I can't find an example which shows it working as described.

Are there any other conditions we can check to decide whether or not to powershift?

---

I'm going to implement a swing timer.

I'm going to implement the mana gradient thing to curb shifting as mana decreases and maybe have some kind of mana cutoff, so you still have enough mana to do a heal and shift back, or something like that.

Edit: actually, I guess you don't need to look at the swing timer. The energy update function will be called if the proc occurs, which will prevent any future shifting.

Zeln · 05/18/08, 12:26 AM

Originally Posted by tony thorpe

i down loaded the feralkit mod but it dosnt show in game how does it work

[2008/05/18 00:24:01-1-x1]: FeralKit\core.lua:15: AceAddon: AceOO-2.0: Library "Sink-1.0" does not exist.
Ace2\AceLibrary\AceLibrary.lua:122: in function <Interface\AddOns\Ace2\AceLibrary\AceLibrary.lua:75>
(tail call): ?:
(tail call): ?:
AceAddon-2.0-57245 (Ace2):973: in function `new'
FeralKit\core.lua:15: in main chunk

You need to download the appropriate Sink library. In this example, prior to him changing it to use Sink-2.0, downloading and installing LibSink fixed it.