Fastwalk system

[VeNdOr]

RunUO uses client/server fastwalk system to prevent use of gear, in fact, if a client uses some speedup software to increase its speed, even if the client sees its player run faster than normal, the server put the player at the right position. (more tiles backward).

This is a very important feature and it would be very nice to be implemented...

[innominabile]

Yes... this is a MUST for pol097 or pol098....
As optional feature if use too cpu.

The use os softwares that modify speed *MUST* end!!!!

[Marilla]

I agree strongly with one thing: That this be optional. Some shards simply have zero trouble with this sort of thing, and it would be nice to leave out what I suspect could be a fairly significant amount of processing.

That said... this is a very interesting issue that I wish I knew more about the specifics of the walk-related packets and client/server communications to play with, as an exercise. I imagine it would ultimately have to come down to being able to keep a running total of incoming walk request packets and being able to determine if they have been coming in at too fast a rate. The trick, I imagine, would be in finding a sweet spot where you catch enough fast walkers, but don't get anyone that simply has a very fast connection... beyond doing it in such a way so as not to slow things down generally.

[CWO]

well I've done this with a packethook with a small bit of lag attached to it. It was enough to generate many complaints about it in legitimate situations and I stopped it. The core could possibly handle this a bit faster to the point where it wont be lagging people behind a little. Marilla its not that much processing at all even in scripts. Clients are sent random 32-bit numbers that the client recieves and automatically sends back with the move request packet (which its doing anyway, just with POL its 00 00 00 00 since POL doesnt send any of these packets). POL just needs to check that its an actual number it sent and that its not 0 and it will be fine. Its still a bit rough to do in a packethook though.

[Marilla]

That's why I said I wished I knew more about how the walk packets worked and stuff

So, how do the client/server deal with the issue of the walk requests being queued up by the client? Does the client just send 00's until it starts getting acks with the next numbers to use, or does the server pre-send something to the client to tell it which numbers to use for it's first couple of walk requests?

Then, beyond that, I'm guessing the client just stores the key values sent in the acks and sends them back out, in order, with the walk requests from there on, and then the server keeps track of the numbers it has sent the client, and validates them on the incoming walk requests to be sure it's sending back the same info it sent out?


Any chance we can see the packet hook you did? That might get some juices flowing.

[CWO]

Basically the client has this all hardcoded. You can use the 0xBF packet to send these 32-bit numbers.

http://packets.polserver.com/index.php?op=showpacket&packet=0xBF

On login, you'd use 0xBF with the first subcommand which initializes the buffer for movement. You can send 6 32-bit numbers to the client. When the client requests to move with packet 0x02, appended onto the end of it is going to be either one of these 32 bit numbers or 0.

http://packets.polserver.com/index.php?op=showpacket&packet=0x02

When one of these moves goes through, you evaluate this number to see if you are going to send 0x21 (denied) or 0x22 (accept) (POL automatically accepts of course so in a packethook, you'd block the initial move request and send deny to the client if needed)

http://packets.polserver.com/index.php?op=showpacket&packet=0x21
http://packets.polserver.com/index.php?op=showpacket&packet=0x22

Now what I had was an outside script (checking a prop on the character to see if it was going and if not, start_script for each character) that at regular intervals, would send out 0xBF with the second subcommand which sends one more key to the client for every successful move they made. So basically, this makes the client receive keys at a regular interval as its moving so it should never run out of keys unless of course, you're running too fast or you're running beyond the lag buffer (smoothwalk). But the client does help the server a lot in that situation if you decide to use it because if it ever requests a move and its out of keys to send, it just sends 0. I say though that you SHOULD check if any non-zero was actually sent to the client in case someone mods their packets to send anything other than 0 which would break the whole system if the server wasn't checking.


This was the code I used but apparently, it was a bit laggy to use..

antispeed.src

[Xandros]

If this is the whole concept behind fast walk prevention, it doesn't
seem so complex, and then I really agree that it should be integrated
into the core.

Xandros

[Yukiko]

I agree with Marilla, it should be an option in serverspecopt. I was personally accused of using FastWalk on a shard. This was back in my early UO days and had no idea what Fast Walk was. In truth I had a Broadband connection and the other user (the plaintif) was on a dial-up. So it appeared to them that I was "fastwalking" when in reality I wasn't.

[CWO]

It appeared to him. But what players see and what the server sees are 2 different things. Theres only one problem so far seen and thats with the 3D client. It really does run slightly faster than the 2D client.

[VeNdOr]

[CWO]

and thats what the scripts I posted above do... it sends the reject packet before saying "Too Fast!" in antispeed.src. Then after that, it blocks the move packet from POL. This is exactly how you force them back to their old spot if they stepped to quickly. But just like we said, it would probably fare better in the core since the scripts tend to generate a bit of lag.


And on my reply, I was saying, if you're on broadband, you would appear to be moving faster to him because hes not only lagging in running but lagging in seeing where you are. So you suddenly jump to him. But the server sees every step you take otherwise you wouldn't be able to take them well in the first place.

[Yukiko]

If it can be scripted then I don't see why this needs to be a core feature. Good work CWO.

[CWO]

[VeNdOr]

[Yukiko]

Then I would like to see it as an option in serverspecopt.