UO Second Age

Regarding the patch note, it is lucky that we have comments from Runesabre that were copied from the CoB to the newsgroups. His statement is as follows:

10) The disarm/arm exploit to get slow weapons to hit faster has been fixed. It
will not be to your advantage to disarm/rearm a weapon.

This clears up any ambiguity regarding what the fix actually did. Additionally, with only one source that talks about this supposedly widely known bug (there's a bit of a disconnect here, a widely known bug that only has documentation in one place: a poorly translated Japanese website), the reality is that we're talking about a single player account which is in direct opposition to the patch notes. With such poor backing, it is practically impossible to support the theory that this was a working tactic, because supporting such a theory requires us to throw out the documentation from those who actually develop the game in favor of just one source.

On an interesting note, your own Japanese website source talks about the explosion/hally/ebolt combo (notice I said it in a specific order), not about the purported explosion/ebolt/hally combo.

Finally, I would like to propose a question as a starting point for explaining how wrestling cannot be related to the swing timer: What minor changes would you make to the code for pre-T2A combat in order to produce T2A style combat, hally cycling included?

When I said explosion, ebolt, hally the ebolt would be prepped Kaivan(figured most people knew that besides maybe those that didn't actually play during t2a). That was the most common tactic used with a follow up ebolt and hally if one or the other did not kill. The second ebolt would sometimes be followed by two harms instead. However, the hally would always be ready after both those final sequence of spells.

I'm not sure what your wrestling comment is referring to because I don't believe anyone here said wrestling wasn't associated with the swing timer.

If you are referring to my comment about the change being associated with just the weapon functions and not wrestling than that would be where the misunderstandment took place. The comment was merely an example that could easily have just been associated with the 'dragging' or 'equipping' functions of the layered items in the code that triggered the equip/arm delays in return leaving wrestling untouched. There was nothing about 'separating' wrestling from weapons inside the actual swing timer code with my comment.

Kaivan wrote:because supporting such a theory requires us to throw out the documentation from those who actually develop the game in favor of just one source

So you are theoretically pretty much just saying patch notes are final say in game mechanics?

How about we go back in time some?

Thieves Guild, new skills, and more Feb 24 1999 1:06PM wrote:Your magic resistance will now affect how much damage you take from spells. You can have up to half the damage removed by effectively resisting a spell.

This seems a bit contracticing. Would you not agree?

Unless one of these 'developers' was Nostradamus whom added this feature that was patched well over half a year later into the demo of course.

Patch notes didn't always 'fix' problems entirely and there are many instances where this has held true. So in other words a 'patch' that fixed one instance of a problem does not necessarily mean it always fixed all instances of the problem. I honestly don't think multiple comments many months later through out the era from various sources would be talking about some bug that only existed for a little over two weeks in February. Again, we go back to being able to pull off the combo in the first place. Frankly, it does not matter if you misunderstood the order of the combo. There is still no physical possibility to pull off the combo one way or the other(meaning if the ebolt/flamestrike was prepped before the hally) without a way to bypass several ticks of the default hally delay.

This is a well known fact that cannot be disputed.

Faust wrote:When I said explosion, ebolt, hally the ebolt would be prepped Kaivan(figured most people knew that besides maybe those that didn't actually play during t2a). That was the most common tactic used with a follow up ebolt and hally if one or the other did not kill. The second ebolt would sometimes be followed by two harms instead. However, the hally would always be ready after both those final sequence of spells.

This is exactly how I PVP'd in t2a.
I would either use a fast casted ebolt (put hally on with cursor for ebolt up) then swing, unequip, release ebolt.
-OR-
A couple buddies and I found that explosion followed by hally hit - a fast casted lightning used in this situation - would be able to do damage within a second of each other for a seemingly "instakill" (The hally hit would do dmg just before EXP, and lightning just after)

Was there also a exp, hally FS? Or was that only after you could get higher than 100 magery to guarentee FS cast?

Brules wrote:Was there also a exp, hally FS? Or was that only after you could get higher than 100 magery to guarentee FS cast?

You can guarantee a flame strike by using a scroll

Faust wrote:When I said explosion, ebolt, hally the ebolt would be prepped Kaivan(figured most people knew that besides maybe those that didn't actually play during t2a). That was the most common tactic used with a follow up ebolt and hally if one or the other did not kill. The second ebolt would sometimes be followed by two harms instead. However, the hally would always be ready after both those final sequence of spells.

Actually, no you didn't. Want to know why? Because you actually said so:

Faust wrote:Due to the way the combat code functions it would be physically impossible to sync an explosion/ebolt/hally combo if a hally could not be cycled.

We know this was never the case during the era and it was quite obvious during the last revision for swing mechanics when tinkering with it here.

Halberd delay at 25 stamina equates to 4.75s and an ebolt delay following an explosion spell is 1.75s fast casted or 2.25s when not fast casted. The explosion spell lands 3 seconds after being casted before intitiating the ebolt spell leaving 1.25s fast casted or 0.75s if not fast casted. Throw in the damage delay for the ebolt and that adds an additional 1.0s onto the damage time frame.

We know the equip delay restarts the weapon delay(after the ebolt would be casted in this case) everytime the hally is dragged or equipped with no question.

A 3.75s delay left over on the weapon delay after the ebolt has literally been targeted would never be possible.

There is no physical possibility that this combo could even be remotely feasible unless a weapon could be cycled.

You also said the following in this thread:

Faust wrote:I am in no way entirely certain you could swing a hally every 2 seconds but most certainly positive beyond any doubt that there was a way to time spell casting with energy bolt to have a hally swing directly after by the time the damage landed using some sort of equip/arm exploit.

So yeah, you made it pretty clear that you meant that you could equip after the energy bolt was cast and have the halberd hit.

I'm not sure what your wrestling comment is referring to because I don't believe anyone here said wrestling wasn't associated with the swing timer.

If you are referring to my comment about the change being associated with just the weapon functions and not wrestling than that would be where the misunderstandment took place. The comment was merely an example that could easily have just been associated with the 'dragging' or 'equipping' functions of the layered items in the code that triggered the equip/arm delays in return leaving wrestling untouched. There was nothing about 'separating' wrestling from weapons inside the actual swing timer code with my comment.

I never said that wrestling wasn't associated with the swing timer. What I asked for were several rational and minor changes to the demo combat code that would allow you to swing your weapon more quickly by exploiting the speed of the wrestling timer. This is, at it's core, your entire argument regarding hally cycling. In your own words:

Faust wrote:First, it does not necessarily mean it fixed the wrestling portion of the exploit and could have easily been associated with swapping fast/slow weapons or even layered items like armor that is known to modify the swing counter. On a side note... it would be nice to know if other layed items on production shards still functioned in that manner like it does in the demo by the way.

Of course, I intend to explain that there is no way to produce an exploit centered around wrestling without massive changes to the very base of the weapon system. There is, however, a very simple method for producing such an 'exploit', although it doesn't rely on the wrestling timer at all.

Faust wrote:

Kaivan wrote:because supporting such a theory requires us to throw out the documentation from those who actually develop the game in favor of just one source

So you are theoretically pretty much just saying patch notes are final say in game mechanics?

How about we go back in time some?

Thieves Guild, new skills, and more Feb 24 1999 1:06PM wrote:Your magic resistance will now affect how much damage you take from spells. You can have up to half the damage removed by effectively resisting a spell.

This seems a bit contracticing. Would you not agree?

Unless one of these 'developers' was Nostradamus whom added this feature that was patched well over half a year later into the demo of course.

From the Stratics page regarding spell resistance:

Bear In Mind that these percentages are added or taken-away from the base_damage AFTER the spell is or is not resisted. Meaning that if your base damage has already been reduced by half(by resisting it), it can be reduced yet another 50% (if you have zero evaluate intelligence). This means that spell damage can be reduced by 50% twice, making the range for damage start from 25%, and spread all the way up to 120%.

So yeah, that patch note seems perfectly normal. Now, before we get into a discussion regarding what they actually 'meant' by that line item, let's look at the very next line in that patch:

Your Evaluating Intelligence skill will affect how well your target resists a spell, thus affecting how much damage they take.

Now, we all know that Eval didn't actually effect your ability to resist spells, it simply effected how well the passive resistance worked, but it's worded in the exact same manner as the line preceding it. As a result, we know that both lines are referring directly to the passive abilities of magic resist, not active resistance abilities already present in the skill.

Finally, if we're discussing a combo such as explosion/hally/ebolt, minor modifications to equipping and lifting items can produce results that would allow you to perform this combo adequately without increasing the speed of your swing by some drastic amount. This, however does not solve any outstanding issues regarding weapon holding.

Kaivan forgot the pejorative "son" at the end of his post...

Kaivan wrote:So yeah, you made it pretty clear that you meant that you could equip after the energy bolt was cast and have the halberd hit.

Kaivan, casted and targetted can be two different interpretations with in this game. A prepped ebolt would have to be casted followed by a hally hit in between the release. The same would even hold true if we were talking about the sequence you thought that I was talking about here.

Faust wrote:We know the equip delay restarts the weapon delay(after the ebolt would be casted in this case) everytime the hally is dragged or equipped with no question.

Do you not see the word 'casted' in this post which can also mean the 'finished casting delay process' and not 'targetted' as you clearly jumped to an assumption with here?

Faust wrote:I am in no way entirely certain you could swing a hally every 2 seconds but most certainly positive beyond any doubt that there was a way to time spell casting with energy bolt to have a hally swing directly after by the time the damage landed using some sort of equip/arm exploit.

Why did you even jump to another wild conclusion that I was even talking about the explosion, ebolt, hally combo in this part of my post to begin with? Do you see me talking about the combo or merely the process of casting an ebolt and having a hally hit ready by the time the damage landed as the post clearly mentions?

Kaivan wrote:I never said that wrestling wasn't associated with the swing timer. What I asked for were several rational and minor changes to the demo combat code that would allow you to swing your weapon more quickly by exploiting the speed of the wrestling timer. This is, at it's core, your entire argument regarding hally cycling. In your own words:

Actually, this process is fairly easy to code by moving the swing states from Standard(0), Prep(1), Animation(2), and Damage(3) to instead Prep(0), Animation(1), Damage(2), and the left over time from state two in a static form until state three reverts the timer back to the beginning. This introduces a 'prep time' upon equipping a weapon using the basic SetSwingCounter(0) function under the drag/equip functions for layered items. The swing pretty much moves into the beginning instead of the end of the swing timer. The only minor requirement would be a change in the CombatHeartBeat() function to know what the new changes are for the animation/damage and a minor change in the movement restriction for archery to know that state change for the prep duration(aka state 1) of the original swing timer code. This version actually resembles the version that Derrick coded significantly but excluding the movement restriction of course.

Kaivan wrote:Finally, if we're discussing a combo such as explosion/hally/ebolt, minor modifications to equipping and lifting items can produce results that would allow you to perform this combo adequately without increasing the speed of your swing by some drastic amount. This, however does not solve any outstanding issues regarding weapon holding.

The only problem with such a theory is based on the fact that the equip/arm delay did and has not changed even to this very day from the way it worked in the original code. At least according to your very own words the function in modern UO worked exactly the same. This would have required a 'ninja' patch from point A(when it was patched into the game after PreT2A and before UOR) to point B(when it was unpatched from the game after T2A). Unless your test conducted in modern UO was in fact wrong of course.

It is my belief that a more progressive change took place with the combat code for the timer by shifting the swing/damage from the end of the swing, too instead the beginning, something similiar to my example two paragraphs above but not entirely.

Colored ore, granting karma, and combat changes Feb 2 1999 10:57AM wrote:Damage for your blow is now assessed on your opponent on the start of the swing, instead of at the end.

The insta hit patch here is quite obvious damage will now happen around the same time as the animation. However, it could have also easily included that the swing will now be calculated at the start of the combat timer, instead of at the end of it too.

The reason being is that a combatant is required to shift from one state to the other. Archery was known to be severely nerfed during t2a but the only opportunity for an archer tank mage to pull off a kill during t2a was by utilizing an explosion, flamestrike, heavy bow shot for a near insta kill. The first shot meant everything and due to the fact the equip/arm delay existed it was nearly impossible to ever get another shot off with any opportunity for a kill with a spell combo. I don't really see any valid way with in the code to pull off a shot upon equipping the weapon in the beginning when using such a combo by the animation/damage taking place at the end of the swing instead of the beginning. Perhaps, it may be possible but it has yet to visualize in any of my designs so far.

Faust wrote:

Kaivan wrote:So yeah, you made it pretty clear that you meant that you could equip after the energy bolt was cast and have the halberd hit.

Kaivan, casted and targetted can be two different interpretations with in this game. A prepped ebolt would have to be casted followed by a hally hit in between the release. The same would even hold true if we were talking about the sequence you thought that I was talking about here.

Except that you made that distinction very clear. Look at the bolded parts of the quote. You specifically stated after the energy bolt was targeted, and after the damage had landed from the energy bolt in each quote respectively. You would not have stated that had you not meant it. Additionally, there is a vast difference between these two methods. One method allows you to have your weapon in your hand for up to 2.75 seconds seconds, while the other only requires the weapon to be in your hand for as little as 0.25 seconds, yet both are claimed to produce a swing.

Faust wrote:

Faust wrote:We know the equip delay restarts the weapon delay(after the ebolt would be casted in this case) everytime the hally is dragged or equipped with no question.

Do you not see the word 'casted' in this post which can also mean the 'finished casting delay process' and not 'targetted' as you clearly jumped to an assumption with here?

Yeah, I do. I also see that you clarified which interchangeable meaning you were referring to in the very next sentence by stating that the combo wouldn't be possible with a large delay after the energy bolt was targeted. This clarifies things and places your reference firmly in the 'after it has been targeted' context.

Faust wrote:

Faust wrote:I am in no way entirely certain you could swing a hally every 2 seconds but most certainly positive beyond any doubt that there was a way to time spell casting with energy bolt to have a hally swing directly after by the time the damage landed using some sort of equip/arm exploit.

Why did you even jump to another wild conclusion that I was even talking about the explosion, ebolt, hally combo in this part of my post to begin with? Do you see me talking about the combo or merely the process of casting an ebolt and having a hally hit ready by the time the damage landed as the post clearly mentions?

This has the exact same mechanical results as the combo you're suggesting. If you're claiming that it's possible to cast, target, and have the damage land after an energy bolt, but still equip and swing directly afterwards, by extension, you must claim that it is possible in the combo. So yes, you were talking about it.

Faust wrote:

Kaivan wrote:I never said that wrestling wasn't associated with the swing timer. What I asked for were several rational and minor changes to the demo combat code that would allow you to swing your weapon more quickly by exploiting the speed of the wrestling timer. This is, at it's core, your entire argument regarding hally cycling. In your own words:

Actually, this process is fairly easy to code by moving the swing states from Standard(0), Prep(1), Animation(2), and Damage(3) to instead Prep(0), Animation(1), Damage(2), and the left over time from state two in a static form until state three reverts the timer back to the beginning. This introduces a 'prep time' upon equipping a weapon using the basic SetSwingCounter(0) function under the drag/equip functions for layered items. The swing pretty much moves into the beginning instead of the end of the swing timer. The only minor requirement would be a change in the CombatHeartBeat() function to know what the new changes are for the animation/damage and a minor change in the movement restriction for archery to know that state change for the prep duration(aka state 1) of the original swing timer code.

In case you were wondering, that's not a minor change. You have to completely change how the code acts to achieve that result. In fact, you said it yourself. To map out the changes you would need to make for melee weapons, you would have to do the following:

• Move the point at which your swing executes to any point in the swing timer.
• Block any advancement of the swing state if the player has moved since the last tick.
• Set a prep timer for x number of ticks that stops the rest of the swing code from executing on a lift or equip packet.
• Allow a player to move into state 2 at any time they are next to their opponent and they are not in state 2 or 3, resulting in an animation.
• Forcefully move to state 3 as soon as the animation is played for melee weapons to evaluate the damage and produce insta-hit.
• Idle in state 3 until you reach the end of your swing and move back to state 0.

These changes require multiple changes to many areas of the code for no good reason at all. In fact, they are specifically tailored for hally cycling, with nearly all of these changes having nothing to do with insta-hit or prep times in the first place, only hally cycling.

Further, what's interesting is that the first step allows your swing to evaluate in any point in the swing timer. This, by extension, allows swinging on the run and swing holding (this is how it functions right now on UOSA due to a bug). However, code is added on top of this in step 2 which prevents swinging on the run from from occurring (this is the bugged code on UOSA). Thus, this code is not only pointless in the context of this system (this code doesn't actually enable swing holding), but it produces contradictory results as well (swinging on the run is disabled on purpose when it works without the code).

Finally, what's worst is that this code isn't adaptable for any other era of combat code. In fact, this kind of code only works in this one specific scenario and is impossible to translate over to pre-T2A, UOR, or later. Given that, in order for the development process to be true, it is necessary to believe that OSI used the code in the demo during pre-T2A (note: OSI had insta-hit for all weapons during the first 3 months of UO so it's not like they didn't know how it could be done with this code), completely rewrote the code in T2A, and then adopted code that was very similar to pre-T2A for UOR and beyond. This is a nonsense notion in the realm of development, considering that many of the principles that would necessarily have been applied to UOR combat code would have worked just as effectively during T2A, and they would have worked off of the pre-T2A code, not some specifically tailored system.

As a final note, I pose my question again: What minor changes can be made to the swing code that enables insta-hit and this exploitation of wrestling timers?

Kaivan, try to follow me here...

1. Cast Explosion
2. Cast Ebolt
3. Prep Ebolt/Target Ebolt <--- either of the two sequences
4. Equip Hally
5. Swing
6. Release Ebolt <---- only would take place if it were prepped
7. Same weapon delay one way or the other

The fact of the matter is that the weapon delay would be the same whatever way you would use this combo prepped or not prepped. The explosion damage delay is three seconds no matter how you look at it here. There is no way to produce a valid standard tank mage hally swing without reducing the timer in some shape or form. I have no possible answer for how you can come up with one of these sequences having an additional 2.75s extra time put into the swing timer. Secondly, there is no possible way you can have a weapon equipped for less than 0.25s due to the fact there is a one second action delay in the first place.

The only possible thing that comes to my mind is some form of miscommunication on you or my part with what combo is being suggested here.

Kaivan wrote:In case you were wondering, that's not a minor change. You have to completely change how the code acts to achieve that result.

This is the part where you are clearly mistaken. Do you realize how many line changes it took me to achieve this process? A total of 5 lines from the original code... if that isn't a minor change than I don't know what could possibly be considered minor. In fact, the only noticable change made was the calculation of the PrepState(InitialDuration) and AnimationState(DurationSecondState) to be placed at the start of the SwingDelay(SwingDuration) instead of at the end. Those are a total of 3 lines that were changed AND the only change made in the AdvanceSwingState() function. The second change was the ResetSwingState(1) call in the movement function for archery to change one character(the 1) to being '0" instead. That totals us up to 4 lines now. The last change would be the 'if' condition in the CombatHeartBeat() function to check for the NewState variable to be 1 or 2 giving us a flat total of 5 lines. The rest of the code is completely identical to the original combat code. Also, in all honesty the code entirely is completely identical to the original swing timer code even after the changes with just line alterations making up the difference AND zero newly added lines. If you call that a 'major' change than I would have to seriously question what a minor change could possibly even be considered here...

Kaivan wrote:As a final note, I pose my question again: What minor changes can be made to the swing code that enables insta-hit and this exploitation of wrestling timers?

This was already answered in my last few responses with the example provided that is also described in the paragraph above in my post here.

Faust wrote:Kaivan, try to follow me here...

1. Cast Explosion
2. Cast Ebolt
3. Prep Ebolt/Target Ebolt <--- either of the two sequences
4. Equip Hally
5. Swing
6. Release Ebolt <---- only would take place if it were prepped
7. Same weapon delay one way or the other

The fact of the matter is that the weapon delay would be the same whatever way you would use this combo prepped or not prepped. The explosion damage delay is three seconds no matter how you look at it here. There is no way to produce a valid standard tank mage hally swing without reducing the timer in some shape or form. I have no possible answer for how you can come up with one of these sequences having an additional 2.75s extra time put into the swing timer. Secondly, there is no possible way you can have a weapon equipped for less than 0.25s due to the fact there is a one second action delay in the first place.

The only possible thing that comes to my mind is some form of miscommunication on you or my part with what combo is being suggested here.

At this point I'm not sure if you're trying to misinterpret what I've said on purpose, or you just don't get what I'm trying to say. First off, the delay on the halberd is not the same in either circumstance. In the event of a prepped ebolt, you equip right after you start the casting animation of the energy bolt, resulting in a 2.75 second difference in how long the weapon has been in your hand. This difference allows your swing to be advanced a much greater distance than it would be if you equipped after targeting the energy bolt. Secondly, I never said that your halberd was only equipped for 0.25 seconds, I made it clear that the difference was the amount of time that the halberd was equipped before you swung. In case you didn't see it:

Kaivan wrote:One method allows you to have your weapon in your hand for up to 2.75 seconds seconds, while the other only requires the weapon to be in your hand for as little as 0.25 seconds, yet both are claimed to produce a swing.

Faust wrote:

Kaivan wrote:In case you were wondering, that's not a minor change. You have to completely change how the code acts to achieve that result.

This is the part where you are clearly mistaken. Do you realize how many line changes it took me to achieve this process? A total of 5 lines from the original code... if that isn't a minor change than I don't know what could possibly be considered minor. In fact, the only noticable change made was the calculation of the PrepState(InitialDuration) and AnimationState(DurationSecondState) to be placed at the start of the SwingDelay(SwingDuration) instead of at the end. Those are a total of 3 lines that were changed AND the only change made in the AdvanceSwingState() function. The second change was the ResetSwingState(1) call in the movement function for archery to change one character(the 1) to being '0" instead. That totals us up to 4 lines now. The last change would be the 'if' condition in the CombatHeartBeat() function to check for the NewState variable to be 1 or 2 giving us a flat total of 5 lines. The rest of the code is completely identical to the original combat code. Also, in all honesty the code entirely is completely identical to the original swing timer code even after the changes with just line alterations making up the difference AND zero newly added lines. If you call that a 'major' change than I would have to seriously question what a minor change could possibly even be considered here...

Ok, nothing you said here actually makes any sense. InitialDuration and DurationSecondState are already at the beginning of SwingDuration, which causes any reversal to put them at the end.

I've got a better idea, why don't you take the demo swing code, make your alterations to it, and post the code. That way no ambiguity arises in what you're attempting to explain. Because right now, it's impossible to make heads or tails of it.

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.

Now onto the discussion about the code. There is definitely some miscommunication on this. I was not simply talking about the PrepState(InitialDuration) and AnimationState(DurationSecondState) being before the SwingDelay variable. This would be a given in any situation. I was talking about the 'actual start of the swing' taking place at the very beginning of the swing counter instead of at the end of the SwingDelay(SwingDuration). This means the start of the swing starts after the first very tick instead of a few before the SwingDuration variable that represents the end of the swing.

Here is a quick write up of code to merely show you an example of what this means first presenting the original and than the example code...

Original Pre-T2A Code: Example Code PS
Sorry, but there were actually a total of six lines that have been modified. I happened to overlook the change from "2" to "1" in the 'if' logic argument inside of the CombatHeartBeat() routine for when the animation takes place in the code. However, other than that the only routine/functions modified from the original was AdvanceSwingState(), RangeWeaponMovement(), and the CombatHeartBeat() routine. This is just merely an example of how it could have easily been possible for the weapon swing to start from the beginning instead of at the end.

I would like to interject here for a moment...

Currently on UOSA we are using the wrestle timer to "cycle" weapons.

I want to know if any of you have actually tried cycling a halberd at 100 dex/stam. Did you know you can swing the halberd every 1.5 seconds? This is because we are using the wrestle timer to swing a weapon, and at 100 dex/stam you punch every 1.5 seconds.

So what this says is, all that jazz about weapon speed means absolutely nothing, unless of course you are using a weapon that is faster then your wrestle speed.

Can you picture this in T2A? All the hard work that the developers put into the weapon speeds is completely negated by the wrestle timer? Even if this was the case, I'm sure OSI would have made this a top priority to fix, and it certainly would not have existed though an entire era.

Anyway, what if there was a function that remembered the last weapon in your hand? By this I mean, having your "last weapon" charge while you are unarmed, then when ready, arm for a hit. Is that at all feasible?

Edit: So basically when you un-equip a weapon the game thinks you are still holding it, unless you punch, or equip a different type of weapon.

If there was a 2.75sec delay or whatever upon arming, how did debuff spam ever work for killing people in T2A? Surely if someone was spamming you with harms or weakens, you could just hold down your greater heal key. Because of the equip delay on a halberd, a hally just could not be used as a finisher. 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?

Rose wrote:I would like to interject here for a moment...

Currently on UOSA we are using the wrestle timer to "cycle" weapons.

I want to know if any of you have actually tried cycling a halberd at 100 dex/stam. Did you know you can swing the halberd every 1.5 seconds? This is because we are using the wrestle timer to swing a weapon, and at 100 dex/stam you punch every 1.5 seconds.

This is actually not possible for 2 reasons. One - we have an action delay of 1s, which means we add another 1 second to the cycle - 2.5s. Then, we also have a short delay between arming a weapon and swinging it. I'm not sure exactly how large it is - maybe .25s? This boosts a cycle with 100 dex up to 2.75, assuming perfect cycling.

Please watch this video on cycling a halberd at 85 dex.

WARNING: THIS IS NOT ERA ACCURATE
Edit: Using a stopwatch between damages, it's just a hair over 1.5 seconds.

nightshark, the action delay does not add tick's to you timer. The wrestle timer is 1.5 seconds long, and the action delay is 1 second long, these two timers run alongside each other and do not stack.

The wrestle timer is longer then the action delay timer, so any adverse effects felt from the action timer are not perceived in this case.