Open crash1115 opened 3 years ago
I'll take a look but its definitely a lot, and I've been looking into what to do for alt rolls but had no ideas yet.
That said for booming blade and such, its best to make that a separate spell. You can make booming blade main roll the strike damage, and the alt roll the run away damage. Because of the crit augment feature, if the main attack crits, you can "upgrade" the booming blade to also crit and life is gucci. That's how I usually handle that and sneak attack.
But Versatile vs Not Versatile is indeed a problem. I was tempted to have seperate buttons MRE style (and make BR config into a tri state for regular/versatile/prompt) but because auto roll vs not auto roll is an option, it wouldn't be clean, and the default for that has to be good on both (best default for damage roll is prompt MRE style, best default for autoroll is regular). Still trying to figure that one out.
The problem with re-rolling though is that people will want to keep their attack roll dice. Unless foundry improves their roll api, don't know if that'll be possible. EDIT: Is there anything that can edit an attack roll actually? Might not be possible so might be fine.
The rest I'll think about though, don't have enough time to fully digest that yet.
I'm not hung up on re-rolls. Mostly a pipe dream that I'd love to be able to see but have no real expectation for. It sorta just solves a problem that might be better resolved earlier in the workflow in the first place... Maybe even with alt rolls.
The point of having alt rolls in the first place is to provide a little bit of flexibility and give a user the option to "shortcut" to another common way to use the item, right? Allowing additional configs might be a natural way to expand on this concept. Maybe doing something like this:
So you get the guy who just wants to click the button and have everything roll - works fine for him. The guy who has an item that does two things - works as it always has for him. That dang sorlock - also works for him, but he's gonna be using alt roll quite a bit. Might be a happy middle ground there.
Right click to select from a list is a way to do it as well. And left click to select as a client setting is an idea as well. Or left click always shows it if there's more than one option is a thing too.
I'm not a fan of options but they are a decent way to separate casual from power user workflows.
Right click (or some other hotkey, Tidy sheet is doing the whole right click thing now) would be pretty awesome. I'm all on board for "it just does the advanced thing if you know how to use it" over "add so much crap to the options that it confuses or slows people down."
Edit: You know what, ignore that. Client (or even item-specific) option for left click to select would be awesome. There is something to say for transparency with this sort of thing, I think. While I generally dislike option clutter, in this case being explicit might actually save more pain than it causes.
So for the short term, this is what I recommend. One of the two will work: 1) Split Booming Blade into separate cards. For example, this is how I handle booming blade on my characters. Its also the reason I added the "mouseover and click + to crit button". The second booming blade is an alt roll.
2) Make a macro with a dialog. Better Rolls has a macro api, and there are sample files to get you started. I do need to consider adding more macros in there at some point and documenting it. Part of the reason your suggestion is tricky and requires a lot of thought is actually because of that macro API.
That said, while booming blade can be handled in one of those two ways, versatile is still a pain point (and one that shouldn't be) and is worth trying to solve even in the short term. I got some ideas on what to do, but they do need some verification, because it needs to be compatible with any future attempts at an arbitrary number of config options, and maybe even compatible with your re-roll dream feature. I'll write about that in length soon, but I wanted to at least mention some options for you in the short term.
So for versatile, I'm going to assume that damage buttons are enabled, or there's a way to force damage buttons on particular items. Gonna get a bit technical here, please forgive me for the wall....
It gets a bit tricky because BR has a concept of damage groups. Each damage field following a conditional like attack is assigned to the same group, and the damage button activates the whole group. Regular rolls only have one group but a macro can have multiple. Even with damage buttons, the damage is already pre-rolled and in the flags and clicking on the button reveals them. Between the damage group system as well as the prompt disappearing once you click it (oh no misclicks!) the solution is a bit complex, and once one solution is picked, its hard to change directions (and updates will break).
For this item: The flags look like this. Entries are the results, and fields are the original parameters (for the purpose of roll repeats): Each damage object in "entries" has a group property with a string key. The prompt property in params controls which ones are visible and which are not using those keys. Frost Brand only has a single damage group though:
When a roll is built, first the fields are created. These come either from a preset (what you call a config), or manually such as from a macro. The fields define intent, such as "I want an attack roll here", "I want a damage roll here, index 0", "I want a save button here", etc. Note that ["ammo"] is always enabled as its a conditional one, but I'm really tempted on removing it unless there actually is ammo.
Afterwards fields are processed to create render entry objects. These define results. "My attack rolled twice and the results were 24 and 18, disadvantage", "I dealt 16 slashing damage", etc. These are then fed to the Renderer class which turns it into html all at once. When a roll is edited, these render entry objects are tweaked and fed back to the renderer. When a roll is repeated, the fields are copied to generate new render entry objects (since the intents are the same, but the results are not).
In the past, BetterRolls had fields and render templates (a list of generated html). Its been swapped to allow more control over editing a roll without having to resort to editing HTML.
So solutions are of two types. Some are pre-roll, and some are post-roll.
Allowing an indeterminate number of roll configurations is a pre-roll solution and its something that happens before the roll begins. It changes which fields are picked for the roll.
Unfortunately BR configs let you control way more than MRE allows. MRE only swaps damage, not whether the attack or save is enabled. This makes handling your reroll dream feature difficult, unless we have some way of configuring only damage roll entries.
Allowing things like multiple damage buttons is a post-roll solution. For example, I feel that if damage prompt is enabled, the default should be to ask if its normal or versatile damage like how MRE does it:
Implementation wise, this throws a monkey wrench on the whole idea of pre-rolling damage render entries and then displaying them. Also, damage buttons in better rolls EDIT the chat message so the button goes away. How do you undo a misclick? Versatile/Normal isn't for the whole roll, its for the damage group, so it can't be part of the right click menu. Haven't figured out the UX/UI for that one yet.
As far as potential solutions for implementation: 1) We could make a new render entry type that contains both the normal and versatile roll like a switcher, which is used only on the first damage formula. This prevents ever handling versatile like MRE does where its a new config altogether. 2) We could not create the damage render entries off the bat, and instead swap them in later. But damage render entries are fully linear, so now we gotta know exactly where to put them. My guess is that we could add the fields regarding damage to the damage button.
I'm still not done thinking it through, but I wanted to at least give an idea on why its a bit tricky.
Ah, and there's also what to do with things like Token Action Hud to consider. I've edited the above post, and I'm starting to like the second option for the given post-roll solution.
Yeah my original thought for how something like this would work was definitely more inline with option 2 there, but I also had no idea what was under the hood with BR and how everything fit together. I can see why this is hard now. "Do everything up front and chuck it all into a flag for use if/when it becomes necessary" seems a little bit odd to me; that solution seems to rectify at least some of that.
Thanks for looking into this; versatile has always been a pain in the butt, so I'm glad to see it getting addressed whilehaving my crazy suggestions taken into account.
Sometimes incremental refactors make those weird compromises come about. Also fields didn't used to be in the flags. When repeat the roll was implemented, they were added in cause now they were needed. When I get some time, I'll likely start on implementing [2].
Also I learned that midi now uses those flags so now I gotta be extra careful with what I do, but at least they don't touch render entries yet?
I'm about ready to start, but I realized that a macro api is needed, and that macro api will decide the implementation. Bleh.
So if Item Macro is installed, you can add a Frost Brand Longsword to your character, and add the following macro (flametongue will not work, that has an "other" formula). Make sure the hooks are enabled in the options.
const card = BetterRolls.rollItem(item);
card.addField("header");
card.addField("flavor");
card.addField("description");
card.addField("attack");
card.addField("damage", { index: 0, versatile: true });
card.addField("damage", { index: 1 });
card.toMessage();
Off the top of my head, card.addField("damage", { index: 0, versatile: "prompt" })
could be a way to implement it. That said, this is a good chance to start updating the macro api. Don't know how many people are using it (I know enso is).
EDIT: I also remembered the other reason why fields turn into render entries immediately and are hidden. Its because its possible to add fields AFTER a roll is made (through hooks). That needs to be taken into account as well. If someone adds a field, they may want to then check what the result of said field is. EDIT2: versatile: prompt actually won't work. If someone adds a field of that type as a post-roll hook, then it will request a prompt once the damage has already been rolled past the point when a thought a prompt wouldn't be required. Will need to think further.
I know there's been some thought put into overhauling BR with the changes occurring in 0.8.x, so I wanted to throw this out here. Currently in BR, you have control over what happens when you use an item - which damage types get rolled, whether it consumes charges, whether or not it shows the description and/or flavor text, etc. This gets configured in the BR tab of the item sheet, and you can set up two configs - one for quick roll, and one for the alt roll. I would really love to see this functionality extended so that there can be more than two configurations.
The Pain Point Dealing with a weapon or item that can be used more than 2 ways is difficult.
In my game I have a sorlock with flame tongue longsword, who will quicken a blade cantrip to get a supercharged third attack in a pinch. Sometimes they have a focus in their other hand, so 2-handing the longsword doesn't always happen. Between versatile, the flame being on and off, and the blade cantrips, that's 8 different potential ways to use that sword. And that's not taking into account things like Smite (spells and the Divine sort), or other damage buffs from various sources that Active Effects aren't the best way to apply. Those would bring (in this character's case) the number of options up to 16. With BR in it's current state, the player can only choose 2 of those to have on speed dial, but many of them come up pretty regularly.
The Current Workaround Presently my sorlock has just created 2 different versions of the longsword - one that rolls with blade cantrip damage and one that does not - and tacks all the possible damage sources onto each one. This works, but it means we have to sit down and hash out which slashing number to use, whether or not their other damage buff is applied, whether or not we're adding the flame tongue damage, etc. It usually results in someone getting pissy.
We've also used macros that allow him to toggle off different BR contexts before rolling the item. This works pretty well, but it's probably overkill for most users.
Alternative Cole's excellent module Minimal Rolling Enhancements has a great solution for this problem that works wonderfully for lower-automation games. Perhaps an alternative is to see if support for the configurations MRE uses can be worked into BR somehow. AFAIK Cole's gone out of his way to mess with stuff as little as possible, so it might be fairly easy to implement, but I haven't looked at it. There might be quite a bit of work required to make everything play nice with the toggles he attaches to each individual thing on the items, but it also might be less than... All of the crap I'm about to say.
Implementation In order to fix my pain point, I'd love to see the following:
If I could have a stretch goal, it'd be the ability to re-roll damage via a button or context menu option on the card that brings up a list of the item's various damage configurations that you can select from. This is handy in the event that you wanna have auto-roll on, but you sometimes need quick access to the non-default configurations. I could see a complication here where if different configs have different values for the consumption of resources or charges, you'd have to figure out how to handle whether or not to refund charges on a re-roll.
Really Bad Mockups
The config setup...
The re-roll option...
A Sample Workflow (for the aforementioned sorlock):
Conclusion Sorry for the wall of text. Just wanted to throw this out there and let you know you're awesome. Always open to continued discussion or more potential alternatives.