Leaderboard

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?

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.

Disregard everything about only one department being able to be used for restrictions, I have PR'd a refactor that allows for multiple https://github.com/ParadiseSS13/Paradise/pull/17442

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.