Skip to content

Reworked client network state handling #2542

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

Closed
wants to merge 2 commits into from

Conversation

Boondorl
Copy link
Contributor

Currently working with client-side prediction is a bit too limiting due to the nature of only having the info that the client is predicting and nothing else. Not only this, but handling the prediction state via cheats is volatile as it allows players to unset it (likely unintentionally) while predicting which will break the game state immediately.

Prediction is now locked behind ClientState which is readonly. This will be used for getting a client's network status (both the consoleplayer and others) and currently supports CS_PREDICTING, CS_LATEST_TICK, and CS_RUBBERBANDING. CS_LATEST_TICK is of particular interest because it can allow effects and sounds to be executed on the player's last "real" tick rather than constantly being repredicted. This allows for things like sounds on landing to be played at the last predicted tick without rapid firing when being played back.

ClientTic has also been added which can be compared against gametic to see how far ahead the player is currently predicting on a given tick. Note that gametic becomes one tick ahead when predicting since its value is incremented after all game logic but before prediction starts.

These fields should mainly be used for client-side prediction as they won't give the same values across clients (similar to consoleplayer), but things like CS_LATEST_TICK and ClientTic are still set for all clients so logic can execute correctly on their end. For instance, a non-consoleplayer client will only update on a real tick, but their flag will always be set to CS_LATEST_TICK so a landing sound would still play at the correct time if checking against it.

Copy link
Member

@coelckers coelckers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make IsPredicting inline. This function gets called in performance critical code and it's a real call that's easily avoided.

Deprecated CF_PREDICTING flag (this was too volatile to leave on cheats). Added ClientState and ClientTic fields to player (these are not synched across the network as they're meant for handling prediction). Added wrapper function for client prediction checking.
@inkoalawetrust
Copy link
Contributor

So CF_PREDICTING is just a total dud now? Isn't that bad for compatibility with mods that might rely on the old client prediction handling, like mods that are no longer in development to be changed to use IsPredicting() instead? Might be a good idea to have CF_PREDICTING still be set and unset somewhere for backwards compatibility.

@Boondorl
Copy link
Contributor Author

It does still get set. As someone who's written a lot of client-side safe code, I'm fully aware it can't be tossed.

@inkoalawetrust
Copy link
Contributor

Oh my bad, I didn't see the line where it still gets switched on and off.

@Boondorl
Copy link
Contributor Author

With 4.13 looming, gonna close this for now since it'll need to be re-structured anyway for the prediction overhaul

@Boondorl Boondorl closed this Jun 28, 2024
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