[1.1.39] Mouse clicks and position are read at different times
Posted: Fri Sep 24, 2021 7:30 pm
Under Linux when you click the mouse the event doesn't seem to include the mouse position. Instead at some later time the game checks where the mouse actually is and then performs whatever action the click triggers at that position.
Normally, playing at 60 FPS, this isn't an issue as the mouse moves very little in 1/60th of a second. But try playing at 1 FPS. You purposefully have to move the mouse somewhere, stop, click and then wait for the game to act on the click before moving the mouse again. Otherwise the click will happen where the mouse is a second later.
Now, playing at 1FPS is no fun but that's just to demonstrate the problem. The same problem appears every time the game autosaves for example. You click to place a blueprint. At the same time the autosave triggers. If you move the mouse while the game saves then suddenly the bluieprint will be placed a different location. The mouse click is registered before the save but the mouse position is only read after the save.
Same problem when roboports loose power and the logistic networks in a large base fractures or any other CPU spike that causes a delay between frames. The mouse click seems to queue up an event and some time later the game sees the click event and reads the mouse position.
If you can't get mouse events that combine the button state and position then you should read the input events in a separate thread that then generates "clicked @ x,y" events so there is never any delay between the click and reading the mouse position. Or you have to at least clear the event queue for the first frame after an autosave so clicks aren't placed at totally wrong positions.
Normally, playing at 60 FPS, this isn't an issue as the mouse moves very little in 1/60th of a second. But try playing at 1 FPS. You purposefully have to move the mouse somewhere, stop, click and then wait for the game to act on the click before moving the mouse again. Otherwise the click will happen where the mouse is a second later.
Now, playing at 1FPS is no fun but that's just to demonstrate the problem. The same problem appears every time the game autosaves for example. You click to place a blueprint. At the same time the autosave triggers. If you move the mouse while the game saves then suddenly the bluieprint will be placed a different location. The mouse click is registered before the save but the mouse position is only read after the save.
Same problem when roboports loose power and the logistic networks in a large base fractures or any other CPU spike that causes a delay between frames. The mouse click seems to queue up an event and some time later the game sees the click event and reads the mouse position.
If you can't get mouse events that combine the button state and position then you should read the input events in a separate thread that then generates "clicked @ x,y" events so there is never any delay between the click and reading the mouse position. Or you have to at least clear the event queue for the first frame after an autosave so clicks aren't placed at totally wrong positions.