#Does the server have to know how far the
quartz beacon
It does have a disconnect reason which is "Can'tKeepUp" that's used by the server.
But that happens when the client is too far behind network wise.
I'm really confused as to how disconnects work when a client can't keep up.
Do you have a packet capture from it I can look at?
It seems like you've been experimenting with it.
dusky quiver
I have some packets but I didn’t get a drop unf
quartz beacon
I'll set up a test.
Yeah, after falling behind to a certain point input actions stop being sent by the client as it's always skipping ticks.
dusky quiver
I didn't notice this earlier, but the ServerToClient's update tick is smaller than the ClientToServer's
shouldn't the server be ahead?
quartz beacon
No, the client uses latency prediction to send inputs it wants the server to process in the future.
quartz beacon
Yeah, after falling behind to a certain point input actions stop being sent by t...
Actually it doesn't skip input actions. It skips empty tick closures.
BTW an easy way to test for client being too slow is to run
/c server = true
on the server, then have the client connect and then run
/c script.on_nth_tick(1, function() if not server then for n=1,1e7 do end end end)
to slow down the client.
And reset it with
/c script.on_nth_tick(1, nil)
dusky quiver
oh, i just spammed biters
quartz beacon
It looks like the server uses the SkippedTickClosureConfirm messages to track what tick the client is on.
dusky quiver
it does look like it occasionally sends a really far behind packet
the previous packet was 10389 from the client
quartz beacon
If you do a player input on the client that's behind it sends a tick closure.
dusky quiver
so basically something internally says: send a heartbeat packet every 16.66ms or every tick, whichever is longer?
looks like if a heartbeat's flags are 0x00, it should be ignored completely
dusky quiver
If you do a player input on the client that's behind it sends a tick closure.
i'll write it up in python and then test it out later, this should allow me to test code that emulates the algorithm and then i can check it automatically
quartz beacon
I did try writing a headless client a few years ago. I could get it to connect but I never really got much further than that https://github.com/Hornwitser/factorio-greyroom/tree/master
It contains decoding logic for most of the network packet structure. Except for the input actions. Unfortunately Factorio's protocol is a dense binary blob you need perfect knowledge of to decode. So without implementing all input actions you can't reliably know the synchronizer actions in a packet.