Is this accounting for the haste?
Is this accounting for the haste?
... No. >.>
Kept checking to make sure I wasn't forgetting anything, and somehow completely blanked on that. Rechecking values...
Test:
Protect II with 30/1024 haste (including belt):
5 if 10/1000, 4 if 20/1000
Result: 5
Protectra III with 101/1024 haste (including belt):
15 if 10/1000 or less, 14 if 11/1000 or more
Result: 14
Curaga IV with 60/1024 haste (including belt):
10 if 11/1000, 9 if 12/1000
Result: 10
Cura III with 30/1024 haste (just belt):
48 if 10/1000, 47 if 11/1000
Result: 47
** Cura III with 51/1024 haste (test with assumption of 31/1024 for belt, +20/1024 from shoes):
47 if 10/1000, 46 if 11/1000
Result: 47
So it's either 11/1000 fast cast recast time and 30/1024 haste, or 10/1000 fast cast recast time and 31/1024 haste. The latter seems more likely, giving it 2% Fast Cast.
I could just be blind, but I don't see a test with any other Fast Cast gear there to rule out the possibility of it being 3%. 3% would make more sense given the haste and quick cast values. Unless I'm unaware of some flooring in the recast equations, the difference should be obvious with just the belt and a 5% FC piece and casting say, Reraise or Klimaform.
The last test might indicate that. With 3% FC, that would be roughly 15/1000 recast? That would land you at 46s after the haste value given.
Last I saw, we'd determined that Fast Cast is only applied to recast in whole percentage increments. As such, 2% and 3% would provide the same 1% reduction in recast time. Has that understanding changed?
That is the current understanding (iirc) and 3% Fast Cast would fit with the rest of the belt.
Ahh. I see what you're saying. Yes, I can check for that later tonight.
Protectra
Witful Belt + Orison Locket (5% FC)
With either 30 or 31/1024 haste:
14 if 30/1000, 13 if 40/1000
Result: 13
At least 38/1000 total recast, meaning 40/1000=4%.
That puts Witful at 3% FC.
Hi there, I'm trying to follow this thread and summarize the way FC works with spell recasting. Forgive me if some other summary like what is below is available in this thread. Can we all agree on the following
Casting Delay
1) Casting time delay reduction caps at a maximum of 80%
2) The varying sources (Grimoire, Fast Cast, Elemental Celerity, -Casting Delay Gear) all appear to stack together additively in one pool.
Recast Delay
1) Recast delay reduction caps at a maximum of 80%.
2) The varying sources are consolidated into different groups of modifiers which appears to be in its simplest form, ([Original Recast Value] x [Job Ability modifier value] x [Haste/Slow modifier value] x [Fast Cast modifier value]).
Fast Cast
1) Fast Cast values from all various sources (job Traits and Gear) stack together in the same modifier pool.
2) The total value of that modifier cannot exceed 40%.
3) It's value is rounded down, odd pieces by themselves are less potent than when they are paired together (and thus eliminate the fractional value).
Haste
1) Haste/Slow from all sources (Gear and Magic) stack together in the same modifier pool.
2) The total value of that modifier cannot exceed the current capped value of 68.75
Here's what I am unclear of
1) Do sources of gear with "reduces x's recasting time" (blu gloves, blm body, Magian recast staffs, etc) exist as their own modifier or are they added into a another group? Which group then?
2) How does the JA modifier work? Are individual ability values added together, or multiplied? If multiplied, then in what order?
Please, can someone shead some light on this?
There is no known cap on recast reduction.
The order of the terms is important, but not currently pinned down.
See the second link.
Recast calculations apparently involve a lot of binary. Despite my intent to, I haven't read through all of the testing carefully enough to explain how it's done.
Nausi ~
In general, that is the appropriate model for for recast time calculation. The exact model remains elusive to this point. What's missing is the order of calculation of terms, and the exact method of calculation for each step. These are both important in predicting the discretization error that will occur in extreme cases. If you're not familiar with discretization error, it's error that is produced due to the limitation of a digital computer's ability to represent numbers. Digital computers can only represent specific real numbers which are different depending on how the computer decides to represent these numbers.
This is a little bit copy/paste from something I sent to TS, but I think it may help clear things up for people who have been having trouble putting it all together (some of my previous posts on the matter are jumbled or outright wrong.)
First, consider a byte that is being used to represent integers. The possible values are the integers equal to and between 0 and 255. Now choose an odd integer from this number space, say 201. Dividing this number by 2 would result in 100.5 in real number space. However, because this number does not exist within the binary number space a byte can represent, the resulting value will be truncated to 100. This is what is meant by discretization error. This is probably exactly what occurs with Fast Cast before it is used in recast calculations. The values for each piece of of Fast Cast gear or trait are stored as integers. The integers are summed, and then divided by 2. Odd values of Fast Cast will thus experience truncation (which is what has been observed.)
Additionally, integers are not the only way computers can represent numbers. Floating point is a format used to represent decimals, and could potentially be used in this calculation somewhere. The numbers any floating point system can represent are also discrete, and the error is even more difficult to predict.
Now, to complicate things further, the order in which calculations are performed has an impact on the error that is produced. In integer number space, for example, (1÷2)*2 = 0 while (1*2)÷2=1.
We know at least the following at this point ~
- All terms are stored as integers not floating points.
- Stored recast times correspond to 0.25 seconds per unit.
- The final term is converted to an integer byte (8 bits) and corresponds to 1.00 seconds per unit.
- The numerator for Fast Cast recast division is 2 and then 100 (remember this value is first divided in half).
- The numerator for Haste recast division is 1024.
Now, I'm not really interested in finding out the interim calculation order or specifics as I don't consider it very useful information. It's also entirely possible to accidentally convert an integer to a floating point and vice versa when programming just depending on your syntax, thus there are a great number of ways this calculation could actually be occurring. If someone is intent in solving it, then I recommend the following.
*Stick to conventional ways that computers represent numbers
There are only a few choices for this. IEEE 754 formats for 16, 32, and 64 bit floating point numbers and 16, 32, and 64 bit integer numbers. I think it's same to assume that none of the intermediate calculations are carried out in any other formats (finding out custom bit lengths etc.) because that would require physically constructing their own server hardware and computer engineering standards to do so. That seems unlikely.
*Assume integer math at first
Floating point calculations require more computational time. Good programmers know this and try to avoid them when appropriate.
I'd like to rewrite the recast time page. Currently it's a bit too technical and difficult to follow, but I've kind of forgotten which terms are lumped together, and how many separate terms there are.
Well, despite what I said earlier about not wanting to do this, I can't seem to stop thinking about it. I'm going to look into the following possible exact methods outlined below.
orCode:R = [[([(r*(100-[f/2]))/100]*(1024-h))/1024]/4]
Code:R = [[([(r*(1024-h))/1024]*(100-[f/2]))/100]/4]The values for r are simply the base recast listed in the game multiplied by four. The parenthesis and brackets denote strict order of operations while the brackets also indicate where truncation to a whole integer would occur.Code:R Final Recast r Base recast f Fast Cast h Haste
The first model is Fast Cast > Haste, the second is Haste > Fast Cast.
Hey Mojo, I'm not sure if you've read this, but Mougurijin has determined that it's Haste > Fast Cast. link
I did read that, but he assumed floats were used there, and in a way that may not be possible without designing your own hardware and engineering standards (i.e., the arithmetic used was not consistent with any IEEE 754 standard.) So I am skeptical of the results unless I have misinterpreted them (which is very possible!)
Neither of the two methods I suggested work. However, there are several other ways that it could be done using just integers (by grouping some terms before truncating by the product of their denominators) which I am looking at currently.
I've been able to get something working quite well using integer math. My data is as follows.
The Fast Cast and Haste values are self explanatory. The result is what I observed, and the numbers in the columns marked A through I are what the model predicted given the truncation order to the right of the letter below. It's kind of shorthand notation, f = fast cast, h = haste, 4 = final division by 4. Everything in brackets would be multiplied by terms I supposed earlier and then truncated by division of the product of their bases.Code:Fast Cast Haste Spell Result A B C D E F G H I 4 150 Reraise 50 50 50 49 51 49 49 50 48 50 4 150 Regen 10 10 10 9 10 10 10 2 150 Regen 10 10 10 9 10 10 10 6 150 Protectra III 14 14 13 14 14 14 13 2 150 Curaga IV 9 9 8 6 150 Protect II 4 4 6 150 Cure III 4 4 6 150 Deodorize 6 6 6 150 Curaga IV 8 8 6 150 Regen 9 9 6 150 Protectra III 14 14 6 150 Protectra IV 14 14 6 150 Reraise 49 49 18 150 Protect II 4 4 18 150 Deodorize 6 6 18 150 Curaga II 7 7 18 150 Curaga III 8 8 18 150 Protectra III 13 13 18 150 Protectra IV 13 13 18 150 Reraise 46 46 30 150 Cure II 3 3 30 150 Protect IV 4 4 30 150 Deodorize 5 5 30 150 Protectra III 12 12 30 150 Protectra IV 13 13 30 150 Reraise 43 43 A [[hf]4] B [[[f]h]4] C [[[h]f]4] D [fh4] E [[h]f4] F [[f4]h] G [[4]hf] H [[h4]f] I [[f]h4]
The table is mostly empty. That's because after a few spells, if the model had thrown an error, I simply discarded it and stopped checking for values as it was already flawed. The model that worked for everything I lumped Fast Cast and Haste together, truncated with division by their common base, and then truncated again by division by 4.
The list of spells used were not random. I selected spells such that the smallest possible change in r would produce a change in R. I did this because spells with such r values are the most likely to throw an error between observed and predicted recast times. I couldn't test every such critical r value as that would have required changing jobs, leaving town, or access to spells that I don't have, but none of the ones I did test threw any errors, and I tested three combinations of Haste and Fast Cast.Code:R = [[(r*(100-[F/2])*(1024-h))/(1024*100)]/4] R Final Recast r Base recast f Fast Cast h Haste
Either way, this model agrees with observations I made before, and seems much more realistic than anything else suggested. It needs more testing though. Every time I think I have this figured out, something breaks it. It only covers Haste and Fast Cast, but I'll work on it more later.
More data
Same idea as before, trying values likely to throw errors. None thrown. I'll try some BLM spells as their spells have many unique r values and would fit well with the WHM testing I've done already.Code:f h Spell Result Predicted 8 150 Cure III 4 4 8 150 Deodorize 6 6 8 150 Barfira 8 8 8 150 Curaga IV 8 8 8 150 Regen 9 9 8 150 Protectra 12 12 8 150 Protectra II 13 13 8 150 Protectra III 13 13 8 150 Protectra IV 14 14 8 150 Regen IV 19 19 8 150 Stoneskin 24 24 8 150 Cura II 32 32 8 150 Cura III 40 40 8 150 Reraise 49 49 10 150 Cure III 4 4 10 150 Deodorize 6 6 10 150 Barfira 8 8 10 150 Protectra 12 12 10 150 Protectra II 12 12 10 150 Protectra III 13 13 10 150 Protectra IV 14 14 10 150 Stoneskin 24 24 10 150 Cura II 32 32 10 150 Cura III 40 40
For testing purposes (can be updated further.)
Code:Spell Recast r Shell 5 20 Protect II 5.25 21 Cure II 5.5 22 Protect IV 5.75 23 Cure III 6 24 1 BLM 6.5 26 75 RDM 7 28 4 BLU 7.25 29 Deodorize 8 32 9 BLM 9 36 1 BLU 9.75 39 Barfira 10 40 Curaga II 10.25 41 Curaga III 10.5 42 Curaga IV 10.75 43 15 BLM 11 44 16 BLU 11.25 45 17 BLM 11.5 46 18 BLU 11.75 47 Regen 12 48 19 BLM 12.25 49 21 BLM 13 52 23 BLM 13.5 54 26 BLU 14 56 30 BLU 14.25 57 26 BLM 14.5 58 Protectra 15 60 28 BLM 15.25 61 30 BLM 15.75 63 Protectra II 16 64 32 BLM 16.5 66 Protectra III 17 68 36 BLM 17.75 71 Protectra IV 18 72 38 BLM 18.5 74 40 BLM 19 76 44 BLU 19.25 77 18 BLU 19.5 78 42 BLM 19.75 79 Haste 20 80 44 BLM 20.25 81 46 BLM 21 84 48 BLM 21.75 87 51 BLM 22.5 90 38 BLU 23 92 53 BLM 23.25 93 60 BLU 23.75 95 Regen IV 24 96 57 BLM 24.5 98 59 BLM 25.25 101 75 BLM 26 104 62 BLM 26.5 106 63 BLM 27.25 109 64 BLM 27.75 111 65 BLM 28.5 114 66 BLM 29.25 117 Stoneskin 30 120 68 BLM 30.75 123 69 BLM 31.5 126 70 BLM 32 128 71 BLM 32.75 131 72 BLM 33.25 133 50 BLU 33.75 135 73 BLM 34 136 58 BLU 34.5 138 73 BLM 34.75 139 74 BLM 36 144 75 BLM 37.25 149 61 BLU 39 156 Cura II 40 160 50 BLM 41.5 166 52 BLM 42.25 169 54 BLM 42.75 171 58 BLM 43.75 175 62 DRK 44 176 60 BLM 44.5 178 37 NIN 45 180 71 BLU 49 196 Cura III 50 200 70 DRK 52 208 61 BLU 56 224 Reraise 60 240 71 DRK 180 720
I'm pretty convinced at this point, unless someone turns up something that can refute it. Going to shift focus over to other recast sources to perhaps incorporate them into the final product.Code:f h Spell Result Predicted 2 150 Protect IV 4 4 2 150 Cure III 5 5 2 150 Deodorize 6 6 2 150 Curaga III 8 8 2 150 Curaga IV 9 9 2 150 Regen 10 10 2 150 Protectra III 14 14 2 150 Protectra IV 15 15 2 150 Haste 16 16 2 150 Stoneskin 25 25 2 150 Cura II 33 33 2 150 Cura III 42 42 2 150 Reraise 50 50 2 150 Aero 7 7 2 150 Thunder 10 10 2 150 Aeroga 11 11 2 150 Firaga 12 12 2 150 Water II 13 13 2 150 Blizzaga 13 13 2 150 Thundaga 14 14 2 150 Fire II 15 15 2 150 Stonega II 16 16 2 150 Waterga II 17 17 2 150 Thunder II 17 17 2 150 Aeroga II 18 18 8 150 Stone 5 5 8 150 Aero 7 7 8 150 Stonega 9 9 8 150 Waterga 10 10 8 150 Thunder 10 10 8 150 Aeroga 11 11 8 150 Stone II 11 11 8 150 Protectra 12 12 8 150 Water II 12 12 8 150 Thundaga 14 14 8 150 Fire II 15 15 8 150 Blizzard II 16 16 8 150 Waterga II 16 16 8 150 Thunder II 17 17 8 150 Aeroga II 17 17
I did some testing on SCH job abilities, but I don't have all of the extra gear, so it could use some additional verification.
Testing I didn't record very well just showed it that Celerity/Alacrity overwrite Light/Dark arts (thus any gear that enhances light/dark arts will not do anything when those other Celerity/Penury are active.) The base appears to be 100, like Fast Cast, although the value is not divided for recast calculations.
The models A B C and D showing shorthand for the truncation order. Only one of them works.Code:s f h Spell Result A B C D 10 15 0 Cure III 5 5 4 4 4 10 15 0 Regen 10 10 9 9 9 10 15 0 Stoneskin 25 25 24 25 24 10 30 0 Protect II 4 4 3 3 3 10 32 0 Protect II 3 3 3 3 3 A [[hfs]4] B [[fh]s]4] C [[s]fh]4] D [[fh]4]s]
More testing needs to be done on this, I didn't do much at all, just to show which one of those possible models it could be. There are many other ways to do it with just integers, although I assumed that the bases would stay with their numerators for each term when being truncated, and this is all of those possibilities.Code:R = [[(r*(100-[F/2])*(1024-h))*(100-s)/(1024*100*100)]/4] R Final Recast r Base Recast f Fast Cast h Haste s Scholar
The value of s is an integer. Light/Arts is s = 10, gear that enhances it adds integer amounts (so relic head = +5, etc.) If Celerity/Penury are active, s = 50, and gear that enhances it adds integer amounts (relic +2 feet I think add 15.)
I forgot to test Manifestation/Accession. Confirmed all of the results from them that others had found. Adjusted to take this into consideration and narrowed down truncation order to the following.
Code:R = [[(r*(100-[F/2])*(1024-h))*(s)/(1024*100*100)]/4] R Final Recast r Base Recast f Fast Cast h Haste s Scholar If Alacrity or Celerity or Manifestation or Accession process,s = (100-c)*(m) If Alacrity or Celerity processes,c = 50 + bonuses from gear (integer values) If Alacrity or Celerity don't process, c = 0 If Manifestation or Accession process,m = 2 if SCH main, m = 3 if SCH sub If Manifestation or Accession don't process,m = 1 If neither Alacrity or Celerity or Manifestation or Accession process,s = (100-a) If Light Arts or Dark Arts is active then If spell matches grimoire, a = 10 + bonuses from gear (integer values) If spell opposes grimoire, a = -20 (gear is ignored) If no grimoires are active, then s = 100