Skip to content

[#1446] Implement toMessage to leverage message parts#1674

Draft
krbz999 wants to merge 1 commit intodevelopfrom
1446-roll-to-message-parts
Draft

[#1446] Implement toMessage to leverage message parts#1674
krbz999 wants to merge 1 commit intodevelopfrom
1446-roll-to-message-parts

Conversation

@krbz999
Copy link
Member

@krbz999 krbz999 commented Feb 23, 2026

Implements toMessage on the base DSRoll class. Subclasses should define PART_TYPE.

Closes #1446.

@krbz999 krbz999 added this to the v0.11.0 milestone Feb 23, 2026
@krbz999 krbz999 self-assigned this Feb 23, 2026
Comment on lines +30 to +34
[foundry.utils.randomID()]: {
flavor: messageData.flavor,
rolls: [this],
type: this.constructor.PART_TYPE,
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't _id required? I've just been leaning on our migrateData function to generate an ID and use it for the key and _id value

author: game.user.id,
sound: CONFIG.sounds.dice,
}, messageData);
messageData.system.parts = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect we will need to make it easier for subclasses to adjust this chunk of data.

* The type used for the `part` of a standard message.
* @type {string}
*/
static PART_TYPE = "";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the base case be just creating a single roll part?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Override DSRoll#toMessage

2 participants