Fast Cast Testing

[Byrthnoth]

None, Weakened Reraise with 25% Haste has a recast of 105 seconds. That's how I know that Weakness is 100% Slow.

60*1.75 = 105 <-- It's this
60*2*.75 = 90 <-- Not this

My mule actually had 29% Haste for those tests, but it all counted as gear Haste because it was Gear/Atma. I did the control and saw 105 as predicted.

[Mojo]

A very simple test using Loquacious Earring and Utsusemi: Ni showed that Haste goes before Fast Cast (the resulting recast is 38 seconds.)

If Fast Cast were first.

45 * .99 = 44.55 => 44.5
44.5 * (1-150/1024) = 37.98 => 37

If Haste is first

45 * (1 - 150/1024) = 38.4082... => 38.4
38.4 * .99 => 38.016 => 38

I'll try and test with some other spells.

[Mojo]

Stonega III (27.25 second recast) observed recast was 23 seconds with Loq Earring and 150/1024 haste. The predicted recast with this would be 22 seconds regardless of which way you took. I think the reason for this discrepancy is because these numbers are really binary calculations and the binary decimal is being truncated. This would make sense as the cap for recast appears to be 255 seconds while the highest precision recast times have is .25 seconds. 256 * 4 => 1024. The reason 255 is the cap is because 256 cannot be expressed in binary without increasing the bit level from 10 to 11. Fast Cast is a bit wacked out because of the way I think it's implemented. Any odd values of Fast Cast would result in a binary decimal when it's divided to determine recast and since the entire thing gets truncated when you've got odd values of Fast Cast, I think the game stores Fast Cast values as whole numbers and goes by the recast. It gets divided by 2 (10 in binary). 1% Fast Cast, for instance, is (01/10) = (0.1), which gets truncated to zero, or say 11% Fast Cast (1011/10) = (101.1) => (101), which is 5 in decimals.

Most importantly is the way it's applied to Haste. Stonega III has a recast time of 109/1024. 109 is 1101101 in binary. The amount of haste I had was 150/1024, 1024-150 = 874, which is 1101101010 in binary. The recast (before fast cast is applied) is [(1101101*1101101010)/1000000000] = [10111010000100010/10000000000] = [1011101.000010001] = [1011101], this is 93/1024 or 23.25 seconds. Fast Cast is then applied. [(1011101 * 1100011)/1100100] = [10001111110111/1100100] = [1011100.000100011110101110000101000111101011100001 01] = [1011100] = 92/1024 = 23 seconds, so it's consistent with what I got.

[Mojo]

So I went through that Utsusemi test and I could not get it to work with any kind of truncation in binary without having at least an 11 bit number . I tried Dread Spikes just now using Loq Earring and Hasso and again using Goading Belt and Hasso. The results from both were still capped (255 second) recast time. This means that, if the recast time is stored in binary (likely), the number carried over between Fast Cast and Haste calculations are at least 11 bits (required for storing a recast time greater than 255 seconds.) Given that I couldn't ever get the binary thing to work without an 11 bit number that had a binary decimal, I'm somewhat skeptical of any sort of truncation occurring between Fast Cast and Haste other than the initial truncation of Fast Cast itself. So the final formula would just be this.

r = [(1-[F/2]/100)(1-H/1024)(R)]

With the final truncation being capped at 1111111111 or 255. It works for all of my results so far.

[Mojo]

Also, if you've got a BRD Byrn would you mind going through some march tiers and seeing if it breaks the above formula? I don't have BRD.

Creed Armet +2 is 5%(2.5%) Fast Cast. Recast on Reprisal was 2:56, 2:54 after adding Vivid Strap. That's all of the gear I have access to for testing.

[Byrthnoth]

Masamune actually came to a similar conclusion about pDIF, I think. He sees no evidence that the values are floored at all (except Piercing Bonus). I have two bards (main and alt), but they both have combined skill over 600 naked. I guess I could not use an instrument?

Maybe SE has no problem with floating point operations server-side, but limited variable size that it sends back and forth to the client? Kind of makes sense.

[Mojo]

Yes that would make sense, although now I'm left wondering if cast/recast times are even calculated server side.

[Byrthnoth]

If they aren't . . . adding "Occasionally Quickens" to the game is kind of a huge liability as far as exploiting goes. If they can't detect when people Flee for 10 minutes in a row, I doubt they can detect if someone is forcing every one of their spells to quicken.

[shaddix]

Yes that would make sense, although now I'm left wondering if cast/recast times are even calculated server side.

If you're still wondering this, here is some more food for thought. I think maybe Yugl posted this somewhere if I PM'd it to him.
You can take two characters, one with 40% FC and one with 42% FC and have them cast cure simultaneously on a common target that's missing a few HP. Their cure animation will be identical(down to the frame) in time taken, however the one with 42% fastcast will heal the missing HP 90% of the time and the one with 40% fastcast will cure for zero 90% of the time. The other 10% occurs due to internets lag etc.

Also I think it was 40% and 42%, not sure. Maybe it was 45% and 47%... I did it a long time ago.