[Script Update] ChatSetAttr 1.8 – now with inline command support

I was motivated to give ChatSetAttr a bit of an update, adding one new feature: inline commands within roll templates. This means that the following will do what you would expect:

&{template:default} {{name=Cthulhu}} !modattr --charid @{target|character_id} --sanity|-{{Sanity damage=[[2d10+2]]}}!!! {{desc=Cthulhu makes you insane.}}

Note the three exclamation marks after sanity damage ends; this is what tells ChatSetAttr to disregard everything coming after that. Due to the way roll templates work, the ChatSetAttr command will not be visible, but the script will pick it up and convert the "Sanity damage=[[2d10+2]]}}" part to the corresponding dice roll.

The parsing for this is probably still buggy, so I'm happy about any bug reports before I make this live.

Script: code – README.

Wow, that's awesome Jakob.

Woaw, you're amazing ! 

This just solved my healing/damage dealing issue :O

Vince said:

Nice addition. I wonder if other script authors will follow suit?  

It's certainly a nice alternative to needing to get to grips with powercards in order to handle some of the more complex use cases isn't it.

Scott C. said:

Vince said:

Nice addition. I wonder if other script authors will follow suit?  

It's certainly a nice alternative to needing to get to grips with powercards in order to handle some of the more complex use cases isn't it.

That's why I made it. "I want to react to rolls in my roll template" is a pretty common request, but it's actually quite nontrivial to do without a custom script. For "simple" logic, I thought that this would be a good alternative. I'm still tinkering with the performance, since I don't want this to parse every single chat message with a complicated regular expression.

I changed the way chat messages are parsed, making it much simpler and hopefully more bug-free. The syntax has now changed; you need to explicitly end the ChatSetAttr part of the message with three exclamation marks (which means that the script no longer has to guess where it's supposed to end).

Hi Jakob, I'm hoping you can help me here: I'm trying to use chatsetattr to decrement my Warlock's spell slots when they cast a spell. Basically I created a class_resource to track the slots and I want to embed the following command in the description of all their spells:

!modbattr --set --charid @{character_id} --class_resource|-1!!!

It almost works, as it calls the command, but it gives the following output:

First, leave out the --set, it's not actually a valid option, so it tries to modify the set attribute, which fails, since there are no numbers involved. 

Also, don't escape the vertical bar, just write it like is: |. That should take care of the trouble with the actual setting.

!modbattr --charid @{character_id} --class_resource|-1!!!

Jakob said:

First, leave out the --set, it's not actually a valid option, so it tries to modify the set attribute, which fails, since there are no numbers involved. 

Also, don't escape the vertical bar, just write it like is: |. That should take care of the trouble with the actual setting.

!modbattr --charid @{character_id} --class_resource|-1!!!

So what you're saying is I failed to comprehend a basic element of the script then over-engineered another! Argh this is what happens when you stay up late trying to get macros and automation setup before game day... I will try out your suggestion Jakob, thanks!

edit: It works! Thank you so much!

One last question, and you can tell me to pound sand on this, is there a way to hide/suppress the command inside the description (bolded for clarity)? (Also: I will throw --silent onto the chatsetattr command to suppress its output to chat): 

Evan said:

Jakob said:

First, leave out the --set, it's not actually a valid option, so it tries to modify the set attribute, which fails, since there are no numbers involved. 

Also, don't escape the vertical bar, just write it like is: |. That should take care of the trouble with the actual setting.

!modbattr --charid @{character_id} --class_resource|-1!!!

So what you're saying is I failed to comprehend a basic element of the script then over-engineered another! Argh this is what happens when you stay up late trying to get macros and automation setup before game day... I will try out your suggestion Jakob, thanks!

edit: It works! Thank you so much!

One last question, and you can tell me to pound sand on this, is there a way to hide/suppress the command inside the description (bolded for clarity)? (Also: I will throw --silent onto the chatsetattr command to suppress its output to chat): 

Haha, don't worry :) Glad it works now. You can certainly suppress the command if it's in a custom macro/ability. (just dump it into the macro text on a new line). The following (in the description field) may also work (it needs to be at the end of the description). No promises though:

}} !modbattr --silent --charid @{character_id} --class_resource|-1!!! {{=

I am using the OneClick ChatSetAttr and I have useWorkers enabled, but my sheetworkers do not get triggered. I can see that the value is updated in the sheet, but dependent attributes do not change. If I manually change the value in the sheet, the workers trigger and work as expected.

What kind of things can make ChatSetAttr not trigger sheetworkers? I am using a custom character sheet, and while I am not asking you to troubleshoot my code, I don't think I am doing anything too egregiously wrong.

As an example, I add some coins to a character, and I see the coin value change on the sheet, but the coin_weight attribute does not update.

ChatSetAttr command

!modattr --fb-public --sel --gold_carried|50

HTML

<span class="tablecell w055">
    <input type="text" class="inputbox w051" name="attr_gold_carried" title="gold_carried" maxlength="5" value="0">
</span>

<span class="tablecell w094">
    <input type="text" class="inputbox w072 readonly" name="attr_coin_weight" title="coin_weight" value="0" readonly>
</span>

Sheetworker Code

on("sheet:opened change:copper_carried change:silver_carried change:gold_carried change:platinum_carried", function() {
    var coins = 0;
    getAttrs(["copper_carried", "silver_carried", "gold_carried", "platinum_carried"], function(values) {
        let cp = parseInt(values["copper_carried"],10) || 0;
        let sp = parseInt(values["silver_carried"],10) || 0;
        let gp = parseInt(values["gold_carried"],10) || 0;
        let pp = parseInt(values["platinum_carried"],10) || 0;
        coins = (coins + ((cp + sp + gp + pp) / 50)).toFixed(2);
        setAttrs({
            coin_weight: coins
        });
    });
});

I do have many other sheetworkers, but the above is the only one related to the gold_carried attribute. Any suggestions for things to look for in the console? Thanks for any advice!

Weird. I know that eventInfo.newValue and previousValue have problems in the API, but your code doesn't use them and otherwise seems simple enough. If it changes the value, this is probably a problem with Roll20's useWithWorker method, not with ChatSetAttr, which simply calls this method, so I don't know how much I can do :).

Try inserting a log statement at the top of the function to see if it gets triggered at all, maybe? I believe that calls to log from within api-sheetworkers show up in the API console.

Jakob said:

Evan said:

Jakob said:

First, leave out the --set, it's not actually a valid option, so it tries to modify the set attribute, which fails, since there are no numbers involved. 

Also, don't escape the vertical bar, just write it like is: |. That should take care of the trouble with the actual setting.

!modbattr --charid @{character_id} --class_resource|-1!!!

So what you're saying is I failed to comprehend a basic element of the script then over-engineered another! Argh this is what happens when you stay up late trying to get macros and automation setup before game day... I will try out your suggestion Jakob, thanks!

edit: It works! Thank you so much!

One last question, and you can tell me to pound sand on this, is there a way to hide/suppress the command inside the description (bolded for clarity)? (Also: I will throw --silent onto the chatsetattr command to suppress its output to chat): 

Haha, don't worry :) Glad it works now. You can certainly suppress the command if it's in a custom macro/ability. (just dump it into the macro text on a new line). The following (in the description field) may also work (it needs to be at the end of the description). No promises though:

}} !modbattr --silent --charid @{character_id} --class_resource|-1!!! {{=

That worked great!

I revised the command to show the chatsetattr output, but if I use

}} !modbattr --charid @{character_id} --fb-header WARLOCK SPELL SLOTS --fb-content _CUR0_ OF _MAX0_ REMAINING --class_resource|-1!!! {{=

it doesn't show the max value for the class_resource attribute. I assume I'm using that wrong? The current value shows up correctly.

I've confirmed the max value is an integer with no spaces or anything.

No, I think that's actually a bug ... it will only show the maximum if you have changed it. I need to fix this. You can probably bypass by using --class_resource|-1|0 instead.

Jakob said:

No, I think that's actually a bug ... it will only show the maximum if you have changed it. I need to fix this. You can probably bypass by using --class_resource|-1|0 instead.

OK, I'll try that thanks! I guess I misunderstood _TMAX_ vs _MAX_, I read "T" as "transactional" and assumed the other one was pulling in the sheet attribute. Actually now that I think about it, I might embed a roll template with the current state instead and keep chatsetattr silent.

Jakob said:

Try inserting a log statement at the top of the function to see if it gets triggered at all, maybe? I believe that calls to log from within api-sheetworkers show up in the API console.

Thanks for the tip, but log(); did not show up in the API console, so I put a console.log(); command in the sheetworker instead. The log entry showed in the browser console when I made the changes manually, but not when using ChatSetAttr.

I added some log(); statements to ChatSetAttr in the setAttribute() function to get the values of state.ChatSetAttr.useWorkers, attr, and value passed to the function. The value of state.ChatSetAttr.useWorkers always reports as true, but attr and value each report as equal to [object Object] - is this right? Or am I (more likely) not understanding how the script works?

To log attr and value, try (in sheet workers) console.log(JSON.stringify(attr)) and console.log(JSON.stringify(value)) or (in API) log(JSON.stringify(attr)) and log(JSON.stringify(value)).

What The Aaron said will work, but I doubt that adding logging from within ChatSetAttr will help matters. If the CSA chat message tells you that it is changing an attribute, that's what it is doing. I have no idea why that wouldn't trigger the sheet workers...

Ah, so it was my ignorance. Thanks to you both. I wanted to grab the values in CSA for the setWithWorker bug report I am preparing. Thanks again!

ChatSetAttr 1.9

• Added an observer pattern for other scripts to register at (documentation in the README). This allows other scripts to react to attribute changes performed by ChatSetAttr.
• Fixed a bug with custom feedback where _MAX${k}_ would not be displayed if only current had been changed, and vice versa.

Will this work with another API and does it support variables?

!setattr --charid|@{character_id} --silent --hit_location|[[ @{hitroll} ]]!!! !otherApi

Scott S. said:

Will this work with another API and does it support variables?

!setattr --charid|@{character_id} --silent --hit_location|[[ @{hitroll} ]]!!! !otherApi

What exactly are you trying to do here? Three exclamation are marks neither necessary nor do they do what you want them to do here --- they are only necessary for inline commands.

What do you mean by "support variables" - do you mean the @{hitroll} and the inline roll? That will work, but only within an ability - generally, inline rolls and attribute substitutions are performed by roll20 before the API ever sees the command.

What do you mean by "will this work with another API"? What do you expect the !otherAPI to do? If you just want to execute both commands in the same macro, just put the other command on a new line.

In summary, you probably want this (in an ability):

!setattr --charid|@{character_id} --silent --hit_location|[[@{hitroll}]]
!otherApi

Hoping for a little help. I have created a macro in my d&d 5e ogl campaign to run a short rest but am unable to get it to run as I wish.  Currently the macro removes hit_die and replenishes other_resource while rolling the correct hit_die for HP. The problem is that the inline roll in the CSA for --hp is added to the correct character, but the inline roll in {{r1}} displays in chat output.  Is there a way to write this so that the CSA --hp references the roll made in {{r1}}?

@{selected|wtype}&{template:simple} !modbattr --silent --name @{selected|character_name} --other_resource|%other_resource_max% --hit_dice|{{hit_dice=hit_dice decreases by [[-?{How many hit dice would you like to spend?|1}]]}} --hp|{{hp=hp increases by [[ ?{How many hit dice would you like to spend?}d@{selected|hitdie_final}+[[@{selected|constitution_mod}* ?{How many hit dice would you like to spend?}]][CON]]]}}!!! {{rname=^{hit-dice-u}}} {{mod=?{How many hit dice would you like to spend?|1}D@{selected|hitdie_final}+[[@{selected|constitution_mod}*?{How many hit dice would you like to spend?}[CON]]]}} {{r1=[[ ?{How many hit dice would you like to spend?}d@{selected|hitdie_final}+[[@{selected|constitution_mod}* ?{How many hit dice would you like to spend?}]][CON]]]}} {{normal=1}}{{charname=@{selected|character_name}}}

Can Chatsetattr change the AC setting on Roll20 OGL 5E sheet? I want to make a macro to change the AC setting on a NPC charater sheet to = the npc_ac setting.

Craven said:

Can Chatsetattr change the AC setting on Roll20 OGL 5E sheet? I want to make a macro to change the AC setting on a NPC charater sheet to = the npc_ac setting.

Yes.

!setattr <targeting options> --AC|%npc_ac%

Jakob said:

Craven said:

Can Chatsetattr change the AC setting on Roll20 OGL 5E sheet? I want to make a macro to change the AC setting on a NPC charater sheet to = the npc_ac setting.

Yes.

!setattr <targeting options> --AC|%npc_ac%

Thanks.

hi! I added a macro on my pathfinder character sheet, as shown below, to use Inspiration points from my total. It works but what's printed from my template is the value that was in the variable before the setattr incremented it. If i manually check repeating_ability_$3_used after, it's at the expected value (after being incremented). How Can i fix this ? Thanks!

!setattr --mute --charid -LSvSABcsrh7VpPq8yEs --modb --repeating_ability_$3_used|+1

@{PC-whisper} &{template:pf_generic} @{toggle_accessible_flag} @{toggle_rounded_flag} {{font=@{apply_specfont_chat}@{use_specfont}}} {{scroll_desc=@{scroll-desc}}} {{color=@{rolltemplate_color}}} {{header_image=@{header_image-pf_generic}}} {{subtitle=Using 1 inspiration point}} {{name=Inspiration}} {{character_name=@{character_name}}} {{character_id=@{character_id}}}{{Status=@{repeating_ability_$3_used}/@{repeating_ability_$3_used|max}}} {{description=+1d6 on skills check (1 pt), +1d6 Atk or Save (2 pts))}} {{Extra}}

The only thing you can do is subtracting 1 from the count when you send it to chat, but this will style it as an inline roll and may look ugly:

[[@{repeating_ability_$3_used}-1]]/@{repeating_ability_$3_used|max}

Oh that's a smart idea! thanks. May I ask why the value isn't updated yet between the calling settattr and printing the command ?

Mat said:

Oh that's a smart idea! thanks. May I ask why the value isn't updated yet between the calling settattr and printing the command ?

Two reasons: firstly, any attribute values are actually filled in when you send the chat command, so the old value is filled in before ChatSetAttr even sees the command; secondly, even if that were not the case, chat commands in the same macro are actually sent at the same time, so ChatSetAttr hasn't had a chance to change the attribute value yet.

Hi,

thanks for the awesome script! 

But it seems to work only sometimes. Especially when I have multiple instances of it in one macro. Example: I try to do health, mana and armor regeneration in one macro. I have this macro as an ability on the charactersheet:

!modattr --charid @{character_id} --LE_Wert|[[{[[{[[1d6+(-1)+(?{Annehmlichkeitsmodifikator|0})]],[[0]]}kh1]],[[{[[@{LE_Wert|max}-@{LE_Wert}]],[[0]]}kh1]]}kl1]] --fb-public --fb-from @{character_name} --fb-header LeP-Regeneration --fb-content _CHARNAME_ regeneriert _TCUR0_ Lebenspunkte und hat nun _CUR0_ von _MAX0_ Lebenspunkten.
!modattr --charid @{character_id} --AE_Wert|[[{[[{[[1d6+(-1)+1+(?{In der Heimat|nein,-1|ja,0})+?{Auf der Erde|ja,2|nein,0}+(?{Annehmlichkeitsmodifikator|0})]],[[0]]}kh1]],[[{[[@{AE_Wert|max}-@{AE_Wert}]],[[0]]}kh1]]}kl1]] --fb-public --fb-from @{character_name} --fb-header AsP-Regeneration --fb-content _CHARNAME_ regeneriert _TCUR0_ Astralpunkte und hat nun _CUR0_ von _MAX0_ Astralpunkten.
!modattr --charid @{character_id} --Semper_Fi|[[{[[2]],[[@{Semper_Fi|max}-@{Semper_Fi}]]}kl1]] --fb-public --fb-from @{character_name} --fb-header Semper-Fi-Regeneration --fb-content Alariels Pflanzenrüstung "Semper Fi" regeneriert _TCUR0_ Lebenspunkte und hat nun _CUR0_ von _MAX0_ Lebenspunkten.

When I execute it, it only sometimes does all three things. Sometimes only one, sometimes the first two of them. I cannot say, why or when this happens. Sometimes it works just fine.

There is no error or message in the Api-Log.

Any suggestions?

That's probably another incarnation of "Roll20 sometimes randomly drops API messages" which I can't do anything about. You, however, can fix it by going to one command instead:

!modattr {{
  --fb-public
  --fb-from @{character_name}
  --fb-header Regeneration
  --charid @{character_id}
  --LE_Wert|[[{[[{[[1d6+(-1)+(?{Annehmlichkeitsmodifikator|0})]],[[0]]}kh1]],[[{[[@{LE_Wert|max}-@{LE_Wert}]],[[0]]}kh1]]}kl1]]
  --AE_Wert|[[{[[{[[1d6+(-1)+1+(?{In der Heimat|nein,-1|ja,0})+?{Auf der Erde|ja,2|nein,0}+(?{Annehmlichkeitsmodifikator|0})]],[[0]]}kh1]],[[{[[@{AE_Wert|max}-@{AE_Wert}]],[[0]]}kh1]]}kl1]]
  --Semper_Fi|[[{[[2]],[[@{Semper_Fi|max}-@{Semper_Fi}]]}kl1]]
  --fb-content _CHARNAME_ regeneriert _TCUR0_ Lebenspunkte und hat nun _CUR0_ von _MAX0_ Lebenspunkten.
    _CHARNAME_ regeneriert _TCUR1_ Astralpunkte und hat nun _CUR1_ von _MAX1_ Astralpunkten.
    Alariels Pflanzenrüstung "Semper Fi" regeneriert _TCUR2_ Lebenspunkte und hat nun _CUR2_ von _MAX2_ Lebenspunkten.
}}

Thanks! Seems to work so far.

Only thing: The second _CHARNAME_ is not resolved - which is not a big problem, but thought I mention it.

Hey - Thanks again for the API, still one of the best ones in roll20!
I had a little query...

In my game, in the 'Mad Dungeon' the party are discouraged from resting too much. So I've proposed a relatively simple method to discourage it. - For every hour that the party rests, or faffs about, each player rolls a D20. On the roll of a 1 they go *slightly* more insane. - This 'sanity' score is then tracked as a character attribute. Thankfully this is all automated. It uses 'success counts' and counts a success of anything which is a roll of 1 or below. The players neither have to roll, nor do they know their own sanity level (unless they go to the effort of checking their attribute score manually).

My macro code is below.... As you can see, there are 5 characters that are effected, and when the macro runs, there is a prompt to ask me hour many hours they're resting for....

/desc The magic of the dungeon passes through the party members minds.
/emas For each character, the DM rolls a D20 for each hour spent resting in the dungeon...
!modbattr --name Amélie Lacroix --sanity|+[[{?{hours}d20!}<1]]
!modbattr --name Dust --sanity|+[[{?{hours}d20!}<1]]
!modbattr --name Hickory Homestead --sanity|+[[{?{hours}d20!}<1]]
!modbattr --name Elena Tregan --sanity|+[[{?{hours}d20!}<1]]
!modbattr --name Galaster --sanity|+[[{?{hours}d20!}<1]]

However, when I run it, only the person at the top of the list is actually effected. Its like the script stops running after line 3.

btw - If I copy and paste each line, one by one, it works fine...

Any help would be appreciated.

EDIT: Sorry it looks like the person above was basically saying the same thing! - Roll20 sometimes decides to randomly stop the API mid-flow. It looks like the solution would be 'going to one command instead' - but given that each player gets a different roll... is that still possible?

When I had the trouble, I thought about using the delay-script to give the api time to process things. I dont know if that would actually help and I didn't test it. But might be worth a shot.

Danii! - I tried the same thing! - But got super confused and gave up a few days ago.

I wanted to try this after I wanted to do a 'roll' via an API, and then view the 'result' after the roll had taken effect. - But it the result was appearing before the roll was 'actioned', even though, in the script, they were the other way around.

I may look into this again...

What about using ChatSetAttr to write {hours} to a holding attribute on some utility sheet? Then write the other commands as separate macros, all called from the first? The separate macros would pull their value from the utility sheet attribute.That might enforce an order and give the API time to respond.

Danii said:

Thanks! Seems to work so far.

Only thing: The second _CHARNAME_ is not resolved - which is not a big problem, but thought I mention it.

Good to know, I'll look into that.

Regarding godthedj's problem, I don't have a good solution that's not extremely hacky. I guess the proper way would be to get Roll20's to fix their stuff, but historically they have been ignoring half of my my bug reports even with a clear replication path attached, so my motivation to do this is quite limited.

It's not perfect, but I've got this is working for me at the moment. There is a 1 second delay between actions, which stops the roll20 from tripping over itself and failing to run the subsequent lines.

Because the random rolling is done WITHIN the API script, I can't actually see the outcome of each roll anywhere, so I'm just kind of having to trust that it's working. - I don't seem to be able to use a 'table template' to show the 'totals' at the end, so instead they're just listed after one another in a bit of a messy line of text....

It takes 7 seconds to 'run' but it's a hell of a lot better than having my players all roll manually :)

!delay 1 --/desc The magic of the dungeon passes through the party members minds.
!delay 1.5 --/desc For each character, the DM rolls a D20 for each hour spent resting in the dungeon...
!delay 2 --!modbattr --name Amélie Lacroix --sanity|+[[{?{hours}d20!}<1]]
!delay 3 --!modbattr --name Dust --sanity|+[[{?{hours}d20!}<1]]
!delay 4 --!modbattr --name Hickory Homestead --sanity|+[[{?{hours}d20!}<1]]
!delay 5 --!modbattr --name Elena Tregan --sanity|+[[{?{hours}d20!}<1]]
!delay 6 --!modbattr --name Galaster --sanity|+[[{?{hours}d20!}<1]]
!delay 7 --/w gm Dust=@{Dust|Sanity}, Amélie=@{Amélie Lacroix|Sanity}, Hickory=@{Hickory Homestead|Sanity}, Elena=@{Elena Tregan|Sanity}, Galaster=@{Galaster|Sanity}

Hey! Was wondering if anyone else has noticed ChatSetAttr becoming a bit less reliable recently, most notably since the roll20 update that screwed up the health bars and such a few weeks back. I've been using it to run virtually every aspect of my game for a while now, and all of a sudden Macros that have been working the entire time regularly fail to update attributes.

As an example, here's one of my weapon equip macros.

!emas @{selected|token_name} prepares to use their Iron Longblade in their Main Hand.
!setattr --sel --Weapon|Iron Longblade --silent
!setattr --sel --BaseDamage|11d10+10|120 --silent
!setattr --sel --STRscaling|4|4 --silent
!setattr --sel --DEXscaling|0.5|0.5 --silent
!setattr --sel --WeaponAccuracy|5|5 --silent
!setattr --sel --DWpenalty|5|5 --silent
!setattr --sel --CRITrange|1|1 --silent
!setattr --sel --FUMBLErange|0|0 --silent
!setattr --sel --MainHand|15|15 --silent

Around a month ago this would work every time. However I now regularly have multiple values not updating, seemingly at random and without prompting error messages, on almost every use. It's gotten so bad that players normally have to use the macro four or five times before all the values will have properly updated.

Anyone got any idea why? I'm guessing it's more related to roll20 than the script itself, but as its become particularly noticeable recently I thought I'd ask anyway!

Thanks a bunch if anyone takes the time to read this and reply and hope everyone's having a great day!

In the meantime, combining your commands into one setattr call instead of 9 ought to make it a lot more reliable, or at least atomic.

Ahhh, combining them into a single call is probably a good idea actually. I'll try doing that as well, though I feel like that's not the only issue since other API scripts (TokenMod) have been failing in a similar manner albeit less consistently.

Either way, I'll try doing that first and then let you know if that seems to resolve the issue! Since if I can resolve it myself with a little fiddling that's definitely better than causing hassle to everyone else.

With regards the game in question, it's a Homebrew System I'm writing for my GM and are currently in the tasting phase of. Hence just a simple little dungeon crawl called "What Waits in the Darkness". Every single character in the game uses ChatSetAttr and TokenMod extensively.

So I am running a home brew and one of my players has created an arcane warrior of sorts that uses Arcane Points for his attacks. I have the macro working to add or subtract points depending on which skill he uses, the problem I am having is the macro exceeding the max value of the resource, arcane points in this instance. How would I go about stopping it from adding 1 to the value if its already at the max allowed?

!setattr --charid @{Dekkar|character_id} --mod --Arcane points|-1 {Arcane points}

@Morgan: Drespar was probably interested in the Roll20 name of the game and character so that he can reproduce it and help fix the bug on Roll20's side :) (at least I believe it's a but in R20 and not CSA).

@Kal if you give the attribute a maximum (as in a attr_arcane points_max – fyi, I wouldn't use spaces in attribute names if I were you), you can use --modb instead of --mod and it will respect the maximum value.

Of course, your player can also just enter the maximum on the attributes & abilities tab instead of going via an input on the character sheet.

Jakob said:

@Kal if you give the attribute a maximum (as in a attr_arcane points_max – fyi, I wouldn't use spaces in attribute names if I were you), you can use --modb instead of --mod and it will respect the maximum value.

Of course, your player can also just enter the maximum on the attributes & abilities tab instead of going via an input on the character sheet.

Ty that works perfectly, It wont go below 0 or above max on sheet. you are the best man, thanks agian

Hey Drespar! So found out a few interesting things with a little further testing. And sorry for the slow reply by the way, been super busy with work the last few days so didn't get a chance to reply.

Firstly, I was unable to really replicate the problem in a new "testing" game with the majority of scripts and functionality taken away. Everything seems to work fine there, even when using macros relatively rapidly.

Secondly, in the actual game everything seems to work relatively well asides from a minor hiccup here or there (especially after following Jakob's advice for one or two tests and consolidating multiple CSA commands into one, something which I idiotically hadn't realise I could do before) but... I normally find that macros don't work the first time one is used in a little while. For example, the first macro I use after starting the game almost always fails and if I then afk for ten or twenty minutes (the equivalent of having players indulge in dialogue) I'll have the first macro after this period often fail again. Almost as if the API has fallen asleep and needs a few moments to wake up again.

Either way, it definitely does seem to be a problem on the individual game/system's end, so I'll mess around with a few scripts and consolidate the rest of my code as recommended by Jakob (thanks again for that suggestion!) and see how it works from there.