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
[1.1.59] Q-Picking is delayed so GUI box still opens
[1.1.59] Q-Picking is delayed so GUI box still opens
- Attachments
-
- q picking delayed so gui still opens.zip
- (4.01 MiB) Downloaded 80 times
Re: [1.1.59] Q-Picking is delayed so GUI box still opens
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
- 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 96 times
Re: [1.1.59] Q-Picking is delayed so GUI box still opens
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.
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.