…Sounds like the title of a really weird game-show…
But anyway…
Since the server is the ‘authority’ in a client-server system, HasAuthority allows an action to process only if the server is the one making the request. If the client is making the request, HasAuthority() simply ignores what it’s hearing.
If you turn HasAuthority() around, the roles are reversed – the server is now not allowed to process the function, and the client is permitted to act as instructed. The client can’t replicate a function, though – no matter what we tell the client, it will never be able to tell the server to move the cube.
Let’s go a bit deeper, though:
When the cube moves on the server (or the client, in this case), its counterpart does not receive the cube’s updated vector. The end result is that the cube’s vector changes on only one side of the client-server partnership – the other side thinks that the cube is still immobile.
As a result, there are effectively ‘two’ cubes present – the ‘real’ cube that’s moving as instructed, and a ‘ghost’ cube that’s still present at the spawn location. So, what happens when you try and interact with the moving cube and its ghost?
Well, if you try and jump onto the ‘real’ cube, you’ll shudder and slide off. If you’re familiar with quantum physics, you might say that the cube is in a state of ‘superposition’: the cube is simultaneously moving and not moving, and both states are technically ‘correct’.
If you try and move through the ghost cube, however, you’ll be blocked by the seemingly-empty space that the moving cube originally occupied. Why is that happening?
Remember that the client has moved the cube, but the client can’t replicate data ‘upstream’ to the server. As a result, the server doesn’t know that the cube has moved. Since the server is authoritative, the client assumes that the server is correct and that the cube is stationary, even though the cube is clearly moving – which creates a ‘ghost cube’ with the server’s vector data.
Headache city…