This can result in it being enabled on the server but not on the client, or vice versa. Disabling the setting and enabling it again (without pausing the game in between) can fix it, but it shouldn't happen in the first place.
The reason this happens is due to a task being scheduled for the next frame to send the RPC (this has valid reasons, explained in code), but because this task isn't stored and checked for if the setting changes, to cancel it if needed, multiple of these can be scheduled and will go through, and it seems the RPCs can arrive in different order, or it's simply due to the multiple scheduled tasks (since they're not ordered when scheduled for the same target tick).
Anyhow, this can happen in two cases I'm aware of:
- Toggling the prediction setting (and applying it each time of course) twice or more with the game paused, then unpausing.
- Doing a seamless player swap (in vanilla this means transforming into Wonkey, or back to your original character).
I already explained why it happens for the first case, and it could be solved by simply allowing only one task to be scheduled at once, and cancelling an ongoing task if the request to do the opposite is received (i.e. prediction is enabled, queue disabling it, but cancel said task if enabled again before the task goes through).
But in the case of the seamless player swap, here's why it happens:
local function RemovePlayerComponents(inst) EnableMovementPrediction(inst, false) fns.EnableBoatCamera(inst, false) inst:RemoveComponent("playeractionpicker") inst:RemoveComponent("playercontroller") inst:RemoveComponent("playervoter") inst:RemoveComponent("playermetrics") inst:RemoveEventCallback("serverpauseddirty", inst._serverpauseddirtyfn, TheWorld) inst._serverpauseddirtyfn = nil end function fns.CommonSeamlessPlayerSwap(inst) inst.name = nil inst.userid = "" if inst.components.playercontroller ~= nil then RemovePlayerComponents(inst) end inst:PushEvent("seamlessplayerswap") end
RemovePlayerComponents disables prediction, which here is only applicable to the client, which schedules a task to send the RPC.
A simple solution would be to prevent this from happening, and letting things go as usual, with the client syncing it (if enabled) in the next frame of their swapped character being fully set up, as if they just spawned (obviously with the task issues I mentioned first being addressed).
Alternatively, the task and RPC sending could just not be done at all when doing a seamless swap, and both the server and client should just use the info from prior to the swap. If prediction was enabled, keep it enabled, otherwise let it default to not being enabled. If the client manually changes the setting mid-process, that might be a very specific edge case, but you could account for it too (the previous simple solution wouldn't run into this issue).
For the general issue:
- Pause the server.
- Toggle prediction on and off before unpausing.
- Notice how sometimes the prediction enabled state will be desynced. Check playercontroller.remote_predicting on both server and client.
For the seamless player swap issue:
- While having prediction enabled, simply turn into Wonkey, or back into your character.
- Notice how sometimes the prediction enabled state will be desynced. Check playercontroller.remote_predicting on both server and client.
-
1
A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now