d9b246cca9
* tgchat (#52426) Replaces goonchat with a tgui based chat panel Fixes #52898 Fixes #52663 It is as fast as goonchat was (if not faster in certain circumstances), and is very extensible. It has all the necessary code for sorting messages into categories, which means that one of the next features will be multiple tab support. Additional features that you will get with tgchat right now: Massively faster server-side performance compared to goonchat, especially if batching multiple messages to one client. Message persistence across rounds and reconnects. (All messages are stored client-side in IndexedDB) More robust scroll tracking. If you scroll up, it will not change the scroll position on new messages like goonchat did. Multiple message combining. (Currently set to combine up to 5 messages over last 5 seconds). If using the highlighting feature, it highlights the whole message as well as the matching word. "Now playing" widget, with preview of the song title, a knob for adjusting the volume and a stop button. Architecture is as following: ``` to_chat() -+ | SSchat (queue, batching) | window.send_message() | v +-------------+ | tgui-panel | |+-----------+| || tgchat || |+-----------+| +-------------+ ``` Subsystem is basically goonchat, but without all the garbage that slows the servers down (string concatenation, double urlencoding, sanitizing, etc). Now, instead of all that, it's being slowed down by json_encode in /datum/tgui_window/proc/send_message, which IMO is completely worth it, and allows sending various templates and widgets to tgchat. /datum/tgui_window abstracts the whole window away from you, establishes a nice message-passing interface between DM and JS, with two message queues on each side, automatically loads js/css assets for you, basically does everything. You as a developer only have to worry about sending/receiving messages and write javascript. tgui-panel is a slimmed down version of tgui, and functions as a container for various widgets, and tgchat is one of them. It of course can be expanded with more stuff. It's also a separate entry point and a JS bundle, so it's not bloating the main tgui bundle, and is currently sitting at about 230kB. * tgchat Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>
Asset cache system
Framework for managing browser assets (javascript,css,images,etc)
This manages getting the asset to the client without doing unneeded re-sends, as well as utilizing any configured cdns.
There are two frameworks for using this system:
Asset datum:
Make a datum in asset_list_items.dm with your browser assets for your thing.
Checkout asset_list.dm for the helper subclasses
The simple subclass will most likely be of use for most cases.
Call get_asset_datum() with the type of the datum you created to get your asset cache datum
Call .send(client|usr) on that datum to send the asset to the client. Depending on the asset transport this may or may not block.
Call .get_url_mappings() to get an associated list with the urls your assets can be found at.
Manual backend:
See the documentation for /datum/asset_transport for the backend api the asset datums utilize.
The global variable SSassets.transport contains the currently configured transport.
Notes:
Because byond browse() calls use non-blocking queues, if your code uses output() (which bypasses all of these queues) to invoke javascript functions you will need to first have the javascript announce to the server it has loaded before trying to invoke js functions.
To make your code work with any CDNs configured by the server, you must make sure assets are referenced from the url returned by get_url_mappings() or by asset_transport's get_asset_url(). (TGUI also has helpers for this.) If this can not be easily done, you can bypass the cdn using legacy assets, see the simple asset datum for details.
CSS files that use url() can be made to use the CDN without needing to rewrite all url() calls in code by using the namespaced helper datum. See the documentation for /datum/asset/simple/namespaced for details.