[D&D5E] Mimicking the "Enter" command as opposed to "NEWLINE" for attributes

Hello. As this relates more for the contents of an Attribute more than the functionality of the APIs, I figure it would be best to post this her rather than in API's I want to make a set of attributes that run a string of commands at a time. I'll give an example attribute of what I am doing: <Attrib>    <Min val>                     <Max val> @defer     @{<character>|defer           @{<character>| @DTD        @{defer|max}DTD@{DTD|max}}    <1 or 0> @DTD0 @DTD1       !token-mod --set currentside#1 --ids @{<character>|character_id} %NEWLINE%!setattr --charid @{character_id} --silent --DT||0 Using the Defer trick I was taught, I am trying to have a setup where if @{DTD|max} is 1, anything running @{DTD} will result in the value written in @{DTD1}. In essence, a Token-mod command as well as a SetChatAttr one. my issue is that the SetChatAttr command doesn't run I believe because it isn't counting it as a true new line, but more of a shift-enter sort of line. Putting them into an Ability Macro and separating them with ENTER, they both work as intended. My question is, is there a way that I can get the same effect of a full ENTER within an Attribute value rather than using %NEWLINE%?

Try replacing %NEWLINE% with  

Jarren said: Try replacing %NEWLINE% with  
 Hm, I gave this a shot, but unfortuantely it did not work. I had the same result as I do with %NEWLINE% (Attempting with a new one called %DTA with the contents "@{DTA1}" @DTA1       !token-mod --set currentside#2 --ids @{<character>|character_id} 
!setattr --charid @{character_id} --silent --dt||1 I tried without the space after the token command, same effect. Unfortunately it seems as though as of so far, it can not be done.

Could be wrong, but I think you're having a problem because your command is in an attribute. The good news is you can use the same prefix truck with abilities. If what you build up to is %{DTD1} instead of @{DTD1}, you should be able to do what you want--though you may want to use ZeroFrame batching. I'm not at my computer right now, but if want to go this route and need help sorting it out, post back and I'll try to help.

I am all for tips and tricks. I actually just moments ago learned from Keithcurtis and Jordan C (from a 4yo post) that you can make an attribute button in an ability macro by doing [button name](!
@{<character>|attribute}). That too came in greatly helpful I'd be up for learning about your idea

Not sure if this violates your request that it be an *attribute* value... or if that request was just because you thought that using an attribute was the only way to do a deferral like this... but, in any case, I just tested this and it works, so use it if it will suffice. You probably have a ton us reasons to use/keep your @{defer} attribute on the character, so instead of changing that one, let's create another called @{abil_defer} Construct it the same way, except use the % sign instead of the @ symbol... <Attrib>     <Min val>                     <Max val> @abil_defer     %{<character>|defer           %{<character>| Then change @{DTD0} and @{DTD1} to be abilities instead of attributes... so instead of constructing @{DTD0} ...or... @{DTD1} ...you are instead constructing %{DTD0} ...or... %{DTD1} In DTD1, put both commands on their own line (at a minimum): !token-mod --set currentside#1 --ids @{<character>|character_id} !setattr --charid @{character_id} --silent --DT||0 This will work. ... "...but if you leave the camera rolling..." ... I would suggest you use ZeroFrame batching, here to avoid the dropped line bug (where one command might fire, but the other gets dropped by Roll20). I would just install the full Metascript Toolbox to get ZeroFrame. Then you can construct your DTD1 ability to look more like this: !{{   !token-mod --set currentside#1 --ids @{<character>|character_id}   !setattr --charid @{character_id} --silent --DT||0 }} (spaces at the start of the lines are optional, but I find it easier to read). That will get you around the dropped line bug. ... "...but if you leave the camera rolling..." ... You could bypass the need for the deferral completely if you used a logical IF statement from the Metascript Toolbox: !{{   {&if @{<character>|DTD|max} = 1}     !token-mod --set currentside#1 --ids @{<character>|character_id}     !setattr --charid @{character_id} --silent --DT||0   {&end} }} That use the "max" value of the DTD attribute, the way you had it set up previously. However, if you go the route of using the conditional rather than the deferral process, you wouldn't need to devote the "current" value of the DTD attribute to the deferral process. You could simply store the 0 or 1 that you need to drive the conditional evaluation in the "current" value, and drop the "max" from the above command line. Hopefully that all makes sense. Post back if anything is less than clear.

That is pretty interesting, I may consider using this in some way. At least for things like the example macros. I do admit, I don't think I fully get the very last bit with not needing to devout the current value, can you elaborate more on that? Also, if you could, can you share an example of a calling? Where the macro is called and checked for its condition? ie the exampled "@{DTD} - @{defer|max}DTD@{DTD|max}} - <1 or 0>" where if anything calls "@{DTD}" it'd check for the condition of if DTD|Max is 0 or 1, but using abil_defer instead? I also remember experiencing that bug when attempting any more than 2 !ammo commands at the same time, it did not like that (it's what had me swap to ChatSetAttr as it could change several attributes at once flawlessly), fortunately I have not experienced dropped commands from mixing tokenmod and setattr, not yet anyhow. I am used to using Abilities for values and conditions like how much damage something does (attribute being an inline value, say "@{WeapA-Base Damage} - [[5+this possible modifier+that possible modifier+etc]], then in @{WeapA-DMG} - [[@{WeapA-Base Damage}d8+etc]], then in the weapon ability macro %{WeapA-Dmg} - &{template:dmg} ... {{dmg1=@{WeapA-DMG}}} .. etc", since that way it's much easier to modify the value of the damage cause it's in attributes and I don't have to sift through like, 400 ability macros lol. Attributes for Values, Abilities for Weapon Attacks/DMG and special things. It's what I'm used to anyhow, so this could be tried and added. Regarding Metascript, that'd be up to the DM as I don't know how much of the campaign there is necessarily left , and adding API's apparently runs the risk of breaking things apart especially if done mid-campaign rather than at the beginning. Though I am not opposed to the idea of giving it a shot in a test campaign perhaps in prep for a new one. I appreciate the insight and interesting tips

.█████╗ ██╔══██╗ said: I do admit, I don't think I fully get the very last bit with not needing to devout the current value, can you elaborate more on that?   Sure... So, the aim of you're whole process (as it seems to me) is to have a single thing* that you click/run, and then the deferral process builds a pseudo-conditional for you: if there's a 0 in the attribute value, it runs nothing; if there's a 1, it runs the TM/CSA combo command. *single thing ... meaning, "ONE thing spawns a different thing that could be one-of-many-options". I understand that you might want to get an one of the options from many different locations at different times during the game... but I am simply referring to each of those being a discrete "go to this place" to determine what (if anything) should run. If you look at the final example, I use the logical construction of an IF statement, and the conditional checks for a given value. That means that this ability is a self-contained solution; you don't need to perform any deferrals to arrive at this ability. Instead of running whatever-starting-point attribute retrieval (like @{DTD} ) you could instead just have this ability saved as "DTD" and run it instead: %{DTD} That would mean -- at least for the problem described specifically in this thread -- that you wouldn't need all of the deferral syntax in the "current" value of @{DTD}... we're no longer referencing it. We're directly looking at the value where you will store the 1 or the 0. You had that in your "max" value of @{DTD}, so that's where I started. But, since we're no longer (in this scenario) using the deferral stuff that's in the "current" value of that attribute, you could just as easily define the "current" value to be the place where you'd store the 1 or 0. .█████╗ ██╔══██╗  said: Also, if you could, can you share an example of a calling? Where the macro is called and checked for its condition? ie the exampled "@{DTD} - @{defer|max}DTD@{DTD|max}} - <1 or 0>" where if anything calls "@{DTD}" it'd check for the condition of if DTD|Max is 0 or 1, but using abil_defer instead? If you mean how to call the version that stopped short of using the Metascript Toolbox (or which only used the batching, but not the conditional), then the calling would be exactly the same... although I did miss the fact that you would want to substitute in @{abil_defer} for where you have @{defer} in the DTD attribute: <Attrib>    <Min val>                     <Max val> @DTD        @{abil_defer|max}DTD@{DTD|max}}    <1 or 0> Currently, you call @{DTD}, and the current value accessing your deferral language, as well as the "max" value to know which command to run. That wouldn't change (if the only change you made was to go to an ability for DTD1 and DTD0, instead of attributes for them). Your only change would be to the syntax of the @{abil_defer} attribute, as well as the @{DTD} attribute, both as noted above. If that's not clear, I'll mock it up with screenshots... but hopefully that does it.

For now this most likely will use pre-metascript stuff only due to concerns with adding new API's to late-game campaigns. So an example use of this method could be something like this? (I have taken to calling abil_defer "befer", for 'bility defer ) <Attrib>     <Min val>                     <Max val> @befer %{<character>|befer           %{<character>| @DTD    @{befer|max}DTD@{DTD|max}}    <1 or 0> <Abil> %DTD0: %DTD1: !token-mod --set currentside#1 --ids @{<character>|character_id} !setattr --charid @{character_id} --silent --DT||0 So I wouldn't require a "%DTD" unless I instead wanted to perhaps write it as: %DTD @{befer|max}DTD@{DTD}} in which I could technically place the value in @{DTD}s current and not need the max? Though that also means I can just put "@{DTD}" in %DTD and let it run as it does in the @DTD example It seems that for a 2-value setup (where the val = 0 or 1), a setup of 1 attribute (@{DTD}) and 2 abilities (%{DTD1} & %{DTD2}) is used. Plus whatever ability/attribute calls for @DTD. And this way, I can string things that would require multiple commands without them being affected by whatever an attribute does to prevent newlines from working as they should for api commands