Real Time Chat Log

[SterLovesFood]

The goal of this is to have a frequently updated auo-saved chat log for the purposes of referencing this .html file in the program OBS when live streaming. Ideally, the chat log would auto-save whenever a message is sent. To avoid saving a massive file every time, only the previous 3-5 chat inputs would need to be saved. If possible, even emptying the chat log if nothing has been inputted in a while to essentially remove old text from the stream -- or an option in general to remove old messages from the chat system.

This sounds like a minor weird thing, but the workflow increase of this small change would be massive for the growing community of streamers using maptools to run tabletop. The alternative currently being to window capture maptools 4+ times in order to create a cohesive overlay, taking up lots of desktop real-estate while running, (https://i.imgur.com/XOhKiRJ.jpg) which still has the issue of not offering transparent backgrounds for the text.

If you've ever seen a twitch chat displayed on any stream it works in a similar manner. A website generates an html version of the chat and, in this case, a website is read in the streaming program in order to display it. ie; anything said in this chat: https://www.twitch.tv/popout/ster/chat will appear here for a moment: https://streamlabs.com/widgets/chat-box/v1/B517A9532EBCB5D83C1C

Similarly, if it were possible to auto-save the initiative window in this fashion (updated whenever next initiative is called), it would further streamline this whole process.

[Dakror]

This sounds like a quite straightforward thing to implement given the existing functionality of chat exports, which are already in HTML.

[Azhrei]

It would be cool if the text added to the chat window could be sent via REST to a server chosen by the user. Then the server could do anything it wanted with the text.

(@SterLovesFood Please use the issue templates. They're there so that folks answer the common questions that always come up.)

[JamzTheMan]

It would be cool if the text added to the chat window could be sent via REST to a server chosen by the user. Then the server could do anything it wanted with the text.

I like this idea, maybe just an option to add a Webhook URL? And any chat output is sent to that webhook? Then you can easily just redirect all output to, say, Discord or any other service?

Of course though, it's going to spit out HTML and not markdown and imbedded images is an issue unless all images are converted on the fly as base64 and embedded?

The saved chat log has the same issue with images IIRC though. We could embed the images again but you need to track repeated images to avoid bloat to the file?

[Azhrei]

I think the OP wanted the text more than anything else. And yes, I was going to point out that this would produce HTML, but anyone who's currently processing the chat log is already getting HTML, so...

I'm not sure what the right way to do this is, though. If we want to be REST-like, then we should provide asset:// URLs that we allow the other end to request. We're obviously not going to do that! But I also don't want to be sending the same image over and over, whether base64-encoded or not. 🤔

If the asset is part of a campaign repository, we could link to it, but many people don't use those.

Yes, the chat log has this issue, but it's easier to fix there. I've already done a POC that shows that base64-encoded images can be placed into CSS content-before blocks and inserted at the right place. I was thinking that the asset URL that MT puts there could be converted by JS on the fly when the HTML is viewed in a browser, but then anyone wanting to post-process the chat log will/may need to process the JS as well and I'm not a fan of that.

[JamzTheMan]

I would assume having the token "portraits" would be wanted (the twitch stream shows them as being used) but that would probably cover 99% of the cases.

IF the goal is to have just the current chat and not the whole history, it wouldn't be as bad to just go ahead and embedded the images as is and limit the file by size and/or timeframe, aka, "chat snapshot" vs "chat log".

[Azhrei]

I suppose the chat log could keep track of which assets it has already sent and just send references to them in the future.

Maybe put blocks of CSS in the middle of the HTML stream. Each asset id becomes a CSS id, and the HTML references those CSS ids. I'm pretty sure that <style> elements can appear interspersed with HTML in most browsers. (Back in the old days, they had to be in the <head>.)

The only problem with that is if the server goes away and comes back later, do we expect the chat sender to re-send images that had been sent previously?

[Dakror]

Since OP wants a live view of the chat withoit too much backlog, just sending all images all the time with a file size cap like @JamzTheMan suggests should be sufficient. Especially when using a webhook to just send the data anywhere ecerything needs to be included anyway in the payload since we webhooks are expected to be stateless.

[SterLovesFood]

Text aspect of the chat is definitely the most important part. Even if the broken image links remained in the chat output from impersonating a token, that can easily be cropped out of the frame in the broadcast software if no more elegant solution is feasible.