mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-10 15:45:05 +01:00
CabinetOnFire
af8f69da13
## 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>
47 lines
2.4 KiB
Plaintext
47 lines
2.4 KiB
Plaintext
///Abstract class for an action an AI can take, can range from movement to grabbing a nearby weapon.
|
|
/datum/ai_behavior
|
|
///What distance you need to be from the target to perform the action
|
|
var/required_distance = 1
|
|
///Flags for extra behavior
|
|
var/behavior_flags = NONE
|
|
///Cooldown between actions performances, defaults to the value of CLICK_CD_MELEE because that seemed like a nice standard for the speed of AI behavior
|
|
///Do not read directly or mutate, instead use get_cooldown()
|
|
var/action_cooldown = CLICK_CD_MELEE
|
|
|
|
/// Returns the delay to use for this behavior in the moment
|
|
/// Override to return a conditional delay
|
|
/datum/ai_behavior/proc/get_cooldown(datum/ai_controller/cooldown_for)
|
|
return action_cooldown
|
|
|
|
/// Called by the ai controller when first being added. Additional arguments depend on the behavior type.
|
|
/// Return FALSE to cancel
|
|
/datum/ai_behavior/proc/setup(datum/ai_controller/controller, ...)
|
|
return TRUE
|
|
|
|
///Called by the AI controller when this action is performed
|
|
///Returns a set of flags defined in [code/__DEFINES/ai/ai.dm]
|
|
/datum/ai_behavior/proc/perform(seconds_per_tick, datum/ai_controller/controller, ...)
|
|
return
|
|
|
|
///Called when the action is finished. This needs the same args as perform besides the default ones
|
|
/datum/ai_behavior/proc/finish_action(datum/ai_controller/controller, succeeded, ...)
|
|
controller.dequeue_behavior(src)
|
|
controller.behavior_args -= type
|
|
if(!(behavior_flags & AI_BEHAVIOR_REQUIRE_MOVEMENT)) //If this was a movement task, reset our movement target if necessary
|
|
return
|
|
if(behavior_flags & AI_BEHAVIOR_KEEP_MOVE_TARGET_ON_FINISH)
|
|
return
|
|
clear_movement_target(controller)
|
|
controller.ai_movement.stop_moving_towards(controller)
|
|
EVLOG_MAPTEXT(controller, EVLOG_CATEGORY_AI_BEHAVIORS, "[controller.pawn] has [succeeded ? "succeeded" : "failed"] at performing [src]", get_turf(controller.pawn), "Behavior finished: [succeeded ? "Success" : "Failure"]")
|
|
|
|
/// Helper proc to ensure consistency in setting the source of the movement target
|
|
/datum/ai_behavior/proc/set_movement_target(datum/ai_controller/controller, atom/target, datum/ai_movement/new_movement)
|
|
controller.set_movement_target(type, target, new_movement)
|
|
|
|
/// Clear the controller's movement target only if it was us who last set it
|
|
/datum/ai_behavior/proc/clear_movement_target(datum/ai_controller/controller)
|
|
if (controller.movement_target_source != type)
|
|
return
|
|
controller.set_movement_target(type, null)
|