Chat messages not merged with core roller about foundryvtt-compact-roll-card-5e

[akrigline]

I suspect this is "intentional" in that the core roller's flow isn't conducive to how I'm merging the cards together.

I use the timestamp to determine if chat cards relate to each other, for lack of a better mechanism. This works pretty well with MRE and fast-forwarded rolls, as well as for several of my modules that add chat cards in response to item usage hooks (from more-hooks).

I'm not interested in adding any data to the cards created, nor maintaining any state in this modules' code, so the options are fairly limited for that collapse mechanism.

But I'm definitely interested in any ideas for how to remedy this shortcoming.

[kaelad02]

That must be what this check is for then?

if (chatMessage.data.timestamp - previousChatMessage.data.timestamp > 300) {
  return;
}

Too bad it only works for fast-forwarded rolls then. Kind of limits the audience. Bummer

[akrigline]

True, but I'm not overly concerned about a limited audience :)

This whole module is unlisted still.

[kaelad02]

The rolls are adding a flag to the chat message that contains the item ID: flags.dnd5e.roll.itemId. The catch is, as far as I can tell, the original item chat card does not put the item ID in the chat message's data. It's there in the HTML (e.g. the data-item-id="yAKKtMnSmrFDMCQz" attribute on the main div) but not somewhere like a flag on the actual ChatMessageData.

Was thinking you could use that to detect instead of time proximity, but I'm not sure how to get the data-item-id from the previousChatMessage.

[krbz999]

Reading the string position of "data-item-id" will do it. Same way Warp Gate's warpgate.dnd5e.rollItem() gets the spell level of a casting, for reference.

[akrigline]

That's an interesting idea.

I don't love the idea that two longsword usages back to back will collapse upwards though.

Could add in something to check that it's the main item card, and if so never collapse those up.