Duplicate tokens being created onDrop by player

So a little background of the issue:
When a GM does a token drop and the size/name/other properties are adjusted, everything works fine, as the token ID is accessible.

When a player does a token drop, the token proto and position is transferred to the GM to edit the size/name/other properties. When this happens, on most maps (not all for some reason, however fully repeatable with vault maps) a duplicate token is created.

Findings:
I hunted down the reason for this, my script adds another token if the original token cannot be found and adjusts that one. On the surface it doesn’t seam like a big issue.

To resolve, I had snap to grid turned on, and converted the position coordinates passed along to the imageControl’s snap to grid function to adjust the coordinates.

Issue description:
What I uncovered was that the x coordinates were correct, but the y coordinates were slightly off. To verify this I also put a known existing token x,y position (already snapped to grid) through the function.

What I found is, although the already snapped token was present, it’s adjusted coordinates had a different Y value as well.

I do not know why an already positioned token position would change when position coordinates are placed through the imageControl’s snap to grid function.

I adjusted my script to compensate correctly, but it does not seam like this is expected behavior.

It sounds like the duplicate token is created by your script, because it can't find the token at the exact location being returned. Is this correct?

Could you create a small extension that recreates the issue specifically without any extra functionality?

If I can get specifically at the y-axis discrepancy you are mentioning, it should be fairly straight-forward to dig into the code. However, right now, I'm not very clear where the issue is at exactly.

Thanks,
JPG

Quote:

---

Originally Posted by Moon Wizard

It sounds like the duplicate token is created by your script, because it can't find the token at the exact location being returned. Is this correct?

Could you create a small extension that recreates the issue specifically without any extra functionality?

If I can get specifically at the y-axis discrepancy you are mentioning, it should be fairly straight-forward to dig into the code. However, right now, I'm not very clear where the issue is at exactly.

Thanks,
JPG

---

I will be making the quick extension to show what I’m talking about tomorrow... sorry for the delay, life has been hectic

Sorry for the crazy delay. Life has been hectic to say the least. So I made the example extension to show what I was talking about.

Activate the extension, open a map with tokens on it, left click on a token, and the chat debug messages output the token info, token x,y position info, and the token x,y snapToGrid info.

The Y coordinate for the snapToGrid is always 2 off from the token info and the token getPosition value.

I know this seam minor, but I have seen in many cases that the snapToGrid is used VERY commonly in script calculations.

the entire script file is as such:

Code:

---

function onInit()
        Token.onClickDown = onClickDown;
end

function onClickDown(token, button, image)
        Debug.chat("token = ", token);
               
        local xtPosi, ytPosi = token.getPosition();
        Debug.chat("token x = ", xtPosi);
        Debug.chat("token y = ", ytPosi);       
               
        local ImageCrtl, ImageWnd, BWindowOpened = ImageManager.getImageControl(token, false);
        local x,y = ImageCrtl.snapToGrid(xtPosi, ytPosi);
        Debug.chat("snap to grid x = ", x);
        Debug.chat("snap to grid y = ", y);
end

---

Thanks for the extension. By helping pinpoint the issue, I was able to focus my efforts on the culprit API (snapToGrid). The API and internal structures use different axes, and this API function was not translating the point before snapping which was causing the issue. I'll submit a fix for the next build.

Regards,
JPG

So the current coordinate issue also is affecting the snaptogrid as well. Using the above simple extension again the x,y is different than the snaptogrid x y for a token that has already been snapped...

additionally the further down on the map, or the further to the right, the further the offset gets (respectively). the offset seams independent of token locking.

so my assumption is that whatever is causing the coordinates issues is also causing issues with more than just the addToken functions.

Figured I'd just point this out to try to help hunt this down what the issue is.

also the draginfo x,y coordinates are drastically off as well

The coordinates for all the token APIs need to be overhauled to be consistent; but I'm hesitant to do so at this point as it will break every extension using those APIs as well as some core ruleset code.

Technically, the onDrop x,y (which should be offset from top-left of image control to be consistent with all other onDrop control behaviors) shouldn't match the token placement x,y at all (which is image data based). However, there needs to be an API to map the image control position to the image data position based on the current viewport, zoom level and UI scale (which I need to add).

It's on my list to revisit; but behind some other things we're looking at.

Regards,
JPG

As always! Thank you for everything you do! If there is anything I can help script out or what have you, please let me know.