[MUD-Dev] Gearing up against GEAR
archer at frmug.org
Tue Jul 24 11:38:19 New Zealand Standard Time 2001
According to Sean Kelly:
> From: "Vincent Archer" <archer at frmug.org>
> I don't buy this. AC, like MMORPG's, will repeat the same combat
> action until you explicitly alter it. So when I hot "attack
> fast/weak" I continue to attack fast until I press the "attack
> slow/strong" button. So the client isn't sending "attack"
> commands every few ticks, it's telling the server "i'm going to
> keep attacking at this rate until further notice." The server
> then does realtime turn-based resolution of combat based on its
> own internal timer. Issuing multiple attack requests is
I'm not sure about this. See the little checkbox on the left of your
attack bar, labelled "Repeat attack"? If you uncheck it, you are
responsible for the attack repetition yourself. And I suspect that,
if you check it, it's merely the client, not the server, who does
I know that ranged attacks (archery) are repeated client-side. I've
fought in high-lag situations, and the archer (pun intended) keeps
on sending arrows until notified that the mob has died. It's not
merely animation, all these arrows are spent (fortunately, since
there was nothing to strike, you can go and collect them from the
> For spellcasting, there might be a slight advantage is using GEAR.
> As while spells take a fixed amount of time on the server, they
> are one-off events. So in times of high lag it might pay to push
> through a couple spellcasting packets all at once.
Given that GEAR is making things hell on Darktide, where offensive
magic and client-repeated archery are the main offensive methods,
one can see the impact of it. :(
>> I'm surprised accelerated movement from GEAR works, given that,
>> for AC the server *does* process movement and has to acknowledge
> I agree. All I can see GEAR doing for AC is screwing up the
> framerate on the client side and flooding the server with extra
> packets on the server side.
Unfortunately, it seems to work.
>> How does one fight GEAR? I see no solution except to report the
>> timer on the client in the packet protocol. This allows the
>> server to check for time drift. If time drifts constantly and at
>> a fast rate, the client is probably GEARed.
> Is there a way to get at any other timer that isn't affected by
> GEAR? If so, I'd report both. Drift should be rapidly obvious.
There aren't many (stable timers, that is). I've checked speedhack
on my machine, to see what other symptoms it could have, and my
standard clock was speeded up by the same ratio. I suspect it acts
on the most basic timer that is used to derive all other timers in
Vincent Archer Email: archer at frmug.org
All men are mortal. Socrates was mortal. Therefore, all men are Socrates.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev