PenUltima Online

I vote for faster computers! =)

I like the idea, but only if optional as suggested

Any news?

News... as in... you want a status report from the Devs as to whether or not they have hopping straight into line to get on what you want them doing?

I think the lack of any Dev posting in this thread could be indicative of something - though perhaps not of outright rejection of the idea. Perhaps they have long since been considering how to best do such a thing, but because they know how much potential for trouble there could be with this, they are opting to carefully consider it, among all the other requests and plans they have, and so right now, they just aren't able to comment much more on it.


So.... be patient. They know this is something that people want, as are so many other things.

one of these "other things" is to decide to read YOUR huge postings or to not read'em. THIS posting I'm replying to is a very short post, so I read'em. but in most cases I don't have time to read tons of lines...

Shinigami

lol shini.

Anyway, don't expect something like that till we get the core close to where it really needs to be anyway.

I don't write the long ones for you guys... the long ones are written for Austin's #1's, to keep them busy, and for people asking a question.

For you guys, when I'm trying to make a point, I keep it short and sweet. Like this post.

But while I'm thinking about it, I should also mention... *gets yanked away from the keyboard*...

Sorry for bringing up an old post!

Would it be faster to just hook the walk packet from the client, record the time of each step, compare it against the previous time, if it's too close (too many walk packets from the client) notify a GM and/or disconnect the character or just send a deny packet?

If anyone has some "speed hack" software and a live shard, I could write a packet hook implementing the above suggestion and we could test it out. Or we could all wait until 098.

I already made one and posted it in this thread. The problem is, it adds a very noticeable amount of lag to the shard and it false alarms a lot. Remember this too tek, you cant expect every packet to be evenly spaced, it comes in in bursts legitimately too. My packethook uses a basically foolproof system that makes sure you have an allowance of moves over a period of time. The problem is, the lag it causes builds up and causes it to trigger the alarm.

I saw it but you said it was laggy so I was suggesting a simpler solution. Now that I think about it though, it's going to be laggy no matter what since you're hooking such a common thing. How common is fast walking?

Actually we found, as common as loading up a 3D client. This was a problem for a while on my shard too... now I have a different solution but requires a lot of staff monitoring. I have the move packet hooked to only count up a prop #moves if they move. Then I have a script run once per second on everyone online taking that prop, subtract 5 or 10 from it (5 if on foot, 10 if on mount) and add it to an array prop. Then clear that #moves prop. My staff have a command that will bring up a list in an HTML gump with every result from the last 5 minutes (in 5 second intervals) of everyone online. The +'s (moving faster than normal) in red text, the others in black. We easily spot who is speedhacking this way. But this is the same old monitor move instead of prevention which would be great to be able to do.

Don’t you have problems with 3D clients?

Our test shows that 3D client run 5-10% faster then 2D clients. More and more players are beginning to use 3D, because 2D client above 3.X will lag if the latency between the server clients is 140+ ping. 3D does not lag for the same player, so 3D is the only choose if someone want to play on a server located on another continent (EU Vs. US).

The fact that 3D are faster then 2D, are a huge problem in PvP for obvious reasons, and we currently have no way of even out that advantage.
The only solution I can see to this problem is to hope that a core fastwalk prevention system will also limit the 3D client to the same speed as a 2D client.

3D clients have been tested and have a faster running speed than 2D. up to 3 steps per second faster on a mount. I have tested this on the same comp POL is on so no lag. And my comp is fast enough to run 2D extremely smooth with POL along side it.

I have an idea. Write some external anti cheat program which would look for malicious tools inside ultima online folder. Without this tool connecting to shard wouldn't be possible. It can be done with aux scripts i think because i know one shard which is using such "gate" to verify player if they have that tool running or not.

The thing is, you dont need a tool running to speedhack. The speedhack I've tested just modifies the client a little bit and thats it. It never needs to be run again.

This is becoming a bigger and bigger problem on our shard, so I’m desperate searching for options.
The biggest problem is not speedhack, but that 3D clients run faster then 2D client, making PvP in 3D the only option if you want to stand a chance.
Why don’t you just disconnect all clients using 3D you might ask? Because all 4.0+ 2D clients lag if you latency is 125+, but 3D clients does not have this flaw, forcing many player to play 3D.

How fast was the server you (CWO) tried that script solution on?

Running on Windows XP
Pentium 4 3.4GHz HT
2GB Dual Channel PC4200 RAM

The server can run about 40 million instructions/min without much lag in tests. Although mine runs less than a million under normal conditions.

How big was your player base at the time you tested it?

40-50 at the time.

Probably what made it so harsh on the shard is that all instructions are critical and theres pretty much no way around it.

My main concern is, as already stated, the faster 3D client, do you have any experince with this problem?

its not foolproof by far but I fire this script from the login and reconnect scripts with Start_Script()

Theres no other known way to me right now.

If I find someone running constantly faster on my server or using 3D past this script, they're considered cheating.

My server is located in Denmark, and most/all players from the US, Canada etc have at least 125 ms latency/ping, meaning they will with newer 2D clients, so they have no other choose then to use 3D.

Currently you only have 3 choices...

Just accept 3D logging into the shard
Lagging your shard down with a speedhack stopper
Putting in a 3D deterrent like I just posted above

Other than that, theres no other way.

Seem you are right. I have tested the speed of 2D and 3D clients on a RunUO server, and the problem is exactly the same. I don’t know if it’s the same problem on OSI, but at least it’s not solely related to POL servers.

just for the record of how this thing might work:
You wouldn't send "denywalk" packets to clients that are too fast, you would only "postpone" the sending of the "walk ok" packets (along with postponing of the actual movement and broadcasting the new position to other clients etc.)
The problem with the deny packet is following - Sometimes the client does a little "lag" between steps all by itself... The result is that instead of 3 walkrequest packets being sent with two equal pauses, it will be one "big" pause followed by the two other packets immediately one after another, even when the player is not speedhacking at all.
The solution is to have a "buffer" that stores the time of say last 3 steps, so that the speed checking system won't interfere with clients that have "in average" proper speed, only their connection/computer is a little jumpy.
Also never deny movement based on speed, simply maintain a queue of the incoming walk requests, and don't process them before they should be processed. That way you don't even need the "fastwalk prevention" that is built-in into the UO network protocol (i.e. the 0xBF subcommands, etc.) - those are actually useless.
Not sure about how this is or isn't possible in scripts, but if properly coded (into core), it shouldn't be CPU intensive at all. Just one little queue of walkrequest packets (which would be empty most of the time) and a speedmeter of last 3 steps...