Item Search
     
BG-Wiki Search
+ Reply to Thread
Page 3 of 12 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 231

Thread: Cast and Recast     submit to reddit submit to twitter

  1. #41
    Sea Torques
    Join Date
    Jul 2009
    Posts
    679
    BG Level
    5
    FFXI Server
    Leviathan

    Quote Originally Posted by Mougurijin View Post
    I have a macc Vayu's staff +2 with wind affinity: recast time -12%.
    The reason Cymmina only observed a -5% recast reduction from the Yama's +2 staff was because the "Recast time -12%" is added directly to Fast Cast!

    Eg: my RDM90/BLU45
    Fast Cast V trait (FC-30% = FC Cast time -30%, FC Recast time -15%)
    + Vayu's Staff +2 (Wind Affinity: Recast time -12%)
    (Wind spells) = FC Cast time -30%, FC Recast time -27%
    (Earth spells) = FC Cast time -30%, FC Recast time -3%
    I didn't have any fast cast on when I had the 5% result with Yama's, as I was SCH/BLM or SCH/SAM for all of my tests. I think it was just a clerical error.

    The affinity: recast working on physical spells is interesting, though.

  2. #42
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    Quote Originally Posted by Cymmina View Post
    I didn't have any fast cast on when I had the 5% result with Yama's, as I was SCH/BLM or SCH/SAM for all of my tests. I think it was just a clerical error.
    That's what I meant. If you were only using just Fast Cast to reduce your spell recasts, you would have recieved the entire 12%, as it is added directly to Fast Cast.
    Because you used arts and strategems, the -12% would be deducted after (or before or w/e) the other deductions, so 12% wouldn't reduce the timer by as much.

    Composure + Gravity Tests:
    Code:
    Composure(*1.25) + Gravity [60s] = 75s
    
    63s = RDM90/SCH45(*0.85)
    54s = + Vayu's Staff +2(*0.88)
    *0.85*0.88 = 56.1 -- doing -15%, then -12% (-25.2%) doesn't work.
    *0.73 = 54.75 -- combining -15% and -12% to make -27% works.
    
    57s = RDM90/SCH45(*0.85) + Dark Arts(*0.9)
    49s = + Vayu's Staff +2(*0.88)
    *0.9*0.85*0.88 = 50.49 -- all 3 separate (-32.68%) doesn't work.
    *0.9*0.73 = 49.28 -- FC combined with staff (-34.3%) works.
    *0.78*0.85 = 49.73 -- SCH Arts combined with staff (-33.7%) works this time...
    
    76s = RDM90/SCH45(*0.85) + Light Arts(*1.2)
    65s = + Vayu's Staff +2(*0.88)
    *1.2*0.85*0.88 = 67.32 -- all 3 separate (-10.24%) doesn't work.
    *1.2*0.73 = 65.7 -- FC combined with staff (-12.4%) works.
    *1.08*0.85 = 68.85 -- SCH Arts combined with staff (-8.2%), this time it doesn't work.
    
    54s = RDM90(*0.85) + "Haste" spell (*1-[150/1024])
    46s = + Vayu's Staff +2(*0.88)
    *(1-(150/1024))*0.85*0.88 = 47.88 -- FC and staff deducted separately doesn't work.
    *(1-(150/1024))*0.73 = 46.72 -- FC and staff deducted together works.
    Edit:
    Hmm. I found some more interesting /BLU spells which behave odd like Grand Slam did... This time without casting Haste or equiping any additional gear other than my Vayu's Staff +2 (wind affinity recast-12%).

    RDM90/BLU45 (naked, no haste, nada.)

    Bludgeon [11.75s] = 9s (9.9875)... + staff = 10s
    Screwdriver [14s] = 11s (11.9)... + staff = 12s
    Terror Touch [21s] = 17s (17.85)... + staff = 18s

    Now Grand Slam could be justified as having something to do with Earth element, therefore having it's recast penalised by the wind affinity staff... I'm not even going to suggest those three physical blue magic spells are linked to Earth element though. :/
    The recast of every other /blu physical spell I have wasn't affected by equiping the staff, though these three spells have a higher fraction after the decimal point than any of those other spells.
    The spell with the next highest fraction is Claw Cyclone [19.75s] = 16s (16.7875), which stays at 16s when I equip the staff.

    Edit:
    OK, so I thought maybe this weirdness might happen if I used a different staff such as my Teiwaz with "Earth Affinity: +1" or my Varuna's staff +2 (Ice dmg, Cast time -12%), but none of those staves had any effect of the recasts on the physical BLU spells above.
    Then I thought, maybe any non-wind/earth spell which after applying RDM90's "Fast Cast V" results in a recast ending with .85~.99 fraction, might get rounded up after equiping my Vayu's staff +2 (Wind Affinity: Recast-12%).

    Bomb Toss (fire element) [24.5s] = 20s (20.825)... + staff = 20s
    Thunder III [29.25s] = 24s (24.8625)... + staff = 24
    Thunder II [21s], the same recast as Terror Touch above = 17s (17.85)... + staff = 17s

    So it seems likely that it's just a wierd bug that is only affecting certain categories of spells. So far only known to affect /BLU physical spells.

  3. #43
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    OK, new post as this is a different subject to my previous post.

    Assuming:
    Haste is calculated before Fast Cast
    Haste = 1 - HasteFractionNumerator / 1024
    Fast Cast = 1 - (FC >> 1) / 100

    Spell Base Recast = 10 bit value (0~1023 --- 0=0s ... 1=0.25s ... 1023=255.75s?)
    Haste to be applied to recast = 10 bit value (0~1023 --- 0=0/1024 [recast*1024/1024] ... 1=1/1024 [recast*1023/1024] ... 1023=1023/1024 [recast*1/1024])
    - Can haste alone lower recast to 50%?
    - Would more than 512/1024 haste reduce recast below 50% before being adjusted by recast cap?
    Fast Cast recast value to be applied to hasted recast = 7 bit value (0~127? --- 0=0/100 [hasted recast*100/100] ... 15=15/100 [hasted recast*85/100] ...)
    - Cap used to be 50% FC (25% recast), now cap is 80% FC? (40% recast?)

    "A >> B" = The value of "A" bit-shifted right by "B" number of bits.
    Equal to: Floor(A/2^B).

    "A << B" = A bit-shifted left by B.
    Equal to: A*2^B

    Here's the formula I'm working with now for: Spell base recast -> Hasted recast -> FC (& Affinity Recast staff) applied recast...
    Code:
    A: Spell base recast value: 10 bits
    B: Haste /1024 fraction numerator value: 10 bits
    C: Number of binary fraction bits to truncate to, to be carried to fast cast.... works like flooring to nearest 1/(2^C)
    D = Hasted recast value: (10 + C) bits
    E: Fast Cast /100 fraction numerator value: 8 bits
    F = Fast Cast recast /100 fraction numerator value: 7 bits
    G: Magic Elemental Affinity: Recast-% /100 fraction numerator value: 4 bits (at least)
    H = Fast Cast applied recast value: 10 bits?
    Z = In-game recast timer (in seconds)
    
    D = A * (1 << (10 + C) - B) >> (10 + C)
    F = E >> 1
    H = D * (100 - F - G) / 100
    Z = H >> 2
    The value for "C", the "amount of truncation after haste", is what I'm trying to figure out at the moment.

    "C" is a variable I added, which chooses how many extra bits to increase the size of the value to, to represent with enough accuracy the result after applying haste, before fast cast will be applied.
    If "C" is not set high enough, the formula can give a lower answer than in-game, which means "C" needs to be increased to carry the whole fraction of the result after haste.

    Hopefully it should be possible to find out for 100% certainty how high "C" should always be; how many bits the value is carried in from haste to fast cast.

    Sorry, this post ended up pretty messy, and I don't think I explained everything properly.
    I probably used a load of wrong terms, as I haven't taken maths at college or anything like that.
    I was struggling to explain it in a simple, logical way that would make sense, but kind of gave up and just spammed a load of stuff instead. :P

    Edit:
    Oops, I meant to put a couple of examples in:
    RDM90 (30% FC) + Dusk Gloves (30/1024 haste)

    Sandspin [9.75s] = 8s ... C:0 = 7s, C:1 = 7s, C:2 = 8s
    Bind [40s] = 33s ... C:0 = 32s, C:1 = 32s, C:2 = 32s, C:3 = 32s, C4 = 33s

    So if "C" needs to be set to "4" to get the correct answer, the size of the value holding recast after applying haste is 14 bits, or larger?
    That's if the formula is correct anyway, and if haste definitely comes before fast cast?

    Edit:
    I've made a spreadsheet to test this formula, and adjusted my main spreadsheet to highlight interesting spell/job/gear combinations.
    Here's one which would be cool to test:

    Composure + Jet Stream = 28.75s
    FC recast-14% & Haste:30/1024 + Composure + Jet Stream ... C:0~C:7 = 23s ... C:8 = 24s

    Should prove if the recast value after applying haste is either: 18+ bits, or less than 18 bits... or maybe just disprove the formula I'm using.

    RDM76~88/BLU38 (FC recast-12.5%) + Loq. Earring (FC recast-1%) + Vivid Strap ? (FC recast-0.5%) = FC recast-14% !
    Could equip Dusk Gloves or something and test that, but I don't have a Vivid Strap or any other way to hit FC recast-14% ; ;

    Edit:
    Here's an interesting one, not that I trust Grand Slam anymore...

    RDM90/BLU45 - naked, other than: AF1+1 head + AF2+1 body + Loq. Earring = (FC recast-26%)
    & "Haste" spell (Haste:150/1024)

    FC recast-26% + Haste:150/1024 + Grand Slam [14.25s] = 8s ... C:0~C:8 = 8s ... C:9 = 9s

    So if all my information is correct so far, the size of the recast value after applying haste is somewhere between 14 to 18 bits long. (C:4~C:8)

    Edit:
    RDM90/BLU45 - naked, other than: AF1+1 head + AF2+1 body + Loq. Earring = (FC recast-26%) & "Haste" spell (Haste:150/1024)
    FC recast-26% + Haste:150/1024 + Aero IV [33.25] = 20s ... C:0~C:5 = 20s ... C:6 = 21s

    So that should narrow it down to between 14 and 15 bits (C:4~C:5)... but...

    RDM90/BLU45 - naked, other than: AF1+1 head + AF2+1 body = (FC recast-25%) & "Haste" spell (Haste:150/1024)
    FC recast-25% + Haste:150/1024 + Composure + Cure [1.25*5=6.25s] = 4s... C:0~C:6 = 3s... C:7 = 4s

    Bah! So... not really sure how to interpret that...
    I've either likely got something wrong in my formula, or I guess there's a slim chance that the the problem is just because I used Composure in that last test, which could mean I've discovered something interesting.
    Either way, I'm off for a couple of weeks now so I won't have an answer any time soon. Hopefully someone else gets interested in this, but probably not. :D

    Edit:
    OK. One last post before I stop... (man, I'm such a nerd) ^_^;

    RDM90/BLM45 - naked, other than: AF1+1 head + AF2+1 body + Loq. Earring = (FC recast-26%) & "Haste" spell (Haste:150/1024)
    FC recast-26% + Haste:150/1024 + Stonega II [19s] = 11s ... C:0~C:6 = 11s ... C:7 = 12s

    Well, that test was very similar to the previous test, Composure+Cure, which gave unhelpful results, but this one doesn't use composure and instead gives the expected results.
    The numbers in the calculation were similar to the Composure+Cure test too, so more testing with Composure is probably needed.
    So, it looks like either 14 or 15 bits (C:4~C:5) is probably the correct value size.

  4. #44
    Groinlonger
    Join Date
    Oct 2006
    Posts
    2,964
    BG Level
    7
    FFXI Server
    Fenrir

    Mou~

    I tried figuring this[the number of decimals being truncated] but eventually gave up for a few reasons. I tried various approaches like doing everything in binary and truncating decimals and it still wouldn't really work quite right unless I simply stopped truncating decimals. I honestly think that it's just a floating point calculation according to some IEEE 754 format (based on the server hardware and the bit depth they specified.) The issue with this is that there is error due to both truncation and finite number space. Computers can only represent a finite amount of floating point numbers given a certain bit range. If you're really that interested in figuring out the exact method of calculation between Haste and Fast Cast (in addition to the n/1024 and n/100 systems that seem to work for Haste and Fast Cast, respectively) then I recommend considering this.

    http://en.wikipedia.org/wiki/IEEE_754-2008

  5. #45
    Relic Weapons
    Join Date
    Apr 2007
    Posts
    348
    BG Level
    4
    FFXI Server
    Ragnarok

    Floating point operations tend to be less accurate the further amount of digits you use. In the unreal engine for network replication for example they automatically truncate past the 3rd decimal which makes a lot of things more complicated than they should be {compress into integers to replicate properly, decompress to extract the float(s)}

  6. #46
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    Well, I still haven't given up on this completely, but it seems like it's getting too complicated for me to get anywhere at all now.

    If you don't truncate at all, you definitely get wrong answers some of the time, so that doesn't seem to be an option.
    Simply casting Aero IV as RDM90 while under effect of "Haste", and wearing just AF1 hat, AF2 body, AF3 earring - and the recast timer in-game will be 1 second lower than the answer you would get on a calculator.

    Quote Originally Posted by Mojo View Post
    ... I recommend considering this...

    en.wikipedia.org/wiki/IEEE_754-2008
    I read that page and other related pages... I think I'll need to reread it several more times before I understand it clearly though. :/

    Quote Originally Posted by Casey_ View Post
    In the unreal engine for network replication for example they automatically truncate past the 3rd decimal which makes a lot of things more complicated than they should be {compress into integers to replicate properly, decompress to extract the float(s)}
    This sounds interesting, although I assume it probably doesn't relate to FFXI? but I'm looking to see if something along this line might solve the problems I'm having.

    - Update -
    I haven't spent much more time on this, but so far it seems like the recast after applying haste is stored as a floating point that has a significand precision of no more and no less than 13 bits.

    Code:
    Aero IV -- RDM90 + "Haste", wearing only AF1 head, AF2 body & AF3 earring
    In-game menu recast timer = 20s
    
    33.25s * (1-150/1024) * (1-floor(52/2)/100)
    8 ~ 13 bit significand precision = 20s
    14+ bit signicand precision = 21s
    Code:
    Reraise -- WHM86/RDM43, wearing only Headlong Belt (I tested Haste+3% on this to be 30/1024), Loq. earring & Incantor stone
    In-game menu recast timer = 53s
    
    60s * (1-30/1024) * (1-floor(19/2)/100)
    8 ~ 12 bit significand precision = 52s
    13+ bit significand precision = 53s
    These are just the two tests I used to narrow the number down. Using a floating point with 13-bit significand precision works for everything I've tried so far.

    This doesn't really seem to match those "IEEE 754-2008" standard formats, but I think it would be possible to cram the value into a 16 bit data type, if the significand is 12 bits with the implied 13th leading bit.
    I think the exponent only needs to be 4 bits, as long as negative (or positive, whichever way round this is) exponents aren't used, and the sign bit obviously isn't needed either.

    - Update -
    Well, I made another spreadsheet with better formulas and stuff, and now I find this 13-bit significand precision floating point idea doesn't actually seem to work... but somehow the old spreadsheet which had messy, crazy badly written formulas does.
    So just want to say what I wrote above probably isn't correct, so don't try and use it, the numbers that worked came from my old spreadsheet which doesn't exactly match my explanation.
    However, maybe by accident my old spreadsheet somehow contains the correct answer.

    - Update -
    Here's the formula I thought worked:
    Code:
    truncate(truncate(recast*2^(13-ceiling(log2(recast*(1-haste/1024))))*(1-haste/1024))/2^(13-ceiling(log2(recast*(1-haste/1024))))*(1-truncate(FC/2)/100))
    truncate = remove fraction leaving just the whole number
    ceiling = round up to next whole number
    log2 = binary logarithm
    recast = either recast in seconds or resources(seconds*4) (eg: Aero IV = 33.25s in-game, or 133 in resources). The outcome is the same, I think.
    haste = total haste from spells, abilities & gear -- the numerator in /1024 format.
    FC = total Fast Cast from traits, gear, etc. -- This is the cast time reduction value (eg: /rdm35 "Fast Cast II" = 15% FC. When 15 is entered, it gets divided by two to give 7.5%, which is then truncated to give the 7% recast reduction.

    However, as I said, that new formula doesn't seem to work.
    Here is my old formula which still works:
    Code:
    truncate(truncate(recast*2^(13-ceiling(log2(recast)))*(1-haste/1024))/2^(13-ceiling(log2(recast)))*(1-truncate(FC/2)/100))
    Basically, instead of doing the binary logarithm on the hasted recast value, I did the binary logarithm on the base recast value.
    The top formula always has a 13-bit significand after haste, whereas this formula drops down to 12-bits in some cases.
    The tests I did, such as Aero IV (33.25s) with 150/1024 haste and 26/100 FC recast, came to the wrong answer in the top formula, but because the bottom formula drops it down to 12-bits on that test, it ends up with the correct answer whilst giving correct answers for the spells that stay 13-bit.

    I don't know if any of that made sense, I don't have enough time to make this post more understandable right now. ^-^;

    - Update, 28th Aug 11 -
    Neither of these formula's are 100% perfect. I originally made a bad choice when choosing how to do this part in both formula's:
    Code:
    2^(13-ceiling(log2(recast)))
    Somehow I hoped it would round up the result with recasts of 2, 4, 8, 16, 32, ... but obviously it doesn't. For these recasts, the formula would have 14 bits of accuracy, instead of 13.
    So here's what I'm changing it to here and in the posts following this:
    Code:
    2^(12-truncate(log2(recast)))
    This is simpler anyway, as "ceiling" is not needed at all now.
    Here's the whole formula:
    Code:
    truncate(truncate(recast*2^(12-truncate(log2(recast)))*(1-haste/1024))/2^(12-truncate(log2(recast)))*(1-truncate(FC/2)/100))

  7. #47
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    Does anyone have any ideas, suggestions, concerns, criticism, etc.?

    It's pretty likely this formula is going to be proved wrong sooner or later, but I'm just wondering how probable this might be: that the recast, before applying haste, is stored as a floating point with 13-bits of precision... then once haste is applied, if the value decreases enough to loose a bit (e.g. spell base recast is 33s, and after applying haste, recast is below 32s, meaning the number is one bit shorter), then the recast carried after applying haste drops to 12-bits of precision?

    I want to simplify the formula, as it has a crazy amount of brackets at the moment, which makes it rather hard to follow...
    Code:
    recast = the spell's base recast, in seconds (.25)
    haste = /1024 numerator
    FC = fast cast, cast time reduction %
    
    
    A = truncate( log2(recast) )    number of stored bits currently used to show base recast.
    B = 12 - A    how much further in bits base recast would need to be shifted to the left, to reach 13 bits.
    C = recast * 2^B    recast, shifted leftwards "B" number of bits, to make it a 13 bit number.
    D = C * ( 1 - haste / 1024 )    shifted recast with haste applied.
    E = truncate( D )    chop off the fraction (if any remains), leaving just the whole number (integer).
    F = E / 2^B    shift the recast again, the same number of bits, but this time shifted rightwards, to give the final hasted recast with it's fraction.
    G = truncate( FC / 2 )    divide FC cast time reduction % by two, then chop off the fraction (if any), to give the recast time reduction %.
    H = F * ( 1 - G / 100 )    apply fast cast to the hasted recast floating point
    
    Final in-game recast time = truncate( H )    <-- this should be the final answer, the same recast time you should get in-game, in seconds.
    Hopefully that was easier to understand, but I'm not sure if it was.
    Oh, and here's the OpenOffice formula for the above:
    Code:
    =TRUNC(TRUNC(A1*2^(12-TRUNC(LOG(A1;2)))*(1-B1/1024))/2^(12-TRUNC(LOG(A1;2)))*(1-TRUNC(C1/2)/100))
    I think it should work pasted in Excel too, idk.
    You just need 4 cells: A1, B1, C1, D1.
    A1 = spell base recast (in seconds [.25])
    B1 = haste (/1024 numerator)
    C1 = fast cast (remember it's casting time reduction %, and not recast reduction %)
    D1 (or anywhere really) = answer, the place you paste this formula into.

  8. #48
    BG Content
    Join Date
    Jul 2007
    Posts
    21,105
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    It seems pretty unlikely to me that anything would be stored in 13 bits, but if the model is more accurate then it's more accurate!

  9. #49
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    I tried to find a reason why it might be 13 bit in a previous post:
    Quote Originally Posted by Mougurijin View Post
    This doesn't really seem to match those "IEEE 754-2008" standard formats, but I think it would be possible to cram the value into a 16 bit data type, if the significand is 12 bits with the implied 13th leading bit.
    I think the exponent only needs to be 4 bits, as long as negative (or positive, whichever way round this is) exponents aren't used, and the sign bit obviously isn't needed either.
    en.wikipedia.org/wiki/Half_precision_floating-point_format

    I didn't really explain it too well, but basically the recast would be stored as a 16 bit floating point value, with 13 bits of precision.
    The recast value is stored in 12 bits, as the extra bit, the leading "1" bit is always known and is not stored, as in IEEE standards.
    The exponent, (how many bits across the recast gets shifted around by) would be stored in the other 4 bits.
    With 4 bits, the exponent can hold the values: 0 ~ 15, although as in IEEE standards, "1111" exponent might be used for errors, but it would still let you shift the value across by 0 ~ 14 bits.
    The "Half" precision floating point format in IEEE standards is broken up into three parts like so:
    0 00000 0000000000

    The first bit is the "sign" bit, for +/- (recast won't be a minus, so this bit doesn't need to be there.)
    The next five bits are the "exponent", but the first bit is used to represent +/- again, so that you can have negative exponents, which hopefully is another bit we don't need, although if slow caps at +100%, you might need -1 ~ 13, which could still be representable.
    The last ten bits are the "significand", where the recast is stored as like 0.xxxx, but because the normalized number always starts with a "1", 1.xxxx, there's an extra bit that isn't stored as it's always a "1".

    So I'm saying it could be in the following format:
    0000 (1)000000000000

    The first 4 bits are the exponent, the amount to shift by.
    The next 12 bits are the significand, the value that gets shifted around, and the "(1)" is the extra bit that's not stored at all, and not shifted around.

    It does still seem kind of far-fetched to me, but as far as I know with my limited programming knowledge, this could be possible? although no idea about it being likely?

  10. #50
    BG Content
    Join Date
    Jul 2007
    Posts
    21,105
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    I don't know, but if you say it's more accurate than just assuming it's floating point then I believe you! xD

  11. #51
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    I'm saying it is a floating point, not that it's more accurate than one.
    I just hope some people might try it out and prove/disprove it.
    Up till now I've found it easy to make spreadsheets to prove/disprove theories, but I'm finding it a little tricky to figure out how/what to test to break this one.

  12. #52
    BG Content
    Join Date
    Jul 2007
    Posts
    21,105
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    Quote Originally Posted by Mougurijin View Post
    I'm saying it is a floating point, not that it's more accurate than one.
    I just hope some people might try it out and prove/disprove it.
    Up till now I've found it easy to make spreadsheets to prove/disprove theories, but I'm finding it a little tricky to figure out how/what to test to break this one.
    Sorry, I meant double (32 bit) I guess (which is what excel defaults to, I think), and I was talking about the accuracy of your model.

  13. #53
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    I think Double is normally known as 64-bit these days, Single is 32-bit, Half is 16-bit, and Quad is 128-bit.

  14. #54
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    This is so annoying...
    No matter how much I think about it, I can't even begin to find a way to challenge this formula.

    Up till now, each theory I've tested had another theory to test it against, where either formula could be right until I found an example where they give different answers -only one matching the in-game recast timer.
    I did this easily using spreadsheets to test two formulas in parallel columns, automatically highlighting examples where they end up with different answers, then testing those spell+haste+FC combinations in-game to see which formula was correct.

    But now, because I've found the flaws in every other formula I've tried so far, I don't have a formula that I don't already know to be wrong to test against, and it seems like I have little choice but to just keep testing near random spell+haste+FC combinations.

    Once a 100% correct recast formula is found, finding haste values for pieces of gear should be much simpler, with no ambiguous situations where, for example - Blitz Ring, looks like it must be 10/1024, but at other times looks like it has to be 11/1024.
    You could just keep testing 10 and 11 in the formula until the first time either value gives an incorrect answer that doesn't match the in-game recast timer, which would show the other value to be correct.
    If 10/1024 gave the incorrect answer, check 12/1024 is wrong too the same way, and you'd know for 100% definite 11/1024 is correct, so long as the recast formula is 100% correct.

    I already know where to include magian staff element "affinity: recast time-12%", which as I said earlier, is added to fast cast recast reduction %...
    So fast cast part of the formula with the staff= *(1-(truncate(FC/2)+aff.recast)/100) ... aff.recast in this case being "12".

    If by chance this formula is already the correct one, then I want to figure out exactly where and how these should be included:
    - RDM Composure
    - SCH Arts & Stratagems
    - SAM Hasso & Seigan.
    FFXIclopedia's "Recast Time" page has a recast formula which includes Hasso and Seigan, but this formula is definitely wrong already, without the JAs.

  15. #55
    BG Content
    Join Date
    Jul 2007
    Posts
    21,105
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    The initial tests I did with recast times and those JAs showed that they were all likely separate multipliers, if that helps at all.

  16. #56
    TSwiftie
    Join Date
    Oct 2005
    Posts
    1,920
    BG Level
    6
    FFXI Server
    Fenrir

    Quote Originally Posted by Mougurijin View Post
    Once a 100% correct recast formula is found, finding haste values for pieces of gear should be much simpler, with no ambiguous situations where, for example - Blitz Ring, looks like it must be 10/1024, but at other times looks like it has to be 11/1024.
    You could just keep testing 10 and 11 in the formula until the first time either value gives an incorrect answer that doesn't match the in-game recast timer, which would show the other value to be correct.
    If 10/1024 gave the incorrect answer, check 12/1024 is wrong too the same way, and you'd know for 100% definite 11/1024 is correct, so long as the recast formula is 100% correct.
    I might have missed something, but when does blitz ring look like 10/1024?

  17. #57
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    Thanks Byrthnoth, I remember reading that on here recently.

    Quote Originally Posted by Kirschy View Post
    I might have missed something, but when does blitz ring look like 10/1024?
    I'm sure I've seen a debate in the past about it, I thought you were even the one that said it, but I guess not.
    I'm sure the value of Blitz Ring is definitely known already, I wasn't really interested, just threw it in as an example I thought I'd heard mentioned before. I don't know if Blitz Ring is 10 or 11, I don't have one so wasn't interested to look it up.

    Edit:
    I was reading the first page in the "Random Facts" thread recently, so Blitz Ring was the first example that came to mind.
    Someone else thought it was 10/1024, but you'd previously and later tested it to be what appears to be the correct value, as 11/1024, but at the time mentioned a possibility of 10/1024.

    I wanted to thank you anyway though Kirschy.
    I've always been very interested in recast timers as someone who virtually always plays RDM, but I never started making spreadsheets and doing really thorough testing until I recently read your old thread about Fast Cast possibly being /1024.
    I spent a lot of time testing that, which lead to me making a very large spreadsheet to test rows of all recasts in .25 increments, and columns of all /1024 reductions from 1 to over 512, with every .5/100 at each interval, and making it automatically highlight each interesting spell+haste+FC combination to try in-game.

  18. #58
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    I'm still not really getting anywhere with finding how to put my theory under more stress.
    It still should be tested a lot more before I accept it, but I almost feel like if I think about it a little more, I could prove it anyway.

    I want to show my theory clearer, for people that are interested but don't know a lot about binary.
    This might be a pretty long post...

    Here is a normal 16-bit integer value, with the decimal values of each individual bit in the columns below them:
    Code:
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    = = = = = = = = = = = = = = = =
    3 1 8 4 2 1 5 2 1 6 3 1 8 4 2 1
    2 6 1 0 0 0 1 5 2 4 2 6
    7 3 9 9 4 2 2 6 8
    6 8 2 6 8 4
    8 4
    Here is the same number of bits, but representing the floating point 16-bit value I use in my recast theory:
    Code:
    0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0
    = = = =|= = = = = = = = = = = =
    8 4 2 1|2 1 5 2 1 6 3 1 8 4 2 1
           |0 0 1 5 2 4 2 6
           |4 2 2 6 8
           |8 4
    First 4 bits (blue) are the "exponent" -- This stores the number of bits across that the significand value has been shifted, and therefore, the number of bits across to shift the number back to represent the original decimal value with it's fraction.
    Next 12 bits (black) are the "significand" -- The recast value that has been bit shifted across by the value in the exponent.

    So the significand 12-bits has to hold the initial base recast of a spell.
    Aero IV base recast = 33.25 seconds.

    Here is 33.25 in binary:
    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
    
    33.25 = 32 + 1 + .25
    The recast value has to fit in the 12 bits shown in black, as binary bits can't directly represent fractional values.
    At the moment, the .25 would be ignored as it's outside the 12 bits and the recast would just be 33s.
    But the recast isn't actually stored as 33.25 in the game's resources -- It's stored as "133", which is four times the value of the recast.

    This is the same as 33.25 shifted left by two binary places:
    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
    
    133 = 128 + 4 + 1
    For each bit to the left that the whole value is shifted, the whole value is doubled.
    If the value is shifted to the right, for each bit the whole value is right shifted, the whole value is halved.
    So because the significand is left shifted by two bits, the value of the floating point is doubled twice.

    This calculation step obviously doesn't actually happen in the game, as the recast for Aero IV is already stored as 133 in the resources.

    Hopefully my explanation has been easy enough to follow up to this point.
    I should point out that I could be very wrong about how all this binary stuff works... but I hope not, so lets continue!

    Aero IV base recast at the moment is 133, and has no reason to be stored as a floating point at this point, but for the next part of the recast calculation with haste we need to be using a floating point.

    So lets convert 10000101 (133) to a floating point.
    Currently, this value is taking up 8 bits, out of the 12 bits available.
    As I said before, there's an extra non-stored bit, which doesn't exist at all, before the 12 bits. This imaginary bit is always a "1" in floating points.
    So we need to make use of the 12 bits and this extra imaginary bit. (13 bits)
    To do this, we left shift our 8 bit "10000101" by 5 bits, making our new 12 bit version:
    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
    This is left shifted across by 5 bits, resulting in:
    
    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
    
    4256
    = 4096 + 128 + 32 
    = 133 doubled five times...
    = 133 * 2^5
    = 133 multiplied by (2 to the power of 5)
    The first bit on the left 'fell off' the 12-bit significand, but because it's always a "1" not a "0", it doesn't matter, and that's how it's supposed to work.
    If it's always a 1, then it's not adding to the the precision of the floating point, so would have just been a wasted bit if stored in the significand.

    The 4 exponent bits must store the information for how many bits the significand value has been shifted by, so that the intended value can be read from the floating point.
    So the exponent needs to represent to whatever reads the floating point, that the value needs to be shifted back by the same number of bits.

    This might be, in this case, by setting it to "0101" which is 5, or maybe some other value.
    As long as the game understands from the exponent how much the significand has been shifted, and how to show the intended decimal value and it's fraction from it.

    I don't really know what would be the most likely way the exponent format part might work, but for just working out a formula, the understanding of how the exponent is formatted isn't really too important.

    (I might try to finish this example sometime, but it's getting late so I'll stop here.)

    -Update-
    This isn't continuing the explanation from where I left off... this is just technical amendments to what I said above.
    Reading this this won't really help if you're trying to understand how this theory works.
    I'll try and finish the original explanation later, probably in a different post though.

    Ok, I'm a bit more awake now.
    The last part I wrote about didn't properly represent how floating points work, but it was written more towards understanding my formula.
    It doesn't matter too much as this mostly just affects the exponent... the results are still the same, but I still think I should clear this part up a bit...

    What I did above was shift the "133" left by 5 bits, which I said made the significand "4256".
    Since the recast is held in a floating point now, the value of the floating point needn't be a meaningless number like "133", and can instead be (and probably is) the recast value in seconds: "33.25"
    The way I explained the floating point above, the exponent would have been -7, informing whatever reads the floating point that the significand "4256" needs to be shifted rightwards by 7 bits, to give the intended value of "33.25".

    However, what I described just then was wrong, in that the exponent isn't -7, and the significand doesn't represent "4256".

    Significands in binary floating points always represent values in the 1.xxxxx range, i.e. between 1.0 and 1.9999~
    In our case, representing spell recasts with floating points, the exponent should always be a positive numbers, and the range of value used for the exponent is probably: 1 to 7 (2.0s to 255.999s~), or at the very most maybe: 0 to 8 (1.0s to 511.999s).

    So the exponent might only need 3 bits (0 to 7), or it could well be 4 bits formatted like IEEE standards say (-7 to +7~+8)...

    So, when before I said something about slow+% maybe requiring negative exponent values, I was definitely wrong.

    Here's what I mean...
    Before I said:
    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
    This value (133) is left shifted across by 5 bits, resulting in:
    
    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
    
    4256
    = 4096 + 128 + 32 
    = 133 doubled five times...
    = 133 * 2^5
    = 133 multiplied by (2 to the power of 5)
    ...and that the exponent would need to store the value "5" so that when the floating point is read, it reads the significand shifted back rightwards 5 bits, giving "133" instead of "4256".

    Here's what I should have actually said:
    Code:
    Aero IV recast "33.25" seconds, trying to fit into a binary integer:
    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
    
    Aero IV recast as it is stored in resources as "133":
    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
    To convert the recast to a floating point, this value is stored as the significand 12 bits "000010100000" (with the non-stored "1" bit in front):
    Code:
    Aero IV recast as it is stored for the 12-bit significand of a floating point:
    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
    
    Here is the value the significand actually represents:
    0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 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
    
    1 + 0.03125 + 0.0078125
    = 1.0390625 -- this is the significand value which the exponent acts on.
    The exponent then has to hold the number of bits that the value should be left shifted by, in order for the floating point to return it's intended value -- the recast in seconds (33.25s)
    So in this case the exponent would be five.

    Integer
    Recast: 133 decimal, 10000101 binary (8 bits in this case)

    Floating point
    Significand: 1.0390625 decimal, 1000010100000 binary (12 bits).
    Exponent: 5 decimal, 0101 binary (4 bits).
    Recast: 33.25 decimal, 0101000010100000 binary (16 bits)
    = Significand * 2^Exponent
    = 1.0390625 * 2^5
    = 1.0390625 * 32

    The exponent in binary is probably stored in the format specified in IEEE standards, which if it's a 4-bit exponent then the exponent is read as it's value minus 7.
    This -7 is known as the "exponent bias". To store the exponent you want, you store the value +7...

    Four bits for the exponent: 0000
    To store an exponent of 5, you would have to store 12 (5+7), which is "1100" (8 + 4 + 0 + 0).
    "1100" (12) is read as 5, because 12-7 = 5.

    So finally, here is how the floating point for "33.25" would actually be stored by the game: 1100000010100000
    Code:
    1 1 0 0|0 0 0 0 1 0 1 0 0 0 0 0
    = = = =|= = = = = = = = = = = =
    8 4 2 1|. . . . . . . . . . . .
           |5 2 1 0 0 0 0 0 0 0 0 0
              5 2 6 3 1 0 0 0 0 0 0
                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
    (I'll try and continue the original explanation later, probably in another post though...)

  19. #59
    TSwiftie
    Join Date
    Oct 2005
    Posts
    1,920
    BG Level
    6
    FFXI Server
    Fenrir

    Quote Originally Posted by Mougurijin View Post
    I'm sure I've seen a debate in the past about it, I thought you were even the one that said it, but I guess not.
    I'm sure the value of Blitz Ring is definitely known already, I wasn't really interested, just threw it in as an example I thought I'd heard mentioned before. I don't know if Blitz Ring is 10 or 11, I don't have one so wasn't interested to look it up.

    Edit:
    I was reading the first page in the "Random Facts" thread recently, so Blitz Ring was the first example that came to mind.
    Someone else thought it was 10/1024, but you'd previously and later tested it to be what appears to be the correct value, as 11/1024, but at the time mentioned a possibility of 10/1024.

    I wanted to thank you anyway though Kirschy.
    I've always been very interested in recast timers as someone who virtually always plays RDM, but I never started making spreadsheets and doing really thorough testing until I recently read your old thread about Fast Cast possibly being /1024.
    I spent a lot of time testing that, which lead to me making a very large spreadsheet to test rows of all recasts in .25 increments, and columns of all /1024 reductions from 1 to over 512, with every .5/100 at each interval, and making it automatically highlight each interesting spell+haste+FC combination to try in-game.
    I think when it comes down to haste in particular and on it's own, the /1024 system explains it perfectly. It might not be the exact system, but the model should work 100% of the time.

    It seems when you add other types of recast reduction, the /1024 doesn't hold up (or so I'm told.) I think it's cool that other people are picking it up and trying their hand at it. I've barely had the time or motivation to play with that stuff these days, but it's all very interesting. Although I don't always post, I'm almost always reading what people test and find out~

  20. #60
    Hydra
    Join Date
    Jul 2011
    Posts
    128
    BG Level
    3
    FFXI Server
    Ragnarok

    Ah, you have a point. I think I was overlooking that haste /1024 works fine as long as you aren't using any fast cast.

    Since I'm always on RDM, I almost always have to factor in the job trait fast cast when trying to determine haste values of gear, and recast values, as most of the haste gear I have I can only equip as RDM, because my other jobs aren't levelled high enough.

    You're right though.
    The only reason having too much accuracy to the recast value after haste, before fast cast, is because you might be using a value like 9.31445 where the game might only have stored a value of 9.314.
    Because the calculation with more accuracy in this case is +0.00045 higher, it might mean that after applying fast cast too, the result ends up as 8.00001 instead of 7.999
    This would give an answer truncated/floored to 8 seconds, whereas the actual in-game recast is truncated/floored to 7 seconds.

    This is a situation I get for Aero IV on RDM90 with 150/1024 haste and -52% FC.