Is the pvp better now then before?

[nightshark]

Spell disruption delay should not exist here and has never once existed on the production shards.

eh? are you saying if my spell is disturbed i should instantly be able to recast? currently on UOSA if you are disturbed from casting you have a 0.5s or so delay before recasting, the same as when you recast immediately after casting a spell.

[Faust]

The current recast delay is actually 0.75s at the moment if you don't wait the 2.25s fast cast delay that negates the recast delay when waiting it out.

Spell disruption works differently by subtracting the spells cast delay from the amount of time that was processed during the spell. So in other words the spell is forced to wait out the current delay no matter what when it's disrupted until another spell can begin casting.

The recast delay has went back and forth because there has been no substantial evidence to suggest what the actual timing was for the delay. Old discussions surrounding the recast delay has referenced it exactly in that manner, a delay. There was never any mention of the value of that delay. However, Kaivan found some information to suggest that it was 0.5s a little while back even though this felt 'too fast' for almost everyone. This was before the tick based system was implemented here and this was more than likely the reason the feel of it felt incorrect when compared to the 0.75s delay.

[Sandro]

you guys said that movement restricting the advancement of the swing timer was 100% accurate for the past 2 years now..

now it will be changed based on what documentation?

same situation on spell recovery ;/

[Domnu]

you guys said that movement restricting the advancement of the swing timer was 100% accurate for the past 2 years now..

now it will be changed based on what documentation?

same situation on spell recovery ;/

Faust claims that whatever he believes at a given moment is 100% accurate. If something happens and he realizes that he was wrong, then his new discovery becomes support for his belief that what he NOW believes is 100% accurate. It's like he forgets he was ever wrong in the first place. It's very strange.

[Faust]

Would help if you made yourself familiar with the topics before commenting Alatar.

The movement restriction was based on two findings. A patch note and visual testing with the demo before it was ever decompiled. However, after the demo was decompiled and specifically the swing timer it became quite clear how this error took place.

The swing timer loops even when you're out of range with the original timer. The visual tests involved trapping a mobile and running back and forth to see if the timer would pause when moving. However, since it was unknown that the swing was taking place even when you wasn't next to the combatant it created the illusion that the timer was being paused but elapsing during turns, etc...

The patch note is based on the correction of this feature that allowed a swing to hold in a held state(what we are currently using) that makes note that you no longer have to stand still to advance your timer in order to make contact with the weapon. This note could have easily been talking about the previous system where you had to stand next to your opponent to get a swing since it would simply start over in a looping fashion if you weren't next to your opponent.

Batlin decompiled the original swing timer and everything became crystal clear and fully backed up by the UOR patch that specifically mentions the range check/swing holding in a held state issue.

Spell recovery is not the same situation. First, there is no known documentation for the value of the delay. However, it has widely been speculated to be the equivalent of two ticks(same as a first circle spell) since the cap value is equivalent of nine ticks(an eigth circle spell). We were first using the default RunUO of 0.75s for well over a year until Kaivan found some documentation that it was 0.5s. However, people complained non-stop(me included) that it just seemed too fast compared to what they remember and it was changed back to 0.75s due to the lack of evidence since Kaivan's information is based on the UOR era. This was before the tick based system was implemented that skips a tick from time to time. This means that 2 ticks would be 3 ticks sometimes just like how 3 ticks is sometimes 4 ticks for the recast delay now. There were many people that thought the recast delay along with many others was increased after the patch.

Domnu, you can believe whatever you like if it makes you happy. No one really cares to be honest besides you maybe. I have been wrong many times and whatever is 'deemed' accurate to me is based on what information is available at that moment. Information comes in all the time that make something inaccurate and that is a part of the way this process works. Not one person here knew the range check was calculated after the swing took place assuming swings 'holding in a held state' was accurate. What does that mean that they thought it was accurate though? Nothing, son.

Btw, what discovery are you talking about here exactly? First, the swing timer was decompiled by Batlin. Second, the recovery delay information is based on Kaivan's findings. Please tell me what 'discovery' was made here by me again son?

[Domnu]

No one really cares to be honest besides you maybe. I have been wrong many times and whatever is 'deemed' accurate to me is based on what information is available at that moment.

I'm not the only person who finds it annoying that you claim something is "100% accurate," and then turn around and claim something else is "100% accurate," when you come across new information. Have some humility and at least admit that what you're advocating is based on the best information available. It will make it a lot easier for people to swallow when you realize that the way you had it wasn't actually the absolute 100% truth.

Evidence of this can be seen in...e.g., Sandro's above post.

[Faust]

Did you bypass this portion of my post or something?

Btw, what discovery are you talking about here exactly? First, the swing timer was decompiled by Batlin. Second, the recovery delay information is based on Kaivan's findings. Please tell me what 'discovery' was made here by me again son?

Sandro's 'above comment' discusses the swing timer movement restriction and recast delays. Both in which was not my 'discovery' son. The swing timer was actually in place here before an game and forum account was even made by me after discovering the shard.

Please try again.

[Domnu]

You caught me, I didn't read your whole post. My point still stands though.

[Sandro]

every time something turns out to be implemented incorrectly you write a book attempting to justify it..

point is, we've had mechanics in place which are incorrect for almost 2 years now and you guys have continuously supported this to the teeth until it was publicly proven to be false..

[rouss]

You couldnt cycle swings on the run, this is incorrect whatever faust says. Moreover this wont be in the upcoming patch. I dunno where people get this sort of stuff.

[Faust]

You caught me, I didn't read your whole post. My point still stands though.

Right, your point still stands even though the two items you listed were just invalidated... makes a lot of sense to me!

every time something turns out to be implemented incorrectly you write a book attempting to justify it..

point is, we've had mechanics in place which are incorrect for almost 2 years now and you guys have continuously supported this to the teeth until it was publicly proven to be false..

No, a book has to be written to describe months of research/discussion for someone's lazy incompetence because that person doesn't know how to inform/educate themselves on the issue.

You couldnt cycle swings on the run, this is incorrect whatever faust says.

What are you talking about? The weapon cycling bug exists in the original swing code but the way it functions isn't the same as the way it works with the current swing timer. The bug simply bypasses the arm delay by using a loop hole with wrestling. This is actually pretty much the same as it is with the current swing timer to be honest. However, the current swing timer holds a swing in a held state, where as the original timer does not.

[rouss]

The weapon cycling bug exists in the original swing code but the way it functions isn't the same as the way it works with the current swing timer. The bug simply bypasses the arm delay by using a loop hole with wrestling.

Might be, but keeping in mind that those files are dated early 1998 it'd be completely dumb to think they havent been revisited since. There has been a lot of changes since then, vast majority of them could be just ninja patches. I still stand on my position.

By the way, Faust, can you sum all or posts regarding accurate PvP on Wiki? There's a special section. Just to make it clear and reference when needed. Also, there's a convinient way to discuss right on wiki. Thanks

[Faust]

No, it definitely didn't change... There are several in era sources that describe the tactic even up to October '99 that backs up the many vets that remember a trick with the hally to 'shorten' the delay. The way it works on the server at the moment allows you to swing the hally immediately after the quick wrestling delay elapses because the 'swing holds in a held state' at that point. This isn't right and a lot different with the original timer that would actually restart back to the beginning when the wrestling delay elapsed. There is no way to land the well known explosion, ebolt, hally combo at the same time without utilizing this bug when you're in actual combat... The only other way is when it's the opening move since you're not in combat(the timer loops when you're in combat). The wrestling delay is 9 ticks(2.25s) standing at 25 stamin. This is 10 ticks(2.5s) short of the end of a hally delay at the same stamina value. Without this bug existing there would be no way to cast an explosion, ebolt, and hally landing them roughly around the same time during combat. The equip/arm delay triggers immediately when you drag/equip a weapon. This function restarts your delay completely meaning when you cast the explosion, ebolt, and equip that hally for the swing you would have to wait an ENTIRE 4.75s until the swing starts... However, when you apply the bug in this scenario you would only have to wait a couple seconds after releasing the explosion/ebolt giving you the ability to land them close together. The trick involves the switch statement in the AdvanceSwingState() function when state 2 is called during a specific instance when you're utilizing the wrestling delay.

Would probably be best to wait until the new combat patch comes before the Wiki is updated in my opinion.

[KydVicious]

I duno about everyone else, but after getting used to it, this is getting closer to how I remember PvP.
I am extremely satisfied with the current fixes and looking forward to the combat system rehaul to really get us playing more

I think like everything else, we have to get adjusted to some of the changes

We have been playing a false version of UO for so long that we have forgotten how mechanics are supposed to function, so of course it's going to feel weird and wrong.
RunUO has warped our brains

I don't remember spam casting, at all. People knew about 1-3'rd circle spells, they weren't a mystery, they just weren't used.
I think UOSA is getting closer and closer to accomplishing true era accuracy when it comes to the Player vs Player mechanics.
Perhaps now it will take haste and high level spell combinations (other than the oh so skilled eb *hally* eb) which will make fights much more interesting

Yes, I agree

[MatronDeWinter]

<Shortened to save space>

Yes, I agree

You know, that's what is funny to me.

I remember mage-type fights going on until someone ran out of mana and the other guy had enough to dump on him and get the kill. Sure there was the occasional interupt, and a random hally tossed in here or there, some katana use. But that was the general style aside from just going all out on some crazy combo that would insta-kill, or para-spam (both of which, were insanely popular).

Here it seems like the secret to PvP, is timing your spells to damage faster than your opponent can mini-heal spam. I never remember this hurdle to killing someone.

I havent really got out to play much since the change, but I am hoping that the 1 second action delay also applies to mini heal?