Insta Hit, Weapon Mechanics, and much more...

[Kraarug]

...

After doing all this research it completely clicked like a light was just turned on in my mind. I remember when this bug was fixed. What you could do is swing with a very slow weapon and arm a very fast weapon to convert your delay to that of a slower weapon. The reason this works is because of the same mechanic that is apparent in the UO Demo. When you equip a weapon with an active swing delay your swing delay would convert to the weapon delay of the weapon that you just equipped. For example, if you hit with a halberd that made your delay 4.5s you could equip a katana converting your delay to a little over 1 second. If you equipped the halberd after waiting out the katana delay you would have a hally swing ready to go. All you had to do was hally, katana, hally katana, and repeat this entire process using the katana as a buffer to speed up the process by converting the delay. A dexer abusing this bug would obviously be devestating one can imagine.

In your example you are mixing the timer results of a 25 stamina character (4.5 second Hally Swing) with that of a 100 stamina character (1.29 second Katana swing). Besides, isn't 15000/((25 stam +100)*25 Speed of Hally actually) = 4.8 seconds. Or, using OSI's 250 ms tick, 5 full seconds? (1.5 seconds for the Katana).

[Faust]

I wasn't basing the hally and kat timers off from factual timers. I just knew off hand what the basic timer was for a katana and hally. A 100 stam is actually sitting at around 3 seconds for a hally. The double hit exploit was most effective when done by dexers, but it was possible to do with tank mages just not as quickly. I have clearly stated this in the past multiple times.

Faust - "A dexer abusing this bug would obviously be devestating one can imagine."

However, you are forgetting one key piece of information due to your lack of experience and knowledge that pertains to this particular era. Do you realize that all of these restrictions were completely client side at one point in time? Do you realize that UOE, UOP, and the rest of those 3rd party apps sent packets from the app to the server? No one could perform a double hit quickly like the 3rd party apps without one of these programs, because of the client side restrictions surrounding the action delays. A great example of this was being able to multi target as many purple pots onto one target as you liked. Grab about 100 purple pots and it would multi target each and everyone. Where was the action delay there? There was a reason they added the recovery delay to spells in late '98, and it was because of multi target with spells.

What about UOE being able to see hidden people? How about UOE being able to bank from anywhere, and the fact that you could open a backpack from an individual and it would stay up at all times? Why do you think fast walk forced movement packets to get the fastest speed pace possible at 0 ping? These programs DID NOT communicate with these client side restrictions and bypassed them completely. UOE and UOP wasn't rendered obsolete until early '00 when it was dealt a final blow when the server finally started to verify the packets being sent instead of the client... The technology involving packets being sent have increased DRASTICALLY since those days. You could see a lot of these exploits early on in the emulation software. RunUO still has MANY action delays that doesn't even exist to this very day.

The action delay is 500ms. Razor offsets this to 600ms to account for the delay in ping. What did you think Razor communicates with the client? I don't think so buddy... The only difference now is that the server communicates with the event restrictions now days unlike in the past.

PS
Don't take my words personally in the wrong way... I honestly don't care enough about you to make this personal. However, your argument is purely based around your credibility at "debunking" my own, which is rather laughable if you ask me. You have pointed out absolutely no evidence to support your theories that only leaves your credibility to prove anything. I only pointed out how your credibility lacks substantially with anything related to this era.

[Kraarug]

Oh Faust, I don't know it personally, but I know when someone tries to make it person. It doesn't bother me in the least.

No one could perform a double hit quickly like the 3rd party apps without one of these programs, because of the client side restrictions surrounding the action delays.

I was unaware that UOSA attempted to selectively replicate the enhanced mechanics of UOE. If that is true, then I've got to rethink things and ask why other 'features' are not replicated.

You are right about one thing in this thread, but indirectly. I honestly do not know anything about UOE or UOP.

UOA, UOA Loop and that multi-client software was all I used. I didn't need much else to make a decent stand while fighting and I had a side business of macroing up accounts for sale as well as selling rares on eBay on Tradespot. I often stole those same rares back in game so I didn't want to stand too far out and lose something that was making me a good deal of money.

So, is UOE or UOP the explaination of the difference in timers? My math showed a normal game mechanic minimum Hally Whack, using the bug you described, set at 3.25 seconds.

Your reply was that I didn't know enough about the client, UOE and UOP because the latter two programs were able to do things faster.

What else am I missing?

EDIT: I'd like to add that the use of UOE or UOP is probably why my T2A experience and 'feel' for the game is much different than yours. I know now that the difference isn't about skill but about helper programs.
I wonder if all these 'vets' that recall this bug were only able to do so because of use of one of these unauthorized 3rd party programs.

The question that remains for me is what is Derrick is seeking to achieve and what mechanics fit that that goal.

[Faust]

I never said once that this server emulates the mechanics of UOE at all... This actually isn't even possible since the RunUO server handles the packets instead of the client...

I have clearly told you what effects that UOE had on the game in my last post. If UO Extreme injected packets forcefully into the server bypassing the client side restrictions such as the action delay it's quite obvious how it would effect the timer. The fastest swing possible in game stands at 1.25s, which was roughly around the quickest a hally could be swung by using the double hit exploit. There were NO action delays when equipping/unequipping using UOE and UOP, because the programs sent packets to the server bypassing any client restrictions like the action delay. I think even UOA didn't have it in the earlier days before the server started to handle the packets instead of the client. There is a reason that people says that Razor's equip/unequip is so slow compared to past programs such as these. This complaint has been plastered all over the RunUO forums since the program was released.

PS
The 3rd party app called Injection that is commonly used on POL servers is a great example of the similar effects that UOE had on the game at that time... The equip/unequip is insanely fast and the program is widely considered one of the worst hacking 3rd party utilities to exist on player run shards. This is mainly because the program was released as open source where anyone can alter it allowing significant cheating/hacking into the game.

[Kraarug]

I never said once that this server emulates the mechanics of UOE at all...

Then what is your objection to removing the 2 second Hally Whack at 25 dex because apparantly it was dependant upon UOE/UOP to be executed and according to your words, UOSA isn't suppose to emulate that ability.

[Faust]

The double hit exploit was fixed by the 2 second disarm delay... The double hit exploit was dependant on these programs not the unequip delay... If that was the case the 2 second swing refresh would not be working on here right now since the server handles the packets. I don't know how you got off track here in this discussion.

My objection is that it's an ACCURATE game mechanic that reproduces the best feature in the history of the game. PVP would be piss poor without it resulting in massive migration to macing, which is completely inaccurate to the era.

This is a replication of the t2a era...

[Derrick]

This thread is pitching downhill faster and faster. I'm going to try to clean up the needless banter and preserve the real information that's in here, but it's quite a task as we're now on page ten of this. I'd really appreciate if there were more posts of substance. Some of this is just agonizing to read.

[Faust]

I figured since information about fighting was added from a different source that the same thing can be added in the opposite side of the argument...

Today in Moonglow Fire finally decided it would be fun to stay on the same screen as me for more then 5 seconds and fight. Combo: explosion, hally, weaken, weaken, weaken, hally, explosion, hally eb, weaken, weaken

A hally takes 5 seconds for the delay to cool down...

- Here we have the standard use of 3 first circle spells to refresh a hally...( 0.5 * 3 ) + ( 0.75 * 2 ) = 3 seconds.
- After the 3 weakens an explosion is casted followed by another hally... Let me guess the guy waited 5 seconds after casting that measily spell that takes 1.75s to cast right, lol?

I can just as easily show some pvp articles where the insta hit refresh was used...


Edit:
Having a source compared to not having one is better than the latter...

There is no reason to doubt it until someone pin points the addition of the unequip delay besides the source that has been provided. The game mechanic was added with certainty and proved without a doubt to exist. The only mention of this delay EVER was in this article on stratics. Provide the proof that this isn't the delay without basing the argument around speculation and theories. If that can be done there should be no reason to take another look at it. However, the confidence that surrounds the delay is pretty high if you ask me.

How can anyone change the delay from the only source that supports it to a source that doesn't exist? What are you going to change it to? What you think it should be? What the next guy around the corner thinks it should be? That would be about the most ignorant approach towards altering a major game mechanic being based around the only source that exists to absolutely nothing just because one or a few people remember PVP differently compared to those that remember the mechanic in mass numbers...

[Orsi]

There was no bug to get a fast halberd hit.

Pre-cast explosion
Halberd Instahit
+ Unequip Halberd
+ Release Explosion
+ Start Casting E-bolt
+ Release E-bolt
+ Equip Halberd
Run and Hit

I don't know where people are getting off saying that there was a little trick to arm a halberd hit in 2 seconds, when it takes atleast 2 seconds to cast E-bolt, let alone all the time it takes to do the actions in between. People need to start realizing that with Humans, Lag, Server-Client interaction, no action will ever be perfected down to the last millisecond.

- http://opp.iwarp.com/archives.htm wrote:
Today in Moonglow Fire finally decided it would be fun to stay on the same screen as me for more then 5 seconds and fight. Combo: explosion, hally, weaken, weaken, weaken, hally, explosion, hally eb, weaken, weaken

Don't assume that all those weakens were back to back. People run, have to chase, move around objects to block line of sight, anything.

Trust me, PvP in T2A was not solely dependent on a 2 second Halberd whack bug to make it great.

[Faust]

Yes, there was and it wasn't a "bug".

A 6th circle spell takes 1.75s add a standard 56k connection onto that and you have 1.95s delay. Adding an action delay of 0.5s still equates to under half of a standard hally delay of 5 seconds. Movement restricts the delay from ticking down, which means the swing has to be ready while stationary after casting the spell...

[Orsi]

Yes, there was and it wasn't a "bug".

A 6th circle spell takes 1.75s add a standard 56k connection onto that and you have 1.95s delay. Adding an action delay of 0.5s still equates to under half of a standard hally delay of 5 seconds. Movement restricts the delay from ticking down, which means the swing has to be ready while stationary after casting the spell...

Stop using just numbers, as I said, people don't react like a computer. The way you are describing it would only be a problem for an automated bot. There wasn't a single process in order to allow ONLY a halberd to swing faster than it should. I played from 98-2000, without ever using UOE/UOA. When did you play?

[Kraarug]

I figured since information about fighting was added from a different source that the same thing can be added in the opposite side of the argument...

Today in Moonglow Fire finally decided it would be fun to stay on the same screen as me for more then 5 seconds and fight. Combo: explosion, hally, weaken, weaken, weaken, hally, explosion, hally eb, weaken, weaken

A hally takes 5 seconds for the delay to cool down...

- Here we have the standard use of 3 first circle spells to refresh a hally...( 0.5 * 3 ) + ( 0.75 * 2 ) = 3 seconds.
- After the 3 weakens an explosion is casted followed by another hally... Let me guess the guy waited 5 seconds after casting that measily spell that takes 1.75s to cast right, lol?

I can just as easily show some pvp articles where the insta hit refresh was used...


Edit:
Having a source compared to not having one is better than the latter...

There is no reason to doubt it until someone pin points the addition of the unequip delay besides the source that has been provided. The game mechanic was added with certainty and proved without a doubt to exist. The only mention of this delay EVER was in this article on stratics. Provide the proof that this isn't the delay without basing the argument around speculation and theories. If that can be done there should be no reason to take another look at it. However, the confidence that surrounds the delay is pretty high if you ask me.

How can anyone change the delay from the only source that supports it to a source that doesn't exist? What are you going to change it to? What you think it should be? What the next guy around the corner thinks it should be? That would be about the most ignorant approach towards altering a major game mechanic being based around the only source that exists to absolutely nothing just because one or a few people remember PVP differently compared to those that remember the mechanic in mass numbers...

I read the entire context of your new source and it doesn't state that the fight lasted only 5 seconds. Please re-read the passage and see what I mean.

I can just as easily show some pvp articles where the insta hit refresh was used...

Please post them and keep in mind that I am staying that there is a difference between insta-hit dmg first and some sort of instant refresh that totally ignores stamina and the attack speed formula.

There is no reason to doubt it until someone pin points the addition of the unequip delay besides the source that has been provided.

Faust, when considering sources for information one must consider the whole source and not just take snipits that happen to agree with one line of thought over another.

Looking at the page where your only source for some sort of 2 second delay, in fact, within the same posting, one can see many mistakes and misunderstandings of the author.

He could have been wrong with his understanding or presentation of an unequip delay. After all, we do not know his source and if indeed they were testing some new delay, it could have been change from 2.1.99 (date of his post) to 2.26.99 when OSI announced they fixed the slow weapon hitting fast bug.

For all we know, at the time of the posting, the equip delay could have been an ADDITIONAL 2 SECONDS to apply to the cool down timer, we simply do not know and he was not clear and never mentioned it again.

In fact, it was never mentioned again in Era. That is my issue.

This would have been a major game altering change and there is no further mention of it than a post that was dated before anything was actually implemented. That's very worrisome.

So, my point is that this source is very flimsy to build an entire game mechanic around, especially one that ignores so many of the games design. A whole string of issues would have to have played into effect for your theory to be true.

I'll recap as so I need not have to post them again and try to keep my point clear:
OSI would have had to...

• Ignore the stamina-dependent-swing timers completely
  OR act as if players had 800 stamina at all times when using a Hally. <do the math and confirm pls
  Ignore weapon speeds
  Have had to replace one bug with a worse one
  Ignore the 97 Patch dealing with swing timers
  Posted they fixed a bug and made it worse on purpose

The OSI/UO WepSpace would also have had to be complete mute on the issue for the entire duration of the tactic.

I honestly can not see how all these events would have to come into play solely to give Mages, which OSI had previously said they wanted to better control, a significant advantage over templates that are stamina dependent.

It equals to giving them the best of both worlds and Faust, that did not exist after 2.26.99.

[Faust]

Scythe,

I played from the very first day that the game was released in September of '97 all the way up until the UOR publish in '00. I'm revered to be one of the most feared PK's on the Baja shard. There is no need to discuss backgrounds because there is no comparison. What exactly does this have to do with the topic though?

If you didn't use a 3rd party app it's no wonder that you don't know about it. There were no decent PVPer's that didn't use a 3rd party utility back then. The beneficial factor for you to use it without an arm/disarm macro would simply not exist.

For all we know, at the time of the posting, the equip delay could have been an ADDITIONAL 2 SECONDS to apply to the cool down timer, we simply do not know and he was not clear and never mentioned it again.

Why do you keep insisting on using this same comment time after time? I have showed you the default delay in code and even explained it to you.

Code: Select all

OnRemove( Mobile m )
{
BaseWeapon weapon = this as BaseWeapon;

if ( weapon != null )
m.NextCombatTime = DateTime.Now + GetDelay( m );
}

I will explain this ONCE more... This code verfies that the weapon exists by making sure it's not null... The next combat time variable is processed by taking the CURRENT date or in other words a timer of ZERO and adding the GetDelay onto it. It doesn't ADD an additional delay onto the CURRENT delay, which would be "m.NextCombatTime = m.NextCombatTime + GetDelay( m );".... The delay is CONVERTED just like the equip delay is in the code... Again, THERE IS NO ADDITIONAL 2 SECONDS ADDED ONTO THE CURRENT DELAY... I hope it sinks in this time around.

[Kraarug]

Code: Select all

OnRemove( Mobile m )
{
BaseWeapon weapon = this as BaseWeapon;

if ( weapon != null )
m.NextCombatTime = DateTime.Now + GetDelay( m );
}

I will explain this ONCE more... This code verfies that the weapon exists by making sure it's not null... The next combat time variable is processed by taking the CURRENT date or in other words a timer of ZERO and adding the GetDelay onto it. It doesn't ADD an additional delay onto the CURRENT delay, which would be "m.NextCombatTime = m.NextCombatTime + GetDelay( m );".... The delay is CONVERTED just like the equip delay is in the code... Again, THERE IS NO ADDITIONAL 2 SECONDS ADDED ONTO THE CURRENT DELAY... I hope it sinks in this time around.

Where did you get this code? From the demo?

[Faust]

....

How could I get it from the demo which was last compiled in August of 1998? The demo does not have an unequip delay, which means it was patched in AFTER August of '98. If it had existed on the demo my time frame for this whole occurance would be invalid... I don't know why you would even ask a question like that.

It is the default code in the RunUO distro package that has been verified on the current UO servers... Again, I have said this many many many times here previously... I'm tired of having to repeat myself over and over and over. How many times does someone have to say the same thing for you to understand it? Seriously, man.