Tagging in to agree, I was genuinely surprised to find out that this still hasn't been updated; I work in software design, so I'm deeply familiar with the ever-growing burden of keeping up with the latest requirements, especially when they're trying to add new game systems all the time! The dev team are definitely up past the neck making all the sheets work even without the updates to maps and things, so it's definitely not that they're sitting on their thumbs, but from a technical perspective this feels like a relatively easy get for me. Basically, the steps are: 1) What kind of roll we doing? (Click the character sheet) 2) Roll math rock (works in the digital, and all of the digital dice seem to be able to send the roll result as a base standard) 3) Apply modifiers (already a separate step in the pure digital, you can see the different values) Most of the work looks like it'll be around step 2, and secret step 0, which is Bluetooth Connection! All they need there is API integration, which Pixels has sent, but when you cut back to the most generic version of the code (because why would I rewrite an entirely different procedure just to connect to a different digital dice? All the dice will send me the number I need, all the numbers need to be treated the same, we stan modularity kids!) all it needs to do is accept a dice roll from a linked external application, not the internal randomizer. There's a hypothetical way to do this that would make it entirely play-system agnostic as well as dice-agnostic; you'd need some configuration with each type of dice to translate what the digital dice send into the number to be modified, but the actual integration should be pretty standard. The reason adding the play systems or new sheets is a chunk of work is converting rules to rolls is the exact math that none of us want to do ourselves, plus the fun of making the code match up and catching where it goes funky--they need to be able to tell the randomizer-plus-modifier system what dice to roll, and what to do with the result. If all we do is add an avenue other than the randomizer to get that number to modify, and if that randomizer-to-modifier system isn't rewritten for each play-system, there's no reason why it'd take more than that config work on getting the number from the digital dice to run Pixels or Go Dice, or any other digital dice maker out there. Unfortunately, I have no idea what Roll20 looks like under the hood, or if it'd be that simple. The modular answer isn't usually the most efficient answer for the first system you wanna build; if they made a full custom integration for Go Dice and how they share data, and have to start over for Pixels, it's a lot more work--especially if the tech changes and how the dice companies send the rolls might change. That's a genuine nightmare, and there's more than enough going on to keep the dev team busy; this just feels like a quick win that I figured we'd have seen by now.
