-
Notifications
You must be signed in to change notification settings - Fork 14
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
Fix bot sounds being inaccurate, fix TP bots stuttering after teleporting, fix bot wrongfully spawning, fix gokz-quiet not working on bots sometimes #358
Conversation
…x TP bots stuttering after teleporting
MakeVectorFromPoints(currentOrigin, currentTickData.origin, velocity); | ||
ScaleVector(velocity, 1.0 / GetTickInterval()); | ||
TeleportEntity(client, NULL_VECTOR, currentTickData.angles, velocity); | ||
TeleportEntity(client, NULL_VECTOR, currentTickData.angles, currentTickData.velocity); |
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.
Why are you using the replay velocity now instead of calculating it from the origin? Doing this always caused inaccuracies in the past.
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.
Calculating it from the origin will fail if the player gets teleported as the velocity becomes inaccurate, causing weird interpolation issues and/or sound issues
I was unaware of this issue until now, what happened previously?
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.
If I remember correctly, the bot would start to drift off in some cases, I assume due to rounding differences, but it's been a hot minute since we last tried that. Would the interpolation issues be solved if we only took the replay velocity on teleport ticks? We can directly set the origin as well in those cases if that'd help I would say.
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.
As the origin of the bot gets updated every tick, drifting should not happen.
About taking velocity during teleport ticks only, this might cause issues if you get teleported by the maps themselves by a short distance as those aren't recorded into the replays themselves, and as far as the client is concerned, being teleported by a map or by the menu should be the same to them.
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.
teleported means bot's velocity becoms very high, why not just teleport them at that tick?
// to prevent inaccurate eye position interpolation. | ||
SetEntPropVector(client, Prop_Data, "m_vecAbsVelocity", currentTickData.velocity); | ||
|
||
SetEntPropVector(client, Prop_Data, "m_vecAbsOrigin", currentTickData.origin); |
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.
Setting the origin directly instead of changing only the velocity was usually the cause of stuttering in the past, would it be enough to fix the issue if we only set the abs velocities and eye angles?
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.
The current stuttering in 3.3.0 is caused by client interpolation not working on fake clients that aren't bots. GameChaos's SimpleTAS also does a similar thing so I believe it should be sufficient.
For the record, the kz_kiwiterror run on youtube is recorded with the code in this PR. Of course you should also test it for yourself as well, as I might miss some other edge cases.
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.
I don't know how m_vecAbsOrigin
really behaves, I just know that setting the regular origin every tick is no good, so it raised a red flag. If it is required to fix the stutters we'll leave it, I'll do some testing as well.
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.
I think as long as the game doesn't add the "no interpolation" flag to the bot (might be the case with TeleportEntity
using the origin
argument), it should be fine, hopefully.
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.
damn you should not set their origin by every ticks, it's very waste of performance
here's a simple solution: https://github.com/shavitush/bhoptimer/blob/master/addons/sourcemod/scripting/shavit-replay-playback.sp#L2677-L2689
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.
I doubt that changing one netprop would cause a lot of lag, and it's definitely less expensive than TeleportEntity with an origin argument (and it only changes the local origin which is insufficient as well, as described in the PR)
I could in theory check for the predicted origin vs the actual replay origin and teleport them when necessary but then the extra comparisons would cost more resources either way.
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.
I see that the bot is a bit choppy after setting origin(netprop) on every tick. Haven't you noticed?
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.
The latest commit should make the bot much less choppy now.
for the first and the second issue, could you consider using an easier way to resolve them? |
The landing and jumping issue that this PR is referring to is different from that fix I believe. His fix refers to the issue that the bot makes no footstep sounds caused by them being in noclip most of the time. In GOKZ, bots are rarely ever in noclip, and they do make footsteps and ladder sounds correctly. The first issue is that the bot never actually "jumps" and therefore never makes any jumping sound. This wasn't very noticeable until I recorded kiwiterror and didn't hear the jumping sounds in the low ceiling bhop sections which annoyed me. The second issue is the bot plays the "falling from very high" landing sound while they obviously did not in reality. #130 is the issue, it's closed but it actually still happens and I only managed to find the solution recently. |
I have pushed a new commit that also changes the non absolute velocity and origin of the bot, which turns out to be necessary to prevent choppiness during the playback and I forgot to put them into the pull request. For more information, I quickly recorded the bot at 0.2 timescale to ensure that it is as smooth as possible. The whole thing on the left is The console on the right is running From the footage, setting the origins and velocity do not prevent the interpolation from working, and the bot does seem smooth as intended. The only non smooth part of the video is caused by either teleport, or ducking which immediately raises/lowers the player origin by 9. On a side note, this PR might also fixes a small issue where the bot's view would clip into a ceiling for one tick if it ducks next to it, but I'm not sure about that. Edit: For some properties |
I pushed a new commit that fixes issue where adding bots wouldn't work on servers with too many players on one certain team. This also fixes a bug where the timer sound is not played if the player paused before they press the end timer. EDIT: Latest commit makes Linux servers segfault eventually. Will investigate... |
…ately plays jumping sounds, remove unnecessary fall velocity code
@zer0k-z Would it be possible to seperate the bot TP part from the rest of the PR? I still don't know why setting the origin every tick would now magically work when it never did in the past and want to do more thorough testing on that first, but I'm not sure when I would have time to do that properly. If the PR would be split, I could at least merge the rest (which was requested by someone to prioritize). |
Deprecated and replaced by the mentioned PRs. |
For the first issue, we SDKCall the jumping sound function whenever the bot "jumps", and sometimes the bot's movetype is incorrect.
The second issue is resolved by setting the absolute origins and velocity of the bots because
TeleportEntity
does not do it.The third issue is resolved by making sure the replay exists before spawning the bot. (Fixes #403)
The last issue ensures gokz-quiet works when bot spawns.