Just a heads-up that I’ll upload another small patch most likely tomorrow since I didn’t quite get the bug I thought I fixed last time.
There won’t be any changes to the parameters or behaviour, but if you get a type error while hovering over a sprite that overlaps the edge of the window, that’s likely that. (It’s annoyingly hard to debug because I can’t reliably provoke it.)
And thank you for your patronage, of course! Very appreciated.
Ver. 1.1.4 is now online and includes direct getImageData parameter validation.
I hope that I also fixed what was causing the invalid parameters in the first place (at least when the window isn’t shrunken), but that’s tricky to debug and with this check it won’t crash.
I tried the plugin and managed to get it to not clash with two other plugins. (Galv-MapProjectiles and triacontane/Wisarut Perunawin-PuictureCallCommon if you're curious.)
It seems to work, and I'm converting the events that used the old MouseSystemEX. I need to get used to it a bit, since the mechanics are different now, but nothing too complex.
As soon as I have any problems with your plugin (I have a slight lag with the image and cursor, but nothing too annoying), I'll let you know.
So far? Very satisfied!Glad to hear that!
If the lag gets too serious, a “fix” may be to use another plugin to draw the cursor onto the canvas, but that only makes both lag synchronously which I don’t love. (It can be quite noticeable at lower frame rates.)
If there was a native-cursor changer with tags feature, I could probably integrate with that. Maybe I’ll make one eventually, but it’s likely quite a messy project and could cause a lag frame when the cursor is adjusted.
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?
