Invalid get index '0' on InputEventSingleScreenLongPress

[yknapp]

When InputEventSingleScreenLongPress is triggered, then an Invalid get index '0' (on base: 'Dictionary') error occurs. I use Godot 4.4 and GodotTouchInputManager v2.1.0. This can be reproduced in https://github.com/Federico-Ciuffardi/GodotTouchInputManager-Demo.

[Federico-Ciuffardi]

I assume you mean Godot 3.4 since Godot 4.4 is not out yet.

I can't reproduce this error on my desktop PC or Android phone (using Godot 3.4 and GodotTouchInputManager v2.1.0).

Can you give me more details on how you are getting this error? It is important that I can reproduce the error to fix it.

[galaxyblur]

Thanks for the great plugin. I get this error when testing via HTML5 and using Safari in the iOS simulator. If I long press on the trackpad, the error shows up in the console. That is at least one way to replicate it.

[Federico-Ciuffardi]

Hi @galaxyblur, I have a few questions that would help me debug this:

1. Did you try using a different browser?
2. Did you try using desktop PC or android phone?
3. I don't know how to test via HTML5 and using Safari in the iOS simulator, could you tell me how to do it or share a tutorial on how to do this? (I searched a bit but didn't find anything useful)

[jlundan]

Hey!

I ran into this too, and managed to capture few screenshots. This seems to happen pretty much on random, I have encountered this once. The scenario where I got this was that I had a (sub-)viewport (and a ViewportContainer) in my game, and I have configured GCC2D drag gesture to be "multitouch". I have enabled both "Emulate Touch From Mouse" and "Emulate Mouse from Touch" in the project settings. When this happened I was running the game in the debug (test) window and was scrolling my viewport with my mouse's center button. The error occurred when I released the button. The screenshots are attached below. I will also try to reproduce this again, but it seems to be somewhat rare occurrence.

Godot 3.4.4.stable.official I got the GDTIM from the latest release (the source.tar.gz file) v2.1.0

[Federico-Ciuffardi]

@jlundan thanks for your report and screenshots. I have a question:

• How fast did you scroll, could it be that you were moving the mouse slowly? In other words, does it make sense that a long press has been recognized?

It looks like this bug is going to be pretty hard to fix, at least until it can be consistently reproduced. I just pushed an update to master so that more information is printed when this error occurs to see if that allows me to better understand what is happening. I would appreciate it if you can use this updated version and upload the new information located in the output if you manage to get the error to occur again.

[jlundan]

I do not exactly remember how fast I was going, but I think it was not that slow. It was during sort of "normal operations": I was debugging my game and moving/scrolling the viewport around pretty fast, but like I said, don't remember that well. =)

I'll try to get into further debugging during this week. I am on a bit of a schedule at the moment, and had to roll back to GDTIM V1 due another issue. Simulated touch events (InputEventScreenTouch) from clicking my mouse middle button (that I think are triggered from the GDTIM's _native_touch_event (https://github.com/Federico-Ciuffardi/GodotTouchInputManager/blob/master/InputManager.gd#L224)) seem to have different positions than the "native" touch events coming from Godot, which I am not sure if that was something to do with my xforms. If I keep my mouse still, and alternate between left clicks and middle clicks, I seemed to get different coordinates. I think the clicks with the middle button seemed to have exactly doubled coordinates (if left click was at (100, 100), middle click was at (200,200)). Anyways, didn't have time to figure that out, and had to roll the version back for a bit (this does not happen with GDTIM V1). When I can finish my current feature (hopefully this week), I will try to schedule in further debugging session for that position issue with the newer GDTIM to try to figure out if I screwed something up. :) While I am on that, I'll see if I can reproduce this issue too.

[jlundan]

Haven't still had time to get to debugging, but one thing came to mind about this: GDTIM uses _unhandled_input to catch events, which allows the client code (for example my game being "client" to GDTIM) to suppress some events from it. I realized this since I use a lot of

get_tree().set_input_as_handled()

calls in my game in a detail level (sometimes I handle touch pressed events, but allow for example touch non-pressed events to flow through). Since GDTIM is on _unhandled_input it might not get the events I handle myself, depending where I handle them (in _input, in _unhandled_input earlier in the event send order etc). This could be problematic for example with long presses or drags which rely on combination of events. I did fix this in my project by moving GDTIM to _input, but I am not sure if this is something you would like to do on general level.

Anyways, I will try to find some time (hopefully soon) to verify this with a small project, but my schedule is seriously lagging behind. Thought I would throw this out here, since this could be a potential culprit for the issue.

[Federico-Ciuffardi]

I'm not sure about changing from _unhandled_input to _input. The most useful thing about _unhandled_input is that it allows to separate interactions handled by the GUI from interactions that are for the game, allowing you to change this if desired (see MouseFilter). At least that's what I wanted in the project I was doing when I created GDTIM, something like a defense tower where if I was interacting with the GUI (control nodes) I didn't want the camera to move. Perhaps your use case and that of many others do not suit the use of _unhandled_input if this is the case this should be configurable (allow to use _unhandled_input or _input) and in that case we could discuss here what is the default value should be.

[jlundan]

I think probably my use case is not so common that it would merit changing GDTIM. Configurable could be nice, but quite frankly it is not that difficult for me to change it in my project - not sure if it makes sense for you to spend time on making that configurable and making the component more complex. I mean, as far as I know I am the only one needing this, and I can manage fine with changing one line of code. Maybe it might make sense to see if more people ask for it, and implement it then if they do? If you ever choose to implement that, I think _unhandled_input is the better default, since I am the first one asking this, which probably means that everyone else are fine with the current implementation. :)

I tried to make a small test project to reproduce the issue, but for the life of me couldn't. That does not surprise me though, since the issue occurred very rarely in my more complex game.

Anyways, thanks for the library and for the support! I will keep an eye out for this (and will use your master version when I add the 2.1.0 back to my game), and I'll let you know if I run into the issue again.

[doemsche]

Hi Federico thanks for the great library. Much appreciated! I ran into this bug and provide the output:

RAW GESTURE:
presses: 
ind: 408 | time: 5.273535 | pos: (1590.975708, 568.990845) | pressed: True
drags: 
releases: 

HISTORY:
T | ind: 408 | time: 5.273535 | pos: (1590.975708, 568.990845) | pressed: True

I'm using Godot 3.5.1(stable) on arch linux. The error occured when I perform a long press on the touch device (Iiymaya 48")

[Federico-Ciuffardi]

Hi @doemsche, thank you for the report!

I have two questions:

1. Can you reproduce the error?

2. Do you remember what were you doing when it happened?

I find it strange that the log says ind: 408 and time: 5.273535 since it should mean that you are doing 408 simultaneous touches in the first 5 seconds. It's also weird that the only thing in the RawGesture is that press. Perhaps this is a Godot bug 🤔.

[ascripter]

Was sent here by the error message in InputEventSingleScreenLongPress. Had this issue too, not on a physical phone but on an Android SDK emulated Google Pixel 4 with Android 30, it shows sth. like:

RAW GESTURE:
presses: 
ind: 1 | time: 67.677034 | pos: (530.9375, 316.39325) | pressed: True
drags: 
releases: 

HISTORY:
T | ind: 1 | time: 67.677034 | pos: (530.9375, 316.39325) | pressed: True

drags and releases is always empty.

When does it occur? Got it several times after launching the project, and then usually 100% reproducible for every single long click w/o moving the mouse (guess that's what the LongPress implies).

Now I can't reproduce it, even after cold restarting Emulator and Godot. I think this happened after I first used Shift + Ctrl + Click to try multi touch in the Emulator. Afterwards a long click didn't trigger the error. However I can't imagine why even restarting everything from scratch and only using long clicks, the error is just gone.

I use Godot v3.5.stable.official [991bb6ac7] on Windows 10

[Federico-Ciuffardi]

Hello @ascripter,

It seems that you somehow managed to get a touch "stuck" probably while trying to use multi touch in the Emulator (which I didn't know was possible). If you manage to do it consistently please let me know.

I have some questions:

• What version of GDTIM are you using?

• Did this cause a crash or just the error message?

[ascripter]

• What version of GDTIM are you using?

2.1.2

• Did this cause a crash or just the error message?

Just the message

[emrodk]

Maybe this is the problem... I was able to reproduce this with a single long press, waiting 2 or 3 seconds, and doing a pinch without releasing the first finger. I disabled that two options and I couldn't reproduce it anymore