Blackbeard wrote:
Didn't understand a word there. The timer is separate from the states? That can't be right at all.
What is there not to understand? The states only advance when you have a combatant because the routine that is called inside of the code that changes the states is called ONLY when you don't have a combatant. The timer still runs if you tab out, get off screen, kill your opponent, and whatever multiple situations that can occur in order to lose a combatant. However, the routine that changes the states does not get called when a combatant isn't present. This isn't that difficult to understand. Also, never said the states wasn't a part of the timer. The swing state is an integer variable attached to the mobile(your character).
Blackbeard wrote:
What's confusing is, earlier in an IRC conversation with Faust, he states:
<Faust> swing, damage, animation = insta-hit
Wouldn't this mean that the damage (state 3), then have to occur before State 2? I guess our conception of insta-hit for the last two years here has been completely wrong but I guess Faust is still going to keep it.
The definition is just going to be completely changed.
You obviously didn't understand a single word in our conversation discussing the original timer.
The animation duration listed in the original code is 4 for archery and 6 for melee weapons(this is just in the timer that allows someone to swing and has no real association with the animation itself). To make insta work in a VERY quick modification to the code you just have to change that variable to 0. This in other words makes the wait time for the animation 0 seconds, meaning it will progress forward to state 3(damage) in one tick.
I don't know what is so hard to understand about this even after being explained to you several times in our conversation.
0, 1, 2, 3
Weapon Duration, Buffer, Animation, Damage
When the wait time for state 2 is 0 ticks in this sequence what do you think happens from state 1 to 3 in this sequence for melee weapons? This should be obvious to anyone if that wait time is 0 ticks when the timer calls this routine every tick(0.25s).
The animation packet is an entirely different discussion and is simply a visual effect with no association with the weapon delay and damage code itself besides telling the packet to be called for a swing.
Blackbeard wrote:
The definition is just going to be completely changed.
He states that this is because of a Patch Note from 2000 that states "Players using melee weapons will now hold their swing until their target is in range."
...
The patch note that you speak of is listed for the UOR publish(an era after the one we are replicating). This clearly tells you that the day before this patch the range check was still being processed in the code after the swing takes place. This same process was active in mid/late '98(a time frame that was before the era we are replicating. We know the code for the range check functioned like this before and after the era we are replicating. I don't see how hard it is to follow from Point A to Point B here...
Blackbeard wrote:
In the end, it kind of sounds like he's just making the instant hit dodge able, which isn't accurate. He even says it himself.
<Faust> theoretically it is dodging but not dodging the animation
<Faust> you will be able to dodge the insta hit by being out of range when it triggers
We can conclusively declare that the range check is in fact accurate after my last paragraph that clearly demostrates that this was the case.
Again, until you learn how to program and understand how the code from the original timer works you will never grasp the concept of how the original timer works. However, Derrick does understand it and can follow the discussion a lot better. If you really want to make accusations that something isn't accurate/false than go learn to read and write C and analyze the original code yourself.
Mens Rosa wrote:What I wonder is how the double-hit bug fits into Faust's proposed system?
This isn't my system.
The double hit exploit actually should be possible by tabbing out in state 3(immediately when you hit) to allow the timer to continue advancing without restarting. This would shift the swing counter and swing state back to state 1(one second before swinging). This is possible because the code for this routine is called every tick(0.25s) meaning the window of opportunity to pull this off is the same.
Axel231 wrote:okay faust can you explain to me with an example of exactly how everything will work with everything to do with weapon swings.
<insert blah blah blah, this isn't divinity
rant>
Divinity is dead, get over it.
The way the original swing timer worked has been explained thoroughly in this thread, please read it.
Alatar wrote:why would you add the ability to dodge a melee attack when theres already a 50% chance to miss at 100 / 100..
Did we develop these game mechanics? Are you asking why we would develop, code, and implement the same code that OSI used in a server that is suppose to be replicating it or what? Please clarify your post since you sound like we are making a server that builds onto t2a instead of one that replicates it.
