Why use gun vs HNM / Gods?

[VZX]

Originally posted by Mithrael
to determin length of time to get ot 100%tp:
int(100 / tp_per_swing + .99) * (delay / 60)

You add .99 to force a roundup (because 8.01 is actually 9 swings/shots), then INT it to remove the fractional part.

mind if I correct you for the mathematical notation?

int(some number) will just truncate the decimal following it.
I think it's better if you say
Ceiling(100 / tp_per_swing + .99)*(delay/60)

(ceiling function)

nice information btw ^^b thank you
I know why I could get TP faster with my crossbow assuming the accuracy is not much difference

[RangerDade]

while i find that to be a valied reason for every other job weapons(for the most part) between rapid shot and barrage, geting tp <5 seconds slower doesnt make up or the added dmg + WSdmg and rng is already second fastest TP gainer(sams ><)

[Mithrael]

Vanguard, Delay to seconds is delay/60. It's been confirmed by quite a few people, but you can check yourself if you like.

To test this:
1.) Switch to a job that cannot counter, double attack, triple attack, or has an innate haste (mnk, nin)
2.) Equip the lowest damage weapon you can, preferably one that you have almost no skill (so you don't kill your prey too fast)
3.) Engage auto-attack. after you've swung a few times, start a time right as you strike the enemy
4.) Let your self swing 20 times, and stop the timer as you make your 20th swing
5.) solve: time / 20 = delay / x
simplified: delay_per_second = (20 * weapon delay) / time

with a little margin for human error (starting/stopping the timer too slow or fast) and lag, your result should be 60.

Edit: IIRC, Apple_Pie had speculated that the delay/60 was a result of FFXI's internal (read: not renderring) frame rate being 60fps. This is a pretty good explanation, though I have no idea how one would go about proving it. While I somehow doubt you have 95% accuracy on VT+ mobs, I don't at all doubt that you get TP faster than 1 minute. Between Triple Attack, and either Double Attack or Ninja Duel Weild 2 (10% haste), you should be on par to gain full TP in about 45-50 seconds, even with 70% accuracy.

=====

VZX, i never mind people correcting me. However, I believe your equation is flawed.

the following formulae are equivalent assuming input precision is only to 1/100th:

int(100 / tp_per_swing + .99)
ceiling(100 / tp_per_swing)

examples:

int(100 / 5 + .99) = int(20.99) = 20
ceiling(100 / 5) = ceiling(20) = 20

int(100 / 5.1 = .99) = int(20.59) = 20
ceiling(100 / 5.1) = int(19.6) = 20

...

int(100 / 18.4 + .99) = int(6.42) = 6
ceiling(100 / 18.4) = ceiling(5.43) = 6


However, note that the suggested equation, ceiling(100 / tp_per_swing + .99), will pretty much always result in an incorrect result:

ceiling(100 / 5+ .99) = ceiling(20.99) = 21
ceiling(100 / 5.1 + .99) = ceiling(20.59) = 21
ceiling(100 / 18.4 + .99) = ceiling(6.42) = 7


edit: had written a longer post but it got eaten by the dreaded ffxionline database error :dead:
ceiling(100/tp) is a much clearer way to show the relationship. I'm not a mathematician, i'm a C programmer, so I tend to think in terms of computational efficiency instead of human-readability.

[Spider-Dan]

re: delay/second
For ranged weapons at least, delay is certainly more than 60/sec. You can see this by taking a 600 delay gun with 240 delay bullets and shooting it. You can fire twice in 9 seconds (that includes both the startup pause, which is the gun delay, and the "reload" pause before you can fire again, which is the ammo delay).

If 60/delay sec were true for ranged, then the gun wouldn't fire for at least 10 seconds, and would take another 4 seconds before you can fire again. 100/sec seems to be about right (different tests provide numbers between high 70s and mid 90s for delay/sec, but that's probably attributable to lag).

re: running out of ranged distance after /ra is started
I believe that if you start a /ra and the target moves out of range, the message you get is "You move and interrupt your aim." I vaguely remember getting this message in that scenario when I was standing perfectly still for quite a while.

re: int/ceiling
IANA mathematician, but I thought floor truncated decimals, ceiling always rounds up, and int does normal 0-4/5-9 rounding function?

[greysenn]

re: running out of ranged distance after /ra is started

I have been able to consistantly hit targets that have moved out of range after a Rattack has started... I have had a fair amount of shots interrupted due to not stopping fast enough before I shoot however.

[Spider-Dan]

I think there are three ranges for /ra:

1) range at which you can start /ra
2) range at which you cannot start /ra, but an existing /ra will still complete
3) range at which an existing /ra will cancel

The easiest way to test this is with a Sarnga on Cactrot Rapido, I think.

[Anakron]

Originally posted by Spider-Dan
re: int/ceiling
IANA mathematician, but I thought floor truncated decimals, ceiling always rounds up, and int does normal 0-4/5-9 rounding function?

I am under the impression that integer division is the same as floor. At least that's how all the CS code I've ever written do it. :p

[imac2much]

Yep in programming terms that's what INT does. But I think dan is trying to say that may not be the mathematical use of INT.

I don't know either, but mithrael is a programmer, so he was probably just using the programmer's term for it :p

[VZX]

hmm
yah

I think I was wrong thinking it was rounded up (ceiling)
it looks more like the number is truncated (seeing sometimes i only gain 13% instead of 14% for every of my connected bow shot)

BTW, int has the same return value as floor for every real number >=0

however, I still think the sum of TP gained is still internally as a floating point number with 2-3 digit precision i think? :/

[Mithrael]

TP gain is a floating point numer with precision only in the 10s. This is easy enough to test on your own if you can keep blink up. It's also consistent with most other formulae that have been derived from the game. Truncation is in pretty much every arguably accurate formula. This isn't surprising since truncation is extremely efficient. the numbers can be simply stored as shorts or bytes instead of doubles and have a multiplier that we don't see (100%tp is probably stored internally as 1000).

Anyway, total TP is therefore only precise to one digit as well. Think of it in simple mathematical terms, the smallest fraction part would be .1*1 = .1, the largest would be .9*9=8.1. There isn't any way you could end up with decimal of 2 places or more.

In any case, the INT or Ciel is around the number of swings required to reach 100%, not around TP gain. You cannot make .1 of a swing, so if it takes you 7.1 swings to get to 100% tp, you really have to swing 8 times. Now reallistically, that's going to give you MORE than 100%tp, but that doesn't really matter, since the point of this particular equation is to determine how often in seconds a player can use a weapon skill. Determing the efficacy of that weapon skill is another matter. You could just as easily replace 100 with any number you like though, so if you say you need 150% tp to effectively use Slugshot on an HNM, then sobeit. That doesn't solve the ranged attack delay problem though.

----
Spider-Dan, am I misunderstanding you, or are you really saying that you can hit the ranged attack command and actually hit a mob twice in 9 seconds with a 600 delay gun with 240 delay bullets?

That would mean the number of frames per second delay for gun would be:

delay_per_second = (2 *840) / 9

or 186

That seems very suspect to me. I'm sure I'm misunderstanding you. That would mean you would have 100%TP in 31.6 seconds.

The biggest problem we face with this is that it's pretty much impossible to ever "know" what the ranged delay is. Lag of .01 seconds could potentially ruin your results since the human is required to mash the buttons at the right time. Using /wait in a macro isn't good enough because the timer built into /wait is really imprecise.

As much as I hate to say it, about the only way to come any closer to knowing the real answer to this question would be to develop a bot that could do the firing and measurement for us...

----
To be perfectly honest, my theory is that "Rapid Shot" is a lot more effective than we think it is. I have a gut feeling that it's pretty much always active, but has varying degrees of effect on shots. Perhaps cutting the delay in half occasionally, and other times only removing 10% delay or so. I suppose in my longish list of things to test i need to add timed test of ranged attacks with THF or SAM, DRK, and RNG. Perhaps the most illustrative test would actually to test Throwing instead of bow or marksmanship. There is no guarantee that it'd be the same del/sec (ignoring ammo), but from everything else I've seen with s-e, I'd be willing to bet that it is.

[imac2much]

Well, you can test as a NIN/anything, as long as the subjob isn't RNG. NIN can use guns and normal bullets without any rapid shot advantage.

[Macht]

Originally posted by Spider-Dan
re: int/ceiling
IANA mathematician, but I thought floor truncated decimals, ceiling always rounds up, and int does normal 0-4/5-9 rounding function?

I am under the impression that integer division is the same as floor. At least that's how all the CS code I've ever written do it.

Mathmatically Int is suppose to drop the decimals no rounding, programmatically though it all depends on what language you are using. Some languages just drop the decimal numbers completly when you use Int and some do a proper rounding with them.

I myself still have some reservations on the delay truely being 60 seconds in it's raw data form. It does make sense that animation sequences would end up making it look like it is 60 seconds. However if you pay close attention to animation and an actual data sequence being change (Monster HP) you'll notice that the two never fall in line.

This animation delay I believe is skewing the accuracy of the math. You can see very obviously that animation and actual attack are not related if you use something like Eagle Eye Shot, There are many times were the animation is ahead of the raw data change and many times were the raw data change is ahead of the animation.

On top of this everyone seems to be assuming that all the math is a straight out mathmatic sequence. Not once have I seen someone consider the fact that they may be using Mersenne primes in their equation for the remainder data.

Anyway that's my look on it, there still seems to be important variables that are missing and variables that are not being properly rendered.

EDIT:

Anyway that's the beauty of Math Theorems, you can come with many different ways to make an outcome look right for the conditions you tested. Doesn't neccisarilly mean it's 100% correct though.

[Spider-Dan]

Originally posted by Mithrael
Spider-Dan, am I misunderstanding you, or are you really saying that you can hit the ranged attack command and actually hit a mob twice in 9 seconds with a 600 delay gun with 240 delay bullets?

No, I'm saying that you can start a second shot within 9 seconds.

If delay = 60/sec, then with a 600 delay gun + 240 delay bullet, the gun wouldn't fire until 10 seconds after you started /ra, and you wouldn't be able to start the next shot for another 4 seconds after that (ammo delay). 14 seconds total.

In practice, you can do:

/ra <t>
/wait 9
/ra <t>

...with the above weapon combo, and you will start a second shot with the second /ra. (I have done this as THF/NIN, btw.)

The second shot is starting before the first shot should have even fired. This is far beyond the effect of any lag.

The biggest problem we face with this is that it's pretty much impossible to ever "know" what the ranged delay is. Lag of .01 seconds could potentially ruin your results since the human is required to mash the buttons at the right time. Using /wait in a macro isn't good enough because the timer built into /wait is really imprecise.

Ironically enough, this is almost exactly a parallel of the argument I have used against the "stopwatching" that has been used to determine melee delay. You have to assume that the autoattack timer is always advancing, which isn't provable either.

The good thing about /wait macros is that they are much more controllable. You can input a macro with a given /wait, and see how it matches up to your expectations. They are easily reproducible and give you precise results (or, as precise as they are going to get) in a very short number of tests.

To date, I have never seen a macro/ranged equipment combo that results in anything near 60/sec delay calculation. The closest I have seen is 78/sec. (The above is 94/sec). The more unaccounted lag that is added, the lower that number goes, of course. 100 delay/sec is the only theory that covers all ranged data, though I haven't yet been able to find exactly what may be lagging melee attacks into non-conformity with 100/sec.

[Caspian]

Originally posted by Macht
On top of this everyone seems to be assuming that all the math is a straight out mathmatic sequence. Not once have I seen someone consider the fact that they may be using Mersenne primes in their equation for the remainder data.

Sorry, can you dumb this down some for us with biology degrees who never showed up to our calculus and other math classes?
Its interesting reading, but I'm sure it would be more so if I could understand better what you're talking about.

[Anakron]

Regarding ranged delays, here's a quote from Apple Pie from here:

For example, the weapon that has 224 delay has the wait, 224 / 60 = 3.733... seconds, between swings and I'm confident of this. Therefore, 1 Delay is equivalant to 1/60 second. There is a guy here verifying this through video capturing.

However for ranged weapons, we haven't been able to verify 1 delay = 1/60 second. It's more like 1 delay = 1/70 - 1/80 second. Our conclusion so far is there must be some unknown modifier for ranged weapons.

...

[Arrows are] also included T_T

What's tricky is this unknown modifier seems to vary depending on the type of ranged weapons.

The delay that determines TP we get from each attack is actually [Bow Delay] + [Arrow Delay] but the actual delay between ranged attacks isn't...

Originally posted by Macht
On top of this everyone seems to be assuming that all the math is a straight out mathmatic sequence. Not once have I seen someone consider the fact that they may be using Mersenne primes in their equation for the remainder data.

Simple division and multiplication is already a somewhat costly operation (in terms of logic gates and time delays). I cannot imagine why any designer in his right mind would implement anything beyond the four basic math functions (addition, subtraction, multiplication, and division), along with perhaps a random function as the formulae for a video game. If you're working with some image-processing program, sure, you're going to have to deal with Fourier transforms and the like, but for simple things like damage and delay calculations in a video game it's reasonably safe to assume they have very basic equations.