getName(), token name or id unknown

[Calypso]

Code: Select all

[h: status = input("targetName||Name|TEXT")]
[h, if(status == 0): abort()]

[h: deselectTokens()]
[h: ids = getTokens()]

[foreach(id, ids), code: {
   [h: name = getName(id)]
   [h, if(matches(name, targetName) == 1): selectTokens(id, 1)] 
}]

When I run that, I get an error that says "Error executing "getName": the token name or id "201522969352000000000000" is unknown."

Looking at the full list of token ids, most look kind of like "000000008DC0B0CED242000000000000", but a few look like "201522969352000000000000" or "974936944385000000000000" or "25362996805".

Any ideas what is going wrong?

[aliasmask]

It's a known bug with token ids. When they look like numbers they end up getting converted to numbers and ids are supposed to be a 32 character string. Easiest fix is to cut/paste the token back on to the map giving it a new id.

[taustinoc]

Java does . . . undesirable thing to token IDs when there are only numbers, and no letters. (It treats it as a number, and strips off leading zeroes - those should all be the same length.)

The quick and dirty fix is to copy the token, and paste it back in, creating a copy, and delete the original. The forces a new id, which will usually be alpha-numeric.

If you have a bunch, and either don't have a lot of macros to fix or are still writing macros, you can try working with this:

Code: Select all

  [h,if(isNumber(id)): switchToken(strformat("%032d", id));switchToken(id)]<BR>

swithToken is the function (you'd need to change that to selectTokens), the if statement forces any purely numeric id to be treated as a string, and pads the beginning with the right number of spaces.

I haven't tested this, but it should be close (assuming I didn't mistype anything):

Code: Select all

[h, if(matches(name, targetName) == 1): if(isNumber(id)): selectTokens(strformat("%032d", id));selectTokens(id)(id, 1)] 

[Calypso]

Sadly, not working. For a token like "201522969352000000000000", isNumber() is returning true, but it's still a BigDecimal, which strformat() seems to be choking on. I'll have to think about it more, thanks for the pointer on the underlying problem I'm facing!

[Calypso]

And for whatever reason, this is returning true from isNumber(): "00000000E56136966485000000000000".

Code: Select all

[h: ids = getTokens()]

[foreach(id, ids), code: {
   [r, if(isNumber(id)): id; ""]
}]

[taustinoc]

I suspect that if the only letter in it is an E, that Java is interpreting it as a number with scientific notation (which is a number).

[taustinoc]

Sadly, not working. For a token like "201522969352000000000000", isNumber() is returning true, but it's still a BigDecimal, which strformat() seems to be choking on. I'll have to think about it more, thanks for the pointer on the underlying problem I'm facing!

Try this:

Code: Select all

[h: ids = getTokens())]
[foreach(id, ids,""), code:
{
  [h,if(isNumber(id)): switchToken(strformat("%032d", id));switchToken(id)]<BR>
  [r:token.name]
}]

This should list all tokens in the chat window. If it fails on the same id, then maybe you're right, and it's a problem with BigDecimal, but I've never run into that even with 24 digit id numbers. I suspect it's more a matter of my quick and dirty attempt at modifying it for selectTokens has something wrong with it.

[Calypso]

KHAAAAAAAN!

Okay, I finally got it working. Here is my code:

Code: Select all

[h: status = input("targetName||Name|TEXT")]
[h, if(status == 0): abort()]

[h: deselectTokens()]
[h: ids = getTokens()]

[h, foreach(id, ids), code: {
   [h, if(matches(id, "\\d+")): name = getName(strformat("%032d", id)); name = getName(id)]
   [h, if(matches(name, targetName) == 1): selectTokens(id, 1)] 
}]

Thanks for the help!

[Calypso]

Improved:

Code: Select all

[h: status = input("targetName||Name|TEXT")]
[h, if(status == 0): abort()]

[h: deselectTokens()]
[h: ids = getTokens()]

[h, foreach(id, ids), code: {
   [h, if(matches(id, "\\d+")): name = getName(strformat("%032d", id)); name = getName(id)]
   [h: pattern = concat(".*", targetName, ".*")]
   [h, if(matches(name, pattern) == 1), code: {
      [h, if(matches(id, "\\d+")): selectTokens(strformat("%032d", id), 1); selectTokens(id, 1)]
   }]
}]

[taustinoc]

Glad you got it working. That particular issue is a real pain.

[bobifle]

If I remember correctly, token ids are uuids type 4.

They should look like "123e4567-e89b-12d3-a456-556642440000". I don't know what stripped them from their minus sign, that would have disambiguated the content, avoiding java to convert it to a number.

[aliasmask]

I would like to see a MapTool solution to this. I'm not sure if the culprit is java or the parser. If anything when doing the conversion there should be a check not to convert length 32 character strings. That or slap a "t" at the front of the token id.

[bobifle]

Done a quick check in the code and my previous comment is wrong.
MT uses a non standard implementation of UUIDs. So I don't think it's targeting a specific version (probably because the implementation predates the UUID class from jdk 1.5)

The problem is the same though: MT does nothing to disambiguate an uuid from an integer, its string representation is a valid integer.
It probably could be fixed by changing the implementation of

Code: Select all

public GUID(String strGUID)
public String toString() 

Something could be inserted by the second function and removed by the first one. That would make the new uuids incompatible with previous MT versions...

[Full Bleed]

That would make the new uuids incompatible with previous MT versions...

That's usually not a problem... it's historically been more important that campaigns in older versions seamlessly transition to newer versions. There's never been a guarantee that things would function in the reverse.

[aliasmask]

I'm not sure how the uuids are being generated, but definitely not through the usual method because of all the padded 0's on the same campaign. I'm guessing it's based on other things about the token and when there is no data, then it puts 0's.

I would write something in to the campaign loading process to assign non-numeric uuids. Do the same procedure on token drop and copyToken() and I think that covers all the token creation points. moveToken() may be another one, but I can see it going either way. Having an MT codebase solution is much faster than a scripting solution. Things could be even easier if you have your own UUID generator procedure so you would only have to change the code in one place.