[1.3B59] Token Movment Distance

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice, MapTool BugReport Manager

jmurrayufo
Cave Troll
Posts: 38
Joined: Mon Apr 27, 2009 5:04 pm

[1.3B59] Token Movment Distance

Post by jmurrayufo »

Tokens in b59 without snap to grid seem to start with a large amount of movement when clicking and dragging. This effect seems to increase with the size of the token.

jmurrayufo
Cave Troll
Posts: 38
Joined: Mon Apr 27, 2009 5:04 pm

Re: [1.3B59] Token Movment Distance

Post by jmurrayufo »

This effect is in 1.3B60 as well. Tokens that are moved without snap to grid on, have a movement indicated @ zero movement. This effect still isn't the same with different sized tokens. For now I can just subtract the initial movement to figure our how far a given token is allowed to move, but this is rather tedious.

Darinth
Dragon
Posts: 424
Joined: Wed Oct 21, 2009 2:52 pm

Re: [1.3B59] Token Movment Distance

Post by Darinth »

Bug exists in b59 and b60, but does not exist in b56. Dangit, and I was gonna have my gaming group upgrade to b60 on sunday hopefully.
Loyalty is not blind, and it cannot be forced. It is a sincere bond formed out of respect and gratitude.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: [1.3B59] Token Movment Distance

Post by Azhrei »

I thought this bug was squashed previously... There's something about a large token being dragged from the upper-left corner instead of the center, so the initial movement shows a huge jump. The bigger the image, the worse the jump.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

It seems to affect all tokens, not just big ones. For instance, a default gridless map starts token movement (even for size 0 tokens, the standard "medium" ones), at 1.5 and counts up from there. With large tokens, the offset is crazy.

Looking at the b56 code vs. b60, there are changes in how and where renderPath() is called, but I can't see any differences (on a relatively cursory look) in how distance is counted. No idea what's causing it.

This may be helpful: I was experimenting with taking a standard "0" size token on a gridless map, and moving it around. Movement always seemed to start from 1.5 and count up from there; the movement path is rendered starting at the center of the token, as expected.

I then increased the size of that token to 10, and moved it around. The movement distance started counting from around 8.5 (I couldn't tell exactly; I wasn't steady enough). I also noticed that the movement path started from the same point that it started when the token was size 0. In other words, despite enlarging the token, it drew the movement path from the same place it did when the token was size 0.
Attachments
size10token_with_movepath.png
size10token_with_movepath.png (202.04 KiB) Viewed 6703 times
size0token_with_movepath.png
size0token_with_movepath.png (93.99 KiB) Viewed 6703 times

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: [1.3B59] Token Movment Distance

Post by Azhrei »

Rumble wrote:Looking at the b56 code vs. b60, there are changes in how and where renderPath() is called, but I can't see any differences (on a relatively cursory look) in how distance is counted. No idea what's causing it.
The problem will be in the subclass that implements the gridless mode. IIRC, there's a GridSquare and a GridHex class, plus one that handles gridless. The offset for where the mouse considers the center of the token to be should be based on the token size and the result of asking the grid class what the grid size is. For gridless, I would think the return value should always be "1", but that depends on how the return value is used.

Sorry, not very helpful but I haven't ever looked at that part of the code in detail. :(

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

I have only a vague grasp on that part of the code (in that there is such a thing as a token footprint and that it is sometimes offset :D) - it's mostly bewildering. Have to get an expert on the job.

On an even more interesting note, it's now starting "size 0" token movement at 7.1, rather than 1.5 (edit: ah, that's because it's 1.5 if your units-per-cell is 1, and 7.1 if your units-per-cell is 5 on a gridless map).

Darinth
Dragon
Posts: 424
Joined: Wed Oct 21, 2009 2:52 pm

Re: [1.3B59] Token Movment Distance

Post by Darinth »

Well, that explains what I was about to post. Looking over the various posts on this bug scattered around the forums there were a lot of conflicting reports on what the actual starting number was. Sounds like it depends on what your units-per-cell is which is nice to know. I convinced my gaming group to switch for this coming Sunday and was starting to get worried that everybody was going to have a different number to deal with when I told them all 7.1. *_*
Loyalty is not blind, and it cannot be forced. It is a sincere bond formed out of respect and gratitude.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

Darinth wrote:Well, that explains what I was about to post. Looking over the various posts on this bug scattered around the forums there were a lot of conflicting reports on what the actual starting number was. Sounds like it depends on what your units-per-cell is which is nice to know. I convinced my gaming group to switch for this coming Sunday and was starting to get worried that everybody was going to have a different number to deal with when I told them all 7.1. *_*
REmember that the offset will differ based on the size of the token. For instance, on 1-unit per cell maps, the offset goes like this:

Size 0: 1.4 (or 1.5, but I think 1.4)
Size 1: 1.7
Size 2: 2.0
Size 3: 2.4
Size 4: 2.9
Size 5: 3.5
Size 6: 4.2
Size 7: 5.0
Size 8: 6.1
Size 9: 7.3
Size 10: 8.7

On a 5 unit map, it's:
7.1, 8.5, 10.1, 12.2, 14.4, 17.5, 20.9, 25.2, 30.4, 36.5, 43.6



On a 1-unit-per-cell map, size -11 starts at 0.1 when you drag it.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

I still don't know what's causing it, but it's been interesting exploring the code to see what I find. So far, here's what I know:

The bug appeared in MT b58; it was not present in B57.

Looking at those two revisions in the source, there were a number of changes, but the places that appear likely to be the source of the change are:

PointerTool.java
Scale.java
ZoneRenderer.java

But I'll be darned if I can find anything. It might be something subtle, I guess - a cast that has unanticipated consequences, or some uninitialized or wrongly initialized variable.

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

Quick update: I believe the bug is located in the SelectionSet class. If those are reverted to their B57 code, movement distance is accurately counted. On the other hand, no path line is drawn.

However, it's narrowing it down.

Edit: I give up. The two problems are related, but I can't figure out where the proper offset isn't being included (or is being doubled up).

cheesethulhu
Cave Troll
Posts: 26
Joined: Thu Aug 20, 2009 3:21 am

Re: [1.3B59] Token Movment Distance

Post by cheesethulhu »

Someone want to try out this patch? Normally, I only use snap to grid, so I may have missed something really obvious.

Rumble: Your work made finding the problem much easier. Thanks.
Attachments
nosnap_distance-patch.txt
(1.87 KiB) Downloaded 143 times

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

I just patched it, and that patch fixes the distance counting problem - awesome! However, it does not address the path rendering issue, which I'm still trying to tease out.

Edit: again, I'm failing to grok the interactions between the various parts (actually, I'm getting confused at the number of different size and scale options :D), but what appears to be happening is that when a token's size is altered, the footprint is not updated correspondingly (at least, that's what it looks like - if you use the default size, the path is rendered from the center, but if you increase or decrease the size, the path is rendered from the center of the default size 0 footprint, rather than the token's new footprint).

Also, I feel like a dunce because I can't dope it out. I managed to make a movement/terrain feature for maptool - spending a TON of time with ZoneRenderer and Token footprints and offsets and all of this, and I can't figure out the change. Sigh. :?

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: [1.3B59] Token Movment Distance

Post by Rumble »

HA! VICTORY IS MINE!

Okay, I finally doped out the error with the path line (for the curious, the token footprint was not having its scale applied, so no matter what you changed the size to, the footprint was always assumed to be the default one).

I have to fix a waypoint issue (same problem; just need to update the waypoint code too EDIT: oooh, interesting issue there; type conflict between int and double), and I think I can submit a patch to Trevor. Cheesthulhu, you should submit the distance patch as well; that appears to fix the whole thing.

Update
Bam! Got it.

Cheesthulhu - do you want to submit your patch separately, or want me to fold it into mine (with credit due to you, naturally)? I'm going to try a fresh checkout of the b60 source and apply both patches to make sure it really works. If it does, I can submit it to Trevor; however you want to do it.


Edit: I've attached the combined patch after trying it on a fresh checkout of the b60 source. It looks like it works - if anyone wants to confirm that, I'd appreciate it.
cheese-rumble.txt
(4.31 KiB) Downloaded 164 times

jmurrayufo
Cave Troll
Posts: 38
Joined: Mon Apr 27, 2009 5:04 pm

Re: [1.3B59] Token Movment Distance

Post by jmurrayufo »

Thanks for the work! This is going to take a HUGE workload off of players and the GM at the next game!

Post Reply

Return to “Resolved”