Do you enjoy the pvp mechanics of uosecondage?

[Faust]

Anyway......you've preached every single time that "this time the timer is going to be correct" and it's been changed how many times? Same goes with quite a few research projects that you've done in the past.

Please reference a comment stating that this comment was ever made by me. In fact, please show me where the timer has actually been worked on in the past besides the latest addition that fixed half of the current swing timer project when the tick based system was implemented...

The same default timer used in the RunUO code(minus the addition of the way the timer elapses based on movement) is being used here and has never been modified or altered in any way shape or form. The movement restriction was implemented here long before my arrival to the shard. The only reason it was ever deemed accurate was based on visual interpretation inside of the demo before it was ever decompiled. It was later discovered that the only reason this mistake was able to take place was based on the range check that looped the timer when you were out of range. When running back and forth with the combatant during the test the swing would restart when you were out of range creating this grossly error. At least until Batlin recently decompiled the original timer a few months back.

Please don't make false accusations like this in the future son.

[punk]

Can someone please link me the thread in Suggestions & Era Accuracy where these "Imminent Changes" were discussed and consequently proven to be the way it actually was?

I feel like I've missed the actual discussion on the matter, and I can't find any threads in the S&EE forum discussing it (although, I did only look at what was on the first page of threads)...

Thanks

[Faust]

There are no threads beside this one if you want to call it that.

Unless you consider the thread over at JoinUO where Batlin posted the decompiled code for the original timer a discussion of it too.

[Hemperor]

Faust you really are full of crap... I remember when you spent 50 pages of a topic showing a screenshot of a journal and saying "See, he died at this point so we know he cycled the hally within 2 seconds!" and anyone who would even try to discuss it, you would shoot down.

Someone please find that topic, there must be over a hundred quotes of him saying that.

EDIT:
http://forum.uosecondage.com/search.php ... mit=Search

More information dug up. This was obtained from an old JoV post that Nighthawk(an old friend and fellow guild member) from wtfman.com posted up many many years ago. The interesting part about this story is the real time involving the journal that is displayed in a picture on there.

Take a special look at the 5th line beside the picture...

Nighthawk wrote:
5> Hally, Ebolt, Hally, Ebolt (as he tries to heal)


Now let's think about this while including the journal log. Take a special notice to the 3 greater heals. It is quite obvious that the first two of them were disturbed since this guy died in a matter of a few seconds from that point. The hally interupts the first Greater Heal, and the ebolt is released to interupt his second Greater Heal attempt. Another ebolt is casted followed by a hally hit RIGHT after a hally hit just occurred. With a finishing ebolt for the kill. Here is yet more evident proof in a REAL LIFE time span clearly displayed on this journal that shows that you could "ebolt, hally, ebolt, hally". If you had to wait the 5 second delay on the hally there is abolutely no way you could have disturbed three greater heals in this manner without it overriding the delay when you casted a 6th circle spell not to mention even do an ebolt, hally, ebolt, hally this quickly...

Reference: http://www.wtfman.com/oldjov/stories/nhawk19.htm

[Axel231]

lol hemporer strikes back.


FATALITY

[Faust]

Again, the same process/bug for weapon cycling is present in the original timer as stated multiple times to you already... my arguement was proven to be correct afterall. The bug just works slightly different than it does with this current inaccurate swing timer but still spares around 2 seconds of the delay with a hally.

Are you trying to say this comment from me is discussing the swing timer, which clearly isn't the case what so ever?

There are two game mechanics related to weapon cycles that make them possible.

- Arm/Disarm delay.
- Wrestling speed of 50.

What is your point exactly?

There is not one single person here, including yourself, that knew the range check came after the swing code processed a swing. This was the only fault in the logic besides a few inaccurate code structures with the swing. The logic and theories were proven to be correct but with in an inaccurate swing timer that is finally getting fixed. There is not one single comment from me stating that the current swing timer is correct, not one.

[hectorc2w]

why do i remember being able to hally eb hally ? is it going to be possible after the next patch? faust ansswerrr meee pleaassee

[Faust]

There is a bug in the code that allows you to bypass the equip delay that would otherwise make you wait a little longer than 2 seconds at 25 stam when arming a hally that would typically trigger the equip delay(process that restarts your weapon delay). The difference in time is more than likely compensated by lag back in the day. The common way to reproduce this bug was to cast an ebolt and equip your weapon since the time of the spell was very close to the point in time the bug would trigger with the wrestling delay.

[nightshark]

So hally cycling is going to be more or less the same, except we have a small chance to hit on the run?

I notice occasionally when I'm chasing people down that my hally timer will "refresh on the run", I assume this is to do with turning around etc. With the new patch, if my hally isn't in that "held state" when I finally stand on the tile next to my opponent, won't that mean I have to wait out another whole cycle? In other words making it even worse and unpredictable?

[Faust]

No, it definitely will not be the same at all. The way it currently works is disarm hally, wait wrestling delay, arm hally, and your swing is ready holding in a held state. However, when the new timer goes in you can ONLY bypass the equip delay not negate the entire hally delay. For example, disarm hally, almost wait the entire wrestling delay, arm hally, and the equip delay that would typically make you wait an entire 5 seconds all over again would be bypassed. You have from the time you equip that weapon until the rest of the hally delay elapses to get next to your opponent before the swing is wasted by the range check. The rest of the delay will elapses when you're moving close to your opponent unlike it does here. The bug is based on the swing timer states when case #2 is called in the AdvanceSwingState() function with the greater than equals statement when you trigger the equip delay or prep time in this instance.

[Mazer]

I'm hoping that I'm wrong but it seems this will not be the type of change I was waiting for. Might be alright in a duel pit where you can stay close but won't be so good on the field. I will wait and see though.

[Sandro]

I'm hoping that I'm wrong but it seems this will not be the type of change I was waiting for. Might be alright in a duel pit where you can stay close but won't be so good on the field. I will wait and see though.

it's the quitting patch of t2a

they keep making stupid changes that only hurt game play..

this is like the 104th pvp change

[KydVicious]

No, it definitely will not be the same at all. The way it currently works is disarm hally, wait wrestling delay, arm hally, and your swing is ready holding in a held state. However, when the new timer goes in you can ONLY bypass the equip delay not negate the entire hally delay. For example, disarm hally, almost wait the entire wrestling delay, arm hally, and the equip delay that would typically make you wait an entire 5 seconds all over again would be bypassed. You have from the time you equip that weapon until the rest of the hally delay elapses to get next to your opponent before the swing is wasted by the range check. The rest of the delay will elapses when you're moving close to your opponent unlike it does here. The bug is based on the swing timer states when case #2 is called in the AdvanceSwingState() function with the greater than equals statement when you trigger the equip delay or prep time in this instance.

The hally was cycled in '99 but it certainly wasn't like it is here. People could pull off a string cycle (they were often accused of speedhacking, exploiting, UOExtreme was rampant in the day), however it didn't "insta-hit" each time, the insta-hit if my memory serves me right ocurred on the first swing (there was a glitch, however, OSI was well aware of it for quite a time that saw "double hits" go off with the insta-hits at times.This gave rise to the dreaded insta-death combo explode, e-bolt, hally double whack, lightning bolt=dead), the tank could then cast after the initial insta-hit swing then re-arm and a swing would occur however, if it was within a certain timeframe it wouldn't insta-hit for some reason and a whiff was a possibility at that time thus wasting your swing and resetting the timer so it was best to time your swings according to the hally delay so you could maximize the insta-hit because if that second swing missed you were waitin it out for that next swing. Strings seemed to be pulled off by people with hellacious pings (cable modems vs. dialup was a bitch), dialup made for a very subjective form of interpretation in regards to what was actually taking place. The difference in pings was so disparate at times people would have totally different perspectives as to the actual events transpiring in a duel. Sometimes you'd be dead after seeing an explosion cast and hearing a hally hit. Now it didn't happen that way but by the time you caught up with the action it looked that way.

[Faust]

I'm hoping that I'm wrong but it seems this will not be the type of change I was waiting for. Might be alright in a duel pit where you can stay close but won't be so good on the field. I will wait and see though.

it's the quitting patch of t2a

they keep making stupid changes that only hurt game play..

this is like the 104th pvp change

The same was said for the current system son.

I don't know why people get stuck on "this is the 100th pvp change, blah blah" whining comment. This server is replicating the '99 era and when things like this pop up they will be fixed. This is something you might as well get used to because this server isn't in the process of development onto the era(for the 100th time itself). The swing timer was finally decompiled(a task the RunUO team never could even manage to do) by Batlin and it's time for it to finally get fixed. You probably should be looking somewhere else if you don't want a server that mimics the '99 era.

[Sandro]

faust you don't even play

you joined this shard in 2008 (lol) and have accumulated a total of probably 48 hours of gameplay..