@Lee: agreed! (in general). The fun for me lies in the restrictions MT has and the challenge it poses to do that which one would say that its not possible. I've done that multiple times in the past and its a kicker.
However given a certain expectation of what it possible you are likely to expect it to work for other circumstances as well. E.g. snapped vs unsnapped. Now this poses a challenge, several actually.
First off for snapped everything works and its (quite) fast as well. So one would like it to work for unsnapped as well. Which poses the following challenge;
1. there is absolutely no way to figure out whether something is snapped or not (there is now with the patch so that is solved)
2. If there isn't then you need to build a function such that it takes into account ALL situations both snapped and unsnapped, which means that the overall performance *will* go down. *That* I find an issue. Granted I can check for it so I can create an exception. Basically to keep it as fast as possible that would require me to double the amount of processing macros (one for snapped and one for unsnapped) to keep performance issues as low as possible again *not* my ideal setup.
3. assuming that I can differentiate between the two and that I will build two types of macros, then for the unsnapped case I need to check a. is mOT true, b. is 'start', 'end' or 'both' coords within the pad area, I can of course write code for that BUT quite a few pads are 'freesize' which means that the size is unknown (again, granted: Jamz fixed this issue by building gettokenwidth/height) and thus its impossible to know whether the 2 coords are on or off the pad area. THEN there is the issue that getTokenX/Y does NOT return the actual top left corner of the image size it had BEFORE it was set to freesize, making it impossible to calculate the relative offset. Granted: again something Jamz *fixed* by allowing for getTokenX(2) that returns the *real* upper left corner.
4. finally given all these functions and features I can indeed calculate whether a coordinate is on or off a token. However 3 posts ago that was not (yet) possible, hence my question.
Finally the question arises, is it feasible to do so... I always use snap in my games and it requires quite some effort to build in this functionality, there are a LOT of special pads now and I would need to double ALL of them for it to work... but that's a different discussion entirely.
Basically the reason I mention the getMoveEvent() (lets call it that) is mainly for performance and secondly to allow gm to use unsnap tokens with my BoT, even though the latter *could* be solved by quite a bit of coding. However as I said, you do not have to do it for me as I won't be using unsnap anyway and I find the current performance acceptable.
It is nice however to be able to check whether a token is unsnapped so i can at least dump a warning on screen explaining that the BoT won't work for those tokens. (and also make sure that no unexpected behaviour occurs like being stuck on a teleport with an unsnapped token).
edit: reading this ramble/rant back I feel the need to clarify:
The above is NOT a request for a new feature, I'm happy with the current change and implementation, I will test it and if I find something I will report back. As far as Im concerned everything is peaches and this topic can be closed! (although if you feel the need to reply to my ramblings, feel free to do so
)