Sign in with
Sign up | Sign in
Your question

EQ1: The Tic and Weapon Delay

Last response: in Video Games
Share
December 2, 2004 4:14:08 AM

Archived from groups: alt.games.everquest (More info?)

OK... we all know about the ubiquitous tic in EQ.

But I ran accross an article claiming that weapon swings were also
governed on a per tic basis. Is this true?

The implications of this are signficant, as there should be fairly
noticable dps jumps as you cross tic thresholds. (ie from 1 swing per
tick to 2 swings per tic, etc...)

It also implies that a 50/50 weapon is the same as a 50/55 weapon. (At
least unhasted), as they will both only ever swing once per tic.

I'd always assumed there was a sub-tic accumulator to carry over the
remainder to eliminate this tic artifact, and ensure that even small
delay differences between weapons could be observed.

At any rate, I'm hoping for a quick answer... I could parse this easily
enough, but I'd prefer not need to :) 

More about : eq1 tic weapon delay

Anonymous
December 2, 2004 4:14:09 AM

Archived from groups: alt.games.everquest (More info?)

42 wrote:

> OK... we all know about the ubiquitous tic in EQ.
>
> But I ran accross an article claiming that weapon swings were also
> governed on a per tic basis. Is this true?
>
> The implications of this are signficant, as there should be fairly
> noticable dps jumps as you cross tic thresholds. (ie from 1 swing per
> tick to 2 swings per tic, etc...)
>
> It also implies that a 50/50 weapon is the same as a 50/55 weapon. (At
> least unhasted), as they will both only ever swing once per tic.
>
> I'd always assumed there was a sub-tic accumulator to carry over the
> remainder to eliminate this tic artifact, and ensure that even small
> delay differences between weapons could be observed.
>
> At any rate, I'm hoping for a quick answer... I could parse this easily
> enough, but I'd prefer not need to :) 

There's no tic based marker on weapon swings in EQ1, unless they added
it in the past month or so since I stopped playing.

With a long enough parse, you can detect a difference in weapon swings
over time with as little difference as that between 41 and 42 delay.

Haste also affects weapon speed; with a /18 weapon and 70% haste you'll
see a lot more than one swing per tic. Again, it was not difficult to
detect a difference between 70% and 75% haste.

When watching speed differences this small, it would be very noticable
if there was tic based interference in the swing rate.
December 2, 2004 5:47:09 AM

Archived from groups: alt.games.everquest (More info?)

In article <WtGdnehCW89d4DPcRVn-iA@dejazzd.com>, emporer@dejazzd.com
says...
>
>
> 42 wrote:
>
> > OK... we all know about the ubiquitous tic in EQ.
> >
> > But I ran accross an article claiming that weapon swings were also
> > governed on a per tic basis. Is this true?
> >
> > The implications of this are signficant, as there should be fairly
> > noticable dps jumps as you cross tic thresholds. (ie from 1 swing per
> > tick to 2 swings per tic, etc...)
> >
> > It also implies that a 50/50 weapon is the same as a 50/55 weapon. (At
> > least unhasted), as they will both only ever swing once per tic.
> >
> > I'd always assumed there was a sub-tic accumulator to carry over the
> > remainder to eliminate this tic artifact, and ensure that even small
> > delay differences between weapons could be observed.
> >
> > At any rate, I'm hoping for a quick answer... I could parse this easily
> > enough, but I'd prefer not need to :) 
>
> There's no tic based marker on weapon swings in EQ1, unless they added
> it in the past month or so since I stopped playing.
>
> With a long enough parse, you can detect a difference in weapon swings
> over time with as little difference as that between 41 and 42 delay.
>
> Haste also affects weapon speed; with a /18 weapon and 70% haste you'll
> see a lot more than one swing per tic. Again, it was not difficult to
> detect a difference between 70% and 75% haste.
>
> When watching speed differences this small, it would be very noticable
> if there was tic based interference in the swing rate.

Thanks I was nearly certain this would be the case! But if it wasn't the
implications would have been profound, and significantly affected how i
approach certain aspects of my equipment :) 
Related resources
Can't find your answer ? Ask !
Anonymous
December 2, 2004 7:39:09 AM

Archived from groups: alt.games.everquest (More info?)

A thousand monkeys banging on keyboards posted the following under the
name 42 <nospam@nospam.com>:

>OK... we all know about the ubiquitous tic in EQ.
>
>But I ran accross an article claiming that weapon swings were also
>governed on a per tic basis. Is this true?

No. Rather obviously wrong actually. What article?


>I'd always assumed there was a sub-tic accumulator to carry over the
>remainder to eliminate this tic artifact, and ensure that even small
>delay differences between weapons could be observed.

The tick is a client side artifact. The server tracks things like mana
and hp in realtime. This means the tick has no gameplay affect at all,
its in there to reduce pressure on the client CPU. Though you still
run into some people who still think sitting to med just before the
tick then standing up then sitting before the next tick works.


--

"Why stop now, just when I'm hating it?" - Marvin

"It's certainly not a "memory leak." - 'shadows', my latest stalker
"No one said it wasn't a memory leak." - 'shadows' a few posts later
Anonymous
December 2, 2004 11:41:26 AM

Archived from groups: alt.games.everquest (More info?)

Ben Sisson <ilkhanikeDIESPAM@yahoo.ca> wrote:
>>I'd always assumed there was a sub-tic accumulator to carry over the
>>remainder to eliminate this tic artifact, and ensure that even small
>>delay differences between weapons could be observed.

> The tick is a client side artifact. The server tracks things like mana
> and hp in realtime. This means the tick has no gameplay affect at all,
> its in there to reduce pressure on the client CPU. Though you still
> run into some people who still think sitting to med just before the
> tick then standing up then sitting before the next tick works.
I'm slightly derailing here but are you sure about that? I did assume
the canni dance was actually working. Though I don't play a shaman. ;) 
And another is aggro on pulls. Sometimes mobs don't notice me when I run
in range and fast out of it again. I did blame it on the tick based
checks but now I'm a bit unsure.


Hagen
December 2, 2004 2:59:16 PM

Archived from groups: alt.games.everquest (More info?)

In article <207tq0du8d09r1j352pfkfpbbchlq0eqio@4ax.com>,
ilkhanikeDIESPAM@yahoo.ca says...
> A thousand monkeys banging on keyboards posted the following under the
> name 42 <nospam@nospam.com>:
>
> >OK... we all know about the ubiquitous tic in EQ.
> >
> >But I ran accross an article claiming that weapon swings were also
> >governed on a per tic basis. Is this true?
>
> No. Rather obviously wrong actually. What article?

Google swings per tic should be in the first couple hits. Something on
"rpgexpert". One of the guides...of which most are very dubious in
quality... but still... there is the odd tidbit... the tribute value
chart is handy ;) 

> >I'd always assumed there was a sub-tic accumulator to carry over the
> >remainder to eliminate this tic artifact, and ensure that even small
> >delay differences between weapons could be observed.
>
> The tick is a client side artifact.

Their is no doubt that their will be -some- fixed temporal granularity
that the game engine is updated on... (Weapon delay data seems to
suggest 1/10th.) Its much closer to real time than the gross granularity
of a tic, but I'm fairly convinced many effects actually -occur- on tic
boundaries, and are not merely -reported- on tic boundaries.

Speaking as a programmer: for effects that only go off 'once per tic'
(e.g. dots) it makes sense to evaluate all of them every 60 cycles (60
1/10th seconds) instead of dealing with them 'in-realtime'. Which is why
two dots even if cast 1.5 seconds apart appear to always impact at the
same instant. (Indeed you can land 2+ dots on a mezzed mob before it
wakes up, and *that* is no 'visual artifact' even if you argue that its
health bar is.

> The server tracks things like mana
> and hp in realtime.

As far as the server tracking hp and mana in realtime... this is
obviously true to a point, we receive heals and take damage more or less
instantaneously (at least within the 1/10th second granularity), but I
wouldn't be surprised if regen is lumped in with the dot evaluation, and
done only once every 60 'cycles'

> This means the tick has no gameplay affect at all,

I played a bard for a -long- time, and I'm convinced of its effect on
several aspects of gameplay.

Mez duration for example... Mezzes *always* wore off at tic intervals,
and two mezzes chain cast (within the same tic) often broke
*simultaneously* indicating that they expired at the tic boundary, and
not in 18 seconds realtime. This was not a 'visual artifact'. There was
no 'reporting delay' Both mobs were still, and then both were NOT still.
There is simply no credibility to claiming the mob was busting my chops
for up to 5 seconds serverside while my client blithely thought it was
still sleeping.

Similiarly when I was 5 twisting. I noticed some buffs simply never
lasted a full cycle while others reliably did. (It appears some are
coded to last 'at least 18 seconds' running 3 tic boundaries, while
others are coded to last 'up to 18 seconds' running only 2 tic
boundaries (the lower level resists in particular I recall are like
this, routinly only lasting 13-15 seconds). I also noticed buffs
routinely wore off *simultaneously* instead of in real time, and this
again was not simply 'a visual artifact'. I concede Stat/resist buffs
are difficult to prove because you can argue that the client updates of
my stats are simply synced to the icon dropping, but that serverside my
+20vsM actually ran out 3.4 seconds ago... However... consider damage
shields... these wear off at the tic mark just like any other bard buff,
and you can monitor its up/not up by observing the damage taking place
on the mob until the instant it drops, and then stopping. There is never
a 3 second lag between the mob not taking ds damage and the ds icon
dropping.

> its in there to reduce pressure on the client CPU. Though you still
> run into some people who still think sitting to med just before the
> tick then standing up then sitting before the next tick works.

I must admit, that while I don't personally engage in this level of
minmaxxing, I did test it at one point, and I was satisfied that it
worked.

I have also experienced the mob aggro effect, where sometimes if moving
fast I can run right through a mob and not aggro it... suggesting that
aggro checks are not performed every 1/10 second cycle, but are also
performed only periodically.

At any rate. I agree that the 'swings per tic' theory this guy was
presesenting as fact is pretty far fetched, and agree that it is
unlikely to be true. But I still wanted to verify. Farfetched and
unlikely aren't good indicators of (un)reality in EQ :) 
Anonymous
December 2, 2004 6:43:19 PM

Archived from groups: alt.games.everquest (More info?)

Ben Sisson <ilkhanikeDIESPAM@yahoo.ca> wrote in
news:207tq0du8d09r1j352pfkfpbbchlq0eqio@4ax.com:

> A thousand monkeys banging on keyboards posted the following under the
> name 42 <nospam@nospam.com>:
>
>>OK... we all know about the ubiquitous tic in EQ.
>>
>>But I ran accross an article claiming that weapon swings were also
>>governed on a per tic basis. Is this true?
>
> No. Rather obviously wrong actually. What article?
>
>
>>I'd always assumed there was a sub-tic accumulator to carry over the
>>remainder to eliminate this tic artifact, and ensure that even small
>>delay differences between weapons could be observed.
>
> The tick is a client side artifact. The server tracks things like mana
> and hp in realtime. This means the tick has no gameplay affect at all,
> its in there to reduce pressure on the client CPU. Though you still
> run into some people who still think sitting to med just before the
> tick then standing up then sitting before the next tick works.
>

Does run counter to my experience as a shaman canni dancing.
Particularly with the number actually being displayed, I can see the
difference in both HP and Mana regen between canni dancing, and just
canning.

--
On Erollisi Marr in <Sanctuary of Marr>
Ancient Graeme Faelban, Barbarian Prophet of 69 seasons

On Steamfont in <Bane of Evil>
Graeme, 16 Dwarven Shaman, 14 Scholar
Anonymous
December 2, 2004 6:43:20 PM

Archived from groups: alt.games.everquest (More info?)

Graeme Faelban wrote:


>>The tick is a client side artifact. The server tracks things like mana
>>and hp in realtime. This means the tick has no gameplay affect at all,
>>its in there to reduce pressure on the client CPU. Though you still
>>run into some people who still think sitting to med just before the
>>tick then standing up then sitting before the next tick works.
>>
>
>
> Does run counter to my experience as a shaman canni dancing.
> Particularly with the number actually being displayed, I can see the
> difference in both HP and Mana regen between canni dancing, and just
> canning.
>
I used to canni dance on my shaman, and certainly seemed to get a lot
more mana back this way than by just standing there and chain casting
canni; wait for a tic, stand, cast canni, sit back down till the next tic.

If mana regen is gradual, than this shouldn't generate much more mana
than just standing, since I was standing about 3/4ths the time

Long before running a shaman, I learned this trick from a druid, who
would stand up, hit melee, and sit back down, I used it for quite a
while with my cleric. The key was to get a high delay, high damage
weapon so you could sit out the time in between delay cycles.

Not only did this seem to work, but I ended up taking it a step further,
when fear kiting, I'd literally sit for about one second per tic,
because I'd have to get up, run up to melee range from the fleeing mob,
hit, and sit.

Not only did this "bunny melee" style seem to generate just as much mana
as sitting the entire time, but there was no noticable difference
between the "sit 5 seconds out of every 6" original style and the "sit
one second out of every 6" chase plan. As long as I was sitting during
the actual tic, I got the same amount of mana back, as far as I could see.

That was a few years back, mind you, and long before they started
listing the actual mana number on your character... it should be much
simpler now to determine what is going on.
Anonymous
December 2, 2004 9:08:47 PM

Archived from groups: alt.games.everquest (More info?)

Lance Berg <emporer@dejazzd.com> wrote in
news:Nv-dnRUnpOzt0TLcRVn-gg@dejazzd.com:

>
>
> Graeme Faelban wrote:
>
>
>>>The tick is a client side artifact. The server tracks things like
>>>mana and hp in realtime. This means the tick has no gameplay affect
>>>at all, its in there to reduce pressure on the client CPU. Though you
>>>still run into some people who still think sitting to med just before
>>>the tick then standing up then sitting before the next tick works.
>>>
>>
>>
>> Does run counter to my experience as a shaman canni dancing.
>> Particularly with the number actually being displayed, I can see the
>> difference in both HP and Mana regen between canni dancing, and just
>> canning.
>>
> I used to canni dance on my shaman, and certainly seemed to get a lot
> more mana back this way than by just standing there and chain casting
> canni; wait for a tic, stand, cast canni, sit back down till the next
> tic.
>
> If mana regen is gradual, than this shouldn't generate much more mana
> than just standing, since I was standing about 3/4ths the time
>
> Long before running a shaman, I learned this trick from a druid, who
> would stand up, hit melee, and sit back down, I used it for quite a
> while with my cleric. The key was to get a high delay, high damage
> weapon so you could sit out the time in between delay cycles.
>
> Not only did this seem to work, but I ended up taking it a step
> further, when fear kiting, I'd literally sit for about one second per
> tic, because I'd have to get up, run up to melee range from the
> fleeing mob, hit, and sit.
>
> Not only did this "bunny melee" style seem to generate just as much
> mana as sitting the entire time, but there was no noticable difference
> between the "sit 5 seconds out of every 6" original style and the "sit
> one second out of every 6" chase plan. As long as I was sitting
> during the actual tic, I got the same amount of mana back, as far as I
> could see.
>
> That was a few years back, mind you, and long before they started
> listing the actual mana number on your character... it should be much
> simpler now to determine what is going on.
>

It is, and at least for canni dancing, it works for both mana and hp
regen.

--
On Erollisi Marr in <Sanctuary of Marr>
Ancient Graeme Faelban, Barbarian Prophet of 69 seasons

On Steamfont in <Bane of Evil>
Graeme, 16 Dwarven Shaman, 14 Scholar
Anonymous
December 3, 2004 1:22:28 AM

Archived from groups: alt.games.everquest (More info?)

A thousand monkeys banging on keyboards posted the following under the
name 42 <nospam@nospam.com>:

>In article <207tq0du8d09r1j352pfkfpbbchlq0eqio@4ax.com>,
>ilkhanikeDIESPAM@yahoo.ca says...
>> A thousand monkeys banging on keyboards posted the following under the
>> name 42 <nospam@nospam.com>:
>>
>> >I'd always assumed there was a sub-tic accumulator to carry over the
>> >remainder to eliminate this tic artifact, and ensure that even small
>> >delay differences between weapons could be observed.
>>
>> The tick is a client side artifact.
>
>Their is no doubt that their will be -some- fixed temporal granularity
>that the game engine is updated on... (Weapon delay data seems to
>suggest 1/10th.)

Yes, but not a 6 second tick. I'm just referring to that.


>> its in there to reduce pressure on the client CPU. Though you still
>> run into some people who still think sitting to med just before the
>> tick then standing up then sitting before the next tick works.
>
>I must admit, that while I don't personally engage in this level of
>minmaxxing, I did test it at one point, and I was satisfied that it
>worked.

It doesn't, whatever those posts below me think. You can see what is
really happening by doing it over a fairly significant period of
time/mana. People used to do tests of this. Try this out and tell me
what happens: get rid of most your mana (and take off your mana regen
gear, it makes this test harder). Then for a while do your
sit-at-tick-stand trick, trying to minimize as much time sitting as
you can. Then start trying to cast a spell with big mana requirement,
starting when you don't have enough but are getting close. For a
while, it will just instantly give you the no-mana message. This is
when the client knows you don't have enough mana. Then there can be
(depending on how much mana you're regenning) a time when you try, the
gems grey out as if you're starting a cast, but then it stops and
again gives the no-mana message. This is the client saying yes, you
have the mana, but the server responding no, you don't. I believe
doing that at that point resyncs the manabar so you'll get instant
notices of no-mana again. Soon after you will have enough mana to cast
and all will be well. People who did this test in the past noticed
that when they did the sit-stand thing and didn't resync (ie, they
waited until they did have the mana to cast the spell before trying),
the spell "seemed" to take more mana than usual (this was before the
numbers were available). You can google the group for those, its come
up many times before.

Notice you can't tell this using cannibalize because you will resync
the instant you cast the spell. The only way to observe this in action
is to force yourself out of sync by not casting while you're sitting
and standing. I don't care if others don't believe me or not on this,
we tested this out before most of them started playing the game. They
can believe whatever they want.

>
>I have also experienced the mob aggro effect, where sometimes if moving
>fast I can run right through a mob and not aggro it... suggesting that
>aggro checks are not performed every 1/10 second cycle, but are also
>performed only periodically.

Well now that one is complicated because movement is controlled
clientside and the position update period changes according to what
you're doing. It's definately *not* on the tick (6 seconds). The
longest I've seen it go is something like 15 seconds (not exact)
sitting in an empty Nexus doing nothing. You see the packetloss bar
creep up as if you're lagging, but all it is is no packets being sent
or received at all. Normal movement it seemed to be every second or
so, perhaps a bit less. During combat and other events like that, its
probably updating position fairly fast (well under a second), since
you see other people reacting almost as fast as they really are. An
interesting biproduct of clientside movement is that the *higher* your
ping, the better chance you have of performing that little trick you
mentioned. Make it high enough and you could conceivably get past a
mob's aggro radius before the server receives your movement packets.
Since the server bows to the client in this case (one of the very few
places this is true in EQ), you get past scott free since I'm pretty
sure the server doesn't check to see what happened in the meantime (it
does try to predict where you are in the future, however, so this will
only work at the start of the movement chain). This is the same basis
as some of the movement cheats in MEQ.


>At any rate. I agree that the 'swings per tic' theory this guy was
>presesenting as fact is pretty far fetched, and agree that it is
>unlikely to be true.

Its mindboggling someone would even suggest that. It's pretty obvious
its not how it works


--

"Why stop now, just when I'm hating it?" - Marvin

"It's certainly not a "memory leak." - 'shadows', my latest stalker
"No one said it wasn't a memory leak." - 'shadows' a few posts later
December 3, 2004 2:20:49 AM

Archived from groups: alt.games.everquest (More info?)

In article <3a4vq0pkohf7f2oc37m5eiotfkvf5isajk@4ax.com>,
ilkhanikeDIESPAM@yahoo.ca says...

> >I must admit, that while I don't personally engage in this level of
> >minmaxxing, I did test it at one point, and I was satisfied that it
> >worked.
>
> It doesn't, whatever those posts below me think. You can see what is
> really happening by doing it over a fairly significant period of
> time/mana. People used to do tests of this. Try this out and tell me
> what happens: get rid of most your mana (and take off your mana regen
> gear, it makes this test harder). Then for a while do your
> sit-at-tick-stand trick, trying to minimize as much time sitting as
> you can. Then start trying to cast a spell with big mana requirement,
> starting when you don't have enough but are getting close. For a
> while, it will just instantly give you the no-mana message. This is
> when the client knows you don't have enough mana. Then there can be
> (depending on how much mana you're regenning) a time when you try, the
> gems grey out as if you're starting a cast, but then it stops and
> again gives the no-mana message. This is the client saying yes, you
> have the mana, but the server responding no, you don't. I believe
> doing that at that point resyncs the manabar so you'll get instant
> notices of no-mana again. Soon after you will have enough mana to cast
> and all will be well. People who did this test in the past noticed
> that when they did the sit-stand thing and didn't resync (ie, they
> waited until they did have the mana to cast the spell before trying),
> the spell "seemed" to take more mana than usual (this was before the
> numbers were available). You can google the group for those, its come
> up many times before.
>
> Notice you can't tell this using cannibalize because you will resync
> the instant you cast the spell. The only way to observe this in action
> is to force yourself out of sync by not casting while you're sitting
> and standing. I don't care if others don't believe me or not on this,
> we tested this out before most of them started playing the game. They
> can believe whatever they want.

Hmmm... I've already encountered something like this, when trying to
cast rez for example... I'll have just crossed the boundary according to
my mana bar, and i stand and poof insufficient mana, and then my mana
number drops 10 or 20 points... resyncing obviously.

However in this case its only out of sync by a tics worth, so its rarely
a big deal. (Although its extremely frustrating when it -is- a big
deal.)

At any rate, a much simpler test than the one you suggest would be to
dry up your mana pool, and then sit-stand dance and see how long it
takes you to get to -full- (when you are full cast a level 1 5 mana
spell to force a resync and confirm you were actually full.), and then
do it again and sit the whole time. Time both tests from 0 to full.

If the server is allocating mana in real time, the time to complete the
first test should be nearly 30-50% longer than the second test, as I am
standing 50% of the time in the first test and getting only "2-5/tic"
instead of "20-30/tic" or whatever I'm at for a given character.

Or is there a flaw you see with this test?

> >
> >I have also experienced the mob aggro effect, where sometimes if moving
> >fast I can run right through a mob and not aggro it... suggesting that
> >aggro checks are not performed every 1/10 second cycle, but are also
> >performed only periodically.
>
> Well now that one is complicated because movement is controlled
> clientside and the position update period changes according to what
> you're doing. It's definately *not* on the tick (6 seconds). The
> longest I've seen it go is something like 15 seconds (not exact)
> sitting in an empty Nexus doing nothing. You see the packetloss bar
> creep up as if you're lagging, but all it is is no packets being sent
> or received at all. Normal movement it seemed to be every second or
> so, perhaps a bit less. During combat and other events like that, its
> probably updating position fairly fast (well under a second), since
> you see other people reacting almost as fast as they really are. An
> interesting biproduct of clientside movement is that the *higher* your
> ping, the better chance you have of performing that little trick you
> mentioned. Make it high enough and you could conceivably get past a
> mob's aggro radius before the server receives your movement packets.
> Since the server bows to the client in this case (one of the very few
> places this is true in EQ), you get past scott free since I'm pretty
> sure the server doesn't check to see what happened in the meantime (it
> does try to predict where you are in the future, however, so this will
> only work at the start of the movement chain). This is the same basis
> as some of the movement cheats in MEQ.



That begs 4 questions:

1) It happens relatively reliably, and as a late night player I'm
skeptical that its really internet dispruption. (Which is what it
appears you are suggesting... high ping, latency spike, lost packets,
etc)

2) I do often pull mobs with proximity (getting close enough and waiting
for them to aggro (ie when I've run out of arrows or other ranged
attacks, but want to maintain as much distance as possible so that I'm
not getting hit instantly...) and they do routinely take up to 2-5
seconds to come at me. Which suggests that aggro is not being checked
instantaneously. Given that I've moved into aggro range and stopped, I'd
expect the server to have good up to date position info. (This seems
confirmed by your own description of how movement data is updated).

3) Unless the packets are outright -lost- why wouldn't the server still
receive them and and process aggro on them unless they were seriously
outdated or out of order. ( I mean, if I send x1,y1.... and then the
server gets x2,y2 and x3,y3 together 3 seconds later sure x3,y3 is
already out of range again... but why not process x2,y2 for aggro and
activate the mob, especially if x2, y2 is smack dab in the middle of a
stationary unengaged mobs aggro range...?)

4) Similiarly but from the -other- side of the coin. Consider me being
stationary for an extended period of time. We can assume the server has
good accurate position data on me. When a mob wanders up, it will
frequently get right on top of me and or even pass me before aggroing.
Given the server has accurate position data on both an unengaged mob and
a stationary player there is no reason for this to occur unless aggro is
only checked periodically.

>
> >At any rate. I agree that the 'swings per tic' theory this guy was
> >presesenting as fact is pretty far fetched, and agree that it is
> >unlikely to be true.
>
> Its mindboggling someone would even suggest that. It's pretty obvious
> its not how it works

I did immediately discount it at first, but then, as rpgexpert allows
people to 'comment' on the article I expected an explosion of "WTF are
you smoking" comments... but instead it was largely... "hey great
article"... and that's what prompted me to want to verify this. I can
see one guy spouting nonense... but usually it gets shot down fast, or
at the very least its gets disputed.

PS
I also noted you didn't address my observations with bard buffs
simultaneously wearing off (which shouldn't even be possible!!) Mezzes
and DSes in particular as the effects of them wearing off more are
visceral than simply some stat number display changes).
Anonymous
December 3, 2004 2:59:15 AM

Archived from groups: alt.games.everquest (More info?)

A thousand monkeys banging on keyboards posted the following under the
name 42 <nospam@nospam.com>:

>At any rate, a much simpler test than the one you suggest would be to
>dry up your mana pool, and then sit-stand dance and see how long it
>takes you to get to -full- (when you are full cast a level 1 5 mana
>spell to force a resync and confirm you were actually full.), and then
>do it again and sit the whole time. Time both tests from 0 to full.
>
>If the server is allocating mana in real time, the time to complete the
>first test should be nearly 30-50% longer than the second test, as I am
>standing 50% of the time in the first test and getting only "2-5/tic"
>instead of "20-30/tic" or whatever I'm at for a given character.
>
>Or is there a flaw you see with this test?

Only a minor possibility that it won't register the "stand" command if
you do nothing but sit down immediately afterwards in the server's
calculations of mana regen. I doubt that would happen though, since we
know it does track sit/stand as it happens, as countless annoying
hyperactive kids doing circles because they're attention span has run
out have proven.

Try that and see what happens.


>That begs 4 questions:
>
>1) It happens relatively reliably, and as a late night player I'm
>skeptical that its really internet dispruption. (Which is what it
>appears you are suggesting... high ping, latency spike, lost packets,
>etc)
>
>2) I do often pull mobs with proximity (getting close enough and waiting
>for them to aggro (ie when I've run out of arrows or other ranged
>attacks, but want to maintain as much distance as possible so that I'm
>not getting hit instantly...) and they do routinely take up to 2-5
>seconds to come at me. Which suggests that aggro is not being checked
>instantaneously.

Or that position is not being checked instantaneously. And we already
know its not. But yes, mob aggro is not in real time, it can't be
because that would be a huge strain on the server. But the
calculations for when a mob aggros is going to be more than a simple 6
second interval check.

Think of the reverse - how many times have you gotten aggro when you
*shouldn't* have, if this system was as simple as 6 second tick
checks?


>3) Unless the packets are outright -lost- why wouldn't the server still
>receive them and and process aggro on them unless they were seriously
>outdated or out of order. ( I mean, if I send x1,y1.... and then the
>server gets x2,y2 and x3,y3 together 3 seconds later sure x3,y3 is
>already out of range again... but why not process x2,y2 for aggro and
>activate the mob, especially if x2, y2 is smack dab in the middle of a
>stationary unengaged mobs aggro range...?)

You'd have to ask a network whiz this but I am about 60% sure the EQ
server will ignore any information packet significantly out of sync
(not commands, though, it will always process them). Isn't this the
core of why it uses UDP instead of TCP or something? For very minor
issues I'm sure it does do exactly what you describe.

>
>4) Similiarly but from the -other- side of the coin. Consider me being
>stationary for an extended period of time. We can assume the server has
>good accurate position data on me. When a mob wanders up, it will
>frequently get right on top of me and or even pass me before aggroing.
>Given the server has accurate position data on both an unengaged mob and
>a stationary player there is no reason for this to occur unless aggro is
>only checked periodically.

Yes, but the formula is more complicated than a 6 second tick.


>I also noted you didn't address my observations with bard buffs
>simultaneously wearing off (which shouldn't even be possible!!) Mezzes
>and DSes in particular as the effects of them wearing off more are
>visceral than simply some stat number display changes).

Spell durations do use the 6 second timer, you are right about that.
My feeling is that a lot of things used that timer at an early alpha
stage of the game as a placeholder, then most things were changed to
more permanent forms later in development. Since it worked fine for
spell durations, they just left it that way. It would *not* work fine
for things like medding, mob aggro, movement, etc, and so all those
things got changed or never were like that.


--

"Why stop now, just when I'm hating it?" - Marvin

"It's certainly not a "memory leak." - 'shadows', my latest stalker
"No one said it wasn't a memory leak." - 'shadows' a few posts later
Anonymous
December 3, 2004 4:50:36 AM

Archived from groups: alt.games.everquest (More info?)

42 <nospam@nospam.com> writes:
> At any rate, a much simpler test than the one you suggest would be to
> dry up your mana pool, and then sit-stand dance and see how long it
> takes you to get to -full- (when you are full cast a level 1 5 mana
> spell to force a resync and confirm you were actually full.), and then
> do it again and sit the whole time. Time both tests from 0 to full.
>
> If the server is allocating mana in real time, the time to complete the
> first test should be nearly 30-50% longer than the second test, as I am
> standing 50% of the time in the first test and getting only "2-5/tic"
> instead of "20-30/tic" or whatever I'm at for a given character.
>
> Or is there a flaw you see with this test?

Not a flaw, necessarily, but I see an even simpler test.

As I read it, the theory being tested is that the client applies
mana (and hp) regen at the tick, but the server applies it on a
finer level (possibly 1/10 second), and that you can see the
difference by forcing the client to sync with the server.

So, how's this for an experiment to test the theory? Get rid of
your mana regen items/buffs (so the percentage difference between
sitting and standing mana regen is larger), and burn your mana bar
down to roughly zero (doesn't have to be exact). Now do the dance,
sitting only for the tick and standing as much as possible. (A
hotkey and a simple macro tool such as the ranger Autofire hack
can help get the timing right.) Watch your mana number and verify
that the client is telling you you're getting sitting regen at each
tick. Once you've gotten a large amount of mana back (say, 1000 or
more), cast a fast 5-mana spell to force a resync, and see what
happens to your mana total.

If the theory is correct, you'd expect your mana to drop a lot when
you cast the spell, as the server informs your client of the true
mana number given that you weren't really sitting all that time.

-- Don.

---------------------------------------------------------------------
-- See the a.g.e/EQ1 FAQ at http://www.iCynic.com/~don/EQ/age.faq.htm
--
-- Sukrasisx, Monk 49 on E. Marr Note: If you reply by mail,
-- Terrwini, Druid 38 on E. Marr I'll get to it sooner if you
-- Wizbeau, Wizard 35 on E. Marr remove the "hyphen n s"
-- http://www.iCynic.com/~don
Anonymous
December 3, 2004 5:50:58 AM

Archived from groups: alt.games.everquest (More info?)

A thousand monkeys banging on keyboards posted the following under the
name Don Woods <don-ns@iCynic.com>:

>42 <nospam@nospam.com> writes:
>> At any rate, a much simpler test than the one you suggest would be to
>> dry up your mana pool, and then sit-stand dance and see how long it
>> takes you to get to -full- (when you are full cast a level 1 5 mana
>> spell to force a resync and confirm you were actually full.), and then
>> do it again and sit the whole time. Time both tests from 0 to full.
>>
>> If the server is allocating mana in real time, the time to complete the
>> first test should be nearly 30-50% longer than the second test, as I am
>> standing 50% of the time in the first test and getting only "2-5/tic"
>> instead of "20-30/tic" or whatever I'm at for a given character.
>>
>> Or is there a flaw you see with this test?
>
>Not a flaw, necessarily, but I see an even simpler test.
>
>As I read it, the theory being tested is that the client applies
>mana (and hp) regen at the tick, but the server applies it on a
>finer level (possibly 1/10 second), and that you can see the
>difference by forcing the client to sync with the server.
>
>So, how's this for an experiment to test the theory? Get rid of
>your mana regen items/buffs (so the percentage difference between
>sitting and standing mana regen is larger), and burn your mana bar
>down to roughly zero (doesn't have to be exact). Now do the dance,
>sitting only for the tick and standing as much as possible. (A
>hotkey and a simple macro tool such as the ranger Autofire hack
>can help get the timing right.) Watch your mana number and verify
>that the client is telling you you're getting sitting regen at each
>tick. Once you've gotten a large amount of mana back (say, 1000 or
>more), cast a fast 5-mana spell to force a resync, and see what
>happens to your mana total.
>
>If the theory is correct, you'd expect your mana to drop a lot when
>you cast the spell, as the server informs your client of the true
>mana number given that you weren't really sitting all that time.

Unless its more complicated than that, possibly due to when the server
actually considers you to start and stop sitting and standing compared
to when *you* do.

I suspect the experiment, if someone tries it (my account is
deactivated), will show mana not being as high as it would be but not
30-50% lower even if 42 is very fast on the mouse.


--

"Why stop now, just when I'm hating it?" - Marvin

"It's certainly not a "memory leak." - 'shadows', my latest stalker
"No one said it wasn't a memory leak." - 'shadows' a few posts later
December 3, 2004 12:07:39 PM

Archived from groups: alt.games.everquest (More info?)

Lance Berg <emporer@dejazzd.com> writes:

> Not only did this "bunny melee" style seem to generate just as much
> mana as sitting the entire time, but there was no noticable difference
> between the "sit 5 seconds out of every 6" original style and the "sit
> one second out of every 6" chase plan. As long as I was sitting
> during the actual tic, I got the same amount of mana back, as far as I
> could see.

The problem is, sometimes the client displays the mana/hp regen of a
tick prematurely - you sit, see your mana tick up, immediately cast
canni, and end up with about as much mana as before the canni,
presumably because the actual server-side tick happened later than the
client thought it did. That happened to my shaman, anyway. So it's
not quite as easy as just waiting for the tick being displayed.
Anonymous
December 3, 2004 12:07:40 PM

Archived from groups: alt.games.everquest (More info?)

patrik@nordebo.com wrote:
> Lance Berg <emporer@dejazzd.com> writes:
>
>
>>Not only did this "bunny melee" style seem to generate just as much
>>mana as sitting the entire time, but there was no noticable difference
>>between the "sit 5 seconds out of every 6" original style and the "sit
>>one second out of every 6" chase plan. As long as I was sitting
>>during the actual tic, I got the same amount of mana back, as far as I
>>could see.
>
>
> The problem is, sometimes the client displays the mana/hp regen of a
> tick prematurely - you sit, see your mana tick up, immediately cast
> canni, and end up with about as much mana as before the canni,
> presumably because the actual server-side tick happened later than the
> client thought it did. That happened to my shaman, anyway. So it's
> not quite as easy as just waiting for the tick being displayed.

Sure, as with all things EQ, it can be kludgy, particularly if you are
in lag.

But it usually worked pretty well... which suggests to me that it was
tic based, even if client and server disagreed sometimes about exactly
when that tic actually took place.

The counterarguement is that mana actually accumulates gradually, and
for some reason the client artificially displays it on a tic basis, but
its lying. My experience suggests otherwise.
Anonymous
December 3, 2004 6:28:56 PM

Archived from groups: alt.games.everquest (More info?)

Ben Sisson <ilkhanikeDIESPAM@yahoo.ca> wrote in
news:3a4vq0pkohf7f2oc37m5eiotfkvf5isajk@4ax.com:

> A thousand monkeys banging on keyboards posted the following under the
> name 42 <nospam@nospam.com>:
>
>>In article <207tq0du8d09r1j352pfkfpbbchlq0eqio@4ax.com>,
>>ilkhanikeDIESPAM@yahoo.ca says...
>>> A thousand monkeys banging on keyboards posted the following under
the
>>> name 42 <nospam@nospam.com>:
>>>
>>> >I'd always assumed there was a sub-tic accumulator to carry over the
>>> >remainder to eliminate this tic artifact, and ensure that even small
>>> >delay differences between weapons could be observed.
>>>
>>> The tick is a client side artifact.
>>
>>Their is no doubt that their will be -some- fixed temporal granularity
>>that the game engine is updated on... (Weapon delay data seems to
>>suggest 1/10th.)
>
> Yes, but not a 6 second tick. I'm just referring to that.
>
>
>>> its in there to reduce pressure on the client CPU. Though you still
>>> run into some people who still think sitting to med just before the
>>> tick then standing up then sitting before the next tick works.
>>
>>I must admit, that while I don't personally engage in this level of
>>minmaxxing, I did test it at one point, and I was satisfied that it
>>worked.
>
> It doesn't, whatever those posts below me think. You can see what is
> really happening by doing it over a fairly significant period of
> time/mana. People used to do tests of this. Try this out and tell me
> what happens: get rid of most your mana (and take off your mana regen
> gear, it makes this test harder). Then for a while do your
> sit-at-tick-stand trick, trying to minimize as much time sitting as
> you can. Then start trying to cast a spell with big mana requirement,
> starting when you don't have enough but are getting close. For a
> while, it will just instantly give you the no-mana message. This is
> when the client knows you don't have enough mana. Then there can be
> (depending on how much mana you're regenning) a time when you try, the
> gems grey out as if you're starting a cast, but then it stops and
> again gives the no-mana message. This is the client saying yes, you
> have the mana, but the server responding no, you don't. I believe
> doing that at that point resyncs the manabar so you'll get instant
> notices of no-mana again. Soon after you will have enough mana to cast
> and all will be well. People who did this test in the past noticed
> that when they did the sit-stand thing and didn't resync (ie, they
> waited until they did have the mana to cast the spell before trying),
> the spell "seemed" to take more mana than usual (this was before the
> numbers were available). You can google the group for those, its come
> up many times before.
>
> Notice you can't tell this using cannibalize because you will resync
> the instant you cast the spell. The only way to observe this in action
> is to force yourself out of sync by not casting while you're sitting
> and standing. I don't care if others don't believe me or not on this,
> we tested this out before most of them started playing the game. They
> can believe whatever they want.

If it resyncs on the cannibalize, then the mana level should drop each
time it is cast, I do not see that behavior when canni dancing.
Particularly now, with the numbers being displayed it is very easy to
tell. I'll try it again tonight if I remember, just to verify, but I
watch the numbers quite carefully, so I know when to cast canni again.
What I have noticed, particularly for the hp bar is two updates occuring
a very short time apart, I always wait on the second update before
casting canni again.

--
On Erollisi Marr in <Sanctuary of Marr>
Ancient Graeme Faelban, Barbarian Prophet of 69 seasons

On Steamfont in <Bane of Evil>
Graeme, 16 Dwarven Shaman, 14 Scholar
Anonymous
December 3, 2004 6:30:15 PM

Archived from groups: alt.games.everquest (More info?)

patrik@nordebo.com wrote in news:87acsvst2s.fsf@pluto.elizium.org:

> Lance Berg <emporer@dejazzd.com> writes:
>
>> Not only did this "bunny melee" style seem to generate just as much
>> mana as sitting the entire time, but there was no noticable difference
>> between the "sit 5 seconds out of every 6" original style and the "sit
>> one second out of every 6" chase plan. As long as I was sitting
>> during the actual tic, I got the same amount of mana back, as far as I
>> could see.
>
> The problem is, sometimes the client displays the mana/hp regen of a
> tick prematurely - you sit, see your mana tick up, immediately cast
> canni, and end up with about as much mana as before the canni,
> presumably because the actual server-side tick happened later than the
> client thought it did. That happened to my shaman, anyway. So it's
> not quite as easy as just waiting for the tick being displayed.
>

Yes, I am aware of that, and I always wait for a short time after the
update. Often you can see two updates occuring, particularly on the hp
bar.

--
On Erollisi Marr in <Sanctuary of Marr>
Ancient Graeme Faelban, Barbarian Prophet of 69 seasons

On Steamfont in <Bane of Evil>
Graeme, 16 Dwarven Shaman, 14 Scholar
Anonymous
December 4, 2004 12:42:20 PM

Archived from groups: alt.games.everquest (More info?)

Graeme Faelban <RichardRapier@netscape.net> wrote:
> If it resyncs on the cannibalize, then the mana level should drop each
> time it is cast, I do not see that behavior when canni dancing.
> Particularly now, with the numbers being displayed it is very easy to
> tell. I'll try it again tonight if I remember, just to verify, but I
> watch the numbers quite carefully, so I know when to cast canni again.
> What I have noticed, particularly for the hp bar is two updates occuring
> a very short time apart, I always wait on the second update before
> casting canni again.
At least for the hp bar the sync is nearly instantaneous imho. I
remember being in the MT group at an avatar of war raid. The flickering
hp bar of our MT then made me nervous beyond belief. And I'm not a
cleric. :) 

On the other hand it was a fantastic experience. You actually could feel
the mighty forces crashing against each other. Unfortunately the AoW won
at that time...


Hagen
Anonymous
December 4, 2004 4:07:56 PM

Archived from groups: alt.games.everquest (More info?)

Don Woods <don-ns@iCynic.com> writes:
> As I read it, the theory being tested is that the client applies
> mana (and hp) regen at the tick, but the server applies it on a
> finer level (possibly 1/10 second), and that you can see the
> difference by forcing the client to sync with the server.
>
> So, how's this for an experiment to test the theory? Get rid of
> your mana regen items/buffs (so the percentage difference between
> sitting and standing mana regen is larger), and burn your mana bar
> down to roughly zero (doesn't have to be exact). Now do the dance,
> sitting only for the tick and standing as much as possible. (A
> hotkey and a simple macro tool such as the ranger Autofire hack
> can help get the timing right.) Watch your mana number and verify
> that the client is telling you you're getting sitting regen at each
> tick. Once you've gotten a large amount of mana back (say, 1000 or
> more), cast a fast 5-mana spell to force a resync, and see what
> happens to your mana total.
>
> If the theory is correct, you'd expect your mana to drop a lot when
> you cast the spell, as the server informs your client of the true
> mana number given that you weren't really sitting all that time.

Well, I ran the experiment tonight, twice. I burned my bar down to
roughly zero (needed to imbue some plains pebbles anyway, so it gave
me an excuse :-), and rigged up a sit/stand hotkey with the right
pauses so it got me as close to 6 seconds as possible, then mashed
away on it, so I managed to sit for only about 2 seconds out of 6,
but almost always at the tick, as verified by seeing how much my
client showed as my mana. It mostly went up 17, compared to 1 if
it thought I was standing at the tick. After I'd gotten back to
around 500 mana, I cast a 30-mana spell and -- at the end of the
casting is when it synched -- it showed me dropping more than 200
mana. So then I shifted my pattern using the same hotkey, but
trying to be standing at each tick, which was a bit easier since
I was standing more than sitting anyway. I held that rhythm for
a hundred ticks or so, getting mostly one per tick, then cast a
5-mana spell, and watched my mana jump up by over 500, landing at
1100+.

So I guess all that dancing is just so you can feel you're doing
something instead of just watching the numbers go by. :-)

-- Don.

---------------------------------------------------------------------
-- See the a.g.e/EQ1 FAQ at http://www.iCynic.com/~don/EQ/age.faq.htm
--
-- Sukrasisx, Monk 49 on E. Marr Note: If you reply by mail,
-- Terrwini, Druid 38 on E. Marr I'll get to it sooner if you
-- Wizbeau, Wizard 35 on E. Marr remove the "hyphen n s"
-- http://www.iCynic.com/~don
December 5, 2004 11:40:19 AM

Archived from groups: alt.games.everquest (More info?)

In article <7wmzwu2ous.fsf@ca.icynic.com>, don-ns@iCynic.com says...
> Don Woods <don-ns@iCynic.com> writes:
> > As I read it, the theory being tested is that the client applies
> > mana (and hp) regen at the tick, but the server applies it on a
> > finer level (possibly 1/10 second), and that you can see the
> > difference by forcing the client to sync with the server.
> >
> > So, how's this for an experiment to test the theory? Get rid of
> > your mana regen items/buffs (so the percentage difference between
> > sitting and standing mana regen is larger), and burn your mana bar
> > down to roughly zero (doesn't have to be exact). Now do the dance,
> > sitting only for the tick and standing as much as possible. (A
> > hotkey and a simple macro tool such as the ranger Autofire hack
> > can help get the timing right.) Watch your mana number and verify
> > that the client is telling you you're getting sitting regen at each
> > tick. Once you've gotten a large amount of mana back (say, 1000 or
> > more), cast a fast 5-mana spell to force a resync, and see what
> > happens to your mana total.
> >
> > If the theory is correct, you'd expect your mana to drop a lot when
> > you cast the spell, as the server informs your client of the true
> > mana number given that you weren't really sitting all that time.
>
> Well, I ran the experiment tonight, twice. I burned my bar down to
> roughly zero (needed to imbue some plains pebbles anyway, so it gave
> me an excuse :-), and rigged up a sit/stand hotkey with the right
> pauses so it got me as close to 6 seconds as possible, then mashed
> away on it, so I managed to sit for only about 2 seconds out of 6,
> but almost always at the tick, as verified by seeing how much my
> client showed as my mana. It mostly went up 17, compared to 1 if
> it thought I was standing at the tick. After I'd gotten back to
> around 500 mana, I cast a 30-mana spell and -- at the end of the
> casting is when it synched -- it showed me dropping more than 200
> mana.

500/17= ~29

29 tics * 2/6 @17 mana/tic = 164
+30 mana for the spell is 194.

Very close to the 200+ you observed. (And my 29 tics is conservative
because it assumes you were sitting at the correct time *every* time
instead of "most of the time".

> So then I shifted my pattern using the same hotkey, but
> trying to be standing at each tick, which was a bit easier since
> I was standing more than sitting anyway. I held that rhythm for
> a hundred ticks or so, getting mostly one per tick, then cast a
> 5-mana spell, and watched my mana jump up by over 500, landing at
> 1100+.
>
> So I guess all that dancing is just so you can feel you're doing
> something instead of just watching the numbers go by. :-)
>
> -- Don.

Again the numbers line up with Ben's model:
100 tics sitting 2s/6s with a 17mana/tic regen is 100*2/6*17 = 566 which
is quite close to expected.

I expect a more rigorous test and measurements would further constrain
the error.

Well, Ben, for mana/hp regen I'm convinced. And we've already agreed
that for spells wearing off the tic is being used.

That leaves aggro as unresolved. You've conceded that the aggro isn't
instantaneous but have maintained that its 'more complicated' than
simply on the tic interval. I can live with that, although I'm confident
that at least one important part of aggro is a periodical check at
around a tics interval (perhaps not even in sync with the players
'tic'), and I have no disagreement with the premise that there are
additional 'triggers' for additional instantaneous aggro checks.
Anonymous
December 6, 2004 1:31:04 PM

Archived from groups: alt.games.everquest (More info?)

42 <nospam@nospam.com> writes:
> Well, Ben, for mana/hp regen I'm convinced. And we've already agreed
> that for spells wearing off the tic is being used.
>
> That leaves aggro as unresolved. You've conceded that the aggro isn't
> instantaneous but have maintained that its 'more complicated' than
> simply on the tic interval. I can live with that, although I'm confident
> that at least one important part of aggro is a periodical check at
> around a tics interval (perhaps not even in sync with the players
> 'tic'), and I have no disagreement with the premise that there are
> additional 'triggers' for additional instantaneous aggro checks.

Somewhat related to spells wearing off and aggro, I've noticed
that when I cast a DOT on a mob, the mob usually doesn't react
right away. I'm guessing the damage is applied only on the tick,
so the spell effect is delayed to start on a tick, and that's why
spells wear off on the tick. (And why all the timers on in the
buffs window are always multiples of six seconds apart.)

-- Don.

---------------------------------------------------------------------
-- See the a.g.e/EQ1 FAQ at http://www.iCynic.com/~don/EQ/age.faq.htm
--
-- Sukrasisx, Monk 49 on E. Marr Note: If you reply by mail,
-- Terrwini, Druid 38 on E. Marr I'll get to it sooner if you
-- Wizbeau, Wizard 35 on E. Marr remove the "hyphen n s"
-- http://www.iCynic.com/~don
!