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.)

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.

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.

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.

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.

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?

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?

Sorry for the necrothread, but perhaps an answer to the overload is simply to segregate traffic into separate windows. One text box for In-game announcments -- combat logs, players coughing, you can't breathe! You yould die for a cigarette, players near you talking or emoting One text box for common comms One text box for department/silicon/cult/etc comms -- all channel-specific comms. It's very common for, for example medical radio calls to get lost in the overall flow of text, having them be split out into a separate window that isn't scrolling like a demonic hamster wheel would help people manage information without needing to be such a dramatic change as abolishing a channel and replacing it with a new mechanic

Fair enough. Retracted.

Background: Currently the experience requirement for Magistrate is 100 hours played as a member of Security. Sec is required to have an understanding of Space Law for both enforcement and sentencing purposes. Yes, playing as sec provides a background in Space Law which is necessary for the Magi job. However "time spent as Sec" does not make sense as the role requirement. When you promote cops, you get police chiefs, not judges. Judges are what you get when you promote lawyers. Proposal: change the "100h as Sec" Magistrate requirement to "100h as Sec or IAA" Benefits: Makes sense IC. The IAA role definition directly requires them to know and apply space law, and if done right, should be providing them trial experience at times as well. Sec role matters too -- In terms of experience relevant to a Magistrate, a 100 hour IAA ought to be a better qualified than a 100 hour Security Officer, but comparably qualified to a 100h Warden or 100h HoS. Makes sense OOC. The RP focused IAA role is better at preparing the player for the RP focused Magistrate role than the often combat-mechanics focused Sec Officer role. Makse sense from a job experience mechanics perspective. (per the wiki) "[Magistrates] ... are not part of the Security Team, nor do they manswer to the HoS or Captain. ... IA Agents... report to the Magistrate." Now, Playing as a doctor qualifies you to be CMO. Playing as CMO qualifies you to be Captain. Every other (non-service) job in the game, playing as the role helps you unlock your boss. IAA is the only one who gets stiffed. The wiki says that IAA is "Legal Department" and their head is the Magi. However from a codebase perspective, we list IAA as a "service" job and they get no qualifying experience. Drives Engagement. Provides people a reason to play the underused IAA role. Implementation: Not a byond coder (yet?), but some look through code, seems like every job contributes to one and only one experience type. I'd propose Adding a new experience type, EXP_TYPE_LEGAL. ensure EXP_TYPE_LEGAL is persisted appropriately across rounds. When the merge occurs, ensure the on-disk records for EXP_TYPE_LEGAL are set equal to EXP_TYPE_SECURITY so players don't lose existing qualifying sec experience. log time in security roles as both EXP_TYPE_SECURITY and EXP_TYPE_LEGAL log time as IAA as both EXP_TYPE_SERVICE and EXP_TYPE_LEGAL Make sure EXP_TYPE_LEGAL doesn't contribute to EXP_TYPE_CREW so that it isn't double-counted. Make Magi depend on EXP_TYPE_LEGAL instead of EXP_TYPE_SECURITY. Make it show in the job prefs UI as "xxxH as Sec/IAA" There's an alternate approach which would have Sec contribute to EXP_TYPE_SECURITY and have IAA contribute to both EXP_TYPE_SERVICE and EXP_TYPE_LEGAL, and this would require a way to set datum/job/*/exp_type to a list and read multiple times and add them. Possibly create a new job category in the crew manifest, "Legal" and move Magi/IAA out of service and into that job category. This might help people notice it more and proactively approach the IAA with problems, instead of the IAA being lost with in the middle of a pile of assistants and cooks and bartenders. If so, IAA (and magi) contributes to EXP_TYPE_LEGAL and stops contributing to EXP_TYPE_SERVICE and then EXP_TYPE_LEGAL does contribute to EXP_TYPE_CREW. Consider adjusting so HoS/Warden/IAA qualify, but Sec Officer and Detective do not. If so, consider dropping the hours requirement since it's harder to get HoS/Warden time