PR #213 introduces a bug where a collision event causes mine to appear to be mined twice in a quick visual glitch.
This happens because now that the client is just interpolating, it no longer computes collisions locally. In order for the appropriate visual side effects of a collision event occur (such as the collision animaton), the server now sends events along with the game state. The callbacks for this event are then triggered on the client. This was done to trigger the collision animation but the "mine" callback also triggers. This causes the mine to lose a resource. Since the server already sent the mine with the updated number of resources we are now showing the state where the mine was mined twice. In the next frame this is likely to get corrected when we interpolate again but this causes a quick visual glitch.
A solution could be to have distinct callback subscriptions on the server and the client. That way the client can just subscribe the animation callback and not the "mine" one.
PR #213 introduces a bug where a collision event causes mine to appear to be mined twice in a quick visual glitch.
This happens because now that the client is just interpolating, it no longer computes collisions locally. In order for the appropriate visual side effects of a collision event occur (such as the collision animaton), the server now sends events along with the game state. The callbacks for this event are then triggered on the client. This was done to trigger the collision animation but the "mine" callback also triggers. This causes the mine to lose a resource. Since the server already sent the mine with the updated number of resources we are now showing the state where the mine was mined twice. In the next frame this is likely to get corrected when we interpolate again but this causes a quick visual glitch.
A solution could be to have distinct callback subscriptions on the server and the client. That way the client can just subscribe the animation callback and not the "mine" one.