Cast and Recast

**Mougurijin** · 2011-08-28 22:03

I changed my formula very slightly earlier today. It's been corrected in my previous posts in this thread.

Now I'm going to try and explain from start to finish how my theory works, and how it only works if you start with 13 bits, and allow the result after haste to stay 12 bit if it drops to 12 bits...

Example #1 - Why you can only start with 13 bits at the very most, but after haste is applied, the recast must be able to drop below 13 bits accuracy...

Here is my explanation for the recast time of Aero IV + 150/1024 haste & -52% FC.
This shows from start to finish the base recast time, then haste applied to it, then fast cast -- giving the final answer the same as the in-game recast, as 20 seconds, not the 21 seconds that might otherwise have been reached.

Aero IV recast in resources as an integer:

Code:

0 0 0 0 0 1 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
128 + 4 + 1
= 133

Aero IV recast in seconds (13 bits):

Code:

0 0 0 0 0 0 0 1 0 0 0 0 1|0 1 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
32 + 1 + 0.25
= 33.25 seconds

Aero IV recast in seconds as the significand of a floating point (13 bit accuracy in 12 stored bits):

Code:

1 0 0 0 0 1 0 1 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
4096 + 128 + 32
= 4256

The value of the recast in seconds has been shifted 7 bits to the left to use all 12 bits and the extra bit.

Now apply 150/1024 haste, from haste spell effect being present:

Code:

4256 * (1 - 150/1024) = 3632.5625

After haste is applied, then the recast to now attempt to store in the significand is 3632.5625:

Code:

0 1 1 1 0 0 0 1 1 0 0 0 0|1 0 0 1 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5

2048 + 1024 + 512+ 32 + 16  (+ 0.5 + 0.0625)
= 3632  (3632.5625)

This is only using a 12-bit significand now... if it was made to represent 13-bits again, with the bits shifted left by 1 bit, the .5 could be represented too.
If the result was 3632.5 or 3632.5625 though, the final recast after fast cast would be wrong.
The .5625 is lost as it does not fit into the significand, which leaves the signficand as 3632 now.

Now to apply fast cast...

RDM90 "Fast Cast V" job trait: -30% FC
RDM60 AF1 hat: -10% FC
RDM74 AF2 body: -10% FC
RDM90 AF3 earring: -2% FC

truncate( 52 / 2 ) = -26% FC recast reduction

3632.5625 * (1 - 26/100) = 2688.09625 (12 +3 bits = no truncation)
3632.5 * (1 - 26/100) = 2688.05 (12 +1 bits)
3632 * (1 - 26/100) = 2687.68 (12 bits):

Code:

0 1 0 1 0 0 1 1 1 1 1 1 1|1 0 1 0 1 1 1 0 0 0 0 1
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
2048 + 512 + 64 + 32 + 16 + 8 + 4 + 2 + 1
= 2687

Now to shift this value "101001111111" (2687) back 7 bits to the right, to give the final recast value in seconds:

Code:

0 0 0 0 0 0 0 0 1 0 1 0 0|1 1 1 1 1 1 1 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5

16 + 4  (+0.5 + 0.25 + 0.125 + 0.0625 + 0.03125 + 0.015625 + 0.0078125)
= 20 seconds (20.9921875)

If more accuracy than 13 bits is used, after applying haste the recast value would be very slightly higher, then after applying fast cast to this, the final recast would be 21 seconds, instead of what the in-game recast timer shows, which is 20 seconds.

-----

Example #2 - Why you can't start with any less than 13 bits of accuracy either...

Reraise + 30/1024 haste & -19% FC

Reraise recast in resources as an integer:

Code:

0 0 0 0 0 1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
128 + 64 + 32 + 16
= 240

Reraise recast in seconds (13 bits):

Code:

0 0 0 0 0 0 0 1 1 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
32 + 16 + 8 + 4
= 60 seconds

Reraise recast in seconds as the significand of a floating point (13 bit accuracy in 12 stored bits):

Code:

1 1 1 1 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
4096 + 2048 + 1024 + 512
= 7680

The value of the recast in seconds has been shifted 7 bits to the left to use all 12 bits and the extra bit.

Now apply the 30/1024 haste (Headlong Belt):

Code:

7680 * (1 - 30/1024) = 7455

After haste is applied, then the recast to now attempt to store in the significand is 7455:

Code:

1 1 1 0 1 0 0 0 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
4096 + 2048 + 1024 + 256 + 16 + 8 + 4 + 2 + 1
= 7455

This time, the recast after haste has remained in 13 bits, not dropping to 12 as in "Example #1".
If however, the recast were to be forced to 12 bits accuracy, the value would be equal to 7454, which would give an incorrect final recast value after fast cast.

Now to apply fast cast...

/RDM43 "Fast Cast II" job trait: -15%
Loquacious Earring: -2%
Incantor Stone: -2%

truncate( 19 / 2 ) = -9% FC recast reduction

7454 * (1 - 9/100) = 6783.14 (13 -1 bits)
7455 * (1 - 9/100) = 6784.05 (13 bits):

Code:

1 1 0 1 0 1 0 0 0 0 0 0 0|0 0 0 0 1 1 0 0 1 1 0 0
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
4096 + 2048 + 512 + 128
= 6784

Now to shift this value "1101010000000" (6784) back 7 bits to the right, to give the final recast value in seconds:

Code:

0 0 0 0 0 0 0 1 1 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 1
= = = = = = = = = = = = =|= = = = = = = = = = = =
4 2 1 5 2 1 6 3 1 8 4 2 1|. . . . . . . . . . . .
0 0 0 1 5 2 4 2 6         5 2 1 0 0 0 0 0 0 0 0 0
9 4 2 2 6 8                 5 2 6 3 1 0 0 0 0 0 0
6 8 4                         5 2 1 5 7 3 1 0 0 0
                                5 2 6 8 9 9 9 4 2
                                  5 2 1 0 5 7 8 4
                                    5 2 6 3 6 8 4
                                      5 2 1 5 2 1
                                        5 2 6 8 4
                                          5 2 1 0
                                            5 2 6
                                              5 2
                                                5
32 + 16 + 4 + 1
= 53 seconds

If instead 12 bits accuracy was used, the result would have been 52 seconds, but the in-game recast timer is 53.

**Ophannus** · 2011-10-12 13:45

What's the earliest that a spell can fire judging by the spell cast% bar? As RDM95/SCH47 with Dark Arts and AF1hat/Af2body/Augur's feet/Loq/Estoq/+3 Jeweled Collar Blizz IV is cast at ~33-35%, adding or removing Varuna Staff(12% cast) doesn't affect this number. I would have thought since cast time is capped at 20% I'd be closer to that number with the staff, also as RDM/NIN without Dark Arts, Blizz4 is still firing off at 33-35% so it seems like Dark Arts and Staff aren't adding much?

**Byrthnoth** · 2011-10-12 13:47

Determining casting speed off animation is not recommended. Remember all that stuff with "Cure Cast Tiers" for white mage?

This is the most promising method I've heard of, but I use a laptop/laptop keyboard so I can't do it.

**Foldypaws** · 2011-10-12 14:21

Originally Posted by Ophannus

What's the earliest that a spell can fire judging by the spell cast% bar? As RDM95/SCH47 with Dark Arts and AF1hat/Af2body/Augur's feet/Loq/Estoq/+3 Jeweled Collar Blizz IV is cast at ~33-35%, adding or removing Varuna Staff(12% cast) doesn't affect this number. I would have thought since cast time is capped at 20% I'd be closer to that number with the staff, also as RDM/NIN without Dark Arts, Blizz4 is still firing off at 33-35% so it seems like Dark Arts and Staff aren't adding much?

Dark arts is a separate term for recast reduction, so I assume it's a separate term for cast time as well.

Which means that if you're already down to 50% with FC, DA will only take you to 45. If Equipment mods are separate as well (like haste/equipment mods are for recast), that'd put you at ~40% with the staff. Spells normally fire at ~80% anyway, and 31% is what you get with multiplicative -50%, -10% and -12% terms on a base of 80. So it's about what I expect.

Losing DA would only push you up to 35% or so, which is within your eyeballing range.

**Mougurijin** · 2011-10-12 20:00

Originally Posted by Foldypaws

Dark arts is a separate term for recast reduction, so I assume it's a separate term for cast time as well.

Which means that if you're already down to 50% with FC, DA will only take you to 45. If Equipment mods are separate as well (like haste/equipment mods are for recast), that'd put you at ~40% with the staff. Spells normally fire at ~80% anyway, and 31% is what you get with multiplicative -50%, -10% and -12% terms on a base of 80. So it's about what I expect.

Losing DA would only push you up to 35% or so, which is within your eyeballing range.

MACC magian staff affinity Recast Time -12% reduction is part of Fast Cast recast time reduction term.
So, DMG magian staff affinity Cast Time -12% reduction is very likely part of Fast Cast term in cast time reduction too.

Dark Arts probably is a separate term for cast time though, as it is with recast time.

I'm glad the Test Server is back up again. I'm hoping to do some thorough testing for cast/recast times, but at the moment I'm testing magic damage.

**Motenten** · 2011-10-19 08:42

Been trying to get some general idea of the effect of Fast Cast, and have been doing FRAPS captures to try to narrow down certain aspects of it. While I know it's not the best method, it's the only option I have available at the moment. I've been getting very strange results, and would like to know if anyone else has seen the same things, or has an explanation.

Tests have been on Reraise 1/2/3. Their rated cast times on the wiki (drawn from the .dats, per Byrth) are 8.0, 7.5 and 7.0 seconds, respectively.

When FRAPSed, the animation times from the first frame of casting to 100% completion on the progress bar have been *exactly* 325 frames, 305 frames and 284 frames (occasional 285 frames for RR3) at 29.97 frames per second. I've tried other frame rates, but while the number of frames of course change, the total time to complete in frames/fps is the same. These match wall-clock estimates of approximately 10 seconds to complete 100% casting.

Reraise 1: 325 frames = 10.84 s
Reraise 2: 305 frames = 10.18 s
Reraise 3: 284 frames = 9.48 s

It happens that those are exact scalings of the rated cast times:

Reraise 1: 10.84 / 8 = 1.355
Reraise 2: 10.18 / 7.5 = 1.357
Reraise 3: 9.48 / 7 = 1.354

Essentially, 100% completion is 35% longer than the rated cast time. Completion time (time from first animation frame to frame where MP is consumed and buff is applied) is in the range of 86% of total completion time (0% Fast Cast, no Arts), generally about 1.25 seconds longer than the rated cast time, so it's not merely that the rated cast time is how long it takes to apply the buff/use MP, with the remainder as animation fluff.

It occurred to me that it may be related to CPU clock frequency, due to issues I remember of people getting jailed for overclocking their CPUs and such to affect movement speed. I have a Core i7 920 with a spec'd clock rate of 2.67 GHz that can self-overclock to 2.8 GHz, and generally idles at about 2 GHz (lots of variation on the lower idle rate). When running FRAPS, the CPU clock frequency is always maxed (thus 2.8 GHz).

Counter to that, while there's a degree of fluctuation in the MP/buff completion time frames, there is pretty much no variation in total animation frames, so I wonder if I'm overthinking that.

I also ran a quick test on Cure V. Rated cast time is 2.5 seconds; 100% animation completion was 3.35 seconds, or 1.34x the rated cast time, and right in line with the Reraise results. And tests on Fast Cast gear so far have shown them to be in line with percent reductions off the 100% animation time.

In any case, I wonder if anyone had any thoughts on the issue. Having a permanent -35% Fast Cast on me is rather annoying to consider.

**Slycer** · 2011-10-19 09:09

Great testing you guys are doing, this is kind of a side note but I thought it worth mentioning (may or may not have come up in the past). Few people I was talking to had thought that Addle was a kind of "negative Fast Cast" affecting both casting and recast times. I used Romanus Cape (Addle +6%) with Klimaform (3:00 recast); as a quick test -- it did not impact recast time. Since you can macro swap through another cape and equip Romanus mid-cast, the Addle effect on the casting time can be avoided, although there's still the potential negative impact on magic accuracy, assuming this is still included with the gear effect.

**Mougurijin** · 2011-10-19 09:27

I think what you said matches what is reasonably well known already -- that spells resolve/finish at ~75% on the casting time bar.
100% = ~75% + the remaining ~25% (1/3 of 75)... so... ~75 x ~1.3333
This information is on the "Fast Cast" page on otherwiki already.

Also, as long as you are standing in the exact same spot at 0% and 75%, the spell will complete it's casting.
So between those percent, you can run around as much as you like, as long as you return to the exact same spot.

The cast %, on the cast time bar continues going up until it reaches 75% (or the % for whatever fast cast, etc. you have) even after you move away from your spot.
So you could find out (roughly) the finish cast % for spells like Teleport-whatever just by starting the cast and stepping away, and checking what % it cancels at.

I have an i7 920 overclocked to 3.8 GHz, but I can't yet get my FRAPS up to 29.97 fps, usually it hovers somewhere between 20~25 fps.
Wish I could figure out why.

**Motenten** · 2011-10-19 10:20

Originally Posted by Mougurijin

I think what you said matches what is reasonably well known already -- that spells resolve/finish at ~75% on the casting time bar.
100% = ~75% + the remaining ~25% (1/3 of 75)... so... ~75 x ~1.3333
This information is on the "Fast Cast" page on otherwiki already.

Unfortunately, that brings up other discrepancies in the results. Here's some sample times for the MP deduction frame (frame where MP drops and status icon appears).

Frame MP completion vs 100% frames, 0% FC without Light Arts:
RR1: 280 / 325 = 86.2% == 9.34 s
RR2: 261 / 305 = 85.6% == 8.56 s
RR3: 235 / 284 = 82.7% == 7.84 s

Same, with Light Arts:
RR1: 248 / 325 = 76.3% == 8.27 s
RR2: 234 / 305 = 76.7% == 7.81 s
RR3: 211 / 284 = 74.3% == 7.04 s

Recast plugin timers actually show up a few frames before that, but not enough to make a truly significant change. In order for the actual spell completion time to match the overscale, it would have to occur at 73.8%. Even with Light Arts active, the fastest of the results (RR3) doesn't quite reach that. The values that should be baseline are at least a full 10% above that threshold, generally over a second longer than the rated cast time.

... I could perhaps explain the differences with network delays. The time between the frame where the /ma reraise command is executed and the start of the animation is roughly between 10 and 15 frames with Spellcast turned off. That would be the delay between sending the request to the server and getting the response back to start the spell cast. Since whether or not you complete the spell has to be determined on the server, it stands to reason that the server could determine spell completion and then send the response back to you, at which point the game client completes the MP deduction and applies the icon.

However, that would seem to imply that any such delay be less than about 15 frames (0.5 seconds). I would actually expect half that delay since it's only from server to client, not client to server to client. That still leaves us with at least another half second unaccounted for. But perhaps the full delay is not incorrect considering that the client needs to send the current player position at completion time, as you noted. However network delay should also be pretty much a constant. If it's 30 frames of delay on RR, it should also be 30 frames of delay on, say, Cure V, and that's well outside the bounds of what's actually seen.

Meh. I'll give it more thought later.

**Byrthnoth** · 2012-01-16 19:10

Phaffi wanted to test this tonight.

Setup:
Phaffi - RDM with Rescuer/Matriarch/Ambition
Byrth - First a COR for XI enhanced Caster's Roll, then a BRD for double soul voiced marches/Haste.

Fast Cast: (40%)
Trait - 30%
Atma - 20%
Caster's Roll - 30%
Total :: 80%

Haste: (68.3%)
Gear - 25 (26% = Dusk +1, V.belt, Nashira legs/feet, Goliard body, Zelus Tiara, Sentinel's Shield)
Magic - 43.3% Haste + double capped potency G-horn/AF3+2 hands Marches, V.march had Marcato (overkill capped).

60*.6*.317 = 11.4 seconds (I don't know how the rounding works, or should know and have forgotten.)
Reraise recast from the menu: 11 seconds (and apparently it quickly ticked down to 10).

So we're looking at greater than 80% recast reduction. There is effectively no cap, and if one exists people would have to use magian recast -% staves and stuff to find it. The most important part is that in any realistic circumstance, you will never hit the recast reduction cap.

**Mougurijin** · 2012-01-16 19:29

Wow, 11 seconds O.o

I don't think I even knew they had lifted the old -50% recast time cap.
I'm pretty certain you calculate with Haste before Fast Cast, but the answer is 11.4 anyway. Nice.

**Byrthnoth** · 2012-01-16 19:35

Not to get in to the rounding thing too much, because it's hard to prove anything, but (I think) the game stores recast times as a 10 bit number, with two of the bits coding either +.00 seconds, +.25 seconds, +.50 seconds, or +.75 seconds. So I would assume it might round it to a 10 bit number with a maximum decimal resolution of .25.

In this cast it comes out to 11.25 seconds regardless of which order you do it in, which is pretty consistent with Phaffi's observation that it ticks down quickly.

**dasva** · 2012-01-16 20:03

Is it possible that going past 80 fast cast it still adds to -recast but not to -cast?

**Mougurijin** · 2012-01-16 21:15

Originally Posted by Byrthnoth

Not to get in to the rounding thing too much, because it's hard to prove anything, but (I think) the game stores recast times as a 10 bit number, with two of the bits coding either +.00 seconds, +.25 seconds, +.50 seconds, or +.75 seconds. So I would assume it might round it to a 10 bit number with a maximum decimal resolution of .25.

That's a nice idea, which does happen to work with the first example in my post at the top of this page, but it doesn't work for the other example in the same post, whether you decide to calculate haste or fast cast first.

Reraise (60 secs)
Haste = -30/1024 (Headlong Belt)
Fast Cast = -19% cast, -9% recast -- (/RDM43, Loquacious Earring, Incantor Stone)
Ingame menu recast timer = 53 seconds.

Originally Posted by Byrthnoth

In this cast it comes out to 11.25 seconds regardless of which order you do it in, which is pretty consistent with Phaffi's observation that it ticks down quickly.

I always used to think the first second sometimes counts down quickly, especially after I started looking for it happening back when I was testing recast timers.

Here's my view on why that may not make much sense:

Reraise recast is 60 seconds, the menu timer shows "1:00" for a whole second, so "1:00" until it reaches 59.0000 seconds left, then it stays "0:59" for a whole second until it hits 58.0000 seconds, etc...
Now if 11.4 (or 11.412, or 11.25) is ticking down to 10 very quickly (if by quick you mean less than a second), then it doesn't really make a lot of sense...

A spell with a recast of 12 seconds starts at "0:12" and stays that for a whole second, past 11.4, past 11.25, till it reaches 11.0 seconds...
A spell with a recast of 11 seconds starts at "0:11"...

Seeing 11.4 tick down quickly might be meaningful if the timer showed "0:12" at the start for 0.4 or 0.25 of a second, then ticked down to "0:11"...
However, as the menu shows "0:11" as the recast time for an 11.4 second recast, it seems either the recast is simply truncated to 11 seconds or "0:11" should be displayed for 1.4 seconds...

Edit:
I have just done a few quick tests to verify my old results, and also to see what happens if I swap Reraise for Klimaform...

Code:

Recast Timers...

=== WHM90 ===
spell = Reraise [240 = 60.00 seconds] (tiers I, II & III)

waist = Headlong Belt (Haste: -30/1024)

sj    = /RDM45 (FC: -7% recast)
ammo  = Incantor Stone (FC: -1% recast)
ear   = Loquacious Earring (FC: -1% recast)

1:00
0:55	sj
0:55	sj + ammo
0:55	sj + ear
0:54	sj + ammo + ear
0:54	sj + waist
0:53	sj + waist + ammo
0:53	sj + waist + ear
0:53	sj + waist + ammo + ear


=== SCH86 ===
spell = Klimaform [720 = 180.00 seconds]

waist = Headlong Belt (Haste: -30/1024)

sj    = /RDM43 (FC: -7% recast)
ammo  = Incantor Stone (FC: -1% recast)
ear   = Loquacious Earring (FC: -1% recast)

3:00
2:47	sj
2:45	sj + ammo
2:45	sj + ear
2:43	sj + ammo + ear
2:42	sj + waist
2:40	sj + waist + ammo
2:40	sj + waist + ear
2:39	sj + waist + ammo + ear


=== Headlong Belt ===
BLM99/SCH49, wearing only Headlong Belt, no buffs.
spell = Tornado [169 = 42.25 seconds]

"0:41"	ingame menu recast timer

41.012	-30/1024
40.982	-3%	(around -30.72/1024)
40.970	-31/1024

---

spell = Thundaga III [136 = 34.00 seconds]

"0:33"	ingame menu recast timer

33.003	-30/1024
32.98	-3%	(around -30.72/1024)
32.907	-31/1024

---

spell = Burst [173 = 43.25 seconds]

"0:41"	ingame menu recast timer

42.025	-29/1024
41.982	-30/1024

**Mougurijin** · 2012-01-17 09:45

I was expecting Klimaform with 19% FC & -30/1024 Haste to have a recast of 2:38...
However, in my post above, the Klimaform test "sj + waist + ammo + ear" gave me a recast of 2:39 !

So this means my formula isn't completely accurate still, even though I had previously thought that it was very unlikely that the formula could be anything else and still work for both my two examples in my post at the top of this page.

The recast of 2:39 seems to imply that the spell base recast + haste is stored in at least a 15 bit value, rather than what I previously thought which was 13 bit...
Either that or it is 13 bits rounded up... or something more weird like the haste recast reduction amount is done separately, truncated, then subtracted from the base recast...

Code:

180 = 8 bits (128 + 32 + 16 + 8 + 4 + 2)
180 * (1 - 30/1024) = 174.7265625

8 bit would be 174, to add more bit accuracy, double the value for each extra bit...
174.7265625 * 2 ^ [number of extra bits]

9 bit	349.453125
10 bit	698.90625
11 bit	1397.8125
12 bit	2795.625
13 bit	5591.25
14 bit	11182.5
15 bit	22365

I'm rushing this a bit as I'm about to log off, hopefully that made some sense...
Basically, 15 bits gives the full accuracy for this value as there is no truncation... however you can't just never truncate recast after haste as it won't work for "Example #1" in my post at the top of this page...

**Motenten** · 2012-01-18 12:13

Code:

=== SCH86 ===
spell = Klimaform [720 = 180.00 seconds]

waist = Headlong Belt (Haste: -30/1024)

sj    = /RDM43 (FC: -7% recast)
ammo  = Incantor Stone (FC: -1% recast)
ear   = Loquacious Earring (FC: -1% recast)

3:00
2:47	sj
2:45	sj + ammo
2:45	sj + ear
2:43	sj + ammo + ear
2:42	sj + waist
2:40	sj + waist + ammo
2:40	sj + waist + ear
2:39	sj + waist + ammo + ear

First, determine Fast Cast values since we can assume they add together without issue. (If they've been completely pinned down elsewhere, correct this part.)

sj: 2:47 (167 seconds) means FC trait has to have between 69/1024 and 73/1024 recast reduction
sj + ammo @ 165 means between 80/1024 and 85/1024.
sj + ear @ 165 means between 80/1024 and 85/1024.
sj + ammo + ear @ 163 means between 92/1024 and 96/1024.

The minimum with ammo+ear means either the base trait is 72/1024 and ammo/ear are 10/1024 each, or base trait is 70/1024 and ammo/ear are 11/1024 each. It's also possible that Loquacious is 10 and the Incantor Stone is 11 (along with a trait of 71), since Loquacious is from the CoP era, whereas they seemed to revise a lot of the haste values for the Abyssea era to be more exact (51/1024 for 5% haste), rather than neat (50/1024 for 5% haste).

Using a total of 92/1024 Fast Cast for sj+ammo+ear.

If we assume that Fast Cast is applied first, recast after FC would be 163.828125 (163 + 848/1024).

Now adding in the belt. Mougu's shown that the belt is 30/1024. Turban is known to be 50/1024. Goading Belt is 51/1024, I believe, but doesn't make a difference here.

sj+ammo+ear +...
Headlong: 2:39 (159)
Turban: 2:35 (155)
Turban+Headlong: 2:31 (151)
Turban+Goading: 2:27 (147)

Straight multiply:
+Headlong = 159.0284729004
+Turban = 155.828704834
+Turban+Headlong = 151.0290527344
+Turban+Goading = 147.6692962646

163.828125 is 163 + 848/1024, which can be reduced to 163 + 53/64, so could be stored in as little as 6 fractional bits.

If reduced to 5 fractional bits (26/32, which could also be 4 bits of 13/16), the Headlong and Turban+Headlong results are still valid (159.0133056641 and 151.0146484375, respectively).

Therefore it can still be stored in 12-13 total bits and get the results we see.

Doing it in reverse order (haste, then fast cast), and truncating the haste result to 5 fractional bits still gives valid results as well.

**Byrthnoth** · 2012-01-19 06:43

Turns out the person was not capped for gear Haste (didn't have Dusk +1 on) and was going by the recast plugin instead of the menu timer. So disregard that last post! We will try to repeat the test at some point in the near future.

**Mougurijin** · 2012-01-19 09:20

I was pretty sure I'd posted my own tests of Fast Cast being n/100 instead of n/1024.

However, just the simple fact that equipping one Fast Cast piece with an odd number like 5 % truncates the recast reduction to the nearest whole number, -2% recast in this case... but equipping two 5% pieces (10% FC) gives you -5% recast...
I think that should be enough evidence on it's own really.

Here's some background information threads:

Kirschy's old threads about a n/1024 system for haste and fast cast...
http://www.bluegartr.com/forum/showthread.php?t=52417
http://www.bluegartr.com/forum/showthread.php?t=61643

More recent posts, by Byrth and Mojo, showing n/100 system for fast cast...
http://www.bluegartr.com/threads/103...=1#post4650526

I'm sure I didn't just accept this information and that I did my own tests, but I guess I didn't post anything because I thought it had already been said...
I'll try and find my old tests confirming the n/100 model for fast cast.

- Update -
The test server is so much easier to test fast cast and recast timers on, there's so many situations you can test.
Here's a good easy one that proves n/100 for fast cast.

Code:

=== BLU72 "Fast Cast 0" trait -- 5% FC (recast = -2%) ===
BLU99/BLM49, no gear, only four spells set:

"Bad Breath" and "Sub-zero Smash" -- for the so called "Fast Cast 0" trait (which is something I wanted to test anyway).
"Bomb Toss"  and "Goblin Rush" -- two spells with useful base recast times for this test.

---

Bomb Toss -- recast is 98 = 24.5 seconds

"0:24"	Ingame menu recast timer

24.021	-20/1024
24.01	-2%	(around -20.48/1024)
23.997	-21/1024

---

Goblin Rush -- recast is 102 = 25.5 seconds

"0:24"	Ingame menu recast timer

25.001	-20/1024
24.99	-2%	(around -20.48/1024)
24.977	-21/1024

Only -2% recast works for both, can't be either -20/1024 or -21/1024...

**Motenten** · 2012-01-19 22:04

Personal validation of various things to make sure I'm caught up...

Walahra Turban:
Aero III (25.25) -- 24 s
Must be 50/1024 (not 50/1000, not 51/1024)

Goading Belt:
Aero III (25.25) -- 23 s
Must be 51/1024 (not 50/1024)

Loq. Earring:
Aero III (25.25) -- 24 s
Cannot be 10/1024, may be 10/1000
Aeroja (47.50) -- 47 s
Cannot be 11/1024, must be 10/1000

Rdm FC2
w/Goading Belt (51/1024)
Klimaform (180.00) -- 159
Cannot be 71/1000, may be 70/1000
w/Swift Belt (40/10240)
Klimaform (180.00) -- 160
Cannot be 70/1024, must be 70/1000

Assuming fast cast portion of recast must be /1000 units

Incantor
w/Swift Belt and /rdm
Klimaform (180.00) -- 159
Must be 80/1000; subtract /rdm leaves 10/1000.

Loq+Incantor+/Rdm, 0% haste:
Cure II (5.50) -- 5
Confirmed no more than 90/1000 FC (91/1000 would be a 4 s recast)

Using 30/1024 for Headlong belt confirmed by Mougu

Checking a few borderline cases

Curaga IV
Loq+Incantor+/Rdm, Turban+Headlong (80/1024) should be 9
Confirmed

Cure II
Loq+Incantor+/Rdm, Turban+Goading+Blessed hands/legs/feet (201/1024) should be 4
Confirmed

Cure V
Loq+Incantor+/Rdm, Turban+Blessed hands+Headlong (130/1024) should be 7
Confirmed

Checking resolution of FC result (FC applied first):

Klimaform
Loq+Incantor+/Rdm, Headlong (30/1024)
158 @ 5 bit, 159 @ infinite
-- 159

159 reached at 9 bits of resolution

Loq+Incantor+/Rdm, Turban+Headlong (80/1024)
150 @ 5 bit, 151 @ infinite
-- 151

151 reached at 6 bits of resolution

Setting limit at 9 bits

Loq+Incantor+/Rdm, Turban+Blessed hands/legs/feet, Headlong (180/1024)
Cure IV
5 @ 9 bit, 6 @ infinite
-- 5
Regen II
11 @ 9 bit, 12 @ infinite
-- 11

Can't find any evidence of needing more than 9 bits.

Lots of checking and cross checking. Came down to two conditions:

If FC is calculated first, followed by haste, FC needs to have 9 bits of fractional resolution.
If haste is calculated first, followed by FC, haste needs to have 7 bits of fractional resolution.

Basically, 15 bits gives the full accuracy for this value as there is no truncation... however you can't just never truncate recast after haste as it won't work for "Example #1" in my post at the top of this page...

Actually, Example #1 still works if you have 7 fractional bits for haste (15 total bits if split as 8 integer + 7 fractional), assuming haste is calculated first, as that still gives you a 20 second recast. You need 8 fractional bits before recast goes up to 21 seconds.

Note that 9 bits on FC if calculating FC first also works for Example #1; 10 bits would be too many.

Also, I can't find any thresholds that would identify the bit depth of fast cast (giving more thought, it may not even be possible). Checked fast cast recast from 1% to 25% with tons of different haste values, nothing shows up. Might have just missed something, but ultimately probably doesn't matter; can just use the same 7 bits as haste.

**Mougurijin** · 2012-01-20 00:03

I like the way you approach your tests Montenten.

Limited fractional bits as opposed to just limited bits for the entire recast value...
I think originally I ruled that idea out as being too unlikely, but I don't know if that was actually true or not.
I don't really know a lot about this kinda stuff anyway, so I probably shouldn't have made such assumptions.

I'm pretty confident that I had enough evidence to show Haste applied before Fast Cast, although I'm not sure where or if I posted any of it.
I'll try to produce another test that won't rely on bit resolution too much again, showing which way round Haste and Fast Cast are calculated.

You seem to have approached this topic the same way I did.

First I made a spreadsheet to locate interesting spell + FC or Haste combinations.
This spreadsheet makes it very easy and quick to narrow down exact n/100 and n/1024 values for each Fast Cast or Haste gear/trait/etc.

The columns labelled: =1/1024, =2/1024, =3/1024, =4/1024, =5/1024, =5/100, =6/1024, etc. -- up to 50/100
The rows labelled: 5, 5.25, 5.5, 5.75, 6, etc. -- for spell base recasts, typing in names of spells for each, if I knew of one.
The cell formulas = [row label] * (1 - [column label]) -- formatted to show as many decimal places as possible, and conditional formatting highlighting each integer change in a bright colour.

Then I made a second spreadsheet to test bit resolution after haste was applied, before fast cast.
I made this spreadsheet in a similar way to the first, automatically highlighting at which bit depths the final recast values would be different.
Then I tried to find tests which could further narrow down the possible bit resolutions.

Before I made the second spreadsheet I had already come to the conclusion that haste was calculated before fast cast...
With the second spreadsheet I then tested and found conflicting cases where no possible bit resolution after haste was possible, but I could see a pattern between lower and higher value recasts...
Then I read up on floating point data types, decided it answered my problem...
Finally I posted my 13 bit resolution after haste theory (13 bits for the full value), with haste applied before fast cast...

So if my memory is correct, I found Haste applied before Fast Cast, and also found limited fraction bits not possible...
One of these must have been incorrect though now, but my old test data is very hard to make any sense of now, and my memory is pretty bad... :/

- Update -
I managed to figure out some of my old data...

Haste = -29/1024, Fast Cast = 30% (recast -15%), Water II base recast = 63 (15.75 seconds)...
The ingame menu recast timer = "0:12"
...although I don't even remember how I actually achieved -29/1024 haste on RDM89+...

My spreadsheet says it had to be 3 fractional bits or less:
The hasted recast value before fast cast was determined to be stored with 3 fractional bits at the most: 61 [111101] + 1/8 [001]...
An extra bit of accuracy would give 61 [111101] + 3/16 [0011], which would lead to a "0:13" recast after fast cast.

The game stores the base recasts in 10-bits, with the last two bits used to represent fractions of a second: .0, .25, .5 or .75
Water II = 63 in resources (63 / 2 ^ 2 = 15.75 seconds)

My spreadsheet was using the resources value of 63 instead of the 15.75 seconds value.

You can view it as either 61 + 1/8 (3 fractional bits), or 15 + 9/32 (5 fractional bits)...
Both these values in binary = 1111101001
61 + 1/8 would be split up as: 111101 | 001
15 + 9/32 would be split up as: 1111 | 01001

So for that test, hasted recast needed to have less than 7 fractional bits, but it depends if I tested that recast correctly as I still don't know what the -29/1024 item was yet...
... and also depends if haste is definitely applied before fast cast I guess...
Another weird thing is that it disproves my previous theory which would also have given a recast timer of "0:13"

Thread: Cast and Recast

Thread Tools

Latest Threads

Up & Coming Threads

Hottest Threads