FEATURE/FIX: Fixed token id

[wolph42]

(This is a feature post, discussion about the functionality of this feature (and this featue alone) can be done here.)

Fixed token id - like asset id but does not change between campaign loads. This is like a db primary key. It never changes.
additionally: token id's should NEVER contain numeric digits only: e.g. 00000123456789 which immediately is truncated to 123456789 in any macro. simply starting with a letter will fix this e.g. 'x0000123456789"

[RPTroll]

I'm not sure if this is a bug in the 1.3 b91 maptool but asset ids change between campaign loads. They either needs to stop changing or, if that's not possible, add a new id that macros can access that doesn't change. The id needs to be unique across maps which means if you import a map the ids will change when imported.

[wolph42]

I'm not sure if this is a bug in the 1.3 b91 maptool but asset ids change between campaign loads. They either needs to stop changing or, if that's not possible, add a new id that macros can access that doesn't change. The id needs to be unique across maps which means if you import a map the ids will change when imported.

I didn't know that (b91 issue). I've abandoned use of ID a while back due to exactly this potential issue and the fact that some id's start with 000... if the ID happens to contain numeric digits only then the id is treated as a number and the 0's are removed. This screws up the macro entirely as the id becomes unusable.

[JamzTheMan]

Wait, asset ID or Token ID is changing?

I refer to assetID as the actual Image Asset ID for a token/stamp and it never changes and is the same across all copies of that Token.

I suspect you mean tokenID? And then yes, I agree, we should treat it as a bug first and see if something broke/changed between versions and fix from there. And we could probably do a quick fix on adding just an "x" in front of all tokenID's although I have no idea the ramifications on campaigns and may break existing ones I'm sure.

Wolf, are both leading and trailing zero's removed?

[wolph42]

indeed token id and no only the leading because the number 00001 == 1. But 10000 == 10000. Its basically a typecasting issue, which is great in maptools as it allows for 'sloppyness' (==dirty coding) but sometimes, like in this instance, not so great.

[JamzTheMan]

It shouldn't be to hard to "fix" the leading zero issue. I'm sure it's stored correctly and just lost in translation somewhere.

The persistence of it needs to be verified though. But we can fix one then the other if needed.

[Jagged]

It shouldn't be to hard to "fix" the leading zero issue. I'm sure it's stored correctly and just lost in translation somewhere.

Well, the issue is with the scripting language rather than the token id. Given JS suffers the same issues, I suspect its harder to solve than it appears. Easier to just make sure the ID always has a letter in it.

[wolph42]

It shouldn't be to hard to "fix" the leading zero issue. I'm sure it's stored correctly and just lost in translation somewhere.

Well, the issue is with the scripting language rather than the token id. Given JS suffers the same issues, I suspect its harder to solve than it appears. Easier to just make sure the ID always has a letter in it.

correct. it *is* stored correctly and it *is* passes on as argument correctly, but as soon as you do *anything* with it, e.g. pass it on to switchToken() its truncated.

[Jagged]

I noticed a change in behaviour between 1.3b86 and 1.3b91. With b91 when you start a server, tokenIds get changed, but with B86 they do not.

After testing this again, I withdraw this terrible false accusation. B86 behaves exactly the same, clearly I do not know what I am talking about. Token IDs change on server start for both builds, and probably have done since time immemorial.

[Azhrei]

In order for tokenID to be constant, it would have to be stored in the token, right?

But then what happens if a token is drag/drop'd into a new campaign and it conflicts with an existing one? Now what?

I think the token IDs were originally supposed to be "internal use only" so it was okay for them to be assigned as tokens were read from the campaign file (which, IIRC, is the way it works, sort of; they're calculated based on the content of the token with IP address and timestamp hashed in as well, I think; check the constructor for GUID).

I presume this is important more for library tokens, meaning that all exported tokens don't need their ID cast in stone? In that case, perhaps the SaveAs functions for tokens could strip the ID when writing out the token, allowing a new ID to be assigned when it is later dropped into a different campaign.

[wolph42]

I have no use for 'static' id's. I *do* have use for id's though (as n'ames `$0m3t1m3$ use "str+nge" ch@racters, screwing everything up), but stopped using them, when the id's changed while using them in a macro.

[RPTroll]

I needed them a while back when I was trying to use the asset id on lib tokens so I could find a token regardless of name change. It seemed a safer alternative. I've since switched to using names but, of course, that breaks if the name changes and names can be duplicated on a map.

The id changing when dropped onto a map or importing of an exported map is a non-issue. I'd want the token to have a new id on a new instance of it. I would like the id to remain fixed over campaign loads. I'm also ok with this id not being the asset id and being something else/new. I'd just like something that stays static once a token/stamp hits the map.

[wolph42]

I needed them a while back when I was trying to use the asset id on lib tokens so I could find a token regardless of name change. It seemed a safer alternative. I've since switched to using names but, of course, that breaks if the name changes and names can be duplicated on a map.

The id changing when dropped onto a map or importing of an exported map is a non-issue. I'd want the token to have a new id on a new instance of it. I would like the id to remain fixed over campaign loads. I'm also ok with this id not being the asset id and being something else/new. I'd just like something that stays static once a token/stamp hits the map.

I think that which you ask for is inherently impossible. The problem is that due to the sheer amount of possibilities in mt its impossible to assign a *static* AND *unique* identifier. The simplest versions of screwing this up is dragging a token into the campaign, more complex is importing a map into a campaign or copy/cut pasting a token. In all these instances id's change.

The closest you could get to this is to have a 20 character string randomly generated and stick that to the token (in the hope that it never gets duplicated).

[Jagged]

I think that which you ask for is inherently impossible. The problem is that due to the sheer amount of possibilities in mt its impossible to assign a *static* AND *unique* identifier. The simplest versions of screwing this up is dragging a token into the campaign, more complex is importing a map into a campaign or copy/cut pasting a token. In all these instances id's change.

The closest you could get to this is to have a 20 character string randomly generated and stick that to the token (in the hope that it never gets duplicated).

There are Java classes specifically for this purpose. I make extensive use of java.util.UUID in my day job

[aliasmask]

This is how roll20 probably does it. They separate the data from the image and you have to manually link a token to the data. Things like token states and anything that really changes the image is associated with the token image data, not the token data. So, you can have multiple tokens pointing to the same token but each image could have different states. MT would need another frame or use the Campaign Map to do the same thing. Each time an image is dropped it has a imageId based on the image, but no token id. I could then drop a tokenId on to an image to associated it with that image. You could have the option of creating a clone or a direct link. The clone would be a new token id with it's own token data and a direct link would change the master data and any future clones.

I can imagine it like this:

Goblin (tokenId)
-- "Goblin" (Grasslands,2,5)
-- "Goblin" (Limbo,1,1)
Goblin 1 (tokenId)
-- (no links)
Goblin 2 (tokenId)
-- "Goblin 2" (Grasslands,3,5)
-- "Frank" (Limbo,1,2)

Goblin would have a unique id and have to links associated with it. Goblin 2 demonstrates the name of image token doesn't have to be the same as the token's token data. Cutting and pasting a token image only creates a new image linked to the same token data. Perhaps have a different keystroke to clone the token data like ctrl-shift-c. Use border color coding to visually show copy method.

Perhaps have an image asset db as well.

Goblin (tokenId)
-- -- Goblin 3 (imageId)
-- "Goblin" (Grasslands,2,5)
-- -- Goblin 1 (imageId)
-- -- Goblin 2 (imageId)
-- "Goblin" (Limbo,1,1)

Other than the current token image, these tokens can change their image to Goblin 3 while only "Goblin" (Grasslands,2,5) can change to Goblin 1 and 2 in the image asset library.

Of course the interface will need to be better than this to avoid confusion to differentiate token names from image names. I don't know, just brainstorming.