[patch - MapTool] moveOverToken + getMoveCount (merged)

Notes on testing the latest builds of MapTool

Moderators: dorpond, trevor, Azhrei

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

[patch - MapTool] moveOverToken + getMoveCount (merged)

Post by Lee »

Discussed here, this patch aims to provide equivalent expectations for the function Wiki: movedOverToken(); specifically, the result of whether or not a token has passed over another token, regardless of what grid (or lack thereof) is active. The return points information differs, however, for snapped and unsnapped movement. Snapped movement is the same as it always has, returning coordinates for footprints that intersect the target area (i.e. x, y). Unsnapped movement now returns the endpoints of line segments that that intersect the target area (x1, y1, x2, y2).

For testing, I used the campaign supplied by wolph42. The first line returned is the result of Wiki: getLastPath(), and the 2nd line is the result of Wiki: movedOverToken().

As requested, screenshots:

Snapped set to prove snapped movement behaves as it always has.
#1 Movement outside target area
Image
#2 Results
Image
#3 Moving on top of target
Image
#4 Results
Image
#5 Moving through the target
Image
#6 Results
Image
Unsnapped demo start.
#7
Image
#8 Moving on top of the target
Image
#9 Results
Image
#10 Moving through the target
Image
#11 Results
Image
#12 Moving outside, on top, and through the target through way-points
Image
#13 Results (note the 3 line segment values and the non-inclusion of segments falling outside the target)
Image
Do test the patch and tell me if I broke anything because of it. Thanks.

Edit: merged this with the fix for getMoveCount discussed here. Please let me know if you have problem or questions. Thanks.
Attachments
[patch - maptool] movedOverToken && getMoveCount.txt
(5.84 KiB) Downloaded 93 times
Last edited by Lee on Sun Dec 02, 2012 4:07 pm, edited 7 times in total.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch] moveOverToken

Post by wolph42 »

I use photobucket. The trick with photobucket is to right click on the image: show picture and use *that* link.


Hmm Picaso eh, let's test:
Image

Yup, same trick.

So dont use the links you provided but right click on the pic you get with those links, show image, and use that link

Edit: ninja'd... Sort of

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

Yeah I use that too. Used that here as well. My campaign utilizes a lot of Google services so I kept everything MT related there. Seems the conflict between G+ and Picasa lead to this problem with sharing individual images.

Edit: Ah, I forgot to use that. I was so used to the ready sharing link given at the right since it was the same as the image url before. That was changed somehow since my other shared images in the forum still work fine whereas you saw what happened earlier.
Last edited by Lee on Thu Oct 25, 2012 2:53 am, edited 1 time in total.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch] moveOverToken

Post by wolph42 »

Ok had a look and #13 comes out a bit peculiar. The movement is in 6 steps, 4 way points and start and end (so steps 1,2,3,4,5,6) of which steps 3 and 4 are waypoints ON the token.

The ontokenmove result however is 2,3,3,4,4,5
Should that not be 3,4?
Note that I'm already happy that we get a true result for this, but just asking.


Edit: ah wait, now I notice the x1 and x2. It shows steps 2 to 3, 3 to 4 and 4 to 5. That makes more sense.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

Yes, I opted to return line segments. If time allows, it can be a foundation for some other stuff I have in mind. Well, I guess we just have to wait for someone to test it.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch] moveOverToken

Post by wolph42 »

Still need to ask: so it's not possible to only show the part that's actually *on* the token?
Ah then moving over the token would return [].
I ask because of event handling. It's nice to check whether a time moved on off or over.
In total there are 6 events: on, off, over, 0 move, off and return, on and remained. The first three are used most.

Testing requires the java dev environment I guess?

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

Well there're caveats to that:

1. It goes beyond the function's intent, which was simply to say yes or no to "did this token move over the other token?". To keep in form with the rest of MT's design, such information should come from another function so other functions can use it; without having to extract it from the nested results of a "super" function.

2. To actually go after the intersection area is to walk into the problem stated by JFJ. I stepped around that by relying on the implication of area in line-of-path, rather than area occupied by the moving token. Yes, there are speedy geometric algorithms for these problems, but I'm guessing they'll be a pain to implement, else JFJ would have probably put it in a long time ago. In any case, they'll still end up relying on the foundation for token bounds set by our MT devs.

Lastly, JAVA's standard classes for area has, historically, poor performance ratings, and while I could investigate those, it would have to be for some other function, and thus some other time; because, IMO, the goal of equivalent evaluation of movedOverToken on snapped and unsnapped movement, has been achieved.

3. Some of the things you mentioned (0-movement) may have problems with, again, how evaluation happens after the token has landed. I haven't tested it though. I'm positive, however, that 0-movement has been handled by someone else previously, so it's likely not to trigger "moving" over a token.

As for testing, I'm afraid so. But since Jamz has been furnishing JARs for your joint VBL project, he could apply this patch to his next build, can't he? :)

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [patch] moveOverToken

Post by aliasmask »

This is semi-related: http://forums.rptools.net/viewtopic.php ... 59#p225792

I was wondering if anyone tackled that bug because it reports getLastPath incorrectly when there are multiple tokens being moved and a mix of snapped and unsnapped tokens.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch] moveOverToken

Post by wolph42 »

Lee wrote:Well there're caveats to that:

1. It goes beyond the function's intent, which was simply to say yes or no to "did this token move over the other token?". To keep in form with the rest of MT's design, such information should come from another function so other functions can use it; without having to extract it from the nested results of a "super" function.

2. To actually go after the intersection area is to walk into the problem stated by JFJ. I stepped around that by relying on the implication of area in line-of-path, rather than area occupied by the moving token. Yes, there are speedy geometric algorithms for these problems, but I'm guessing they'll be a pain to implement, else JFJ would have probably put it in a long time ago. In any case, they'll still end up relying on the foundation for token bounds set by our MT devs.

Lastly, JAVA's standard classes for area has, historically, poor performance ratings, and while I could investigate those, it would have to be for some other function, and thus some other time; because, IMO, the goal of equivalent evaluation of movedOverToken on snapped and unsnapped movement, has been achieved.

3. Some of the things you mentioned (0-movement) may have problems with, again, how evaluation happens after the token has landed. I haven't tested it though. I'm positive, however, that 0-movement has been handled by someone else previously, so it's likely not to trigger "moving" over a token.

As for testing, I'm afraid so. But since Jamz has been furnishing JARs for your joint VBL project, he could apply this patch to his next build, can't he? :)
Thanks for the elaboration.
You are right that it would go too far to return point intersections and too be honest, I'm not waiting/have need for these anyway.

Interestingly enough I just realised that your fix will actually break the (most used) teleport pads (for unsnapped movement)... since these should only trigger when move onto them, but they will now also trigger when you move off or over them (as you can't distinguish between these anymore), rendering them effectively useless... argh.
Note that I'm not implying that you should revert this, cause movedOverToken now works as it *should* work.

About the 0 move, its actually pretty useful as you can trigger a pad without the need to *actually* move. That and I've implemented a setting in the BoT to ignore it if required so. So I would actually appreciate it if you leave that one alone.

The reason I bring this all up is because of unsnapped movement icw my ontokenmove pads. Which mainly use on,off and over. to be able to somehow distinguish between these would be nice (or even all 6 movedovertypes), but I can also simply state that the pads will not work for unsnapped movement.

which does bring me to something that IS handy though and I really miss and keep running into: some check to see whether a token is or is not snapped to grid. e.g. getSnapped(). This at least gives me the opportunity to distinguish between the two as the generated results by these two 'states' can differ hugely.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

wolph's reported problem with getMoveCount is easy enough to fix. Instead of copping out and returning a 0 in instances of the error, I'll first see if it is more beneficial to have a new token initialized to a "path" based on where's it first landed.

As for your reported bug, that looks like a gnarly mess of tangled, smelly dog hair, and I haven't even looked at it yet. Seems JFJ might have taken a look see, perhaps he can give a status update on what he knows, and I'll sleep on it and see if it is something I'm capable of having on my to-do list.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

It's probably a late night where you're at or you've had a long day so far, too :), but IIRC, the solutions you and A.M. came up with for tracking and blocking movement through VBL can possibly be jury-rigged in combination with the line segments given, to solve the problem here. Apart from this, off the top of my head, I can imagine it'll be trivial for you, once the value of the new stuff sinks in, to use the 2 points of a line segment combined with other line segments in the path, as determinants whether or not a token entered from outside, was in, passed through, or has left another token's area.
actually its a severe case of the Rhino that got me flewoord. So bad actually that I'm still not *getting* it. e.g.:
"to use the 2 points of a line segment combined with other line segments in the path, as determinants whether or not a token entered from outside, was in, passed through, or has left another token's area."
assuming no waypoints are used, doesnt return movedOverToken three times the same same thing? That is the start and end point of the moving token? Its fairly possible that it the copious amounts of *wool* I currently have in my head that impairs my sight on this, so some elaboration would be nice.
But if you think about it, with this patch, you already can figure out if something is snapped to the grid or not, by checking if the path contains x, y or x1, y1, x2, y2. Ah, how I love deriving stuff from implicit values :)
nice...! That one i *do* get and indeed, getting implicit values is one thing I use a LOT in my MT coding. Thanks!

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: [patch] moveOverToken

Post by JamzTheMan »

Lee wrote:As for testing, I'm afraid so. But since Jamz has been furnishing JARs for your joint VBL project, he could apply this patch to his next build, can't he? :)
Why not. Done.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

@wolph sorry, long day. Well, waypoints included or not, the line segment remains a vector quantity, the target location and area are static values as are the moving token's starting and ending points. With your extensive work with the BoT, and working with offsets and relative positions, wouldn't it be easy to figure out, with some work, values needed to test contexts? Examples such as:

a. x2 - x1, if positive means movement to the right, negative to the left. y2 - y1 would be down for positive, up for negative.
b. When used in relation with the target's area and location, wouldn't one be able to check if the moving token is approaching or moving away from the target? And, with all these points, wouldn't application of triangulation be easier?
c. With moveOverToken, wouldn't it then be know whether collision/intersection occurred?
d. wouldn't x1, y1 in conjunction with the patched movedOverToken's results, say whether a token started on the target or not? and x2, y2 && the patched mOT also say whether or not the moving token ended on top or passed through the target?

I'm sure you've been applying the same things in your other works. If I can venture a guess, I think the disconnect in what you're actually looking for and what I'm thinking is that you want the checking function to give these pertinent information since it's in the area anyway, whereas I was thinking that, with the usual creativity every veteran here has demonstrated repeatedly, much can be done with a smaller feature (albeit with a little more work) in order to get the same results.

I started programming when I was very young. I was of the school that witnessed what people could with a small library of functions such as what were found in C, Pascal, and 8086 assembly. By the same token, it's what I appreciate with the MT community, with all that has been done with the relatively small (but with complete essentials) function set MT provides. I must admit that this is the bias by which whether or not I do something to add to MT, gets weighed. So, I apologize for the times that I differ, or am not possessed with the motivation to go the same direction or think the same way :)

edit: @JamZ. Thanks, that was gracious of you.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [patch] moveOverToken

Post by wolph42 »

@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 :D )

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [patch] moveOverToken

Post by Lee »

Okay. Again, it would be trivial for anyone working on the code to make available the snapped/unsnapped status to the scripting language. It's on my to-do list, but admittedly, at the bottom, and it's a very long list ATM. I get that it'll be useful for you, and that alone, already has merit to it. But I'd like to know if anyone else in the community, will find it useful, perhaps CiF, or A.M.

It can then become driven by demand, and thus, have a higher priority than what it has now. Because as it is right now, I feel people can get by just fine without it disrupting how they use MT, until such time there'll be an opportunity to address adding it to the functions list, don't you think? And thanks for all the input wolph, it's always helpful.
Last edited by Lee on Fri Oct 26, 2012 11:25 pm, edited 1 time in total.

Post Reply

Return to “Testing”