-
Notifications
You must be signed in to change notification settings - Fork 106
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
Validate roll
in unoccupied sync
#624
Validate roll
in unoccupied sync
#624
Conversation
There are two rules that the
So, the checks by the link above consider both things and cover all possible cases. |
I validated |
Download any unoccupied ("quantum") crasher and check the basic ways of how they modified both direction and roll. Both of them can get any invalid values out of range (or even inside the range, but non-orthogonal) and they are all produce the same effects in the end for all streamed players (lite result is when the unoccupied vehicle just becomes invisible and more damage will occur if player are in spectating on this vehicle or surfing on it).
I'm pretty sure that at least NaN/infinity cases cannot be achieved in omp server even now because iirc some filter for all float data was built-in somewhere while processing the sync. The checks that really needs to be added are actual ranges (-1.0 < roll/dir < 1.0) and orthogonal check for two arrays (vectors) to each other. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for it to be std::fabs(1.0 - glm::length(unoccupiedSync.Roll)) >= 0.000001
instead of std::fabs(glm::length(unoccupiedSync.Roll)) > 1.0
? I'm rusty on all this stuff, but I just wanna know what's the deal behind that
No description provided.