Client-side actors exhibit bizarre behavior after force states

[floralvikings]

Client A

Client A walks toward edge of earth, is corrected to prevent invalid locations.

Client B

Client B perceives A walking to edge, and forcing. Afterward, A's apparent position is wildly different from the correct position while moving. This is likely caused by an incorrect reset of state when Client A is forced.

[floralvikings]

Going to have to test the Tankolution demo again to double check this; will get on it asap.

[floralvikings]

This bug is definitely still an issue. Basically, other clients see a moving client's position as far over-corrected while the client is moving, but it quickly corrects to the proper position when an idle state occurs. I'm thinking that this is an issue on the clients that aren't moving, not properly setting steps taken when an actor is forced.

[floralvikings]

This currently appears to happen when a client actor is moving diagonally and is forced to stop. What's strange is that it doesn't seem to occur when the actor is moving in a cardinal direction and is forced to stop.

[floralvikings]

Even stranger, this only appears to be occurring if the forced state is caused by moving to the "west" edge of the world, and moving diagonally. Testing to see if this is true of the "east" edge as well.

[floralvikings]

Yup. Also occurs on "east" edge. And the longer the client attempts to force against the edge, the more the correction is offset.

[floralvikings]

Well now it seems to be happening no matter what edge is forced...

[floralvikings]

Moving out of and back into visible area seems to reset the corrections

[floralvikings]

Also seems to only happen if the state was already forced when the client tried moving to another invalid location. I think this is the key to the issue, I'm just not sure exactly how.

[floralvikings]

1. Client Moving toward wall
2. Client Forced to stop, server state changed to "idle".
3. Client Stops trying to force, sends "idle" state change request.
4. Server State is changed to "idle" even though it was already idle
   • Could this be causing the problem?
5. Client tries to force against wall again, sends state change request.
6. Server gets state change request, changes actor state on next update.
7. Server actor is immediately forced, state changed to idle
   • Maybe there's an error in the timing of forcing the state, or counting of forced steps? I'm thinking that maybe the forced steps aren't being counted properly.
8. Other clients see client forced to stop
9. Client moves away from wall, sends state change request
10. Server changes client state, broadcasts state change messages
11. Clients see massive jumps while player is moving, but immediate jumps to correct position on idle

[floralvikings]

Think I found the problem. Steps taken aren't being incremented when correcting the state fails.

[floralvikings]

Going to overhaul the step function.

needStateChange = overStepped > 0
isMaxCorrect = overStepped >= MAX_CORRECT
if needStateChange
    successfulCorrect = correctOverSteps(overStepped);
    if not successfulCorrect
        forceIdle
    resetState
successfulStep = stepForward
if not successfulStep
    forceIdle
    resetState
stepsTaken++;

[floralvikings]

It's looking more and more like this is being caused by extra steps being added to the server-side actor when states are forced

[floralvikings]

Well. This particular issue appears to be resolved now. There is still a slight...issue...with the client position being properly reflected in the client. It's an extremely small discrepancy, and it only seems to occur when contacting a force at an indirect angle. Client actors representing server-side forced actors tend to lose a few units (in most cases less than 0.02). I'll try and get this patched right away but it's not being cause by the same problem as far as I can tell.

[EDIT]
As expected, this was caused by inaccurate rounding. Fixed by changing one line =D