## About The Pull Request
This Pull Request adds a new logging system that uses a timeline to
track and visualize important events for specific datums.
This is done via a new window in which you can select a datum for
tracking, which adds it to the timeline. If this datum implements the
EVLOGGING macros, it can track important events onto this timeline. As
an example, we can log whenever an AI is deciding to make a new path, if
it decides to generate a new decisionmaking plan, it finishes an action,
or it decides to target someone/something.
We can select these events to see more information, and optionally get a
snapshot of important variables at the time this event was logged (like
the blackboard and current plan for AI controllers).
You can also filter out specific events / track info, which is done via
categories. Each event / piece of track info is given a category and if
you disable a category all events / track info in that category is
hidden. This lets you filter out things you might not care about.
<img width="2346" height="1209" alt="image"
src="https://github.com/user-attachments/assets/0763077c-e349-4c7c-b017-23d29e1d089b"
/>
_whoever thinks we didnt need advanced cleanbot logging is a noob_
In the video below I showcase how this works;
https://file.house/7nsOiqdvmSTxlsk3fs-e8g==.mp4
A cleanbot is roaming the halls, I turn on the event logger, click the
"pick target" button and click on the datum I'd like to track (the
cleanbot). This results in the cleanbot now tracking its events. I spawn
some dirt and the cleanbot decides to clean it, and I go through the
events; You can see theres different events being listed, such as when
the cleanbot starts targetting the dirt, when it cleans plan, when it
makes it JPS path and every time it moves over it.
The macros I've currently implemented are as follows:
**EVLOG_TEXT(DATUM, CATEGORY, INFO)**
Only adds text to the event logger window, no world-visuals
EVLOG_LOCATION(DATUM, CATEGORY, INFO, TURF)
Adds text to the event logger and adds an image to where that turf is.
EVLOG_TURFS(DATUM, CATEGORY, INFO, TURFS)
Adds text to the event logger and adds an image to each turf in the
TURFS list
EVLOG_LINES(DATUM, CATEGORY, INFO, TURF_A, TURF_B)
Adds text to the event logger and adds a line from turf_a to turf_B
EVLOG_PATH(DATUM, CATEGORY, INFO, TURFS)
Adds text to the event logger and visualizes a path from A to B (same
way as the pathfinding debugger, of which I moved the visualization
before to SSPathfinder)
In terms of performance, the logger is a singleton, and events are ONLY
logged if
1. The logger is running
2. The datum has the DF_EVLOGGING flag.
This means most of the time, logging an event is a single var lookup
(Since the runner is off by default). The DF_EVLOGGING flag is off by
default as well and has to be enabled by the event logger, or set
temporarily by a dev in code.
This system can easily be extended with more event types / visualization
types as well. (I'm thinking of datumizing the ones I have now)
The TGUI is still a bit of a mess, I would love some pointers because
I'm not really good at react so I just kind of hit it with a hammer
until it did what I wanted 😎
Also, all of this is based on VisLogging from Unreal Engine, so it will
have some likeness https://unreal-garden.com/tutorials/visual-logger/
## Why It's Good For The Game
This system allows us to debug more complex systems (like basic AI) in
an understandable and clear way. While the implementation cases are not
super common right now, extending this system could make debugging these
systems much more comprehensible, and hopefully lets more developers
help us with improving these systems. (plus, we LOVE timelines)
## Changelog
🆑 CabinetOnFire
refactor: Implements "Event Logging" an improved way for programmers to
debug specific datums.
/🆑
---------
Co-authored-by: Lucy <lucy@absolucy.moe>
This reverts commit 9acf5bd821.
MSO determined that because we use `file(...)` instead of a string
instead of an asset being locked to its initial state via a cache object
we are sending it as it is on disk every time. which means that when a
new server deployment updates the tgui it will send this new tgui code
even if the currently running DM code does not support it.
* Move element to component, start UI, move assets into their own directory
* Complete UI
* Stop when another surgery is started
* Set your real zone since I forgot you actually need to start the surgery too
* Bring this back since I was just removing it as part of a cleanup for asset cache, but I can't prove it's not used anymore
* Remove unnecessary constructor I was using for something else
* Fix signal override
CabinetOnFire