Match Dice Inline Rolls Format Inconsistently (looking at you, Burn Bryte)

Building on the bug report I put in for the Fate Dice and the roll parsers, I've discovered another oddity about the parsing of match dice... namely that the `match` mod object has a `matches` property that is sometimes an array and sometimes an object with keys and values. Below are two images of the JSON-stringified inline roll object... the rolls are virtually identical input: 10d10m (with `matches` object) 10d6m (with `matches` array) My best guess as to what the data means... For the object, it seems that the keys are limited to the die results which composed a match, where the key is the side of the die and the value is the CSS color for formatting of any die with that value. For the array, it always starts with a `null` (probably to offset a 0-based array and make a 1-based die result match). The array index, then, is the side of the die, and the array has elements for the die sides up to the highest side involved in a match. The value of each element is the CSS color for formatting for any die with that value. But there is no reason for the two roll objects to be formatted differently -- this is just the way the data is stored/packaged. The presentation or implementation of it for any character sheet or API would have to know how to access it. And the anomaly doesn't stop there... the same roll that produced a `matches` object  (10d10m) produces an object for exploding (10d10!m), but it produces an array  for penetrating (10d10!pm). Here are some outputs: ROLL              =>    OUTPUT 10d6m            =>    array 10d8m            =>    object 10d10m          =>    object 10d12m           =>    object 10d20m          =>    object 10d100m          =>    object 10d10!m          =>    object 10d10!pm         =>    array 10d10!mt         =>    object 10d10!mtd2       =>    array 10d8m             =>    object 10d8m[Label]     =>    array {10d8mt,10d8mt}>2 =>    array (each) 10dFm             =>    object 10dFm4            =>    array This seems... really... inconsistent. Another Issue: Dropped Dice Formatted as Matches This one is a matter of how the roll data is formatted in the roll tip. If I drop dice from a roll, those dice should not be eligible for forming matches, and in fact they don't contribute to the overall "score" value of the roll. However, in the example roll (below), the three 1s were dropped (and they showed up as dropped in the JSON string of the roll object), but they are formatted with a match color: This is happening because the CSS styling for the die in the roll tip is handled in a class for dropped dice, success dice, and failure dice, but it is handled with an inline style declaration for the match color. Since the style declaration comes after the class, it wins. Here is the css for that chat entry: <span class="inlinerollresult showtip tipsy-n-right fullcrit" original-title="<img src="/images/quantumrollwhite.png" class="inlineqroll"> Rolling 10d3m3d3 = (<span class="basicdiceroll" style="color: #ff9c00"">2</span>+<span class="basicdiceroll critsuccess " style="color: #688de8"">3</span>+<span class="basicdiceroll dropped" style="color: #ee0086"">1</span>+<span class="basicdiceroll dropped" style="color: #ee0086"">1</span>+<span class="basicdiceroll" style="color: #ff9c00"">2</span>+<span class="basicdiceroll critsuccess " style="color: #688de8"">3</span>+<span class="basicdiceroll critsuccess " style="color: #688de8"">3</span>+<span class="basicdiceroll critsuccess " style="color: #688de8"">3</span>+<span class="basicdiceroll dropped" style="color: #ee0086"">1</span>+<span class="basicdiceroll" style="color: #ff9c00"">2</span>)">18</span> Zeroing in on one die: <span class="basicdiceroll dropped" style="color: #ee0086"">1</span> In this case, the 1 should not have received a "match" designation in the first place. My guess is if it never had a color assigned to it, it would not get the "style" declaration, either. The way to fix it would be to remove the dropped dice, first, before the matching is done and before the colors are assigned in the matches property. That way, if there weren't enough of a die result remaining to form a match at the given threshold, it wouldn't get added to the matches property in the first place. This seems to be the operational order for the roll total (which gets the value correct), but not for the formatting in the matches property.

This looks like there are two places where the matches property can be initialized, and one is initializing with a {}, the other with a [];

The Aaron said: This looks like there are two places where the matches property can be initialized, and one is initializing with a {}, the other with a []; Yeah, the weird thing is... downstream of those initializations the R20 parsers would need to get the match results into that property, but the methods to do that for an object vs an array are very different -- where an array would use push() or unshift() or a function that resulted in an array like concat(), map(), reduce(), or _.pluck(), while an object would explicitly set the property or use Object.fromEntries(). It makes me think that the commitment of the dice to the property is also different, one place to another. EDIT: After some conversation, Aaron's right: it is probably just a matter of the initialization. I also found another problem with the matched inline result I'll add to the original post...