Hi, sorry to bother you.
I was converting the events to your new plugin when I realized I can't make events interactable ONLY with the mouse; yes, in the sense that if I approach with the character and interact with the keyboard instead, this event doesn't activate.
I reread the help section to see if I missed something. Is there a way?
I tried alternatives, with conditions like "TouchInput.isTriggered()" and thought it was a good idea, but then I found that I can still interact with the keyboard if I click the mouse somewhere else at the same time, or "TouchInput.isTriggered() && !Input.isTriggered('ok')", but even in a particular way, the problem here is that the event doesn't activate if the keyboard and mouse are pressed simultaneously.
Honestly, I'm fine with any solution, even a "dirty" one, like activating a switch/selfswitch when you interact with the mouse using this plugin, but if it's already integrated into the plugin, enlighten me and forgive me in advance for not having seen it.
Use “Exit Event Processing” as first Command and then “!OnTouch:” right after.
(“!OnTouch:” acts as entry point, so Event processing will start right at that line.)
The Event may still turn to face the Player if it’s not Direction Fix.
If the Event should turn, you can do that manually with “Set Movement Route…” (“Direction Fix OFF”, “Turn Toward Player”) and then reset with “Revert OnTouch Turn” and “Set Movement Route…” (“Direction Fix ON”).
No worries 🙂
Admittedly, this only happens to work because I wanted to support distinct left- and right-click behaviour on the same Event (the hover tags are combined between those entry points, btw), but this approach that makes use of the existing engine is something I aim for in general.
That’s (part of) why so many of my plugins are rule-based instead of relying on Note Tags now.
I stumbled upon this little bug by accident.
I tested it on a project without any other plugins to see if it was one of my plugins, and it wasn't.
As you can see from the image, the mouse pointer is just one pixel beyond the tile where the event is located (the image of which is taken from the map's tilesetB) and calls up the cursor image, and when I click the mouse, it triggers the event. (Even without the extra cursor image, the event still triggers, but I admit that without the cursor image, I never would have found this bug.)
I discovered that the plugin basically ALSO checks the first column of pixels in the graphics to the right of the one you're using, whether it has opaque pixels (even if they aren't displayed graphically).
This happens with both a "charset" and a "tilesetB/C/D/E". (The other attached image is taken from the "Outside_B" base graphics.)
It only does this on the right side, and I created graphics specifically to show the other three sides as well, but they look fine.
I hope I've been clear and helpful with all the information I've been able to find.
That’s a great bug report, yes, especially that it gives me a good way to reproduce the issue.
I roughly know what causes this. I’ll play around with the rounding a bit to see if I can fix this pixel-perfectly (or at least clamp it to the correct area of the bitmap). Might take a few days though, it depends on how busy I am next week.
Are you using the latest version 1.1.4?
