Provide a method to roll the hit die for a specific class, rather than a specific hit die denomination

[schultzcole]

In working on #936 I've run into a counter-intuitive little bit of UX, which is that if an actor has two classes with the same hit die denomination and a user tries to use the "roll" button for the second class in the new configure hit dice window, it will deduct hit dice from the first class if that class has any hit dice available.

Steps to reproduce (requires the 936-edit-hit-dice branch):

1. Import "Randal (Human Fighter)" from compendium.
2. Add the Paladin class from the compendium to Randal. Randal now has one level in Fighter, and one level in Paladin (both d10 hit dice).
3. Open the hit dice config window for Randal and ensure that both classes have one available hit die.
4. Click the "Roll" button in the Paladin row.
5. After rolling the hit die via the dialog, observe that the Fighter class now has 0/1 hit dice available, while Paladin has 1/1.
   Expected result: clicking the roll button for the Paladin class should deduct hit dice from the Paladin class item.

This isn't a huge deal since the actor still has the correct number of each denomination of hit dice, but it might result in an unexpected user experience.

Currently the configure hit dice window uses the Actor5e#rollHitDie method. I would propose an optional parameter to this method to specify the id of the class item from which to deduct the hit die.

[schultzcole]

Originally in GitLab by @aaclayton

I agree it makes sense to make more flexible. I can think of at least 3 modes of "I want to roll a hit die" that we should probably support:

1. I want to roll the best available HD
2. I want to roll a HD of a certain denomination, but I don't care what class it comes from
3. I want to roll a HD from a specific class

[schultzcole]

I think the following signature would probably be a good approach:

  /**
   * Roll a hit die of the appropriate type, gaining hit points equal to the die roll plus your CON modifier
   * 
   * `options.classId` and `options.denomination` are mutually exclusive. If `options.classId` is defined, `options.denomination` will be ignored.
   * If neither `options.classId` nor `options.denomination` are provided, this method selects the highest available hit dice denomination.
   * @param {object} options
   * @param {string} [options.classId]       The id of the class item to draw hit dice from.
   * @param {string} [options.denomination]  The denomination of hit dice to roll.
   * @param {boolean} [options.dialog]       Show a dialog prompt for configuring the hit die roll?
   * @returns {Promise<void>}
   */
  async rollHitDie({ classId, denomination, dialog=true }) {

[schultzcole]

Originally in GitLab by @aaclayton

Looks good to me

[schultzcole]

Originally in GitLab by @akrigline

Assigning to %"D&D5E 1.3.0 - Level-up Experience" for now as it relates closely to !200 and #936

[schultzcole]

Should we try to gracefully deprecate this by determining if the first parameter is a string, and if so, showing a warning message and recovering?

[schultzcole]

Originally in GitLab by @akrigline

IMO we should make a new method rollSpecificHitDie and deprecate the old one, rather than replace it. Making the old method call the new method for a few release cycles with a warning attached won't hurt anything and won't break anything.

[schultzcole]

Originally in GitLab by @zeel01

I'm having a hard time coming up with a situation where the class the hit die came from would be relevant. The size yes, we must be able to select the size, but if you have d10 from multiple classes, I'm not aware of any rule that would make which of the d10 relevant. In fact, I don't think there really is a distinction at all, it's just a pool. Similar to spell slots (except Warlock).

Would it not be better for the UI to be simplified, and hide this concept of which class the die comes from from the user? It's understandable that the values are being tracked on the classes, but the user doesn't need to know/interface with this.

[schultzcole]

Originally in GitLab by @aaclayton

Given that we just made improvements to hit dice rolling and short rest dialog already in 1.3.0, should we just scrap this issue until we are clear that further changes are actually required?

[schultzcole]

Originally in GitLab by @aaclayton

Closing this issue as unnecessary. If anyone strongly disagrees please re-open.