Odd Behaviour In PlayerController States

[Rdshft]

I'm getting some really odd behaviour with my PlayerController states. If my PlayerWalking state in the PlayerMove function I check a bool to see if it's true. If it is, I switch to a different state called PlayerOnLedge. This is where it gets weird. If I put log functions in my BeginState and EndState functions in the PlayerOnLedge state I see that my PlayerController is constantly entering and exiting out of the PlayerOnLedge state.

Note, that I have checked many times and I don't have any other code that makes the PlayerController change state. This only happens when I am connected to a dedicated server. Also, I checked and the server is still in the PlayerWalking state while the cilent is in the PlayerOnLedge state. Of course, if I switch to a standalone game, the constantly entering and exiting of PlayerOnLedge stops.

Also, after further playing around I got this to stop if I switch PlayerController on the client and server to the same state by calling GoToState in a unreliable server function.

I don't quite understand why this is happening, can anyone shed some insight? Is calling GoToState on the client and server correct to sync the overall state of the PlayerController?

[Rdshft]

I did some digging and messed around. It doesn't seem to matter actually if I change the state of the PlayerController on the server and client. The problem seems to be caused by when I change the pawn's physics to PHYS_Flying. I'm going to have to look further and see if there's a function that's changing the PlayerControllers state somewhere.

[meowcat]

I ran into this all the time with some Parkour code I wrote for my UT2k4 YARM mod. The client can easily get forced back into its old state by the ClientAdjustLocation function called when the server replicates to the client a PendingAdjustment, which can include a PlayerState name (See ServerMove, SendClientAdjustment and the ClientAdjustPosition functions).

The only way of 'kind-of' getting around this was to have the client force the server to explicitly go to the newstate by calling a replicated function, and then ignoring any calls to reset its own current state back to playerwalking etc. if the client received a 'ClientAdjustment' before the server updated itself to the new state. It ended up being kind of like either:
1. The client asks the server to go to the new state, and then waits for the server to do so and replicated back to itself to go into the new state, -or-
2. The client goes to the new state, and tells the server forcibly to go to the new state, and in the mean time ignores any calls from the server (via ClientAdjustPosition) to change its state back.

Because of the annoying replication issues (and figuring out when/where to execute various BeginState code (client vs. Server), I abandoned the system of different states in the PlayerController and instead made a new system in the pawn instead (was using states, now using custom 'Move' objects that handle setup, exit, and execution of parkour type moves). My playercontroller now 'polls' it's pawn during PlayerMove to see if a different NewAccel vector and Rotation rotator should be used. My pawn handled the notification tot eh server that it should begin, terminate, or transfer to a new parkour move.