Token name override not working

[liquidox]

I have configured Token name override set to "Mob". Numbered tokens is "on" as well as Show name tag.
I tested with a token from MM as well as a sheet imported using !shaped-monsters.

Both are showing up as "Actual monster name 1", and not "Mob 1".

[symposion]

This works for me when I select a token and run !shaped-import-monster. As you know I can't test the MM drag. Can you give me a reproduction path that doesn't involve MM drag?

[liquidox]

Yes I see the same issue when using "!shaped-import-monster --Lich" for example. Shows up as "Lich 1" for my Test player in the game.

Could Tokennamenumber or Healthcolors be messing with it? I will disable those now for testing.

[liquidox]

Same issue with either or both of those scripts disabled, I don't have any other related script I think.

Could make a video to demonstrate, but not sure it helps any...

[symposion]

So to clarify, you are doing:

1. Drag token to tabletop
2. Select token
3. !shaped-import-monster --Lich

After you do this, you're seeing a token that is named Lich %%NUMBERED%% rather than Mob %%NUMBERED%%?

Or are you doing !shaped-import-monster --Lich and then assigning a token to it afterwards? Because that won't work, and can't work thanks to the rather counter-intuitive way that Roll20 handles the character->token relationship. The default token for a character is a JSON blob containing a snapshot of the data for the token at the point that you assign it to the character. If you subsequently modify the token in some way, it will not update the character's default token, because the character has an independent snapshot of the token taken at the point where it was assigned, and there is no ongoing object relationship between the character and the token you selected to be the default. I find this behaviour exceptionally confusing, as does basically every other new Roll20 user, but that's how it works.

As a result, if you want things to work as expected, you need to start with the token, and then run !shaped-import-monster with it selected.

In general, I'd strongly recommend that you start with the "how to" guides in the script documentation before diving in and experimenting with the commands on your own - these guides provide sequences of steps that are known to work for the major use cases, and there's usually a good reason why they are ordered/structured the way they are. The limitations of Roll20 require the script and then sheet to work within quite narrow parameters to even function at all, and we frequently have to accept extremely unsatisfactory user experiences because there's simply no other way to make things work. I'd love to make the behaviours of all the commands intuitive and obvious, but since that's not possible in most cases, the only alternative is for people to start by following the instructions to the letter before going off-piste and running up against the peculiarities of Roll20s UI.

[liquidox]

Using a blank token as base indeed worked correctly. I wasn't trying to experiment with the commands, I was using it according to the documentation:

You may no or 1 tokens selected when running this command. If you have no tokens selected, this command will just add the new characters to the journal.

and

Token Name Override If this is not empty, all new tokens will have their name tag set to this value. This is most useful in combination with Numbered Tokens,

Not sure how a user like me should be expected to know this only works on existing tokens. I understand roll20 scripting is frustrating, but I have mostly been testing Shaped in combination with roll20 modules, I do not consider that off-piste...

[symposion]

Hey,

Sorry, didn't mean that to come off as critical/shitty - I share your frustration with this. It should work like you expect :-( I was just trying to recommend that you start with the sequences in the "Usage" section of the docs - which are known good workflows - before trying other workflows which may or may not function as you expect.

It's EXTREMELY frustrating to me that I can't test any of the stuff that you're seeing with modules (which I totally agree is not "off-piste" in any way) without dropping $50 on one. Sigh. Maybe we'll get some sort of response on this on Tuesday, but I'm not holding my breath.

The docs for Token Name Override docs could use some work. The Token defaults are really "defaults for tokens for newly imported monsters" rather than "defaults for all new tokens". I don't think that defaults for all new tokens would be especially useful, since tokens get used for a lot of different stuff and I think it would probably be quite frustrating to have them all automatically labelled as if they were monster/NPC tokens.

[symposion]

I'm closing this because I've now opened #429 and #430 to cover the generic problem behind this.