[0.16.51] Camera jumps in multiplayer games when a mod sets player.walking_state

[Windfisch]

Hi,

when a lua mod sets

Code: Select all

game.players[i].walking_state

on a player which is not the server in a multiplayer game, then the "remote controlled" player's camera jumps around. I suspect this may be a latency-hiding related issue.

Find below a demonstration of the problem. The left view is that of the server, while on the right, the second player is shown. Clearly, the right red dot skips around whenever it changes direction.


https://ente.hawo.stw.uni-erlangen.de/~ ... roblem.mp4

A small demonstration mod can be found here:

https://ente.hawo.stw.uni-erlangen.de/~ ... a/demo.zip


I'm relying on setting walking_state in my factorio bot github.com/Windfisch/factorio-bot, which I'd like to showcase on the 35C3 in late december, so I would be really happy if that issue can be resolved


Steps to reproduce:
1. install the above mod on two factorio installations (on the same machine in my case)
2. launch one hosting a game
3. launch the other as a game client. This one will have a jumpy camera.

Best regards,
Windfisch

[Rseding91]

Thanks for the report however I don't see this changing. What you're seeing is the latency system predicting where the player is going to walk and the script logic changing where it will walk outside of the latency system resulting in its predictions being wrong.

[eradicator]

I've posted about pretty much the same issue about 9 month ago: Make the player walk somewhere in a nice looking way..

I was trying to make the player walk towards an object when clicked, like in any RPG where you click something to walk there. This works fine in SP, but in MP is completely unusable. In MP not only will it jitter like hell, the results are also unpredictable and the player would frequenly walk way past the target instead of stopping when there.

[Windfisch]

Thanks for your replies.
This is what i thought, Rseding91, but shouldn't the latency system be able to predict what's gonna happen next? (It's in the script, it just needs to be evaluated)

Other than that, for my use case it would already be sufficient to disable the latency prediction altogether on the respective game client (but please not on the others). I think that would be a rather easy config option to add, and it would enable my bot to be presented/watched on-screen.

[Rseding91]

... shouldn't the latency system be able to predict what's gonna happen next? (It's in the script, it just needs to be evaluated)

Predict what happens next in a touring complete dynamic script language? No

[Windfisch]

(that would be just a bit of state prerolling and restoring, but I see your point)

Anyway, could you add an option to disable the latency hiding? That would be pretty easy, probably, and totally sufficient to me. Would be great

[eradicator]

I'd even go so far and say that it should automatically be disabled if walking_state has been set by script. Otherwise writing to walking_state can't really be used for much. (And by extension probably the same for firing_state or script-induced car movement.)