Kilidian said: When I add an exclamation mark to the front and replace the base inline command with the zeroframe way of doing it as you instructed like so: {&simple} {&eval{^}modattr --name Buzz Aburame --class_resource|+[^[^$[[9]].value+$[[11]].value^]^]{&/eval} it outputs the damage in chat but does not actually update the class resource on the character sheet, Unfortunately, that's my fault. I left a typo in the macro code. I'll explain, below. Kilidian said: {&simple} {&eval}modattr --name Buzz Aburame --class_resource|+[[$[[9]].value+$[[11]].value]]{&/eval} And that seems to work perfectly, i believe i tried something like that before based on what i learned yesterday but i may have mistaken the lack of a chatsetattr whisper message as it not working, anyways got it to work so thanks for the help! If you would be so kind i would like a little explanation on what the ^ character does and why it seems to behave in the complete opposite way i would expect it to from my understanding of it, and if you have any insight as to why ChatSetAttr doesnt output a response anymore once used inside plugger even though there is no --silent operator present for it id love to understand that as well. OK, so the ^ would be acting as a deferral character... if I had enclosed it in parentheses instead of braces: {&eval(^)} That's the first problem. I corrected my post, above, to remove this error. In its proper form, the character within the parentheses will be used as a deferral character... meaning that when Plugger dispatches the outbound command line (this time to ChatSetAttr), it will remove that character. Up to that point, the Roll20 parsers have only seen a version of the entire command line (the whole message) that included the deferral character, and the presence of that character meant that the Roll20 parsers didn't properly identify the syntax constructions that it could have. Roll20 won't detect: @^{Actual Cannibal|normal_tuesday_night} ...as something it needs to retrieve from the game-character "Actual Cannibal." However, when Plugger removes the ^ letter-character from the construction and sends the embedded command, the Roll20 parsers have another chance at the line, and this time they recognize the syntax. That's important when you have something that you don't want to be caught by the Roll20 parsers, or something which can't be caught by the Roll20 parsers immediately... like where you reuse roll markers in a different inline roll: [[$[[9]].value + $[[11]].value]] That syntax would break a normal inline roll. Roll20 doesn't know what to do with it. If you are using that and *not* seeing it break, it very likely is not getting you the correct data. It might be zero-ing out parts of the roll, or using some other static value. What needs to happen is that (1) the source rolls are detected and compiled (rolls $[[9]] and $[[11]] in their original position). Then, (2) ZeroFrame extracts the value of the rolls. Then (3) the outer roll is detected and parsed. Steps 1 and 3 happen in the Roll20 parsers, but each message only passes through them one time. Since Plugger dispatches a new message, it gives you another chance at the R20 parsers. In order for the outer roll to be detected during that later message (and not before ZeroFrame has a chance at the .value constructions), they have to be masked with the deferral character. SIDE NOTE : ZeroFrame also has a deferral character, and it establishes a loop where it passes the message over the Roll20 parsers and the rest of the metascripts until no more meta-constructions are detected. That would also work in this case, but I won't confuse the issue by going into it now. (The syntax is different from Plugger.) Why ChatSetAttr Doesn't Report When a script sends a message through the chat interface (a script-generated message, as opposed to a user-generated message), a few things are lost. There is no set of selected tokens, the "who" of "who sent the message" is changed, as is the "playerid" associated with the message. Most of the time, the lack of selected tokens is the key thing that is lost... (a script calling a second script leaves the second script without a set of selected tokens that it might have been counting on). In your case, you are running into another issue. ChatSetAttr doesn't know to whom to report the output message. Since Plugger is calling ChatSetAttr, the who and the playerid are both lost. The fix for this is to install SelectManager (another metascript). It comes configured to give back the selected tokens, and you can instruct it to give back either/both of the playerid and/or who. Once installed, issue this command: !smconfig +playerid +who One of those should allow ChatSetAttr to properly whisper its output to you to let you know what it has done.
