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).
Facebook
Twitter
Instagram