The Aaron said:
You have a trailing } on all your entries. Try this:
D'oh! I knew it had to be something simple. Many thanks for the extra set of eyes!
The Aaron said:
You have a trailing } on all your entries. Try this:
D'oh! I knew it had to be something simple. Many thanks for the extra set of eyes!
Hey, I'm having some difficulty. I recently changed up my macros and now things aren't working like they used to. I'm trying to set the Guidance condition on the target of the macro, while simultaneously setting the Concentration status on the caster. It's currently adding the Guidance status just fine, but Concentration isn't being added. Here's my code:
!token-mod --ids @{target|target 1|token_id} --set statusmarkers|Guidance
!token-mod --ids @{selected|token_id} --set statusmarkers|Concentration
Any suggestions?
Hi Sasha,
Just number your 2 Token-Mod lines diffrently and it should work !
!token-mod*1 --ids @{target|target 1|token_id} --set statusmarkers|Guidance
!token-mod*2 --ids @{selected|token_id} --set statusmarkers|Concentration
I have no idea what that *1 and *2 are intended to do, does that actually work?
I would make sure that's it's Guidance and not guidance, and Concentration and not concentration. The Status Markers are case sensitive.
They're definitely capitalized. It works fine sometimes (completely random, or at least I can't figure out any kind of pattern). It also works if I make it all one !token-mod string, except that it puts both Guidance and Concentration on both tokens.
I can also confirm that *1/*2 do nothing (except break the macro...).
Hello...I was playing around with TokenMod's ability to modify bar values on a token. I have noticed some inconsistent behavior when using "target" vs. "selected" when the operation on the bar value results in a negative number.
Specifically, this always seems to work correctly:
!token-mod --set bar3_value|=[[@{selected|bar3} + ?{Damage}]]
While this does one of two things: It either does nothing, i.e. the value on the bar does not change at all OR it displays an incorrect result:
!token-mod --set bar3_value|=[[@{target|bar3} + ?{Damage}]]
When I remove the "!", the math appears to operate correctly by what is showing in chat.
Am I doing something incorrectly or is this a bug ?Hi
I'm having an issue with TokenMod too, I can't seem to get a custom status marker to show up.
I've made a macro for one of my players so that he can use his action to transfer his vision to his familiar and thus take away his own. The first half works perfectly but I wanted to toggle a 'blinded' status marker on the player token to remind everyone else that he can't see anything.
here's the macro I'm using:
[Toggle](!token-mod --flip light_hassight --ids -M9IOH9fhvMQpm45jItr -M9ILc9vZ_izE_wlI4MT !token-mod --set statusmarkers|!Blinded::1731177 --id -M9ILc9vZ_izE_wlI4MT)
and here's what my token mod 'help' page looks like:
I've tried using Blinded[Blinded::1731177], [Blinded::1731177] and Blinded::1731177 in the macro, but it just doesn't seem to want to work.
Any help you could offer would be greatly appreciated, thanks in advance!
~Darkora
EDIT: Fixed it! I needed to use --ids instead of --id.
Consecrated said:
Hello...I was playing around with TokenMod's ability to modify bar values on a token. I have noticed some inconsistent behavior when using "target" vs. "selected" when the operation on the bar value results in a negative number.
Specifically, this always seems to work correctly:
!token-mod --set bar3_value|=[[@{selected|bar3} + ?{Damage}]]
While this does one of two things: It either does nothing, i.e. the value on the bar does not change at all OR it displays an incorrect result:
!token-mod --set bar3_value|=[[@{target|bar3} + ?{Damage}]]
When I remove the "!", the math appears to operate correctly by what is showing in chat.
Am I doing something incorrectly or is this a bug ?
When you use @{target}, the API does not receive the selected tokens. This is an old bug I've been trying to get fixed for years. Try this:
!token-mod --set bar3_value|=[[@{target|Which|bar3} + ?{Damage}]] --ids @{target|Which|token_id}(Or use a different target if that's what you're after)
SashaTK said:
They're definitely capitalized. It works fine sometimes (completely random, or at least I can't figure out any kind of pattern). It also works if I make it all one !token-mod string, except that it puts both Guidance and Concentration on both tokens.
I can also confirm that *1/*2 do nothing (except break the macro...).
This is hard to diagnose via thought experiment, If you want to PM me an invite and GM me, I can come try and figure it out directly in your game.
SashaTK said:
Hey, I'm having some difficulty. I recently changed up my macros and now things aren't working like they used to. I'm trying to set the Guidance condition on the target of the macro, while simultaneously setting the Concentration status on the caster. It's currently adding the Guidance status just fine, but Concentration isn't being added. Here's my code:
!token-mod --ids @{target|target 1|token_id} --set statusmarkers|Guidance
!token-mod --ids @{selected|token_id} --set statusmarkers|ConcentrationAny suggestions?
I'd suggest using target syntax for both, because selection could be getting lost in the asynchronous process of running both those commands in the same chat input.
So try:
!token-mod --ids @{target|Guidance|token_id} --set statusmarkers|Guidance
!token-mod --ids @{target|Concentrating|token_id} --set statusmarkers|Concentration
Or something along those lines.
Worth a try. The API doesn't get msg.selected if @{target} is used, but @{selected} should be fine even in a multi-line message.
Ok, so I did some experimentation, and it appears that whichever string is first is the one that triggers. So if I put the @{selected} trigger for Concentration first, then it will put Concentration on the caster, but if I put it second, it instead adds Guidance to the @{target}. It still asks me for the target regardless of the order, but it will only execute the command that is on top.
@Sasha - you may wish to use either Victor (Newer) or Robin's (Older) Concentration API for the concentration portions of any spell that uses concentration, then use your @{target} for Guidance itself.
Also, Victor is working on Combat Master, which may be everything you need, and with a little creative programming may accomplish everything you're trying to do here in one click.
SashaTK,
I have a number of macros that use token mod exactly as you originally had it and never have an issue with both (the selected/caster and the target) conditions firing. What might be different is that I generally am calling token-mod from PowerCards. I know from the PowerCard thread that you use PowerCards, so you might try calling token-mod from a PowerCard. Here is my guidance macro:
!power {{
--emote|@{selected|token_name} gives a blessing to @{target|token_name}
--tokenid|@{selected|token_id}
--format|Spells
--name|Guidance
--target_list|@{target|token_id}
--Description|You touch one willing creature. Once before the spell ends, the target can roll a d4 and add the number rolled to one ability check of its choice. It can roll the die before or after making the ability check. The spell then ends.
-- api_setattr|_name @{selected|character_name} _guidance_status|2 _concentration_status|1 _concentration_spell|Guidance|GU _silent
-- api_token-mod*1|_ids @{selected|token_id} _set statusmarkers|Concentrating
-- api_token-mod*2|_ids @{target|token_id} _set statusmarkers|Guidance
}}
Wolf Thunderspirit said:
@Sasha - you may wish to use either Victor (Newer) or Robin's (Older) Concentration API for the concentration portions of any spell that uses concentration, then use your @{target} for Guidance itself.
Also, Victor is working on Combat Master, which may be everything you need, and with a little creative programming may accomplish everything you're trying to do here in one click.
Seconding this post.
Update v0.8.58 -- Added --move command to script multi-step movements of tokens respecting current facing. (Thanks Cindurion)
Move
Use --move
to supply a sequence of move operations to apply to a token. By default, moves are relative to the current facing of the token as defined by the rotation handle (generally, the "up" direction when the token is unrotated). Each operation can be either a distance, or a rotation followed by a distance, separated by a pipe |
. Distances can use the unit specifiers (g
,u
,ft
,etc -- see the Numbers section for more) and may be positive or negative. Rotations can be positive or negative. They can be prefaced by a =
to ignore the current rotation of the character and instead move based on up being 0. They can further be followed by a !
to also rotate the token to the new direction.
Moving 3 grid spaces in the current facing.
Moving 3 grid spaces at 45 degrees to the current facing.
Moving 2 units to the right, ignoring the current facing.
Moving 10ft in the direction 90 degrees to the left of the current facing, and updating the facing to that new direction.
Moving forward 2 grid spaces, then right 10ft, then 3 units at 45 degrees to the current facing and updating to that face that direction.
Update v0.8.59 -- Added ! as an option to the end of setting bar values. Appending ! will restrict the value to the bounds of the bar (0..max). (Thanks Boz)
Setting a bar to a numeric value will be treated as a relative change if prefaced by +
, -
, *
, or /
, or will be explicitly set when prefaced with a =
. If you are setting a bar value, you can append a !
to the value to force it to be bounded between 0
and max
for the bar.
If you're applying changes to multiple selected tokens, and they have different max values, does this respect each token's values?
It does!
!token-mod --set bar1_value|+15!
Will add 15 to each selected token's bar1, but will not exceed each individual token's max value.
Is there a way to apply that limit to a formula? For example, !token-mod --set bar3_value|=[[@{target|Which|bar3} + ?{Damage}]] --ids @{target|Which|token_id}
Yup.
!token-mod --set bar3_value|=[[@{target|Which|bar3} + ?{Damage}]]! --ids @{target|Which|token_id}
That setting (which was only released 2 days ago) hasn't been exposed to the API yet. I'll definitely be adding it as soon as it is!
Yup, UDL itself is pretty new and possibly not 100% ready for prime time. Once the settings are there, I'll roll them in. =D
The Aaron said:
Update v0.8.58 -- Added --move command to script multi-step movements of tokens respecting current facing. (Thanks Cindurion)
Move
Use
--move
to supply a sequence of move operations to apply to a token. By default, moves are relative to the current facing of the token as defined by the rotation handle (generally, the "up" direction when the token is unrotated). Each operation can be either a distance, or a rotation followed by a distance, separated by a pipe|
. Distances can use the unit specifiers (g
,u
,ft
,etc -- see the Numbers section for more) and may be positive or negative. Rotations can be positive or negative. They can be prefaced by a=
to ignore the current rotation of the character and instead move based on up being 0. They can further be followed by a!
to also rotate the token to the new direction.Moving 3 grid spaces in the current facing.
!token-mod --move 3gMoving 3 grid spaces at 45 degrees to the current facing.
!token-mod --move 45|3gMoving 2 units to the right, ignoring the current facing.
!token-mod --move 90|2uMoving 10ft in the direction 90 degrees to the left of the current facing, and updating the facing to that new direction.
!token-mod --move -90!|10ftMoving forward 2 grid spaces, then right 10ft, then 3 units at 45 degrees to the current facing and updating to that face that direction.
!token-mod --move 2g 90|10ft =45!|3u
This update is now in the 1-click!
Hello everyone,
I'm having a couple small issues with my macro and I was hoping someone here could help me with.
!token-mod {{ ?{Vision|Torch, --on has_bright_light_vision emits_bright_light emits_low_light --set bright_light_distance#20 low_light_distance#20 tint_color# |Hooded Lantern, --on has_bright_light_vision emits_bright_light emits_low_light --set bright_light_distance#30 low_light_distance#30 |Bullseye Lantern, --on has_bright_light_vision emits_bright_light emits_low_light --set bright_light_distance#60 low_light_distance#60 |Lamp, --on has_bright_light_vision emits_bright_light emits_low_light --set bright_light_distance#15 low_light_distance#15 |Candle, --on has_bright_light_vision emits_bright_light --off emits_low_light --set bright_light_distance#5 |Darkvision, --on has_bright_light_vision emits_bright_light emits_low_light has_night_vision --set bright_light_distance#0 low_light_distance#0 night_vision_distance#60 |Superior Darkvision, --on has_bright_light_vision emits_bright_light emits_low_light has_night_vision --set bright_light_distance#0 low_light_distance#0 night_vision_distance#120 |No Light Source, --off has_bright_light_vision emits_bright_light emits_low_light has_night_vision |Blinded, --off has_bright_light_vision emits_bright_light emits_low_light has_night_vision } }}
So now for my issues:
1. With the bullseye lantern, how do I set the angle of the light to a 60ft cone?
2. With the Blinded option, my players can still see other light source, how can I prevent this?
Not sure if this is something I am doing wrong or missed in the documentation, or it might be something that TokenMod cannot fix.
I am trying to create a chat menu with buttons that use TokenMod to add status markers with numbers. When I use the colon TokenMod uses for this, the chat menu link does not work.
For example, this works:
&{template:default} {{Frightened = [ON](!token-mod --set statusmarkers|!screaming)}}
But this does not:
&{template:default} {{Frightened = [ON](!token-mod --set statusmarkers|!screaming:2)}}
I also tried encoding the colon using : but that does not work either.
&{template:default} {{Frightened = [ON](!token-mod --set statusmarkers|!screaming:2)}}
Is there something I missed? Any ideas? Thanks in advance for any help
Hmm. I think the only way to solve this is by having a character with abilities that are the TokenMod actions and call the abilities from the menu buttons. The problem is the chat parser just looks for a colon to signify a URL, so you can't have it there directly.
Having one issue and a few questions. I am trying to tweak NPC monster tokens from an adventure that was purchased to how I like to view them. And changing hundreds of tokens doesn't sound fun. This is what I came up with.
!token-mod {{ --ids @{selected|token_id} --off showname --set bar3_link|passive_wisdom --on showplayers_bar1 --set bar_location|bottom overlapping --set bar_style|compact }}
The first four commands work fine, except for linking passive_wisdom. The drop down box gets changed, but it doesn't fill the value. The character sheet is linked to the token. Did I miss something? <Image 1 below>
The last two commands I made up. I did not see anything about them in the help file. Did I miss them or could this be an upcoming feature? <Image 2 below>
Thanks for the advice!!!
Those last two settings have never been exposed to the API by the dev team.
Also, any reason why you are bothering with --ids? Without it, you could select and manage groups of tokens with one command.
When I link passive_wisdom on a token I've pulled in from the compendium, I get the updated passive_wisdom value in the bar as well as linking it. If you do @{selected|passive_wisdom} in the chat, do you get a value?
Update v0.8.60 -- Added new Updated Dynamic Lighting settings for Vision limits and directions, Emitted light limit and direction, and night vision coloring.
Night vision tint uses the field night_vision_tint:
!token-mod --set night_vision_tint|#ff0000
It uses the standard color options from the help that you'd use for aura and tint colors.
Directional Light has three settings:
Setting the light to come out of the right of the token (90º) in a 60º arc ( +/- 30º from 90, from 60º to 120º):
!token-mod {{ --on has_directional_bright_light --set directional_bright_light_center|90 directional_bright_light_total|60 }}
For vision, there are 6 settings that mirror the above for regular and night vision (But see the important caveat below!):
Important Caveat: The user interface for tokens only has 3 settings for the above, an on-off that sets both the limits on or off, a center that sets both centers, and a total that sets both totals. For full compatibility, you'll want to set each of these in pairs. For the moment, I have left them separate because you can do some neat (and bizarre) things with them set separately. It doesn't completely work, but I want to see what people can do with it and maybe we can make a compelling argument for it working as we'd expect (or maybe a future update will see some neat enhancements). Note that saving changes on the Token GUI will force the pairs to be identical.
Setting vision limits like the GUI:
!token-mod {{ --on has_limit_field_of_vision has_limit_field_of_night_vision --set limit_field_of_vision_center|90 limit_field_of_night_vision_center|90 limit_field_of_vision_total|60 limit_field_of_night_vision_total|60 }}
keithcurtis said:
Those last two settings have never been exposed to the API by the dev team.
Also, any reason why you are bothering with --ids? Without it, you could select and manage groups of tokens with one command.
Bummer, give us all the toys!
--ids was there because I though I had to. I will be dropping it promptly. Thanks.
The Aaron said:
When I link passive_wisdom on a token I've pulled in from the compendium, I get the updated passive_wisdom value in the bar as well as linking it. If you do @{selected|passive_wisdom} in the chat, do you get a value?
I do get a value, but it is incorrect. Also, the npc isn't from the compendium. The adventure is an add on and has the monsters in the journal. Would that screw it up?
Hmm... If it's the OGL 5e Sheet, it looks like it doesn't have Passive Wisdom set up for NPCs. You could calculate it, but you'd need to do all the like NPCs together to get the right value:
!token-mod {{ --off showname --on showplayers_bar1 --set bar3_value|[[10+@{target|npc_perception}]] --ids @{target|token_id} }}
The Aaron said:
Hmm... If it's the OGL 5e Sheet, it looks like it doesn't have Passive Wisdom set up for NPCs. You could calculate it, but you'd need to do all the like NPCs together to get the right value:
!token-mod {{ --off showname --on showplayers_bar1 --set bar3_value|[[10+@{target|npc_perception}]] --ids @{target|token_id} }}
It is the OGL 5e Sheet. That's weird it doesn't work, I swear it has before “¯\_(ツ)_/¯“. Thanks for the assist though.
Before I hit Submit Post, I opened a game and made a quick NPC and linked the passive_wisdom in the drop down box myself and it worked. Is there something screwy with the pre-made adventure NPCs you think?
Edit: It wasn't the passive perception it was reading, but only the wisdom. By changing the Perception score, the passive was not effected. Only changing the Wisdom altered the score. I better check I didn't mess up other NPCs.
I've been experiencing a weird if only mildly irritating behavior with Tokenmod pertaining to the location of Bar1. The token defaults for my campaign are set to "bottom overlapping". When I drag monsters out of the Compendium onto a map, they all come in with bottom-overlapping bars. However, as soon as I run the macro below on a token, the default token bar location changes to "above." So for every monster I add to my game, I have to reset the default token bar location to "bottom overlapping" after setting it up with the macro below. I'm sure I'm missing something obvious, but I don't see how the macro should affect bar location, on the face of it. What am I missing?
!token-mod {{ --on showname light_hassight --set name|"@{selected|character_name} %%NUMBERED%%" aura2_color|#980000 defaulttoken }}
Yeah, that is annoying. That's because the setDefaultTokenForCharacter() function provided by Roll20 for setting the default token does not know about or respect the token bar locations. We've been asking for that and the ability to set them pretty much since it came out. It's still on the back list, so hopefully we'll get it soon. Until that point, you'll just have to set the default token manually if you have custom bar positions.
The Aaron said:
Yeah, that is annoying. That's because the setDefaultTokenForCharacter() function provided by Roll20 for setting the default token does not know about or respect the token bar locations. We've been asking for that and the ability to set them pretty much since it came out. It's still on the back list, so hopefully we'll get it soon. Until that point, you'll just have to set the default token manually if you have custom bar positions.
Oh, good to know I'm not crazy (on this issue, anyway)! Thanks for the explanation, Aaron.
Is there anyway for Token-Mod to affect ALL NPC tokens in the game? Basically right now I'm using Bar 2 for npc_ac but I want to switch it to Bar 3. It wouldn't be a big deal to switch PC tokens as well if the only option was to affect all tokens that are tied to a character sheet. But I'd rather not have it affect ALL tokens (such as the invisible ones that I use for doors and things).
Looking at the Apply Default Settings experimental button, I don't see the Bar Links as options, and it also warns that it will affect all tokens (including ones that I don't want to affect, like doors.)
And now that I'm thinking about it... I'll probably want it to update all the default tokens for character sheets so they'll be updated when I pull them from the journal tab.
There's not a way to do that in TokenMod short of specifying each NPC character ID on the command line. However, I think I have a script snippet that can do that for you. I'll take a look...
Ok. Here's a script that will fix this, with a few caveats:
If any of that doesn't sound right, let me know. I highly recommend copying your game and running this on the copy first.
on('ready',()=>{ const fixChar = (npc) => findObjs({type:'graphic',represents:npc.id}) .forEach( (t,i)=>{ t.set({ bar3_link: t.get('bar2_link'), bar3_value: t.get('bar2_value'), bar3_max: t.get('bar2_max'), bar2_link: t.get('bar3_link'), bar2_value: t.get('bar3_value'), bar2_max: t.get('bar3_max') }); if(0===i){ setDefaultTokenForCharacter(npc,t); } }); on('chat:message', (msg) => { if('api' === msg.type && playerIsGM(msg.playerid) && /^!fix-npcs(\b\s|$)/i.test(msg.content)){ let who = (getObj('player',msg.playerid)||{get:()=>'API'}).get('_displayname'); let npcs = (findObjs({ type: "attribute", name: "npc", current: "1" })||[]); sendChat('',`/w "${who}" Fixing ${npcs.length} NPCs.`); const burndown = ()=>{ if(npcs.length){ let npc = npcs.shift(); fixChar(npc); setTimeout(burndown,0); } else { sendChat('',`/w "${who}" Finished updating NPCs.`); } }; burndown(); } }); });
!fix-npcs