[1.1.59] Q-Picking is delayed so GUI box still opens

We are aware of them, but they have low priority. We have more important things to do. They go here in order not to take space in the main bug thread list.
Post Reply
AntiElitz
Filter Inserter
Filter Inserter
Posts: 451
Joined: Sat Aug 29, 2015 11:37 pm
Contact:

[1.1.59] Q-Picking is delayed so GUI box still opens

Post by AntiElitz »

Case:
Press Pipette tool Q and immediately/ simultaneously leftclick / place

Behavior:
you open the GUI of the entity AND you have an item on you cursor that you place
I thin this can also result in a case where the GUI immediately closes but the smart belt draggign is still messed up
See: https://clips.twitch.tv/SillyConcernedI ... ys4QHztAni

Expected behavior:
a) You open the GUI and cannot pipette as the GUI is open
or b) you q picked and have an item in the hand and therefore cannot open the GUI

note: the Belt dragging weirdly is not the bug I talk about here. I am aware of belt locking being disabled when a GUI window is open. That is just to showcase that i still drag with the pipetted item even though i also opened the gui

Replay attached
Attachments
q picking delayed so gui still opens.zip
(4.01 MiB) Downloaded 78 times

AntiElitz
Filter Inserter
Filter Inserter
Posts: 451
Joined: Sat Aug 29, 2015 11:37 pm
Contact:

Re: [1.1.59] Q-Picking is delayed so GUI box still opens

Post by AntiElitz »

Here is a case where its even more easy to reproduce
- hold item in hand
- double q oder entity
- drag immediately

As visible in the replay the gui sometime only appears for a frame. I think this can end up in a case where the gui isn't visible at all like in the clip

Replay attached
Attachments
q picking delayed so gui still opens_ hidden gui.zip
(3.89 MiB) Downloaded 92 times

Rseding91
Factorio Staff
Factorio Staff
Posts: 13347
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [1.1.59] Q-Picking is delayed so GUI box still opens

Post by Rseding91 »

Thanks for the report however I don't see any way for this kind of thing to be prevented. The input handling does not disallow processing multiple pressed keys during the same tick and will process each one as they arrive generating actions for each.

Since the game does not apply those actions between each keyboard/mouse event being processed in the same tick it has no way to know if a previous action already generated for a given tick will change how the next action will behave.
If you want to get ahold of me I'm almost always on Discord.

Post Reply

Return to “Minor issues”