ChatSetAttr - %attr% values broken?

THIS ISSUE HAS BEEN FIXED! Thanks @Timmaugh for the help: THE FIX (From @Timmaugh): Simply add a space to the end of any line where %attr% are being called by chatsetattr in a ZeroFrame construction and it works. Very simple fix! So for example, in my problematic macro: !{{ !token-mod --set statusmarkers|=blue|-blue --ids @{selected|token_id} !setattr --charid @{selected|character_id} --hp|%hp-max%&nbsp; !setattr --charid @{selected|character_id} --tmp-hp|0 }} There needs to be a space after %hp-max% above, or the line break causes problems. Thanks again @timmaugh! EDIT: Suspect the issue may have to do with ZeroFrame? See Edit 2 below Hey folks, I tried googling this but couldn't find anyone else reporting the problem. I have a simple "Full Refresh" macro that uses TokenMod and ChatSetAttr to remove all status markers, remove temporary HP, and restore a token to full HP. It looks like this: !{{ !token-mod --set statusmarkers|=blue|-blue --ids @{selected|token_id} !setattr --charid @{selected|character_id} --hp|%hp-max% !setattr --charid @{selected|character_id} --tmp-hp|0 }} I've been using this for weeks and it has worked fine but starting today, it is writing "%hp-max" to the token's HP value. I've tested it and it seems to wholly ignore the second % sign entered regardless of what I put in there. I can change it to set to a static value and that works fine, it's only pulling attributes with %attr% that fails. I've restarted the API and as far as I can tell I made no other changes that would have broken this script. Anyone have a guess? EDIT: I'm suddenly having a bunch of API issues unrelated to the specific %attr% issue above. I can open a separate thread for this but I wonder if there's a similar cause. For example, when using SelectManager to get a player ID, I keep getting an error in the API console "Unable to locate player with ID:" and it always returns a nonsense Player ID that is not valid for any players in the game. The same scripts used to work just last week so I'm really confused on what broke. EDIT 2: Okay, I have tracked down the issue and it looks like it's the use of the ZeroFrame batching syntax !{{...}}. For whatever reason this syntax worked great for me for weeks and it just doesn't function now, or breaks a lot of the interior commands in weird unpredictable ways. If I remove !{{...}} from around my !commands then everything works fine. I have another thread for some sample macros where I was implementing !{{...}} to minimize dropped API commands here:&nbsp; <a href="https://app.roll20.net/forum/post/11650692/is-there-any-best-practice-to-minimize-dropped-api-script-commands-other-than-minimizing-concurrent-installed-scripts" rel="nofollow">https://app.roll20.net/forum/post/11650692/is-there-any-best-practice-to-minimize-dropped-api-script-commands-other-than-minimizing-concurrent-installed-scripts</a> Is ZeroFrame busted somehow right now?

I answered the ZeroFrame question in your other thread, so give the suggestion there a try and let us know if you're still having some of the other problems you're noticing. It may be a matter of when a metascript formation is resolving. Also, SelectManager shouldn't be the one returning a playerid... I would think that would be Fetch. In any case, like I said, if you're still having trouble after implementing the suggestion (or if you don't understand it), post back and we'll get it sorted.

timmaugh said: I answered the ZeroFrame question in your other thread, so give the suggestion there a try and let us know if you're still having some of the other problems you're noticing. It may be a matter of when a metascript formation is resolving. Also, SelectManager shouldn't be the one returning a playerid... I would think that would be Fetch. In any case, like I said, if you're still having trouble after implementing the suggestion (or if you don't understand it), post back and we'll get it sorted. Saw that post and working to implement now -- thank you! I'll keep most discussion to the other thread, but just so I can understand, is there a reason my flawed !{{...}}} construction worked temporarily and only suddenly started not working? It's strange to me that it'd suddenly partially drop %attr% calls or fail to execute lines due to pulling the wrong player ID, but it didn't do that weeks ago. Is this like an API performance issue that can cause it to behave erratically? Just trying to abstractly understand, this would make more sense if it was broken immediately when I added !{{...}} but it's weird that it all seemed to work for awhile.