floor() expressions being mangled on the way in to API

Sorry for the flood of bug reports, I seem to be finding a lot of broken things at the moment!&nbsp; I'm trying to access the "AC" attribute on a 5e shaped character sheet from the API. I'm having lots of problems with it, as it is a complex calculated field and every part of the system appears to process it slightly differently! One thing that seems definitely broken is that if I do sendChat("", "@{Mage|AC}", function(result) { ... }); The expression that comes back looks like this: (((1-0) * (((0+floor()+0+0+floor()+0+0+floor()+0+0+floor()+0+0+floor()+0+0+floor()+0 + 0) + (10+$[[0]]+floor()+0+0+0+0+0+0 + 0) + abs((0+floor()+0+0+floor()+0+0+floor()+0+0+floor()+0+0+floor()+0+0+floor()+0 + 0) - (10+$[[1]]+floor()+0+0+0+0+0+0 + 0))) / 2)) + (0 * 12)) Notice that all those "floor()" calls are empty.&nbsp; Typing @{Mage|AC} in the chat window yields: (((1-0) (((0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0 + 0) + (10+2+floor((0 + 0.001))+0+0+0+0+0+0 + 0) + abs((0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0 + 0) - (10+2+floor((0 + 0.001))+0+0+0+0+0+0 + 0))) / 2)) + (0 12)) Which is really odd because it has decided to remove all the multiplication signs, but at least you can see that&nbsp; all of those floor calls should have small decimals inside them. For additional comedy, if you send the AC value to the API directly like this: !my-api @{Mage|AC} you get something different again: (((1-0) * (((0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0 + 0) + (10+$[[0]]+floor((0 + 0.001))+0+0+0+0+0+0 + 0) + abs((0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0 + 0) - (10+$[[1]]+floor((0 + 0.001))+0+0+0+0+0+0 + 0))) / 2)) + (0 * 12)) ...which is at least a valid expression that could be resolved to a real value with the help of the inline rolls object. If you ask for the value of the Mage's AC attribute by calling getAttrByName from the API, you get another answer: ((@{is_pc} * @{pc_AC}) + (@{is_npc} * @{npc_AC})) You can interpolate a character name into each one of those attribute references and pass it back to sendChat, at which point it gives you back the same expression with the empty floor() calls that we first started with by sendChatting @{Mage|AC}. For one final variant, if you make an attack using a character sheet macro that includes @{target|AC}, that resolves completely to a target number with no problems at all.&nbsp; Not sure why none of the other ways of referencing (including the chat window) can't do this... It's all a bit confusing; the two things that stand out as actually broken are the behaviour of the chat window for @{Mage|AC} and those empty floor() calls, which *may* be related to <a href="https://app.roll20.net/forum/post/2433743/bug-get" rel="nofollow">https://app.roll20.net/forum/post/2433743/bug-get</a>... since there is a drop-down involved, even if I'm not actually calling getAttrByName directly myself (but perhaps the roll20 code is somewhere). Cheers, Lucian

Lucian H. said: Typing @{Mage|AC} in the chat window yields: (((1-0) (((0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0 + 0) + (10+2+floor((0 + 0.001))+0+0+0+0+0+0 + 0) + abs((0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0+0+floor(0.001)+0 + 0) - (10+2+floor((0 + 0.001))+0+0+0+0+0+0 + 0))) / 2)) + (0 12)) Which is really odd because it has decided to remove all the multiplication signs This is because "*some text*" in the chat window is the syntax for italicizing the text. If there were an odd number of multiplications in the equation, you'd see the last one.