Open quimnuss opened 2 days ago
@quimnuss how do you tell the server that the client is still sending the message? how is this implemented in the godot client?
the actions are move_left-1 and move_left-0. 1 for pressed (started) and 0 for released. So the server will assume right is pressed until it receives a 0. Is that the question you were asking?
It shouldn't send two consecutive move_left-1, it's redundant @diegoquintanav
Latency is solved with a sensitivity parameter in #14
Latching commands until the button is released sounds like challenging right now. Why is sending repeated signals a problem?
Challenging how? It's pretty common to register presses and releases as different events, godot works like this as well, isn't it easy to do in javascript?
too much traffic that sompics has to process everytime for every player. And it will work like this pressed/released logic anyway between each command.
I've checked and I get a latency from 4 to 11ms from the wifi, which should be fine if we remove the 20ms frontend latency. Another argument for switching to events is that with polling we will have 20-ish people in the lan flooding the network every <20ms and godot processing these packets almost every frame (the physics tick is fixed at 16ms). That's around 30B8/0.0220ish=240kbps which should be fine for wifi and godot won't probably choke on this, but I would prefer switching to events and avoid both the latency and bandwidth worries.
tested on both android and desktop
Keeping left/right pressed should only trigger one action, instead it keeps sending the left-1/right-1 action continously.
Fixing this might solve #12 #11 #8, there might also be a kind of app latency at play where it does not react to a new action if it's done within one second of a previous action.