Token ID's generated without any Letters (i.e. only numbers)

[Kinks]

Hi guys,

First of all I'm sure someone else must have had this problem, but I've not been able to find a thread, so I apologise in advance if that is the case.

Secondly, this is my first post. Hi all and thanks for the awesome software.

Finally, my problem.

Version 1.3 b91
Some times when new tokens are created there id's don't have any letters. e.g. 00000008798538752900000000000. Most of the time 1 or 2 of the characters are an upper-case letter.

This causes problems when storing the an id as a variable to be used later on in the macro or in a different macro. For example:

[id = currentToken()]
[id = 00000008798538752900000000000]
[id = 8798538752900000000000]

When the proceeding 0's are automatically removed the id is no longer recognised. This only happens if there are no letters in the ID, if there are letters MapTools doesn't remove the proceeding 0's (presumably as it realises the ID is not a number).

This problem has only recently started occurring and I have no idea what has triggered it. I don't know if something has changed recently to allow ID's to be created without letters, if previously ID's without numbers were recognised as non-numbers or if there is some kind of bug in my framework.

Like I said this problem only occurs very rarely (less than 1% of the time when a token is created) and there does not seem to be any common theme for when it does occur. The Framework uses copyToken() quit a lot to produce new tokens, I've had multiple macro's produce tokens with ID's without letters of all different types: Tokens, Objects and Backgrounds. In addition on one occasion using ctr+C and ctr+P to copy a perfectly normal token (with a letter in it's ID) resulted in pasting a 'bugged' token (without any letters in the id).

I know there are was to check if an ID has letters and ensure that it is stored / passed on correctly, but this would obviously mean changing a LOT of macros, which I would prefer to avoid. This problem never use to occur, is this some kind of bug? Is it possible to make all new token IDs contain letters?

A simple fix to this problem is to copy and paste the 'bugged' token, which often produces a new token with an 'un-bugged' ID, however this is not always practical.

Any help or advice would be greatly appreciated. Thanks.

[wolph42]

yes this is a known problem. one way to deal with this is running 'diagnose' on the bag of tricks (link in sig). this scans all tokens for potential issues, of which that is one and fixes or reports them. there are other methods available as well.

[Full Bleed]

yes this is a known problem.

And an annoying one.

I'm surprised this hasn't been addressed in 1.4.

[wolph42]

yes this is a known problem.

And an annoying one.

I'm surprised this hasn't been addressed in 1.4.

it isn't? I thought it was. IRC a fix was given a while back.

[aliasmask]

Even an id with all numbers is okay except for the fact that the leading 0's are removed. I also pointed out another problem using text.#D# format for a variable name because it does a conversion of the variable name that causes an error. I think one solution would be to realize the number is beyond the scope of a normal 15 digit float and that it should be treated as a string when stored.

[Kinks]

yes this is a known problem. one way to deal with this is running 'diagnose' on the bag of tricks (link in sig). this scans all tokens for potential issues, of which that is one and fixes or reports them. there are other methods available as well.

Thanks Wolph, wish I had posted here a long time ago rather than chasing my tail. I'm not going to confess how long this has been causing me problems.

[JamzTheMan]

Pretty sure its stored as a GUID internal class type. Problem is probably around returning it via macros.

Is there a specific test case to test with? I was just in some of that code this week, if its a quick fix....

edir: Oh, I see you meant stored as a string in the macro var?

[wolph42]

There is a quick fix irc azh mentioned adding a character at the front of the I'd, eg "i00000122345...", apparently this had not been submitted then

[lmarkus001]

Detect Bad IDs

Code: Select all

[H: selectTokens()]
[H: ids = getSelected()]
[H: badids = "[]"]
[H,FOREACH(id,ids),CODE: {
  [ tlen = length(id) ]
  [IF( tlen != 32 ): badids = json.append(badids,id); ""]
}]
[R,FOREACH(id,badids,""): "<b>Bad ID:</b> " + getName(strformat("%032d",id)) + " ("+id+")<br>" ]
[R: json.length(badids) + " IDs are bad."] 

Detect and Repair Bad IDs - Note this will not preserve the token Shape property.

Code: Select all

[H: selectTokens()]
[H: ids = getSelected()]
[H: badids = "[]"]
[H,FOREACH(id,ids),CODE: {
  [H: tlngth = length(id) ]
  [IF( tlngth < 32 ): badids = json.append(badids,id); ""]
}]
[R,FOREACH(id,badids,""),CODE: {
  [H: switchToken(strformat("%032d",id)) ]
  [H: tname = getName() ]
  [H: tupdates = json.set("{}","name",tname,"delta",1,"x",0,"y",0)]
  [H: copyToken(strformat("%032d",id),1,"",tupdates) ]
  [H: removeToken(strformat("%032d",id)) ]
  [R: "<b>Bad ID:</b> " + tname + " ("+id+")<br>" ]
}]
[R: json.length(badids) + " IDs were bad and repaired."] 

[RPTroll]

Nice.