Remove the new object and action delay.

[Derrick]

ticks were really the speeds of server side processing, but even then, some actions were event based, and not queued for timers.

The packets may have been pulled out of a queue on the basis of ticks, but for example a player can run faster on a horse than the tick speed.

[Kraarug]

ticks were really the speeds of server side processing, but even then, some actions were event based, and not queued for timers.

The packets may have been pulled out of a queue on the basis of ticks, but for example a player can run faster on a horse than the tick speed.

Is spell casting one of these actions dislodged from ticks?

[Derrick]

the animations and timings are designed around ticks, as though are timed server side, but they can be initiated at any time. It's hard to test this though in demo, as there is no way to cast two spells in less than a tick.

[Kraarug]

the animations and timings are designed around ticks, as though are timed server side, but they can be initiated at any time. It's hard to test this though in demo, as there is no way to cast two spells in less than a tick.

hrmmm... this maybe some of the cause behind the 'feel' of pvp. An object based combatant such as a warrior, would have ticks applied to everything they do. Ie Arm, disarm, drink potion, use bandage.

If a spell caster is somehow dislodged from the same time keeping system and their actions are recorded server side by the millisecond rather than tick then it would inherently be faster and not on the same level field as object based actions.

It doesn’t seem to jive to me.

In an x, y, z world I can see how and why movement and location would be considered a critical priority to the game system, but not spells.

I don't think the designers fretted weather or not a given player initiated a spell down to the millisecond but the location of a target and or player would defiantly be a major variable in the system.

It would be clear to see how and why not treating player actions such as these the same would cause a balance issue.

I think player cause actions, with perhaps the exception of movement, were all on the tick system and treated the same in terms of packet priority.

[Kaivan]

One of the things we don't know is exactly how restrictions were applied to the processing of packets that are received. For example, we don't know how the server would handle a packet that came 0.05 seconds after the beginning of a tick. Would the packet be immediately processed as part of the tick that just passed, or would it wait until the next tick came around to process the packet? The one thing we can be certain about is the fact that the action delay is indeed 1 second. Through testing on the demo, and on live OSI servers (and a mid-way confirmation through the quote posted by Faust), the time was confirmed to be at 1 second, with times on OSI servers experiencing a slightly longer than 1 second delay when tested over an extended period (part of that whole "when does a packet get processed" deal based on when the packet was received due to lag).

[Kraarug]

I think having spell casting on a separate and more fluid timing system than object based combat, along with the current interruption system, is the chief reason why the pvp doesn't feel right and the lack of town fighting.

These two items just tilt the balance a little too far towards spell casting.

First of all, not placing spells on the tick system simply just applies all the benefits of a fast connection speed and the default RunUO timing system to spells. That's off. All spells should be placed on the tick system. There's no reason to believe they were not.

Secondly, about the interruptions, a weapon based combat approach yields a 25% chance to interrupt a spell while measly casting any harmful spell easily doubles that chance.

[Faust]

Secondly, about the interruptions, a weapon based combat approach yields a 25% chance to interrupt a spell while measly casting any harmful spell easily doubles that chance.

First, this was already stated in another thread to be invalid giving both disrupt abilities a unique nature towards the way they function.


Second, spell delays increment in ticks starting at 0.5 for the first circle.

The last time that I checked this portion of the code a timer that increments in ticks was being used in the RunUO default scripts...

The timer class has always existed in the RunUO code that can tick in a multitude number of different tick intervals. Simply because some game mechanics such as the weapon delay is based on date stamps doesn't entirely mean EVERY thing is constructed that way in the code.

If anything is tilting unbalance it's weapon combat...

The weapon delay doesn't abide by a timer that increments in ticks. The only thing that was coded previously was the previous timer(a date stamp) would construct the variable into what the ticks would be. This means weapons currently are faster than what they should be still by one tick since its rounded down instead of up to the closest 0.25 interval.

[Kraarug]

Secondly, about the interruptions, a weapon based combat approach yields a 25% chance to interrupt a spell while measly casting any harmful spell easily doubles that chance.

First, this was already stated in another thread to be invalid giving both disrupt abilities a unique nature towards the way they function.


Second, spell delays increment in ticks starting at 0.5 for the first circle.

The last time that I checked this portion of the code a timer that increments in ticks was being used in the RunUO default scripts...

The timer class has always existed in the RunUO code that can tick in a multitude number of different tick intervals. Simply because some game mechanics such as the weapon delay is based on date stamps doesn't entirely mean EVERY thing is constructed that way in the code.

If anything is tilting unbalance it's weapon combat...

The weapon delay doesn't abide by a timer that increments in ticks. The only thing that was coded previously was the previous timer(a date stamp) would construct the variable into what the ticks would be. This means weapons currently are faster than what they should be still by one tick since its rounded down instead of up to the closest 0.25 interval.

You clearly do not use weapons as your primary method of attack here on UOSA and I would suspect neither did you on 1999 OSI.

I suspect that most people who played a 1999 weapon based template would agree with me that something is off in terms of accurate balance and I'm trying to find out what it is rather than just reinforcing what we have presently.

I've raced karts for years as my other hobby and know that what usually makes the differce between winning is measured in several minor milisecond differences. Added up, they turn minor bits of time into several seconds of a lead and advantage in a race.

That little something that we are missing here lays somewhere in the system and it's probably not just one thing.

I know this though, just defending what we have here over and over again is not going to fix things and certianly is not going to make it The Way It Was.

[Kraarug]

Duplicate post

[Faust]

I didn't repeat anything...

My post merely was stating the facts towards the misinformed information that you listed in your post.

- Spells use the timer class for the casting delays.
- Weapons don't use the timer class for their delays with the exception of the date stamp being formatted based on rounding the tick down one if it's not an even tick.

This post or the last post was not indicating that something may or may not be wrong with timers... You can think what you want about my experience on the actual OSI servers. I can guarentee you that it is well above anyone else that plays this shard.

Also, I think the weapon delays should be based on the timer class to be more precise in my opinion. The problem with using timers is that they hog a lot of resources in the system. I also believe that the delay used an on and off base for consuming the delay. Where the timer would begin "ticking" if your character wasn't moving and stop "ticking" if he wasn't. This would mean a tick would finish out even while on the move if you stopped moving for a brief moment and the timer would stop if you were moving at the end of that tick.

[noxmonk]

Personal opinions aside, the differences between UODemo and 99OSI are many. Short of actually attaining a patched server client from that timeframe you only have an idea of what it may be like. Fact is, not everything is in patch notes. MMO's of today, after 10+ years of refining MMO's, still do not have complete patch notes. Still put incorrect information in patch notes, and still make game mechanic changes only to publish them in later patch notes. However, that's about all we have unfortunately.

What Kraarug is trying to say, is something feels off about playing a dexxer. Maybe it's what a lot of people attribute to faster connections, computers, and player knowledge. However, writing someone off just because that is really all they have to go on is stupid. Kraarug has already stated he played for a long time. There's a lot of people here who played 97-00 extensively who have viewpoints that differ from what we have here. Does that mean their wrong? Not necessarily. Hell, they could've changed a myriad of back-end game mechanics and never told a soul, or just posted it later. That's not easy to research but, since you claim to be the penultimate researcher of T2A era mechanics, giving him suggestions on how to start researching and where to go to try and get information would be a better start.

[Faust]

Saying "something seems off for weapons" doesn't help support an argument.

Being a little more direct makes for a better argument.

The only thing that he has mentioned in the past is surrounding this topic is the swing delay timer, which has been declared a hundred percent accurate in regard to elapsing only while you're not moving. However, the way that timer elapses surrounding ticks is definitely up for discussion. That is why in my last post a possible example of how it possibly worked.