Post: #13

yep that's the problem: windows
windows timing use "CPU ticks" instead realtime milliseconds/nanoseconds, and this is a problem when we need high precision timing

UO walk animation take 100ms, so EF_FastWalkPrevention must only accept another walk packet after 100ms. In theory, this method is an perfect fastwalk killer. But since timing is not 100% precise on windows, it will make EF_FastWalkPrevention imprecise. That's why EF_FastWalkPrevention still an experimental feature which maybe it will work or maybe not

on linux it works fine, as you can see on this example here http://cpp.sh/9jge running on linux. Just click on the Run button and it will return values with perfect 100ms precision. But on this example on windows http://rextester.com/KFZ64696 every 100ms will turn into an random 80~120ms

so if you really need an working fastwalk prevention, maybe the only solution is use sphere linux builds. On windows, you can disable EF_FastWalkPrevention and try some tweaks on WalkBuffer/WalkRegen settings but honestly I don't trust these old checks, since for many years ppl had told that it can block fastwalk but I already tried many different values and it never really worked (at least on my server running on windows)

maybe the only way to get EF_FastWalkPrevention working on windows is find an way to make sphere run each server tick using realtime instead CPU ticks. But this is hard to do, or even impossible on windows (if you search on google you will find many articles telling "windows is not good for realtime applications" without find any solution for this problem)

I don't know about RunUO but I think it have this same problem too, since the FastWalk check on RunUO needs high precision timing and RunUO only enable high precision timing when this feature is available on OS (eg: linux)