Mark fumble with rerolls

Hi all, I'm trying to figure out how to have critical fails (fumbles) marked in the roll template when the roll in question is also subject to rerolls. For my case, the die is rerolled on 1s; BUT I want the red highlighting to be applied to the number in the template even though the rerolled value will eventually not be a 1. As a simple example, consider: /r [[d4r<1cf<1]] If the result was initially a 1, then rerolled to a 3, the output would be the typical yellow box with a 3 in it.  I'd like the yellow box to have the red border in this case as well - a 1 was involved at some point, which is all the criteria that is required to indicate to the players that a critical fail may be involved. Is this possible?  I'm willing to explore custom templates, or any other advanced features - but I haven't found any support for extracting the rerolled results yet.  (But they must be available, as they will show up in the tooltip if you mouse over the yellow box...). Thanks for any help!

I think this is only possible with a custom API script.

The idea being to custom handle all of the rolling as an API function, and then cobble together whatever components are needed to output?  Or are you saying that in an API function the default rolling (like my example) can be used, but that there is greater access to the underlying rolls?

You could alter the roll to use the fumble highlighting in a couple of ways, the simplest to write would be to use exploding penetrating dice on a 1 instead of rerolling. So- [[ 1d4!p1 ]] On a one this will reroll the die without dropping it (maintaining the fumble colouring) but since it's penetrating subtract one from the new die so it doesn't affect the total outcome. You still get get values 2..4 but if you rerolled it will have the fumble colour.

Thanks Rainbow, that's actually a very clever solution.  I'll have to see if I can adapt it to my more complex actual roll (the post here was simplified to isolate this problem), but I think it'll work.  Much appreciated!

Jesse said: The idea being to custom handle all of the rolling as an API function, and then cobble together whatever components are needed to output?  Or are you saying that in an API function the default rolling (like my example) can be used, but that there is greater access to the underlying rolls? The default rolling doesnt allow you to interrogate the roll and display information twice, differently. To show the final result, and show whether you got a fumble on the first roll, is beyond the default rolling, and you'd need to create your own roll in the API. It is possible. So you could set up a routine:     have it make a roll without any exploding mechanism, then inspect the roll to see if you got a 1 and record that. Then if you got a 1, call the routine again, to simulate the exploding mechanic. So you'll get a legitimate final total, but also have a record that you rolled a 1 at the start. Then you build the output, formatting it to show what data you want. It's a lot more complex than just using a standard roll, but much more flexible in what you can do with it. Thinking about it, the Scriptcards script might be able to do this without needing a custom API script.

Thanks GiGs.  I ultimately may resort to using the API and writing something custom.  I'll take a look at Scriptcards first to see what it's all about.