I am a coordinates idiot 
who wants to do the following. When the mouse pointer is at the top edge of the screen
I find this logical, but it does not work.
PS: It works (sometimes) for two or three keystrokes, then no more. Is this a bug?
I'd recommend to not do exact matches but rather use "less than" or "greater than", because mouse coordinates can sometimes be slightly off 0 (even though the display in BTT would show 0 due to rounding)
So something like is greater than -5 (I made the y coordinates negative in 3.860 to have the same coordinate logic for everything)
I'm currently preparing some advanced examples of what can be achieved with the mouse based conditions.
Thank you @Andreas_Hegenberg. I have tried many variant. The actions are executed completely randomly, or not at all, no matter where the mouse pointer is.
This setup should work, right? But it doesn't. 
Ah sorry, when inverting the y position in 2.860, I forgot something. It's now working again in 2.861 (tested with your example)
Yes, now it works! Thanks, Andreas 
Sorry, I was too fast. It works two or three times, then no more. It works again when I restart BTT. Again two, three times and so on. It remains random and unpredictable.
weird, it works all the time here (stopped after 30 trys 
). What would the opt+cmd+i shortcut do in your case?
opt+cmd+i shows and hides the inspector in Scrivener. The trigger is (as a test) "a".
This is one action
And that the other
looks all good
Are you sure the action is not executed? Maybe it's a problem with opening the inspector and not with the trigger condition?
Does the state on the right still appear green when it's not working anymore?
No, black
It is completely insane
I changed the trigger from "a" to "s". When I type "s", it first writes "a" twice, then "s".
Black would mean the condition is not fulfilled for some reason. Does the mouse_position_y still show a value > -5 when the text goes black?
in the screenshot the mouse position is not near 0, thus not fulfilling the condition. It should go green when moving your mouse to fulfil the condition
This is the global mouse position, if you are using an external monitor the top of the monitor wouldn’t be the 0 point
Yes, I am using an external monitor. And yes, it changes to green when the mouse is at the very top of the monitor, which is 0, I think. ???
But look: This happens when I type "s" in Scrivener.
if it’s going green all is correct.
So you now configured „s“ to trigger „a“, right?
Looks like it’s doing a key repeat for a, then at some point stops and goes back to the original key mapping.
Is there a key repeat activated for the trigger in BTT?
The trigger was a. I changed it to s as a test. But now Scrivener writes a first when s should be written.
Ah, sorry, now s = s before a = a
Yes, I have done that. Not in BTT. As you advised me to turn off these "bubbles", in macos:
defaults write -g ApplePressAndHoldEnabled -bool false
If the mouse is really at 0, both actions work correctly for a few times. Then only "s" works. When I restart BTT, also "inspector on/off" works again. But only for two or three times.
Unfortunately no luck in reproducing it here - but I do not have Scrivener in case it might be a app specific issue :-/
Ah, good idea, I'll try the same in other apps to see if it works there. I'll get back to you with the results
Hi @Andreas_Hegenberg So I did the test with the analog setting (as in Scrivener) in different apps, with different triggers and different actions.
No problems at all in Safari and Chrome, Vivaldi.
The same problem as in Scrivener also occurs in TextEdit and in Pages. In all apps the problem occurs only when the setting is app specific. If I move the same setting to "all apps", everything works with every app. Right now my workaround is to set everything up "globally", even if it should only work in a specific app.
Does this help you in any way? I have no idea if this is only happening to me.
