Why use gun vs HNM / Gods?

[Macht]

Hmm, dumb it down. Actually when I was thinking about I got myself mixed up with Mersenne Primes and what I ment to say was Congruence Equations.

Basically the mathmatics could have a modulus taking care of remainders to be re-added in differently as whole numbers. It's very very basics working with remainders in a division instead of decimals.

So its a more complex version of doing 37/6 will have a remainder 1. Then having that remainder 1 added back to the totaly so the answer would be 7 instead of 6.166666666. So then 38/6 would end up at 8 instead of 6.3333333, and so on.

Thing about Math Theorems especially when you have so many unknowns is you can come up with thousands of different possible results and demonstrate your findings to be true. It doesn't guarentee they are though because if I were to do something like find how many different ways I can have and equation equal 8 you'll have tons of different ways and all will solve to 8 but that doesn't mean any of them are how I came up with it.

With the fields we can actually test many of what people give as math results may seem right, but the instant they fan out to more then a single equation ends up adding in more possibility of it being wrong or that the programmer truely did make multiple equations.

Either way all I'm trying to state is that the mathmatics you get from tests you kind of have to take with a grain of salt. They are by no means completly accurate and not every Math Theorem requires there to be decimals for you to get the correct answer to it.

All these mathmatics would be royaly skrewed if the system truely didn't keep a decimal count but tagged that information differently. That means making theories off these theories can be bad.

If you want an example of what I mean it's like solving this silly math excersise. 17 Students steal a stack 1-dollar bills, they split it evenly and have 3 dollars left over. They get into a fight and 1 student is killed. Now the remaining 16 students split the money and have 10 dollars left over. Again another fight occurs and another student is killed. The 15 students split the money again and this time there is no remaining bills. What is the smallest possible number of bills the stack could of had?

If you end up with decimals in this at all then your Math Theorem is flat out WRONG! I've done this quite a few times and got many numbers that would satify it and some are decimals but logically you can't have a decimal of a 1 dollar bill.

[Macht]

Originally posted by Anakron
Regarding ranged delays, here's a quote from Apple Pie from here:



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.

What I'm stating is very much at the heart of what you are trying to countering my statement to be. Math Theorems you can break down a equation to having 2 variable answers. It doesn't mean that both will always have the same answer though but for the condition you tested them under they can.

And using moduluses are very much within the computer processing capablities. All mathmatics break down to the 4 you stated. I can do 5^3 and that basically equates to 5x5x5, which breaking down even more is (5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5).

What in truth is more trouble for a computer is running a series of tests. The more IF statements you put into a program the slower and slower it'll go. Loops and Statements are what slow processing the most. So far if we continue this path of almost everything having 3 unique equations are getting to over thousands and thousands of IF statements.

That is insaine when you can define specific things to number equations and have a single equation solve it.

If I really am wrong in that then I wonder how come my phonetics for my database has allowed me to now process 5 million records in under 5 min. when my if statements took 3 hrs.

All I'm Trying to state is that all these math theorems you see people coming up for this game doesn't mean they are right at all so don't start trying to define them as being absolute and judging players on that basis.

[Anakron]

Originally posted by Macht
All mathmatics break down to the 4 you stated. I can do 5^3 and that basically equates to 5x5x5, which breaking down even more is (5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5+5).

Eh, don't mean to be an ass here, but 5^3 would most likely be turned into (5 << 4) + (5 << 3) + 5. ( << is left-shifting, so in our case, we have 5 left-shifted by 4 bits, effectively multiplying by 16, just a whole lot faster) Depends on the compiler and stuff, of course.

I know very well that most any personal computer is very capable of handling whatever operations that you feed it; my point is that there is no reason to introduce even the slightest increase of complexity when all we're doing is calculating delays, damage, and the like for a video game. With this in mind, there is a good chance that the formulae presented are very close to being correct.

I don't see anybody judging others because they don't agree on the formulae presented, and I definitely don't see anything wrong with attempting to discover formulae to better understand the game. If they're wrong, come up with new ones. You make it seem like there's no point in even attempting to discover formulae, simply because there may be other possibilities.

[Caspian]

Thanks Macht.
I understood most of it just didnt know what Merenne prime were. That and I have NO background whatsoever in computer programming so I'm trying to interpret how it works from what I can understand in these forums.
Yeah, math is kinda weird like that. Theres a story/math equation kinda thing about some guys who got to a hotel in Vegas and split the room evenly, but when there is a discount later a dollar disappears. I can remember the specifics (i.e. the actual numbers or how it even works) but I'll ask my friend for it again. Its pretty interesting.

Agreed, there are so many possible ways they could have come up with that we'll prolly never know for sure unless they make it open source. However, a lot of the equations and such that Apple Pie and Co. have come up with work well in all tests so far, so for the most part I'd consider them theorems at this point, and since math pretty much takes theorems as fact there is no harm in using them until they are proven wrong.

[Macht]

Originally posted by Prince Caspian
Thanks Macht.
I understood most of it just didnt know what Merenne prime were. That and I have NO background whatsoever in computer programming so I'm trying to interpret how it works from what I can understand in these forums.
Yeah, math is kinda weird like that. Theres a story/math equation kinda thing about some guys who got to a hotel in Vegas and split the room evenly, but when there is a discount later a dollar disappears. I can remember the specifics (i.e. the actual numbers or how it even works) but I'll ask my friend for it again. Its pretty interesting.

Agreed, there are so many possible ways they could have come up with that we'll prolly never know for sure unless they make it open source. However, a lot of the equations and such that Apple Pie and Co. have come up with work well in all tests so far, so for the most part I'd consider them theorems at this point, and since math pretty much takes theorems as fact there is no harm in using them until they are proven wrong.

There is harm if you take the math they are giving as being set in stone. I'd just hate to see players being evaluated and picked to party only if their weapon and delays is agreable to a math theorems I feel that are still a bit flawed to be making such decisions on.

Originally posted by Anakron
Eh, don't mean to be an ass here, but 5^3 would most likely be turned into (5 << 4) + (5 << 3) + 5. ( << is left-shifting, so in our case, we have 5 left-shifted by 4 bits, effectively multiplying by 16, just a whole lot faster) Depends on the compiler and stuff, of course.

I know very well that most any personal computer is very capable of handling whatever operations that you feed it; my point is that there is no reason to introduce even the slightest increase of complexity when all we're doing is calculating delays, damage, and the like for a video game. With this in mind, there is a good chance that the formulae presented are very close to being correct.

I don't see anybody judging others because they don't agree on the formulae presented, and I definitely don't see anything wrong with attempting to discover formulae to better understand the game. If they're wrong, come up with new ones. You make it seem like there's no point in even attempting to discover formulae, simply because there may be other possibilities.

You have abilities that randomly shorten the delay of an attack, you have spells and even WSs that are affected the day in the game. I think it's pretty safe to say there is a bit more of a complexity in this game then people seem to be giving it credit for.

[Caspian]

Originally posted by Macht
There is harm if you take the math they are giving as being set in stone. I'd just hate to see players being evaluated and picked to party only if their weapon and delays is agreable to a math theorems I feel that are still a bit flawed to be making such decisions on.

I agree they shouldnt be taken as hardened fact nor should they be used to detemine whether the player with that gear is inherently better or more what they want based simply on those equations.

Personally I see them more for personal use of guessing particular outcomes and just basic knowledge to try and build on with in-game experience.

[Anakron]

Originally posted by Macht
You have abilities that randomly shorten the delay of an attack, you have spells and even WSs that are affected the day in the game. I think it's pretty safe to say there is a bit more of a complexity in this game then people seem to be giving it credit for.

Never really thought of those when I posted, so yeah, it's a bit more complex than I thought when I posted. I'll be damned if any of their calculations require anything more than high school algebra (maybe calculus and a little modular arithmetic, but that's pushing it), though. The number theories your proposed are certainly out of the question, if you ask me. :p

[Fire]

this thread makes me sleepy

[Mithrael]

Spider-dan, ah, i thought i must have been getting that wrong. I don't think that's out of reason.

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.

If /wait were reliable, I'd aggree. Unfortunately, /wait isn't completely unreliable. for example:

/ja "Sneak Attack" <me>
/wait 1
/ja "Trick Attack" <me>

will succeed greater than 99% of the time, yet other times Trick Attack won't fire. /wait is clientside, which means that latency and lag can affect your results. Auto-attack is server-side. Things that are server-side will tick on regardless of your internet connection. That's why sample size is crucial, while you may have a slight delay in your graphic, your next attack will be "on-schedule" and over the course of many attack, the inconsistencies will work themselves out. The concept behind stopwatch timing is based on larger sample sizes, 20, 30, 40+ swings. As long as you don't take any other actions, the timer shouldn't stop for anything. Perhaps you could argue that parry, guard, counter, shield block, etc. do play a small role in delay. I haven't seen any evidence to support the idea that the auto-attack timer stops when the PC takes no action though. That idea is especially suspect when you consider that the animation for swings is often eaten due to an action like parrying, shield block, or getting hit with a critical. The hit occurs in the log, but not on your screen.

The idea that the delay is based on 60fps seems to be pretty sound, given that the game is designed on a ps2 which has a framerate of 60. The question is where in the firing does the ammo/weapon delay overlap.

I still haven't had time to investigate this much more. But I still think to have a fair representation, you have to remove every possible alteration. THF/NIN does have innate haste that should not affect ranged attacks. However, until it's been safely ruled out, I can't say that the /nin subjob isn't affecting results. About the only safe jobs to test this on are thf, drk, sam, rdm, and war. between them you should be able to have a varied combination of weapons and ammos, should you have the spare money to donate to science.

If I'm able to finish off Ole' Man Maat tonight I'll do my part and test what I can as DRK/WAR with various delay bolts. I can't do much as RNG or THF though, they aren't really high enough level to accomplish much.

In any case, /wait should be able to give you an idea of delay within a second or two margin. just anything fractional can't be factored in, and there is almost certainly some fractional part to the delay.

[Mithrael]

Ok, so I did some brief tests.

Job combo was DRK70/THF35.

Macros looked like this:
/ra <t>
/wait x
/echo x seconds
/ra <t>

Equip set #1
Great Bow+1 (delay: 524)
Horn Arrow (delay: 90)
total delay: 614
x = 8
614 / 8 = 76.75


Equip set #2
Great Bow+1 (delay: 524)
Bone Arrow (delay: 120)
total delay: 644
x = 8
644 / 8 = 80.5

Equip set #3
Zamburak +1 (delay: 280)
Holy Bolt (Delay: 192)
total delay: 472
x = 6
472/6 = 78.67

Equip set $4
Zamburak +1 (delay: 280)
Holy Bolt (Delay: 288)
total delay: 568
x = 6
568/6 = 94.66

Ok, so I'm pretty much more confused than ever. It appears that ammo has a less profound affect on delay than the weapon itself. It's hard to say though since there isn't much difference between the slowest and fastest arrows. The only things that this (extremely crude) test confirms is that the delay is not 60, and that delay:second ratio doesn't appear to be very steady for ranged weapons. Unfortunately .99 seconds is a lot of skew to make anything of these results, so the test is nearly useless.

[Spider-Dan]

Originally posted by Mithrael
Auto-attack is server-side. Things that are server-side will tick on regardless of your internet connection. That's why sample size is crucial, while you may have a slight delay in your graphic, your next attack will be "on-schedule" and over the course of many attack, the inconsistencies will work themselves out. The concept behind stopwatch timing is based on larger sample sizes, 20, 30, 40+ swings. As long as you don't take any other actions, the timer shouldn't stop for anything.

My point is that this is not verifiable. But setting that aside, there is a better argument to make.

First of all, as I previously said, if there is uneliminated lag in a test, it will drop your delay/sec lower than what it actually is. For example, suppose I used a gun/bullet combo with exactly 900 delay (Hellfire + silvers should work). Now, based on other tests I've run, I can safely say that a /wait 9 macro (which would put delay/sec at exactly 100) almost certainly wouldn't work, if for no other reason than lag. You'd probably need to use a /wait 10, which would put delay/sec at 90. The point of all this is that as you get less precise with your timing, the delay per sec result you get becomes lower, not higher.

Most (actually, all) of the reported stopwatched melee tests I've seen wind up with some number in the mid/low 60s as delay/sec, which everyone rounds down to 60. Yet, based on the above statement, you should be rounding up if you have a lack of precision, not down. In order for you to round down, that would mean that you are saying that your swings are having negative lag (they are going faster than they should be), which should only happen if you have haste, 2A, DW, etc., which everyone obviously eliminates from the start.

So why is 60/sec accepted, instead of (for example) 70/sec?

[VZX]

Originally posted by Mithrael
Ok, so I did some brief tests.

Job combo was DRK70/THF35.

Macros looked like this:
/ra <t>
/wait x
/echo x seconds
/ra <t>

Equip set #1
Great Bow+1 (delay: 524)
Horn Arrow (delay: 90)
total delay: 614
x = 8
614 / 8 = 76.75


Equip set #2
Great Bow+1 (delay: 524)
Bone Arrow (delay: 120)
total delay: 644
x = 8
644 / 8 = 80.5

Equip set #3
Zamburak +1 (delay: 280)
Holy Bolt (Delay: 192)
total delay: 472
x = 6
472/6 = 78.67

Equip set $4
Zamburak +1 (delay: 280)
Holy Bolt (Delay: 288)
total delay: 568
x = 6
568/6 = 94.66

Ok, so I'm pretty much more confused than ever. It appears that ammo has a less profound affect on delay than the weapon itself. It's hard to say though since there isn't much difference between the slowest and fastest arrows. The only things that this (extremely crude) test confirms is that the delay is not 60, and that delay:second ratio doesn't appear to be very steady for ranged weapons. Unfortunately .99 seconds is a lot of skew to make anything of these results, so the test is nearly useless.

what's the difference between eq set #3 and eq #4?

are you trying to write Bloody bolt which has 240 Delay on set #4?

If x you gathered is the smallest integer you can have to make 2 ranged attack works, there is some possibility that there is an exact time for delay / (wait) p, where x-1 < p < x

[Mithrael]

Most (actually, all) of the reported stopwatched melee tests I've seen wind up with some number in the mid/low 60s as delay/sec, which everyone rounds down to 60. Yet, based on the above statement, you should be rounding up if you have a lack of precision, not down.

You're right, a stopwatch test is really a pretty bad way to do it. However, I have not seen the tests to which you refer. Maybe you could post a link, or the data itself? Anyway, since what you describe with the times actually being in the mid-60s wasn't at all my experience, I did the following test.

https://webspace.utexas.edu/carrbm1/...delay_data.htm

I took a video with each of those weapons (the videos are linked in the html if you want to see them to verify). I then opened the video in VirtualDub and wrote down the time index of the frame of each strike.

A strike in this test is counted as the first frame in which the blue burst with the white sparkles appears. The first time index is only used as a basis for the first delay, it is not counted as a strike since it's more or less impossible to count the time from when "Attack" is engaged and the first strike is made.

Anyway, you can see the results in the HTML. The slowest was 58.85311871, or rougly delay/59. The fastest was 60.11583012, which as you say should technically rounded up to delay/61. I think you'll see that it's pretty convincing that delay for melee weapons is indeed 60/second.

are you trying to write Bloody bolt which has 240 Delay on set #4?

Oops. The second test was with Sleep Bolts which are delay 288.

While there is a possibility that there is some odd number that fits, I'm skeptical at this point. After thinking these (inconclusive) test results over a bit, I'm actually inclined to believe the following (which pretty much sums up what people ahve already said matches their gut feelings).

The sum of the two delays is more like this:

[code]
[weapon delay]
[ammo delay]
[/code]

than

[code][weapon delay][ammo delay][/code]

If delay is indeed based on animation (as it is with melee attacks), one could make the speculation that the delay of the bow is what you'd expect (bow delay/60), and the delay of the arrow is when you pick up the arrow and but it to the bow string to the point it fires (arrow delay/60). The catch is finding when the arrow delay really starts, and seeing if it applies to other bows. Does each bow, or bow model have a diferent delay before the arrow starts, etc. I don't really know at this point.

To devise a reasonable test pretty much involves some sort of outside mechanism (bot/scripting) to measure the small increments of time needed and input the commands to fire.

Ideally the test would decrease the allowance until it found the value.

i.e. 10 seconds, 5 seconds, 7 seconds, 6 seconds, 5.5 seconds, 5.75 seconds, 5.6, done.

Then repeat it multiple times, perhaps 10 iterations per bow and arrow combination. Obviously bows of very different delays would have to be used (sniping and sargna come to mind.) To make sure rapid shot wasn't interfering as the tolerance got lower.

However, my desire to find out how it really works doesn't exceed my distaste for botting. So at the moment, I don't really see myself testing it any farther.

Actually... I just thought of one more thing I can try that will either disprove or provide more evidence (but not prove) to the sliding ammo delay thoery. -.-; Guess i'll try it... Damned obsessive behavior.


Edit: Theory about shifting delays is just flat out wrong. At a loss until I can come up with a legal way to accomplish anything more specific.

[imac2much]

A fellow longhorn

Great testing and information, Mithrael. Keep up the good/hard work.

[Spider-Dan]

Originally posted by Mithrael
You're right, a stopwatch test is really a pretty bad way to do it. However, I have not seen the tests to which you refer. Maybe you could post a link, or the data itself?

It's fairly common; I think that's what you referred to when you talked about measuring time over "20, 30, 40+ swings." It's when you engage, start your stopwatch, and stop it after x amount of swings, then calculate seconds per swing and determine delay per second from that.

On a side note, I suggest you use Marksmanship for your tests. Archery is erratic and nonsensical.

Try a test with a bow+wooden arrows (120 delay) vs. scorpion arrows (90 delay) and you will see what I mean.