-
-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Speed hack" potential in MoveManager #368
Comments
Interesting! Clamping the values on the server seems like an easy solution but I'm wondering if this entire bit of MoveManger code is still sensible. It's jumping through hoops (and introducing slight inaccuracies to the move state) just to shave a few bits off each packet. That definitely made sense in 2001 but how about now? On the other end, this old post makes it sound like we could go even further with the optimization and cut another 3 bits/packet with some more clever float packing. |
This does not seem to affect Torque3D MIT, please list some steps that could be taken to reproduce this behavior. |
First, notice this line:
Torque3D/Engine/source/T3D/gameBase/moveManager.cpp
Line 273 in ac39577
It writes 6 bits for the "py" field, so the value ends up being anywhere [0 to 64).
Now look at this line:
Torque3D/Engine/source/T3D/gameBase/moveManager.cpp
Line 199 in ac39577
So, if the value is 63 here, the y field will be much higher than 1, and it will end up being passed to the respective ::processTick(...) eventually and cause 1. players to move much faster and 2. vehicles to accelerate much faster, maybe other things. This was the case in Blockland.
This doesn't happen i.e. when you do $mvForwardAction = 3 or something, because the range for these members on the move struct are clamped on the client side!
Torque3D/Engine/source/T3D/gameBase/moveManager.cpp
Line 230 in ac39577
and
Torque3D/Engine/source/T3D/gameBase/moveManager.cpp
Line 176 in ac39577
For a fix, changing the bits read to 5 probably isn't the right solution, since ideally the range should be [0 to 32], not [0 to 32). So, throw in a call to ::clamp(...) right after the move is unclamped on the server end, or simply write in some if-thens to limit the range of x/y/z after unclamping (or px/py/pz before).
(note I haven't tested if this bug applies to this version of the engine, I'm simply reporting from my experience with Blockland which is a TGE 1.5.1 game)
The text was updated successfully, but these errors were encountered: