Skip to content
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

Closed
wants to merge 12 commits into from

Conversation

zer0k-z
Copy link
Contributor

@zer0k-z zer0k-z commented Aug 24, 2022

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.

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);
Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

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);
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link

@Nyano1337 Nyano1337 Aug 25, 2022

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

Copy link
Contributor Author

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.

Copy link

@Nyano1337 Nyano1337 Aug 25, 2022

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?

Copy link
Contributor Author

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.

@Nyano1337
Copy link

Nyano1337 commented Aug 25, 2022

for the first and the second issue, could you consider using an easier way to resolve them?
like https://github.com/shavitush/bhoptimer/blob/master/addons/sourcemod/scripting/shavit-replay-playback.sp#L2152-L2175

@zer0k-z
Copy link
Contributor Author

zer0k-z commented Aug 25, 2022

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.

@zer0k-z
Copy link
Contributor Author

zer0k-z commented Aug 26, 2022

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 cl_pdump which I used to track the networked values to the client. It is useful to see how a replay bot differs from a real player in terms of netprops.

The console on the right is running cl_interp_watch, which is responsible for tracking client interpolation. In 3.3.0, tracking the bot would not print out anything, as it just straight up does not interpolate non-bot fake clients.

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 cl_pdump only tracks your own and not others' (eg. m_flFallVelocity)

@zer0k-z zer0k-z changed the title Add jumping sounds for bots, fix bots landing sounds being broken, fix TP bots stuttering after teleporting Add jumping sounds for bots, fix bots landing sounds being broken, fix TP bots stuttering after teleporting, fix missing bot sounds and bots not spawning Sep 19, 2022
@zer0k-z
Copy link
Contributor Author

zer0k-z commented Sep 19, 2022

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...
EDIT2: fixed

@zer0k-z zer0k-z changed the title Add jumping sounds for bots, fix bots landing sounds being broken, fix TP bots stuttering after teleporting, fix missing bot sounds and bots not spawning Fix bot sounds being inaccurate, fix TP bots stuttering after teleporting, fix bot wrongfully spawning, fix gokz-quiet not working on bots sometimes Oct 31, 2022
@zealain
Copy link
Collaborator

zealain commented Nov 29, 2022

@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).

@zer0k-z
Copy link
Contributor Author

zer0k-z commented Dec 1, 2022

Deprecated and replaced by the mentioned PRs.

@zer0k-z zer0k-z closed this Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants