[Script Update] TokenMod -- An interface to adjusting properties of a token from a macro or the chat area.

Thanks Everyone!!!

Hey all. 

Hopefully this question hasn't been asked. I went through the post here but I may have missed something.

I have been using tokenmod --set defaulttoken as part of a macro i wrote to create an reusable NPC setup. It works great but I was thinking that I wanted the character object to also have its avatar updated to the token image as well. I thought first about writing my own script to be notified by when a character gets its token changed, but it seemed too big a hammer as players might be changing their own tokens. So then I said to myself "hey tokenmod has its own notification", but I then realized that the prev and current objects passed into the notification are token objects (I think), which of course makes sense. So my question I guess is "Is there some way I can know through tokenmod nofification that the default token on a character was changed?

Thanks in advance for any help, and thank you The Aaron for writing such a great script.

That's an interesting question!  Not currently.  The fact that defaulttoken gets set by TokenMod is a slight stepping out of bounds from its original intent.  Since that change happens on a Character, it doesn't show up in the change event from TokenMod.  And since API changes don't trigger native events, you can't get an event from it.  The best you could do would be to take the TokenMod event, check if the token represents a character, grab the character, get its defaulttoken, then compare the imgsrc to the avatar image and see if they differ.  (technically, you could compare the token's imgsrc to the character's avatar, just depends on where you want to make assumptions.  I could probably add some ancillary information to the event callback that would make this easy.  I'll look at options tonight. 

I'm having  little difficulty getting bar3 set to a value.  I'm hashing together some scripts I found for my own wildshapes and everything works except Bar 3's value gets set to nothing instead of what it I think it should be.  The first setting for bar1 is the normal form and that is correct.  But after that, it doesn't change for any of the forms that are chosen.  If I run the command separately in chat to change the value, it works.

&{template:npcaction} {{name=@{selected|token_name} }} {{rname=Wildshape}} {{description=[Aldoran](!token-mod --set  bar3| currentside|1 width|70 height|70 light_radius|5 light_dimradius|0 light_angle|360 --off light_otherplayers @{selected|token_id})
[Cat](!token-mod --set bar3|[[1d4]] currentside|2 width|70 height|70 light_radius|60 light_dimradius|30 light_angle|360 --off light_otherplayers @{selected|token_id})
[Panther](!token-mod --set bar3|[[3d8]] currentside|3 width|70 height|70 light_radius|60 light_dimradius|30 light_angle|360 --off light_otherplayers @{selected|token_id})
[Dire Wolf](!token-mod --set bar3|[[5d10+10]] currentside|4 width|140 height|140 light_radius| light_dimradius| light_angle|360 --off light_otherplayers @{selected|token_id})
[Brown Bear](!token-mod --set bar3|[[4d10+12]] currentside|5 width|140 height|140 light_radius| light_dimradius| light_angle|360 --off light_otherplayers @{selected|token_id})}}

Irondrake said:

I'm having  little difficulty getting bar3 set to a value.  I'm hashing together some scripts I found for my own wildshapes and everything works except Bar 3's value gets set to nothing instead of what it I think it should be.  The first setting for bar1 is the normal form and that is correct.  But after that, it doesn't change for any of the forms that are chosen.  If I run the command separately in chat to change the value, it works.

&{template:npcaction} {{name=@{selected|token_name} }} {{rname=Wildshape}} {{description=[Aldoran](!token-mod --set  bar3| currentside|1 width|70 height|70 light_radius|5 light_dimradius|0 light_angle|360 --off light_otherplayers @{selected|token_id})
[Cat](!token-mod --set bar3|[[1d4]] currentside|2 width|70 height|70 light_radius|60 light_dimradius|30 light_angle|360 --off light_otherplayers @{selected|token_id})
[Panther](!token-mod --set bar3|[[3d8]] currentside|3 width|70 height|70 light_radius|60 light_dimradius|30 light_angle|360 --off light_otherplayers @{selected|token_id})
[Dire Wolf](!token-mod --set bar3|[[5d10+10]] currentside|4 width|140 height|140 light_radius| light_dimradius| light_angle|360 --off light_otherplayers @{selected|token_id})
[Brown Bear](!token-mod --set bar3|[[4d10+12]] currentside|5 width|140 height|140 light_radius| light_dimradius| light_angle|360 --off light_otherplayers @{selected|token_id})}}

I'd bet that it's a problem with adding roll templates into the button call syntax.  Things will likely work well if you create each of those TokenMod commands as separate abilities on a Macro character sheet (or your druid) and then reference them like so:

[Cat](~MacroCharacter|CatForm)

Hello TokenMod gurus! I'm very new to using APIs in general and really, even macros. 

I've sussed out that I need TokenMod to adjust Bar Values and thankfully, only need it to do so none fashion. But, I have no idea ho to set up the macro/api interactions.

Would someone kindly help me out?

APIs installed: Combat Tracker, TokenNameNumber, TokenMod and various support APIs Vector, Path, Matrix HTML

What I need is to take the total successes rolled in the macro below and have those successes subtracted from the Target Bar3. 0 or negative successes should do nothing.

Current Output:

&{template:default} {{name=@{selected|character_name}'s Attack Roll}}{{@{selected|character_name} attacks the @{target|character_name}!
[[(@{selected|attack}d6>3)-(@{target|defend}d6>6)]] Successes!

1 BP damage/success.

[Link: Attack Action](http://journal.roll20.net/handout/-M3hKyHi_Oe7ApL0EeNc)}}

That doesn't sound like something you can do with TokenMod directly.  You'd need something that looks for that template to occur in chat, and then extracts the details and applies them to the tokens.

Dang. Thanks Aaron. I appreciate the reply. I was hoping it was something simple. It isn't a game necessity as I can easily apply damage directly.

Thanks again! 

KC, thank you.  That did work.  I just split the commands up into token actions and it all works the way I need it to.

Hi,

using Token Mod to set a default character token after linking the 3 bars and the token is "losing" the bar style (compact) that i manually set. Assume that is expected behaviour because the API cant access that setting? Annoying that even though i manually set it, it loses it when i use tokenMod to set the rest of the things i need, then link it :(

Any idea when the API might be being updated to accessing the Bar style settings of a token?

Echoing the Aaron here. The lack API support of that makes most of the rest of setting up a default token far more difficult.

Honestly, until there is API support, it simply isn't worth it for me to use those settings. =(

Ok, thanks for confirming 

Is this possible to set a token status marker when an attribut is greater than a certain number ?

I can't think of a way to do that off the top of my head with TokenMod.  Depending on what you're looking for, that could be a pretty easy snippet to write.

I use an attribute in a character sheet to store the recoil penalty of a weapon during a fight and I would have liked to have a status marker displayed when the value of this attribute is greater than O.

Knowing that I cannot store the value in one of the three bars of the token.

I have this script that might do what you want: https://app.roll20.net/forum/post/6613608/script-realizestatusmarkers-create-attributes-on-you-player-characters-that-represent-the-number-on-statusmarkers/?pageforid=6614230#post-6614230

It needs to be updated for Custom Token Markers, but should work fine for the originals.

Thank you very much !

trying to use this to make a macro that disable's selected token's sight but can't get the macro right.

its so they players don't know where the edges of darkness spells are when they fight against the drows i have coming up.

Try:

!token-mod --off light_hassight

I've updated TokenMod to be able to set the Updated Dynamic Lighting features on tokens.  I'll probably make some more changes as things change, so feedback welcome!

Here are the relevant updated sections of the help (accessible with !token-mod --help )

Boolean Arguments

Numbers or Blank

Please let me know if you run into any weird behavior, or think it needs changes.

Thanks for updating TokenMod for UDL, Aaron. I am trying it out and I'm seeing some weird behavior (some of which I believe is how the UDL functions):

When I use TokenMod to update UDL settings, such as has_bright_light_vision, the token's Dynamic Lighting UI does not reflect the changes (e.g. if TokenMod toggles Vision ON, the Token still shows that setting as OFF). Similarly, updating Distances does not display the new number on the token. However, the tabletop display seems to reflect TokenMod's updates.

For some reason, Night Vision doesn't seem to interact properly with other objects emitting light (Dim Light areas override Night Vision so the area is dim for a token with Night Vision). But I think that's a feature of UDL right now.

Some of that is definitely UDL current behavior/issues.  If you can drop me some reproduction steps (the command you ran, screenshots where applicable, etc), I'll try and sort out what's me and what's UDL. =D

There's definitely some UI strangeness still, I've been sending the Devs some reports here and there, so I'm not surprised if they're still persisting...

Good news! I'm not seeing the problems that I pointed out earlier (except the Night Vision not interacting properly with light, which other folks are reporting about UDL). At the time, I was having the issue where turning on ULD spikes memory use, so maybe that was behind it.

Chris said:

Good news! I'm not seeing the problems that I pointed out earlier (except the Night Vision not interacting properly with light, which other folks are reporting about UDL). At the time, I was having the issue where turning on ULD spikes memory use, so maybe that was behind it.

It spikes memory use?  With all the Covid/ Social Distancing TT Players flooding the site, Lag has already been at an all-time high.  I'm hoping they keep the legacy DL ...

The Updated Dynamic Lighting is in Public Beta as a parallel system.  They won't remove Legacy Dynamic Lighting until it has feature parity and good performance.

Aaron, just wanted to ask this publicly to answer the question for others. But do these boolean arguments work with Torches as well? Thanks.

(Do you mean the Torch Script? Oh yeah, I see your PM again. =D)

Torch is not yet released with UDL support.  I have a converted version, but it breaks things hardcore in the API.  I passed it off to the Devs to try and track down the issue.

Yeah. Sorry. Yes, the Torches Script. Thanks. 

I have a basic damage macro using Tokenmod that is mostly just a cut-and-paste from what TheAaron supplied a few weeks ago. :)

!token-mod --set bar1_value|[[{@{selected|bar1|max},[[@{selected|bar1}-[[?{Damage}|0}]]]]}kl1]] --report all|"/em {name} takes {bar1_value:change} points of damage!"

Is there a way to modify that macro so that it can apply the same damage to multiple tokens? 

No, because it needs to reference the selected token, which won't work with that syntax across multiple tokens.

The Aaron said:

The Updated Dynamic Lighting is in Public Beta as a parallel system.  They won't remove Legacy Dynamic Lighting until it has feature parity and good performance.

I played around with it a bit.  I wish they had a way to toggle a normal vision from a "darkvision", where they would show everything in Grayscale instead of color.  I used to achieve something similar by doing 60/-1.  But when I took a look - they like to show everything as if it was under a prison floodlight unless I missed something.  And then there was mention of performance issues, but that isn't the hardest part for me.  I really just hate the idea of going through every map and redoing the default tokens in my game, though I think I could change my light macro now that you've updated TokenMod to include all the new widgets; once I understand them ....

(I'd give credit to who started this, I just modified their code to play nice with my game, but I've forgotten where I pulled it from at this point.)

/w gm &{template:5e-shaped}{{title=Adjusting vision for **@{selected|token_name}**}}{{subheader=to token-mod's parameters of:}}{{text_big=?{Vision|Torch, light_radius#40 light_dimradius#20 light_hassight#yes light_angle#360 light_otherplayers#yes|Light Cantrip, light_radius#40 light_dimradius#20 light_hassight#yes light_angle#360 light_otherplayers#yes|Hooded Lantern, light_radius#60 light_dimradius#30 light_hassight#yes light_angle#360 light_otherplayers#yes|Bullseye Lantern, light_radius#120 light_dimradius#60 light_angle#60 light_hassight#yes light_otherplayers#yes|Lamp, light_radius#30 light_dimradius#15 light_hassight#yes light_angle#360 light_otherplayers#yes|Candle, light_radius#5 light_dimradius#=0 light_hassight#yes light_angle#360 light_otherplayers#yes|Darkvision (Std 60'), light_radius#60 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no|Darkvision (90'), light_radius#90 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no|Darkvision (Drow 120'), light_radius#120 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no|Warlock Devil's Sight, light_radius#120 light_dimradius#=120 light_hassight#yes light_angle#360 light_otherplayers#no|No light source(Dusk), light_radius#120 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no|Fog, light_radius#200 light_dimradius#=5 light_hassight#yes light_angle#360 light_otherplayers#no|No light source, light_radius#10 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no|Blinded, light_hassight#no light_angle#360 light_otherplayers#no statusmarkers#+bleeding-eye|Flametongue Weapon, light_radius#40 light_dimradius#40 light_hassight#yes light_angle#360 light_otherplayers#yes|Sun Blade, light_radius#30 light_dimradius#30 light_hassight#yes light_angle#360 light_otherplayers#yes} }}
!token-mod --set ?{Vision}

I'll get around to adding the new UDL support ... eventually ....

Yeah. I feel your pain. I'm also not ready to fully embrace the UDL stuff. I look forward to having soft edges in the light and variation in the what Nightvision looks. I know they're working on those things, so soon maybe. 

On the update side, I plan to write a script to do the conversion work once the API part is less broken. =D

The Aaron said:

Yeah. I feel your pain. I'm also not ready to fully embrace the UDL stuff. I look forward to having soft edges in the light and variation in the what Nightvision looks. I know they're working on those things, so soon maybe. 

On the update side, I plan to write a script to do the conversion work once the API part is less broken. =D

Noice, well I started taking a look on the macro, and wondered if you thought these two would be the same thing.  When I went tinkering around, I did note a very distinctively different thing they did (or I may be out of my mind, jury is always out on that).  It seems they are going with the compiling of light rather than defining and redefining. I.E.  A torch is no longer 40 bright/ 20 dim, but 20 bright and an additional 20 dim.  This is more in flavor with the way the rulebooks define it, so ... yay ... but coming off the old way of converting it to macros is getting interesting ....

Anyway, am I on the right track here with a Torch?

Torch, light_radius#40 light_dimradius#20 light_hassight#yes light_angle#360 light_otherplayers#yes

Torch, bright_light_distance#20 low_light_distance#20 has_bright_light_vision#yes has_low_light_vision#yes emits_bright_light#yes emits_low_light#yes

Now that you mention updating to UDL - do they plan to patch all store bought modules to UDL?  Oh gawd... I felt a pain in my gut even thinking of that ... Here comes another CoS Lag nightmare ...

That looks right to me, but I'd have to try it out to be sure.

You're right on the bright/dim light division.  As with other token settings, I've tried to keep the TokenMod interface matching the GUI, so the dim light gets added to the bright light for a final radius, rather than redefining how part of it looks.  Peeking behind the curtains a bit, this is purely a UI change, the backend data still deals with things where bright needs to be entered as the total distance from the token, which is actually a bit obnoxious as it means when you change bright radius, you must also update dim radius.  Oh well...

So I don't see a light radius associated with the UDL - how will that work with Beacon Lanterns if they expect all light to be 360 degrees around the token?  Granted that Beacon lanterns were the only real issue, ever (Except in a recent thing I did with a Lighthouse and Auto-Rotate API), in needing less than 360 degrees of light, but that was their entire function...

That's on their list of things to fix, along with many others.  I should go re-read that list...

My eventually seems to be today (in regards to fixing up the Macro)

I'm experimenting again with it ...

Any 'normal' vision seems to be best to setup under Nightvision.  They only have one range with that though, so it is all or nothing; no limits, no color tint, nothin like that.  So blazing sunshine or bust where u can see.

So - here's what I'm thinkin there:
Human and others with no darkvision: 5 feet.  Even in the dark, you can register enough ambient light to see a bit from you if you focus.
Darkvision: It's limit, most is 60, drow get 120, etc.

As far as light sources, thats where you get the emit light dim & bright.

So this is what I came up with for now - probably needs more testing first ....

/w gm &{template:5e-shaped}{{title=Adjusting vision for **@{selected|token_name}**}}{{subheader=to token-mod's parameters of:}}{{text_big=?{Vision|Torch, light_radius#40 light_dimradius#20 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#20 low_light_distance#20 has_bright_light_vision#yes has_low_light_vision#yes emits_bright_light#yes emits_low_light#yes has_night_vision#no|Light Cantrip, light_radius#40 light_dimradius#20 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#20 low_light_distance#20 has_bright_light_vision#yes has_low_light_vision#yes emits_bright_light#yes emits_low_light#yes has_night_vision#no|Hooded Lantern, light_radius#60 light_dimradius#30 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#30 low_light_distance#30 has_bright_light_vision#yes has_low_light_vision#yes emits_bright_light#yes emits_low_light#yes has_night_vision#no|Bullseye Lantern (No UDL), light_radius#120 light_dimradius#60 light_angle#60 light_hassight#yes light_otherplayers#yes has_bright_light_vision#no|Lamp, light_radius#30 light_dimradius#15 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#15 low_light_distance#15 has_bright_light_vision#yes has_low_light_vision#yes emits_bright_light#yes emits_low_light#yes has_night_vision#no|Candle, light_radius#5 light_dimradius#=0 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#5 has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#yes emits_low_light#no has_night_vision#no|Darkvision (Std 60'), light_radius#60 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no  has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#no emits_low_light#no has_night_vision#yes night_vision_distance#60|Darkvision (90'), light_radius#90 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#no emits_low_light#no has_night_vision#yes night_vision_distance#90|Darkvision (Drow 120'), light_radius#120 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#no emits_low_light#no has_night_vision#yes night_vision_distance#120|Warlock Devil's Sight, light_radius#120 light_dimradius#=120 light_hassight#yes light_angle#360 light_otherplayers#no bright_light_distance#20 low_light_distance#20 has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#no emits_low_light#no has_night_vision#yes night_vision_distance#120|No light source(Dusk - No UDL), light_radius#120 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no bright_light_distance#20 low_light_distance#20 has_bright_light_vision#no|Fog (No UDL), light_radius#200 light_dimradius#=5 light_hassight#yes light_angle#360 light_otherplayers#no has_bright_light_vision#no|No light source (Human-Like Vision), light_radius#10 light_dimradius#=-5 light_hassight#yes light_angle#360 light_otherplayers#no has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#no emits_low_light#no has_night_vision#yes night_vision_distance#5|Blinded, light_hassight#no light_angle#360 light_otherplayers#no statusmarkers#+bleeding-eye has_bright_light_vision#no has_low_light_vision#no emits_bright_light#no emits_low_light#no has_night_vision#no|Flametongue Weapon, light_radius#40 light_dimradius#40 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#40 has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#yes emits_low_light#no has_night_vision#no|Sun Blade, light_radius#30 light_dimradius#30 light_hassight#yes light_angle#360 light_otherplayers#yes bright_light_distance#30 has_bright_light_vision#yes has_low_light_vision#no emits_bright_light#yes emits_low_light#no has_night_vision#no} }}
!token-mod --set ?{Vision}

There were some limits where I just turned off UDL. 
Macro does it from DL & UDL - so it only depends on the current map setting.
Setting for torch ,Output (Shaped 5e):

The Macro works - but I will note during the experimentation, the interact between a cast light source (Lantern) and Vision (Darkvision) is very strange ...

It presents itself as a cancelling corona of light against the Darkvision ...

GM view - note the black rainbow

Human with Torch View is fine (Using CTRL+L)

Drow view (Using CTRL+L) .... kinda weird .... there is a gray rainbow where light should not be broken (the rest of the gray is GM viewing area, I hope)

Yup.  Those are some of the know issues in the bug thread.  Might help them to post this over there.

The Aaron said:

Yup.  Those are some of the know issues in the bug thread.  Might help them to post this over there.

Ih ... time for me to head to bed ... but if anyone wants to use the macro - I experimented with it, it should work for them until it's all good behind the scenes and I revisit it.

Thanks, as always, for TokenMod Scriptomancer!

Is there one place where all the newer Tokenmod commands and features are documented? I'm trying to figure out what commands the --report options accepts besides --all, but it doesn't appear in the one-click documentation, or in github, from what I can see.

The help is always the most up-to-date source for information:

!token-mod --help

Updating the help for 1-click is not yet automated in my deploy system, which means I forget to do it—Sorry!

Here's the post where I explained the --report features: https://app.roll20.net/forum/post/4225825/script-update-tokenmod-an-interface-to-adjusting-properties-of-a-token-from-a-macro-or-the-chat-area/?pageforid=7759266#post-7759266

It has some examples.  And if you run across anything confusing, let me know, it's still experimental and I'm looking to refine it based on user input.

Arg, thanks Aaron, totally failed to see the --help option! :D

No worries!

Aaron, I'm wondering how one could remove the minus sign that appears when I use the change option for bar1 in a damage macro. It's not a huge deal, but it's kind of ugly IMO to see "Character X takes -5 damage." 

Ah, that's a great idea.  If you add this after line 2727:

                    case 'abschange':
                        return Math.abs((parseFloat(ctx.token.get(prop))||0) - (parseFloat(ctx.prev[prop]||0)));

--report all|"{name} takes {bar1_value:abschange} points of damage."

to show just the absolute value of the change.  I'll roll this out in the next version.

Many thanks, Aaron!

Update v0.8.52 - Many fixes and enhancements for imgsrc, fix for currentSide in reporting (Thanks KC .  (Seriously, they did an outstanding job of testing these and finding edge cases!))

I'll summarize the changes here, but see the help below for full details and examples.

• Appending images with + now lets you insert them at a given location using @<dst>.
• You can reorder images using / by specifying <src>@<dst>
• You can replace images using ^ with @<dst>
• Everything works more consistently and edge cases (appending to a single image token, etc) all work sanely.
• using {currentSide} in a report string both works and reports the correct human readable number.

Here is the relevant section of the help:

Image