Will you leave UOSA if the hally mage is nerfed?

[Halbu]

Can anyone who played during T2A honestly tell me that they do not remember debuff/harm spamming to block heals while waiting for the halberd kill?

Yea this was possible but of course the hally couldn't be cycled as fast as it is now. It worked differently. But yes the hally swung very soon after equipping, like it does on UOSA.

The delay before you swing is minor and by the time you close in on your opponent you're usually ready to swing.

[Kaivan]

The combo that I thought you were first talking about Kaivan was the common explosion, ebolt, hally combo used here on UOSA. This combo involves prepping explosion, hally, target, ebolt, target, hally after initially hitting with a decent hally blow from the beginning. After this prolonged discussion went on for ages, it appeared that you shifted that combo to the explosion, ebolt(target), and than hally. So to be honest it's been unclear to me several times what combo you were talking about to begin with here. The fact of the matter is if we are talking about the two different variations of the explosion(target), ebolt(prep or target), hally combo there is still a significant amount of time left over for the hally delay no matter what the situation is with it being prepped or targetted. This would not matter if you equipped casted during the ebolt spell or not(would be stupid to equip cast if you could weapon cycle). There is no disputing this known fact despite any misinterpretation between what combo is being discussed.

If you believe that this is due to some sort of mis-communication, then we'll leave it at that. However, I will note that I have not claimed (at least intentionally) any one specific combo. I have only attempted to address the combos that have been presented, which has commonly been the explosion/energy bolt/hally combo. If we're talking about the explosion/prep ebolt/hally/release ebolt combo, then it is much more plausible that such a combo could be pulled off. In fact, the prep time doesn't even necessarily have to be some extremely small period of time for that to work with relatively good results. All it has to do is be effective within 3 seconds of equipping, which leaves multiple options for creating a system that allows for a 'prep time'.


As for the code:

Aside from the fact that your code does change the way that the system works drastically by moving the actual swing to the beginning, the code is specifically tailor made for hally cycling. In fact, the only possible 'exploit' of this system is disarming a weapon and then re-arming (not weapon switching or any of the fantastic ideas), which brings us right back to the mini-patch, that specifically states that it was fixed.

An additional problem is that if the code actually operated this way on OSI servers, then OSI couldn't actually fix this code as they said they did in they did in the mini-patch. This is because of the fact that two things are dependent on your PrepTime, the transition to state 1, and ResetSwingState(0) for archery movement. Thus, if any number other than 4 is used, this system breaks archery by making the delay for movement extremely long. As a result, this system 'unfixable' via modification to the PrepTime. If, however, they decided to use 4 states (this theory is equally valid due to the scope of what it changes), this wouldn't be an issue as OSI could have scaled the point of the swing to any position in the swing, and it wouldn't hinder archery.

Finally, in a somewhat ironic twist considering the previous bit about archery, this system makes archery completely broken another way. Because of the fact that you have modified ResetSwingState to pass in a 0 when moving with archery, it is possible to wait until just after your shot should hit or miss and then move a single tile, resetting your swing counter and state to 0. This produces 2 second archery shots under all conditions and is certainly not a pragmatic result.

One other thing, your code suffers from a problem that all code under this type of system suffers: The code does not produce true insta-hit; it still has a 0.25 second delay between the animation and the damage because it must pass through state 1 and state 2, which takes 1 tick to do so. This requires the same fix under all systems which is to add new lines of code that forcefully set all of the right variables to complete a swing, and set all of the appropriate variables to 0 on the mobile.

Further, here is a much simpler combat system, using the same combat syntax:

Code: Select all

        public virtual int AdvanceSwingState()
        {
       int OldState, NewState;

            IWeapon weapon = this.Weapon;

            int swingDelay = weapon.GetDelay(this);
            int swingCounter = this.SwingCounter;

            int AnimationState = (weapon != null) && weapon.IsRanged() ? 4 : 0; // ranged or melee

            AnimationState = swingDelay <= AnimationState ? 0 : swingDelay - AnimationState;

            int PrepState = AnimationState <= 4 ? 0 : AnimationState - 4;

            OldState = SwingState;
            NewState = OldState;

            switch (OldState)
            {
                case 0: if (swingCounter >= PrepState)
                    {
                        swingCounter = PrepState;
                        NewState = 1;
                    }
                    break;
                case 1: if (swingCounter >= AnimationState)
                    {
                        swingCounter = AnimationState;
                        NewState = 2;
                    }
                    break;
                default: if (swingCounter > swingDelay)
                    {
                        swingCounter = 0;
                        NewState = 3;
                    }
                    break;
            }

            SetSwingCounter(swingCounter);
            SetSwingState(NewState == 3 ? 0 : NewState);

            return NewState;
        }

        public virtual void ResetSwingCounter( Item item )   // Equip/arm delay, only fired on equip packet
        {
            if (item is IWeapon || item is IArmor || item is IClothing)
            {
                Some code here to set the swing counter to a variable, can be statically set, or dynamically set.
                Or a prep time can be set here while the swing counter is left alone.  The options are limitless and flexible.
            }
        }

        public virtual void ResetSwingState(int TargetState)   // Routine is only used as the movement restriction for ranged weapons.
        {
            if (TargetState == 0)
            {
                SetSwingCounter(0);
                SetSwingState(TargetState);
            }
            else
            {
                SetSwingState(TargetState - 1);
                AdvanceSwingState();
            }
        }

        public virtual void RangeWeaponMovement()   // Routine is called during movement.
        {
            if ( weapon != null && weapon.IsRanged() )
                ResetSwingState(1);
        }

        public virtual void CombatHeartBeat()
        { 
            if (SwingCounter < 1000)
                SwingCounter++;

            if (Alive && AccessLevel != AccessLevel.Counselor)
            {
                if ( Combatant != null )
                {
                    int OldState = SwingState;
                    int NewState = AdvanceSwingState();

                    if (OldState != NewState && NewState >= 2)
                    {
                        IWeapon weapon = this.Weapon;

                        if (InRange(Combatant, weapon.MaxRange))
                        {
                            if (NewState == 2) // Start Animation/Swing
                            {
                                weapon.OnStartSwing(this, Combatant);
                                if(!weapon.IsRanged)
                                {
                                    SetSwingState(0);
                                    SetSwingCounter(0);
                                    weapon.OnFinishSwing(this, Combatant);
                                }
                            }
                            else // Start Damage/End Swing
                            {
                               weapon.OnFinishSwing(this, Combatant);
                            }
                        }
                    }
                }
            }
        }

Finally, here is a mock up system that uses 4 states instead of 3:

Code: Select all

       public virtual int AdvanceSwingState()
       {
            int OldState, NewState;

            IWeapon weapon = this.Weapon;

            int swingDelay = weapon.GetDelay(this);
            int swingCounter = this.SwingCounter;

            int swingEnd = swingDelay <= n ? 0 : swingDelay - n;

            int swingAnimate = (weapon != null) && weapon.IsRanged() ? 4 : 0; // ranged or melee

            swingAnimate = swingEnd - SwingAnimate <= 0 ? 0 : swingEnd - swingAnimate;

            int archeryHold = swingAnimate <= 4 ? 0 : swingAnimate - 4;

            OldState = SwingState;
            NewState = OldState;

            switch (OldState)
            {
                case 0: if (swingCounter >= archeryHold)
                    {
                        swingCounter = archeryHold;
                        NewState = 1;
                    }
                    break;
                case 1: if (swingCounter >= animateSwing)
                    {
                        swingCounter = animateSwing;
                        NewState = 2;
                    }
                    break;
                case 3: if (swingCounter >= swingEnd)
                    {
                        swingCounter = swingEnd;
                        NewState = 3;
                    }
                    break;
                defaut: if (swingCounter > swingDelay)
                    {
                        swingCounter = 0;
                        NewState = 4;
                    }
            }

            SetSwingCounter(swingCounter);
            SetSwingState(NewState == 4 ? 0 : NewState);

            return NewState;
        }

        public virtual void ResetSwingCounter( Item item )   // Equip/arm delay, only fired on equip packet
        {
            if (item is IWeapon || item is IArmor || item is IClothing)
            {
                Some code here to set the swing counter to a variable, can be statically set, or dynamically set.
                Or a prep time can be set here while the swing counter is left alone.  The options are limitless and flexible.
            }
        }

        public virtual void ResetSwingState(int TargetState)   // Routine is only used as the movement restriction for ranged weapons.
        {
            if (TargetState == 0)
            {
                SetSwingCounter(0);
                SetSwingState(TargetState);
            }
            else
            {
                SetSwingState(TargetState - 1);
                AdvanceSwingState();
            }
        }

        public virtual void RangeWeaponMovement()   // Routine is called during movement.
        {
            if ( weapon != null && weapon.IsRanged() )
                ResetSwingState(1);
        }

        public virtual void CombatHeartBeat()
        { 
            if (SwingCounter < 1000)
                SwingCounter++;

            if (Alive && AccessLevel != AccessLevel.Counselor)
            {
                if ( Combatant != null )
                {
                    int OldState = SwingState;
                    int NewState = AdvanceSwingState();

                    if (OldState != NewState && NewState >=2 && NewState <= 3)
                    {
                        IWeapon weapon = this.Weapon;
                        if (InRange(Combatant, weapon.MaxRange))
                        {
                            if (NewState == 2) // Start Animation/Swing
                            {
                                weapon.OnStartSwing(this, Combatant);
                                if(!weapon.IsRanged)
                                {
                                    SetSwingState(3);
                                    weapon.OnFinishSwing(this, Combatant);
                                }
                            }
                            else // Start Damage/End Swing
                            {
                               weapon.OnFinishSwing(this, Combatant);
                            }
                        }
                    }
                }
            }
        }

This system has the advantage of preserving more of the functionality and isolating all of the relevant changes one place: the advanceSwingState functon. Even ResetSwingState and ResetSwingCounter remain untouched. Also, this system is highly adaptable, and it only requires a single number to be changed, the n value in the calculation of swingEnd to change the position from the end of the swing that you are at with . As a final bonus, this system does not suffer from the problems surrounding using ResetSwingState(0) for archery.

[Matty]

it's very hard for me to understand these codes so i'm not even going to try. but i feel like what's being argued is if insta hit upon re-arming your weapon is era accurate? it was! i remember this well.

[Faust]

Sorry, but the following line from the code above should have read...

Code: Select all

        
        public virtual void RangeWeaponMovement()   // Routine is called during movement.
        {
            if (weapon != null && weapon.IsRanged())
            {
                if ( SwingState <= 1 )
                    ResetSwingState(0);
            }
        }

The arguments involving one tick from animation to damage being incorrect no matter what is kind of weak in my honest opinion.

How can you rule the possibility that the animation state did not simply get changed to 0 instead of 6 for melee?

That is the most simple modification that could be made to create a version of insta hit. Who cares if the animation may not take place sometimes? The same experience can happen in the original swing timer code by being out of range for the animation and getting back in range for the damage. To even consider the possibility that it HAS to be in sync with the animation state requiring the code to be changed rather drastically is a fool's rush to judgement.

What is the point of that second set of code in your post Kaivan?

That set seems like a huge drastic change to the system from the original code. The code example that was provided by me was due in part to your request and that was pretty much it. You asked for code that changed the original swing timer with minor modifications that utilizes 'wrestling' and you got it. The system could be considered fundamentally changed drastically but code wise very little changed drastically.

Also, it seems you may be getting a little ahead of yourself Kaivan. We are not going to produce a valid form of era accurate insta hit without producing the original version that was patched in on February 2nd, 1999 before the February 26th, 1999 patch that would have altered it in some way shape or form. This clearly means we need a form of insta hit code that 'made slow weapons swing faster by disarming/rearming' first followed by a version that would have made some correction to that system in a minor fashion. Honestly, the code that was posted by me above is the closest to anything created so far for such a thing if you ask me.

[Kaivan]

Sorry, but the following line from the code above should have read...

Code: Select all

        
        public virtual void RangeWeaponMovement()   // Routine is called during movement.
        {
            if (weapon != null && weapon.IsRanged())
            {
                if ( SwingState <= 1 )
                    ResetSwingState(0);
            }
        }

The arguments involving one tick from animation to damage being incorrect no matter what is kind of weak in my honest opinion.

How can you rule the possibility that the animation state did not simply get changed to 0 instead of 6 for melee?

That is the most simple modification that could be made to create a version of insta hit. Who cares if the animation may not take place sometimes? The same experience can happen in the original swing timer code by being out of range for the animation and getting back in range for the damage. To even consider the possibility that it HAS to be in sync with the animation state requiring the code to be changed rather drastically is a fool's rush to judgement.

Regarding the code modification, that piece of code allows a player to shoot and move, which is a function we know wasn't even tackled until UOR. However, the main point is that you have to tailor make such a system as this to produce these functions, and that there is no adaptability without consequences for other combat styles.

As for insta-hit, the fix for insta-hit is required in any implementation that doesn't follow a system that is substantially different from the demo. The reason for this is because you will enter the state required to swing your weapon on one tick, and it takes another tick to reach the state where the weapon actually does its damage. Thus, the weapon doesn't actually hit at the beginning of the animation, it hits a tick later. As further corroboration of exactly what the beginning of the animation really means, we can turn to OSI, which reverted to the insta-hit system (minus any prep time) with publish 15, or we can look at insta-hit scenarios during the rest of UOR. During that time, and even now, when you swing a melee weapon, the damage happens exactly as the animation starts, not a tick later. If their code for determining how you moved between states looked anything like the code from the demo (it doesn't need to look very different at all), they would need those same forceful modifications in order to achieve that result.

What is the point of that second set of code in your post Kaivan?

That set seems like a huge drastic change to the system from the original code. The code example that was provided by me was due in part to your request and that was pretty much it. You asked for code that changed the original swing timer with minor modifications that utilizes 'wrestling' and you got it. The system could be considered fundamentally changed drastically but code wise very little changed drastically.

And that's exactly the point, because the entire system is flipped on its head, it is a drastic change. However, in the realm of drastic changes, it's pretty easy to see what issues exist with your proposed system, and to propose a system that is just as drastic, but doesn't contain any of the problems that your system inherently contains.

Also, it seems you may be getting a little ahead of yourself Kaivan. We are not going to produce a valid form of era accurate insta hit without producing the original version that was patched in on February 2nd, 1999 before the February 26th, 1999 patch that would have altered it in some way shape or form. This clearly means we need a form of insta hit code that 'made slow weapons swing faster by disarming/rearming' first followed by a version that would have made some correction to that system in a minor fashion. Honestly, the code that was posted by me above is the closest to anything created so far for such a thing if you ask me.

I understand that, and if you look at the first set of code posted, it contains one section for potential changes (this is where any exploits would exist and be subsequently fixed), a single line of code changed, and the required changes to force insta-hit to work properly. That set of code follows the base system of the pre-T2A code much more closely, while maintaining a wide open door for a variety of possible exploits.

In any case, I've said my piece on this subject, and I'll continue to look in for any more era information people can bring up regarding specific issues such as swing holding (again, the entire point of our code review).

[Faust]

Regarding the code modification, that piece of code allows a player to shoot and move, which is a function we know wasn't even tackled until UOR. However, the main point is that you have to tailor make such a system as this to produce these functions, and that there is no adaptability without consequences for other combat styles.

Uhh, no it doesn't? When you move during the four ticks of both the prep and animation time it resets back to the beginnning of the prep time just like it does in the original swing code. I'm not quite sure or even understand how you came to such a conclusion that you could shoot and move with the additional modification made with the movement restriction code that was added before your response.

Thus, the weapon doesn't actually hit at the beginning of the animation, it hits a tick later. As further corroboration of exactly what the beginning of the animation really means, we can turn to OSI, which reverted to the insta-hit system (minus any prep time) with publish 15, or we can look at insta-hit scenarios during the rest of UOR. During that time, and even now, when you swing a melee weapon, the damage happens exactly as the animation starts, not a tick later.

Would you happen to be able to prove this?

EA did in fact modify the animation speed of weapon swings during UOR and this held true through publish 15 that made insta hit look retarded compared to how it looked during t2a. I don't see how someone could make such a bold claim without any doubt what so ever. Publish 15 insta hit was nothing like the original isnta hit and this is well documented information.

I understand that, and if you look at the first set of code posted, it contains one section for potential changes (this is where any exploits would exist and be subsequently fixed), a single line of code changed, and the required changes to force insta-hit to work properly. That set of code follows the base system of the pre-T2A code much more closely, while maintaining a wide open door for a variety of possible exploits.

Would you mind showing me such an exploit under the first set of code?




Honestly, it appears that your mindset is stuck on weapon swings happening at the end of the timer with some sort of modification to the equip/arm delay that was ninja reverted during UOR sometime. I was stuck in this same mindset and came to the conclusion that such a system has very little room for correct insta hit code after several designs failed in the past couple years working with it. Would be very interested to see if you or anyone else can come up with something that could follow the required list or steps that would potentially give us the most accurate form of the combat code.

The prep time added in February 2nd, 1999 defies the sole fabric of having an equip/arm delay function when the final blow of a weapon takes place at the end of the swing duration without heavy code modfication. The only way this could even remotely be correct is under a system that held your weapon swings verifying if one is ready or not upon equipping/arming. However, we both know archery did not save and this would require two fundamental systems to be in place to make the two significantly different based on logic statements.

[Kaivan]

Consider this a final direct response on this subject without any new information (ideally regarding swing holding).

Regarding the code modification, that piece of code allows a player to shoot and move, which is a function we know wasn't even tackled until UOR. However, the main point is that you have to tailor make such a system as this to produce these functions, and that there is no adaptability without consequences for other combat styles.

Uhh, no it doesn't? When you move during the four ticks of both the prep and animation time it resets back to the beginnning of the prep time just like it does in the original swing code. I'm not quite sure or even understand how you came to such a conclusion that you could shoot and move with the additional modification made with the movement restriction code that was added before your response.

Actually you're right, it doesn't do that, it breaks it in the other direction (and you didn't actually make it publicly known that you made your fix until 2 hours after it was pointed out). It causes each step to force you back to the beginning of the swing, resulting in an 8 tick wait period.

Thus, the weapon doesn't actually hit at the beginning of the animation, it hits a tick later. As further corroboration of exactly what the beginning of the animation really means, we can turn to OSI, which reverted to the insta-hit system (minus any prep time) with publish 15, or we can look at insta-hit scenarios during the rest of UOR. During that time, and even now, when you swing a melee weapon, the damage happens exactly as the animation starts, not a tick later.

Would you happen to be able to prove this?

EA did in fact modify the animation speed of weapon swings during UOR and this held true through publish 15 that made insta hit look retarded compared to how it looked during t2a. I don't see how someone could make such a bold claim without any doubt what so ever. Publish 15 insta hit was nothing like the original isnta hit and this is well documented information.

Regardless of whether EA changed the animation itself (the animation time was reduced from 5 ticks to 4) with UOR is irrelevant. Under any system that is similar to the demo in basic structure absolutely needs these fixes. It isn't something that is dependent on the animation length, or anything of the sort.

To give you an example, let's suppose we have this information:

Swing length = 20 ticks
Animation start = 20 ticks
Length of animation = 5 ticks

On tick 19, you have not started your swing state has not been set to the appropriate state to start swinging. On tick 20, your state is set to the proper point to begin the swing. It is not until tick 21 that you move to the right state to finish the swing. This is true in all systems, and it produces a 1 tick delay between the animation start and when the swing actually happens. The length of the animation has nothing to do with the insta-hit.

Regarding publish 16 insta-hit (small error, it wasn't publish 15), the insta-hit at that time looked identical to what it did during the rest of UOR. The only difference was that they removed the code that made you hit later in the swing, resulting in insta-hit for anyone using a melee weapon. This is exactly the same as it was during T2A when everyone had insta-hit, except that the animation played faster (which, again, is irrelevant).

As for proof of the fact that it hits at the very beginning of the animation, just get on an OSI account and test it. Pick up any random melee weapon and attack something, and you'll find that your swing and the start of the animation happen at the same time.

I understand that, and if you look at the first set of code posted, it contains one section for potential changes (this is where any exploits would exist and be subsequently fixed), a single line of code changed, and the required changes to force insta-hit to work properly. That set of code follows the base system of the pre-T2A code much more closely, while maintaining a wide open door for a variety of possible exploits.

Would you mind showing me such an exploit under the first set of code?

One quick example would be the following:

Code: Select all

        public virtual void ResetSwingCounter( Item item )   // Equip/arm delay, only fired on equip packet
        {
            if (item is IWeapon || item is IArmor || item is IClothing)
            {
                SetSwingCounter(20);
            }
        }

That's not to say that this is exactly how it was implemented, but it's easy to jump ahead in your swing this way, and it can be implemented in one of many ways, including ways that don't break swing timers (i.e. by checking the current swingCounter or getting the total delay of the currently equipped weapon).

The point is that the functionality can all be contained in here, and that it is highly adaptable (and fixable).

Honestly, it appears that your mindset is stuck on weapon swings happening at the end of the timer with some sort of modification to the equip/arm delay that was ninja reverted during UOR sometime. I was stuck in this same mindset and came to the conclusion that such a system has very little room for correct insta hit code after several designs failed in the past couple years working with it. Would be very interested to see if you or anyone else can come up with something that could follow the required list or steps that would potentially give us the most accurate form of the combat code.

The prep time added in February 2nd, 1999 defies the sole fabric of having an equip/arm delay function when the final blow of a weapon takes place at the end of the swing duration without heavy code modfication. The only way this could even remotely be correct is under a system that held your weapon swings verifying if one is ready or not upon equipping/arming. However, we both know archery did not save and this would require two fundamental systems to be in place to make the two significantly different based on logic statements.

Well, if we consider the concept of a 'ninja revert' during UOR, both systems would have been effected by it. There is no documentation that actually shows that the prep time was ever removed, yet we know that it doesn't exist. Thus, whatever implementation that actually produced the prep time would have been ninja patched, regardless of how it worked. The major difference between each system is that one system is a modification to the animation length and a modification to the equip delay, while another is a modification to the animation length and the rest of the swing mechanics as well.

Finally, to reiterate what I said at the top, I won't be discussing this issue any further. Effort should be concentrated on attempting to find information about swing holding because that is the point of the investigation.

[Roser]

As for proof of the fact that it hits at the very beginning of the animation, just get on an OSI account and test it. Pick up any random melee weapon and attack something, and you'll find that your swing and the start of the animation happen at the same time.

Ive opened a new 14 day trial test account if anyone would like to use it. What Kaivan says here is true.

Account name: tinfoilhat
Password : davidicke

BTW these 14 day trial accounts are unlimited in use, you don't even have to use a new e-mail to register.

[Faust]

Actually you're right, it doesn't do that, it breaks it in the other direction (and you didn't actually make it publicly known that you made your fix until 2 hours after it was pointed out). It causes each step to force you back to the beginning of the swing, resulting in an 8 tick wait period.

How do you think it works for the original swing timer in the demo?

When you take a step in state one(PrepState/InitialDuration) or two(AnimationState/SecondDuration) it falls back 8 ticks too... The InitialDuration and SecondDuration are 4 ticks each and everytime you move one step with a ranged weapon it falls back to the InitialDuration at all times. There is no difference between the two systems besides the shot starting at eight ticks at the beginning of the SwingCounter instead of taking place eight ticks from the end of it.

Both systems are pretty much identical in regard to shooting a bow and moving around with it.

Code: Select all

        
        public virtual void ResetSwingCounter( Item item )   // Equip/arm delay, only fired on equip packet
        {
            if (item is IWeapon || item is IArmor || item is IClothing)
            {
                SetSwingCounter(20);
            }
        }

Was actually hoping for something more with some logic behind it with whatever example you ended up posting instead of something that would obviously never be used. We already know a programmer can alter/modify code into anything the imagination can dream up. However, providing an example that OSI may have possibly used is an entirely different story. In other words I was looking more towards an example that could possibly explain the prep time before damage after equipping along with the equip/arm delay or even the exploit fixed in February 26th.

There have been many designs made in this fashion ranging from grabbing/altering the SwingCounter, SwingState, and even the SwingDuration of the currently equipped weapon but nothing has ever caught my attention with any substantial results or even hint at the idea of "Oh hey this could possibly be it..." after playing around with it. Definitely have not ruled out this possibility but it's starting to seem that way after these past two years working with the various designs.


Also, on a side note... the prep time could easily have been removed when EA reverted back to the original swing timer mechanics with the UOR publish. The same could possibly even be true with the February 26th patch meaning the exploit could have been introduced with the original insta hit patch. Despite whatever the situation there will be no true era accurate insta hit system if the final version cannot be logically explain through various versions with patch/updates from the critical combat patches(aka my list/steps towards era accurate swing code).

There should be serious hesitation to whatever final product is produced if the following sequence can't be reproduced with multiple versions until the final code.

1. Use the original OSI combat timer code.
2. Implement Patch Colored ore, granting karma, and combat changes Feb 2 1999 10:57AM into the code.
3. Update timer using Patch Mini-update with small fixes Feb 26 1999 11:25AM
4. Take Patch Mini-Update Apr 28 2000 3:30PM CST into consideration for how little the code actually changed.
5. If a double hit exploit does not exist, you are wrong.
6. Finished, era accurate insta hit combat code.

Kaivan, there is no doubt in my mind that your first set of code will be the starting point for whatever system ends up being developed due to your heavy influence. However, it will be interesting to see how your version makes it to step one and finally onto step two. I will mess around with your code to see if there is any possible way to reproduce the following first two steps but there are some serious doubts in my mind due to past designs that were very similar if not identical.



PS: Also, just wanted to point out that the transition from one tick to the damage is not really even noticable unless you knew it existed in the code. Guarentee not one person here would notice it if they didn't know it was threw in out of no where for testing purposes.

[Faust]

Hrm, made some interesting modifications to Kaivan's code that would be nice to try on the test center...

[Roser]

I've played around with what Faust was working on, and at first glance, I have to say it feels good.

Once we have time to mess around with it a bit more, I will post up a video of what tank mage pvp looks like.

[Brules]

The big question is: Will Faust play with it - or pull another epic dodge after changing pvp yet again?

[Guerrilla]

Im all for the pvp changes, as far as nerfing the hally goes, good deal, but i tell u what unless you up the damage dealt by a halberd, it will be pretty pointless to use one... second, Faust with 5900 posts, give it a rest bro, you've tried to explain your opinions 5900 times and people still wont listen to your candy ass. NUFF SAID

[Faust]

The big question is: Will Faust play with it - or pull another epic dodge after changing pvp yet again?

Why does me playing concern you or anyone else for that matter?

Second, the current swing timer was coded by Derrick... not me.

How does that equate to me 'changing pvp' out of curiousity?

[Bicchus Dicchus]

OP =

Bitching to staff in order to get things your way, is one thing we don't need to be era-accurate about, thanks.


burn