Testers - MapTool 1.3 Build 77

[Phergus]

For copyToken, useDistance:0 should put the square corner in the middle of the hex and when :1 should have the center in the center of the hex.

Uhm, no.

With useDistance:0, copyToken should center the token on the target cell.

When useDistance:1, copyToken should a) ensure snap-to-grid is off for that token, b) place the token's top left pixel at the absolute map pixel location passed in. (Assuming delta:0) Since most images will have an even number of pixels vertically and horizontally there isn't a center pixel but there always is a top-left pixel. It's that pixel that is used as the origin point when drawing the image to the display.

Snap to grid seems to snap the upper left corner to the hex. So, where ever that corner is, is where it snaps.

Yup, that's what I said. When snap-to-grid is enabled on a token it is snapped to the hex that its top-left corner is in. When turned off the token is repositioned so that its top-left corner is now in the center(ish) of the same hex.

[aliasmask]

I was talking about pre b77 application of copyToken. Actually, b77 does that too, but we don't want it too because of the reverse logic on useDistance. useDistance 0 was used for grid units and 1 was for map xy values. Because snap to grid takes the upper left corner of token and because the upper left corner, if centered appears in a different hex should have that corn centered in hex for it to snap to correct hex. So, snap to grid, hex and useDistance 0 (grid units) all go together and the token upper left corner should be in the center of hex at 0,0 (which is the center of the hex).

[Phergus]

The reversed logic for useDistance has already been fixed in the development code.

You have the relationship backwards. Snap-to-grid for tokens (where tokens == PCs/NPCs) has nothing to do with what grid cell the top-left corner of the token image falls in. It is about placing the token such that the center of its footprint is centered on a specific grid cell. This is true for hex or square grids. Note that on both grid types the token image can extend well outside of its nominal footprint and normally does with tokens on hex grids. The correct math has to be done to position the token image properly in relation to the target cell taking into account both footprint, positioning of the image relative to footprint and image dimensions. This is easier on square grids for obvious reasons.

copyToken() should apply the same rules that dragging a token to a new location does.

[aliasmask]

The reversed logic for useDistance has already been fixed in the development code.

Yes, I know. I just haven't been able to see the change yet.

You have the relationship backwards. Snap-to-grid for tokens (where tokens == PCs/NPCs) has nothing to do with what grid cell the top-left corner of the token image falls in. It is about placing the token such that the center of its footprint is centered on a specific grid cell. This is true for hex or square grids.

I'll have to disagree with you there. The observed behavior for both square and hex uses the upper left corner to snap to grid. The only exception is the token layer for square grids and I recall Az mentioning some work was done for that. For a square grid on the token layer only, then snap occurs when the center of token goes in to a new square. I actually mentioned that in a bug report recently: http://forums.rptools.net/viewtopic.php ... 57#p182662, but I mentioned it as a desired behavior.

Note that on both grid types the token image can extend well outside of its nominal footprint and normally does with tokens on hex grids.

Yes, that's because of the snap. If you unsnap the token in a hex grid, you'll see the true position of the token. That's demonstrated in the last picture of this post: http://forums.rptools.net/viewtopic.php ... 15#p182739. This is not the behavior of b77 for copyToken, but before b77.

The correct math has to be done to position the token image properly in relation to the target cell taking into account both footprint, positioning of the image relative to footprint and image dimensions. This is easier on square grids for obvious reasons.

copyToken() should apply the same rules that dragging a token to a new location does.

I'm not going to argue about the math or footprint, that all seems fine. I was just noting because of the reverse logic in b77 for useDistance and hexes the placement of the token was different. With no grid snapping and using the map xy, when placing a hex at 0,0 we expect it to be in the center of hex 0,0, and it is. But I then turn on snap to grid, that token now jumps to -1,-1 because the grid snap grabs the upper left corner of the token (footprint, not image) and uses that to determine it's snap hex location. So, that's why when placing a token using grid units on a hex map the corner is put at location 0,0 and when using map x,y the center is placed at 0,0. Using the map x,y assumes no grid, so no snapping of grid. This can be demonstrated using Wiki: moveToken().

Code: Select all

<!-- on hex map for token not snapped to grid, token is centered in 0,0 hex -->
<!-- on hex map for token snapped to grid, token snaps to -1,-1 hex because upper left corner appears in that hex -->
[moveToken(0,0,1)]

<!-- on hex map for token not snapped to grid, token's upper left corner is placed in center of 0,0 hex -->
<!-- on hex map for token snapped to grid, token is snapped to 0,0 hex -->
[moveToken(0,0,0)]

I seem to be getting a lot of resistance to pointing this stuff out. I'm either not describing it correctly, or people are taking this as criticism. I've tried to explain this as best I can and I'm hoping this last post will clear it up. I'm not criticizing anyone. There's been a lot of fine work done on the mapping system and just this one hiccup using useDistance for copyToken (which has been fixed) started this conversation. I agree with "It is about placing the token such that the center of its footprint is centered on a specific grid cell." but placement does matter depending on the snap-to-grid. Snap-to-grid uses the upper left corner to determine the cell it will be snapping to. This would be a whole different story if the snap happened at the center of the token like it does for the token layer on a square grid which is the only case this is true.

[Azhrei]

I seem to be getting a lot of resistance to pointing this stuff out. I'm either not describing it correctly, or people are taking this as criticism.

No criticism from me. I'm just trying to understand how the hex math works. What can I say? I grew up in a Cartesian world.

Snap-to-grid uses the upper left corner to determine the cell it will be snapping to.

Bingo! And because a square token of 50px is a token whose (0,0) extends outside of the snap-to-grid hex cell that the token's centerpoint is in, it snaps to a weird location. The snapping should be done by compensating for the fact that the center of the footprint should be used, not the upper left corner.

But I need to understand the hex coordinate system first. Fortunately, work is over for this week so I hope to spend some time on this over the weekend.

[aliasmask]

On the hex grid, you can see the token footprints overlapping. But the snap to grid actually uses a formula for the hex, so as soon as that corner crosses or meets the drawn hex line, it'll jump to that hex.

[Azhrei]

Yep, exactly. The formula needs to include an offset to the center of the hex so that the snap works correctly. I'm just not familiar enough with the code to know where or how to add that change. Yet.

[Phergus]

I seem to be getting a lot of resistance to pointing this stuff out. I'm either not describing it correctly, or people are taking this as criticism.

While possibly some of the former, it is not the latter.

Snap-to-grid uses the upper left corner to determine the cell it will be snapping to.

Starting with this base assumption is why it is broken. Neither the upper-left corner of the token image nor token footprint (they aren't necessarily the same) should be used for determining the snap-to cell.

Bingo! And because a square token of 50px is a token whose (0,0) extends outside of the snap-to-grid hex cell that the token's centerpoint is in, it snaps to a weird location.

Note that the upper-left pixel of a token on a square grid can also lie outside of the intended target cell.

FootprintVsImage.png (42.58 KiB) Viewed 1908 times

This token, with snap-to-grid enabled, used on a square grid does get correctly positioned by copyToken() so clearly the top-left pixel of the token image isn't used to determine the snap-to location by itself.

The snapping should be done by compensating for the fact that the center of the footprint should be used, not the upper left corner.

Exactly.

[Rumble]

I just did a bunch of work with footprints and so forth; I'll see if I can spot how to do this so that the center of the token footprint is the snap-point.

[jfrazierjr]

well.. according to what I have seen, both in comments and in code(not that I looked that closely) is that square grids are the only ones with tokens beginning in the upper left corner. For Hex and gridless the "reference location point" of the token is based on the token's center point. With that in mind, hex should snap when the center point of the token's footprints cross the hex line barrier(not such was the behavior SHOULD be if dropped on the line itself????) into the hex which contains said point.

[Rumble]

That is the case - hex grids place token X,Y in the center of the token. However, I think snap is basing it off something else, and in a quick look, I couldn't figure out which part of ZoneRenderer and/or Token actually decided what cell to snap the token to. It occurs to me that the fix may be, in the various sections that render tokens, to separate out Hex grids and Square grids and handle them slightly differently instead of just having hex and square grids handled as a single unit, and gridless grids handled as a separate unit, as it appears to be now.

[Azhrei]

I don't think the main problem is the snap code, but that copyToken doesn't compensate the way the snap code does.

The whole footprint thing seems like an afterthought that was done to make hex grids work and it isn't neatly tied into the whole package.

[Phergus]

The whole footprint thing seems like an afterthought that was done to make
hex grids work and it isn't neatly tied into the whole package.

The footprints came in a lot later and were added to handle non-square tokens in both square and hex grids. Several systems treat horses and similar critters as occupying a 1x2 footprint (either squares or hexes).

It seems to me that copyToken() shouldn't be trying to do any calculations of its own for a tokens position. Those should be handled in the Token itself or perhaps in the ZoneRenderer or Grid classes.

[Azhrei]

It seems to me that copyToken() shouldn't be trying to do any calculations of its own for a tokens position. Those should be handled in the Token itself or perhaps in the ZoneRenderer or Grid classes.

I think the Grid classes should do all the work.

Alas, that's not how the current code does it. And I'm not about to make such a large change at this point. So if copyToken can be made to work properly, great. If not, this won't be fixed in 1.3.

[Phergus]

Sounds good. Flag it as a known bug and leave it for 1.4.