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.
[1.1.39] Mouse clicks and position are read at different times
Re: [1.1.39] Mouse clicks and position are read at different times
For the other devs: I looked into this on windows and at least there the mouse position is always where the click happened regardless of game speed/frame rate. I'm not able to test on linux but some searching online showed people having issues with mouse positions and SDL so maybe it's linux specifc?
If you want to get ahold of me I'm almost always on Discord.
Re: [1.1.39] Mouse clicks and position are read at different times
Stuff like this is highly dependent on the underlying event system that reports keystrokes and mouse. So this doesn't surprise me.
Now that I watch out for the effect though I noticed something odd. It seems like clicking at the hotbar to e.g. select the destruction planer right when the autosave happens still selects the deconstruction planer even though I moved the mouse. Or maybe it just selected it for 1 frame before the autosave and that's just not long enough for the eye to see.
Something to look into in the code though. Is there a difference between selecting tools from the hotbar compared to placing entities or blueprints in how it figures out the mouse position?
Now that I watch out for the effect though I noticed something odd. It seems like clicking at the hotbar to e.g. select the destruction planer right when the autosave happens still selects the deconstruction planer even though I moved the mouse. Or maybe it just selected it for 1 frame before the autosave and that's just not long enough for the eye to see.
Something to look into in the code though. Is there a difference between selecting tools from the hotbar compared to placing entities or blueprints in how it figures out the mouse position?
Re: [1.1.39] Mouse clicks and position are read at different times
I can't reproduce this on Linux either. It's possible that the CPU spike lags the whole system and the mouse event the game receives is generated from the new location of the mouse.
Re: [1.1.39] Mouse clicks and position are read at different times
I have also experienced this issue.
could it be event compression with the tick based timing? IE the click comes in during the autosave, along with the whole pool of move events, jammed together into one input state for the resuming tick, effectively dropping the click location.
simplest resolution would be to just flush the input for 1 tick and return to normal. kinda hackish, tiny chance of lost input, but probably less disruptive than misplaced BPs or entities.
could it be event compression with the tick based timing? IE the click comes in during the autosave, along with the whole pool of move events, jammed together into one input state for the resuming tick, effectively dropping the click location.
simplest resolution would be to just flush the input for 1 tick and return to normal. kinda hackish, tiny chance of lost input, but probably less disruptive than misplaced BPs or entities.
Re: [1.1.39] Mouse clicks and position are read at different times
I highly doubt that. If the CPU spike blocks the X server (which has a far higher priority) then the mouse cursor itself wouldn't move. You can get that when swapping.