Routing communications into separate viewable areas

[Tenheydes]

The flow of information from SS13 can be pretty hard to manage.  The purpose of this proposal is to provide users a tool to manage the information.

With this proposal, the current chatOutput window remains, no matter what, and accepts 90% of the to_chat messages. (by souce code reference, not by frequency of use.) 

So all your in-game messages to the user ("You feel a tiny prick!", "Joe Diphtheria coughs!", <object description text>, "The glass table breaks!", "You feel like having some nicotine right about now!") -- These all stay as they have been, along with any channels you haven't messed with.

However, the current headset TGUI gets expanded.  Right now it looks like this...

With this proposed change, Instead of just a column of checkboxes, there's now a new grid of radio buttons.

Now for each channel, you can can choose (in columns) among:  "A / B / C / Main / Mute"

"Mute" is the same as the current "Unchecked" behavior.  Put it in mute and you don't hear it.

"Main" is the same as the current "Checked" behavior -- the chatter from that channel is mixed in with all other chatOutput messages.

The new behavior -- If you have any channels sorted into the "A/B/C" categories, then your chat window splits into (up to) four panes.  How many panes it splits to depends on how many different categories you have configured using the radio buttons).

Here's an example comms setup:

(you'll have to imagine the tgui for this part, I haven't prototyped it yet.)

A - Antagonist (this is the roll-up of traitor comms, changeling hivemind, spider talk, whatever kind of baddie you are)
A - Command (This also sets the routing for CentCom / ERT / Deathsquad / Admin messages too)
A - Security
B - Engineering
B - Science
B - Medical
Main - Supply
Mute - Service
B - Procedure
C - Common

So that's me as a player expressing comms preferences of:

Most important -- Antag / Command / Security  (So if you're an antag, antag comms matter.  If you're a captain or head, then Cmd/Sec matter.  If you somehow are actually hearing radio chatter from all three of these channels simultaneously, then you're you're definitely living your best life.)
Moderate Importance - Engi / Sci / Medical / Procedure (Three of these departments kinda matter, and I guess I'd better at least keep that IAA asshole engaged, so he doesn't go faxing CC over nothing...  (Again!) )
Low Importance - Common (The gretytde wasteland needs its own (ignorable) window.)
Main output - Supply, plus All the other in-game messages. (That QM doens't know how to shut up, I'll stick him with the rest of the stuff, like getting shot)
Muted output - Service  (I can't possibly be bothered with whatever the bartender is yammering on about.)

Not everybody's headset will have all comms, but you can still configure the routing for irrelevant channels.  So you can set up, "yeah if I roll antag some other round, then I want that in my "most important comms" channel.   Maybe types of comms that your current headset doesn't support are greyed out, to make it clearer. All this gets stored in a user pref so it's persisted from round to round.

With that config you get a client that looks like this:

Note that each of the four chat panes is lightly background-colored -- green / blue / grey / white -- to help tie it to the tgui columns so the channels make sens connect up from a visual presentation. 

Next steps:

• Also provide a mechanism to pop green/blue/grey panes out into a full window, allowing them to be tiled onto a second monitor.
• Make it per-user, with prefs saving so it lasts across rounds, not just a proof of concept.
• ... profit?

 

[Rythen]

I really like the idea of this so far and as long as the "default" is still a single chat window for people who do not want to take advantage of this then I personally would love to see it happen.

Also, I think if these settings are going to persist between rounds then the UI for configuration should be in the Game Preferences rather than something you configure mid-round on your headset itself.  It isn't very intuitive to me that channels that I mute would be persisted between rounds.

Edited February 20, 2022 by Rythen

[Tenheydes]

Yup, can easily build this so that the default setup is "works exactly like it does today." 

Maybe/maybe not also have a a one-time popup, or chat message that says, "hey, here's this new feature, go <instructions> to configure it, or click <here> to ignore this message" and the very first time you pull up that configuration dialog or click ignore, it sets a flag and the helper text never shows again?

Game prefs -- yes.  I somewhat like the idea of tying it to the headset itself, becuase that's an easy user interface way to make mid-round adjustments, vs trying to find something buried in "OOC verbs" which is pretty cluttered...  But I suppose there are also players who don't have headsets too...  But if they don't have heasdsets maybe setting the routing stops mattering.  Hmmmm.  Maybe it's a verb. There's a couple paths that could bring up the page to configure which channels go where, feedback about the best way(s?) to get to the config are certainly welcomed.

Another thought is, maybe the "command/highest priority" window doesn't show unless you have a command-channel capable headset?  So that if you spawn in as an assistant, then you don't have this fourth message pane that's permanently empty for an entire round.  Maybe if you're an assistant who puts on a "borrowed" sec headset midround, that's the point that the client pops open the new pane for sec comms?  I.E. maybe the pane only shows if both you have it configured for a separate tab, and also you have a headset that can receive it.

At first, I had thought the idea of routing some "super-priority" messages (admin bwoinks, syndie wardecs, you've been brainwashed) into a specified channel would be a good idea.  But now that I look at it a little deeper, I feel like some of those should be un-routable, and  go to the main chatOutput no matter what.  I also think that probably the main chatOutput window with the game messages should NOT be allowed to popout to a separate window.  What do people think?

[Tenheydes]

In case it wasn't clear, in that screenshot, where chat is split into 4 parts - Those individual panes can be visible/hidden independently -- so you can have, depending on your comms preferences, 1 pane, 2 panes, 3 panes, or 4 panes, in the user interface, however you choose to slice and dice it.

[Rythen]

One of the reasons I like the idea of tying this to Game Preferences rather than headsets is because then it opens the door for in the future expanding this chat routing for things that aren't just comms messages.

This could be really useful for admins being able to route game logs to a specific window or having deadchat go to a specific window, etc.  I'm not saying we need to have those capabilities initially but if this were implemented the game preferences route then the option would be there to expand the options that are available later for other purposes.

Tying the preference to the headset limits it to only really work with "telecoms channels" and it's already a little weird with the fact that changeling hivemind and cult comms exist but arren't (and shouldn't be) tied to headset configuration.

[Tenheydes]

Agreed -- Also the idea of having "hivemind' controllable through.. a headset, and spidertalk for spiders who... don't have headsets, is mixing an OOC setting into an IC equipment device.  So yes, needs to be its own setting.

Also channel muting since it's a per-selected-role round-start setting, agreed, should be on the headset (and not persisted)

From the admin persepctive, yes, that's easy to select subsets of messages to get routed -- anywhere we call to_chat, we can tie it to a window preference.

Talked a bit with Mochi, I'm gonna go look at the tgchat implmementation and get some ideas about how they do stuff too.

[S34N]

There has been some effort towards allowing "tabs" for chat in the form of mochichat.

That being said, this is a phenomenally difficult thing to code, goonchat is deeply woven into our systems. It would take a full chat rework such as mochichat to accomplish this.

[Rythen]

Maybe I'm misunderstanding but my understanding was that the proof of concept you see is running live on Paradise code and showing chat being directed to multiple windows.  

What makes it completely not viable without a full rework?  Might be useful to see Tenheydes WIP code if they can share it?

I can definitely see not wanting to include this if a full rework is already in progress though since it might just get replaced.

Edited February 22, 2022 by Rythen

[procdrone]

This looks absolutely amazing

[Tenheydes]

So the prototype I have is built atop spawning multiple goonchat browsers on the client, and routing chat messages to the appropriate browser -- Yes, goonchat sucks.  It's what's in the code currently, so it's what I route to.

By contrast I've looked at tgchat, and its built on a completely different concept. It's tgui based instead of just a standalone javascript.  It's built around tgui itself doing the routing, creating tabs inside the browser. This means you can maybe do splitters, but you can't do full pop-out windows.

The model I have, instead allows sending to separate browsers in each pane in the Byond client interface.  It would let us make this change without rewriting the whole system.  Any code we don't touch routes to the main output window.  As we start tagging specific things -- radios -- admin chat -- admin event logging -- each one becomes routable as we do that change.  We don't have to tag everything all at once.

Personally I don't like the idea of tabs at all, as seen in tgchat - It just makes it so you don't see text because it's behind a different tab, and now you have to mouse interact constantly to get info. It raises workload, instead of lowering it.  To me, panes or windows are the way we should be going.

This has one big design trade off.

With tgchat, you send the chat to one BYOND client browser window, and the tgui inside that browser routes the data to each tab in turn, and the settings for "what shows in what window" affects visibility, not routing.  Meaning if you enable a checkbox the window shows history from before you enabled the checkbox -- it was always there, just hidden. by the settings

Whereas the model I've prototyped, the server targets the chat message to a specific window -- In this case, if you change the routing settings, it affects where the messages go from that point on but doesn't move prior chat history to the correct window.  I don't feel like that's necessarily a problem.

The model I've prototyped can also route to any chat system -- can route to goon, to tgchat, to any chat.  We just need to be thoughtful about whether we use a combination of routing and tgchat style filtering.

That said, I hear statements of "This is really hard" -- but I'm honestly not seeing it be that hard.  I'll keep working on it to validate that there's no real roadblock -- And also to learn, this was the project I picked to force me to go actually learn some of our codebase and get DM and TGUI savvy.

As soon as I have at least some debug functions (text commands) to configure routing dynamically (currently the routing is hardcoded for testing), I'll push a branch to my GitHub fork so people can look at it.

[Tenheydes]

Proof of concept source is up at https://github.com/Tenheydes/Paradise/tree/chat_is_pane_princess

First four commits are cleanup/refactor of existing code -- unused parameters, variable name clarification, code style.

Next commit is the UI changes. 
Alibi:  This commit adds a whole new html and js which are trimmed down.  Better would be to add a function to the JS to turn on "lightweight mode" mode instead of making completely new files  Just faster for a proof of concept build.

Next commit is the change to code to define a set of categories, and add the capability to existing functions (to_chat, hear_radio, etc) to route traffic based on the categories which are set.
Note:  to_chat currently accepts mobs, clients, and lists as its target.  So add some logic at the end, for each type, such that it, finds the client, so that the (client-specific) routing preferences are available.  Once the client is located, we then go to a route_chat_message() function which only accepts clients.

Next commit is a commit that tags a bunch of calls to to_chat.  This patchset is super simple, it's just adding a message category tag.  Existing calls with no category are unaffected.  So if there are other messages that need routing in the future, its as easy as finding where the message is generated and adding the appropriate tag.

Once it's built and running:

There's a preferences tab popup box (Route Chat Channel) which has you select a category by description, then you enter a number (0...3 -- 3 is the top window of the four, 0 is the bottom).  

Currently the client loads with all the panes visible -- Obviously we don't want the panes visible if the user is not using routing.

Currently the game is preconfigured with a routing, putting admin/server/command/sec/hivemind in one channel, most of departments in the second, supply/common in the third, everything else in the fourth -- We'd want the default to be "Everything in one big pane" so that there's no changes to user interface unless a user turns it on.  I've just left a default routing so that it's not a pain in the ass to set up to test.

[Tenheydes]

Also, here's a bit of eye candy for the admins -- The branch that's up on GitHub sorts admin-privileged information too! 

(I forgot to do it for the screenshot, but attack logs default to pane 2.)

[procdrone]

A suggestion. considering that chats are separated, sometimes, it might be hard to follow the flow of events. A timestamp on messages by default could help a lot in that regard

[Generaldonothing]

35 minutes ago, procdrone said:

A suggestion. considering that chats are separated, sometimes, it might be hard to follow the flow of events. A timestamp on messages by default could help a lot in that regard

To me at least, this seems like an idea that can go horribly wrong very quickly, with people somehow knowing when a message was sent could make people try to use that for an in game advantage 

 

Also like, nobody irl would keep track of that