mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-26 17:11:52 +00:00
0e1b20e6db
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.
44 lines
1.3 KiB
Plaintext
44 lines
1.3 KiB
Plaintext
/**
|
|
* # asset_cache_item
|
|
*
|
|
* An internal datum containing info on items in the asset cache. Mainly used to cache md5 info for speed.
|
|
*/
|
|
/datum/asset_cache_item
|
|
var/name
|
|
var/hash
|
|
var/resource
|
|
var/ext = ""
|
|
/// Should this file also be sent via the legacy browse_rsc system
|
|
/// when cdn transports are enabled?
|
|
var/legacy = FALSE
|
|
/// Used by the cdn system to keep legacy css assets with their parent
|
|
/// css file. (css files resolve urls relative to the css file, so the
|
|
/// legacy system can't be used if the css file itself could go out over
|
|
/// the cdn)
|
|
var/namespace = null
|
|
/// True if this is the parent css or html file for an asset's namespace
|
|
var/namespace_parent = FALSE
|
|
/// TRUE for keeping local asset names when browse_rsc backend is used
|
|
var/keep_local_name = FALSE
|
|
|
|
/datum/asset_cache_item/New(name, file)
|
|
if (!isfile(file))
|
|
file = fcopy_rsc(file)
|
|
hash = md5(file)
|
|
if (!hash)
|
|
hash = md5(fcopy_rsc(file))
|
|
if (!hash)
|
|
CRASH("invalid asset sent to asset cache")
|
|
debug_world_log("asset cache unexpected success of second fcopy_rsc")
|
|
src.name = name
|
|
var/extstart = findlasttext(name, ".")
|
|
if (extstart)
|
|
ext = ".[copytext(name, extstart+1)]"
|
|
resource = file
|
|
|
|
/datum/asset_cache_item/vv_edit_var(var_name, var_value)
|
|
return FALSE
|
|
|
|
/datum/asset_cache_item/CanProcCall(procname)
|
|
return FALSE
|