## 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>
## About The Pull Request
reduces the cost of the planning subsystem. instead of calculating
able_to_plan on every fire for every mob, we only calculate it when a
mob queues/dequeues a behavior. also converts behavior lists into lists
rather than lazylists to reduce the amount of checks we do on process.
these are the differences after ran on tracy.
## Why It's Good For The Game
reduces the cost of ai planning subsystem
## Changelog
🆑
/🆑
## About The Pull Request
Nother bit ripped out of #79498
[Implements a get_cooldown() proc to get around dumb manual overrides
and empower me to optimize the findtarget
logic](https://github.com/tgstation/tgstation/commit/7047d294dd2675b7e38db2424d6d79c52f21783a)
[Adds modify_cooldown, uses it to optimize find_potential_targets
further](https://github.com/tgstation/tgstation/commit/4ebc8cedcefaa57a1c3d1afbbb485baa6fae0a4f)
No sense running the behavior if we're just waiting on its output, so
let's run it once a minute just in case, then push an update instantly
if we find something
[Optimizes connect_range and
promxity_monitors](https://github.com/tgstation/tgstation/commit/bcf7d7c5b371e46c02aa9039d4ccd4715b999400)
We know what turfs exist before and after a move
We can use this information to prevent trying to update turfs we don't
care about.
This is important because post these changes mobs with fields will be
moving a lot more, so it's gotta be cheap
[Implements a special kind of field to handle ai
targeting](https://github.com/tgstation/tgstation/commit/80b63b3445778eb2c75fc2f8f61aca07ed482b1f)
If we run targeting and don't like, find anything, we should setup a
field that listens for things coming near us and then handle those
things as we find them.
This incurs a slight startup cost but saves so much time on the churn of
constant costs
Note:
We should also work to figure out a way to avoid waking ais if none is
near them/they aren't doing anything interesting
We don't need to do that immediately this acts as somewhat of a stopgap
(and would be good regardless) but it is worth keeping in mind)
## IMPORTANT
I am unsure whether this is worth it anymore since #82539 was merged. As
I say it was done as a stopgap because ais didn't know how to idle.
If not I'll rip er out and we'll keep the other
refactoring/optimizations.
## Why It's Good For The Game
Cleaner basic ai code, maybe? faster basic ai code, for sure faster
proximity monitors (significantly)
## About The Pull Request
This one is a double feature because Watchers and Basilisks share the
same typepath. You might see a couple more of those.
As is tradition I decided to fuck with them rather than just port them.
Here's what's up.
**Basilisks**
- Have a new soulless sprite which looks less like a living blue hedge.
- Walk at you and shoot you while you are not in range (just like
before).
- Become supercharged if they become "heated" by lava, lasers, or
temperature weapons. This was a feature they also previously had but
they would never encounter lava, so now it also works if you use the
wrong gun on them.
- Lose their supercharge if you cool them down.
- Otherwise pretty normal mobs.
**Watchers**
https://www.youtube.com/watch?v=kOq_Bf78k5A
Here's a traditional video of me intentionally getting hit by mechanics
(trust me its definitely on purpose)
- They glow emmissively a little bit so you can see them from further
away.
- Their eyes light up about 0.5 seconds before they are able to shoot at
you.
- No longer melee attack, instead try to stay out of melee.
- Will occasionally put you into "Overwatch", meaning they will shoot
you rapidly if you move or act while they're staring at you for a brief
time period (after which you become immune for 12 seconds, and during
which other watchers will play fair and stop shooting at you).
- If they start taking damage they will also start using their "Gaze"
attack, look away or suffer some kind of negative effect!
- - Normal watcher gaze flashes and confuses you.
- - Magmawing watcher gaze obviously burns (and briefly stuns) you.
- - Icewing watcher gaze freezes you and throws you backwards.
- Magnetically attract and eat diamonds. They also used to do this, but
just if they happened to coincidentally walk past some.
**Other accompanying changes**
All basic mobs will now adopt the "stop gliding" trait if they get
slowed down too much.
I moved behaviour for "fire a projectile from this atom" into a helper
proc because I was using it in three places and I will probably use it
in more places. There are probably other places in the existing code
which could be using this.
I think I made the basic mob melee attack forecast default a little more
forgiving, they were fucking me up too much and I am the playtester.
## Why It's Good For The Game
Another one off the list.
New tricks for old dogs.
Framework for making mobs with ranged attacks "fairer" (you can see when
they are ready to shoot you).
More (hopefully) versatile AI behaviours which we will reuse later (I
hope I'm not duplicating one someone already made).
If our players "enjoy" them enough we can give more mobs "don't look at
me" mechanics.
Removes some soul sprites.
## Changelog
🆑
refactor: Basilisks and Watchers now use the basic mob framework. Please
bug report any unusual behaviour.
sprite: Basilisks have new sprites.
add: Basilisks will go into a frenzy if heated by energy weapons or
temperature beams as well as by lava.
add: Watcher eyes will be illuminated briefly when they are ready to
fire at you.
add: Watchers can now briefly put you into "Overwatch" and penalise you
for moving while they can see you.
add: Wounded watchers will occasionally punish players who look at them.
balance: Unusual watcher variants are more likely to appear.
/🆑
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
## About The Pull Request
Fixes#72116
I've had a persistent issue with basic mob actions reporting this error
and think I finally cracked it
When replanning with `AI_BEHAVIOR_CAN_PLAN_DURING_EXECUTION` it can run
`Setup` on one action leading to the plan changing, meaning that it runs
`finishCommand` to cancel all other existing commands
If you triggered a replan by setting up a movement action in the middle
of another movement action, cancelling the existing action would remove
the target already set by the current one.
We want actions to be able to remove _their own_ movement target but not
if it has been changed by something else in the intervening time.
I fixed this by passing a source every time you set a movement target
and adding a proc which only clears it if you are the source... but this
feels kind of ugly. I couldn't think of anything but if you have a
better idea let me know.
Also while I was doing this I turned it into a feature because I'm
crazy.
If you feed a mouse cheese by hand it will stop being scared of humans
and so will any other mice it attracts from eating more cheese. This is
mostly because I think industrial mouse farming to pass cargo bounties
is funny.
Mice controlled by a Regal Rat lose this behaviour and forget any past
loyalties they may have had.
https://user-images.githubusercontent.com/7483112/208779368-3bd1da0f-4191-4405-86e5-b55a58c2cd00.mp4
Oh also I removed a block about cancelling if you have another target
from the "hunt" behaviour, everywhere using this already achieves that
simply by ordering the actions in expected priority order and it was
messing with how I expected mice to work.
Now if they happen to stop by some cheese they will correctly stop
fleeing in order to eat it before continuing to run away.
## Why It's Good For The Game
Fixes a bug I kept running into.
Makes it possible to set up a mouse farm without them screaming
constantly.
Lets people more easily domesticate mice to support Ratatouille
gameplay.
## Changelog
🆑
add: Mice who are fed cheese by hand will accept humans as friends, at
least until reminded otherwise by their rightful lord.
fix: Fixed a runtime preventing mice from acting correctly when trying
to flee and also eat cheese at the same time.
/🆑
## About The Pull Request
Allows basic mobs / datum AI to switch between movement datums. Useful
if you need JPS in some moments, but simple obstacle avoidance in others
This isn't used anywhere yet, but is a building block for basic bots.
## Why It's Good For The Game
Allows us to pick the right tool for the job!
## Changelog
🆑 Capybara Holly
refactor: Datum AI can now switch to different movement datums in their
behavior.
/🆑
Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com>
Simple_animals / mobs are the biggest lie in this code-base. They're far from simple and have an extreme god-object problem. Especially when you get to /hostile, where there is so many procs, vars, and what not, that you can't make any interesting additions without snowflaking the hell out of the code.
This PR hopes to help kill this problem by introducing a new /living subtype, /living/basic. The idea of this refactor is to slowly start moving all old simple_animals to this new system, moving over behaviors like charging and more extravagant mobs like megafauna over bit by bit similar to how newfood was implemented.
One of the other big goals of this refactor is to move many of the fringe simple animal behaviors into either AI datums, or components/elements. (Some of which still needs to be done in this PR).
As a proof of concept, I created the base mob/living/basic, and moved cockroaches over to the system. Since cockroaches have both a passive, melee and ranged mob.
This PR does slightly affect balance as the behavior isn't 1-on-1 due to it no longer running on the janky /hostile behavior, but I tried to keep the effects to a minimum, and the glockroach and hauberoach are not spawnable through many means as far as I know.
This does a variety of improvements to monkey ai that I got drawn into after fixing a relatively simple bug with monkeys and guns. This pr is in support of #58565 so that in the rare chance pun pun gets a gun, they know how to use it. Previously #16630 made it so monkeys could use guns but semi-recently that was broken. Now that's fixed and in addition some other monkey ai capabilities were enhanced, read the changelog for the full list.
CabinetOnFire