## About The Pull Request
this makes it so `SSai_controllers` and its subtypes use a `currentrun`
loop, instead of directly looping thru
`GLOB.ai_controllers_by_status[planning_status]`
## Why It's Good For The Game
most other processing subsystems do this, why shouldn't we?
it should ensure all ai controllers get to process, even if the server's
under load.
## Changelog
no player-facing changes, prolly
## About The Pull Request
I heard you liked commas.
## Why It's Good For The Game
Trailing commas make everyone happy!
## Changelog
Nothing anyone will notice besides downstreams adding to these lists
## About The Pull Request
As the title says.
`init_order` is no more, subsystems ordering now depends on their
declared dependencies.
Subsystems can now declare which other subsystems need to init before
them using a list and the subsystem's typepath
I.e.
```dm
dependencies = list(
/datum/controller/subsystem/atoms,
/datum/controller/subsystem/mapping
)
```
The reverse can also be done, if a subsystem must initialize after your
own:
```dm
dependents = list(
/datum/controller/subsystem/atoms
)
```
Cyclical dependencies are not allowed and will throw an error on
initialization if one is found.
There's also a debug tool to visualize the dependency graph, although
it's a bit basic:
Subsystem load ordering can still be controlled using `init_stage`, some
subsystems use this in cases where they must initialize first or last
regardless of dependencies. An error will be thrown if a subsystem has
an `init_stage` before one of their dependencies.
## Why It's Good For The Game
Makes dealing with subsystem dependencies easier, and reduces the chance
of making a dependency error when needing to shift around subsystem
inits.
## Changelog
🆑
refactor: Refactored subsystem initialization
/🆑
## About The Pull Request
AI controllers do not respect their tick limits, behaving as if they
need to process all controllers in one tick.
This means every time the idle subsystem runs we process 500 controllers
at once. This is bad, and induces overtime for free, which sucks.
I can't think of a reason we would need to do all this work at once.
## About The Pull Request
ai controllers that fail planning no longer process until theyre able to
plan again. this makes it so /process is called less thus you'll have
less AI competing against one another for cpu. also converts idle
behaviors into singletons
## Why It's Good For The Game
AIs that dont have a plan dont do anything during processing so its
better to just make them sit out the cycle instead of draining cpu
## Changelog
🆑
/🆑
## 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
idled basic mobs now instead of completely shutting off, will be
delegated to a much lower priority subsystem to do their planning.
## Why It's Good For The Game
Mobs can now perform their functions without needing players to be
nearby in a way that doesnt starve other subsystems. this allows animals
such as goldgrubs to eat ores, lobstrosities to fish, seedlings to tend
plants (and many others) without needing any players nearby
## Changelog
🆑
fix: idle basic mobs will now plan behaviors rather than completely shut
down
/🆑
## About The Pull Request
this makes ai controllers use cell trackers and signals to determine
when to idle
## Why It's Good For The Game
might be better than looping over all clients for every controller
## Changelog
🆑
code: The way mobs idle has been refactored, please report any issues
with non-reactive mobs
/🆑
## About The Pull Request
On one compile of MetaStation, I saw that there's 45 basic mobs on the
station, 256 on lavaland (the number growing from tendrils), and 59 in
all other z levels combined.
While we do expect Lavaland to be visited every round, at least it won't
be running during the times when no one is there, but even more
importantly, space exploration is something not done every round, so we
don't have any reason to waste our resources on AIs that will never be
interacted with.
Simple animals had an easy solution to this:
If no one is on the Z level, their AI turns off
If someone is on the Z level, they are idle unless needed.
The last simple animals that exists right now are bots, megafauna,
geese, gondolas, and some minor ones like mimic, zombie, dark wizard,
soulscythe, etc.
Point is, we're very much nearly done going through all simple animals,
so this code is being wasted just to ensure things like cleanbots won't
work if no one is on the z level, something I doubt happens often, so I
took their code and made it work for basic mobs instead. I could've done
both but I thought it would look very bad, and maybe this is a good
incentivize to get more basic mob conversions.
There's one major change here and it's that we're missing the "Idle"
mode, some basic mobs like the Lavaland village seems to be made with
intent that they'll be running even if players aren't around, so this
sets up a future PR that makes idle AI easier to add, and I want to make
sure those cases are taken into account.
## Why It's Good For The Game
We don't need to always be processing these basic mobs, and sets us in
the future to hopefully also implement idle AIs.
## Changelog
🆑
balance: Basic mob AIs with no mobs on the Z level now stop.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
In some cases, you need to perform behaviors that can occur ontop of
different behaviors. E.g. "I need to continiously spit out foam while
moving to a point". If these behaviors are put separetely, it is
difficult to determine that the behavior for spitting out foam needs to
end. And in the current code, aslong as it has not ended, the plan will
never end. So once the AI reaches the point it would stand still at the
end and spit out foam unendingly.
To work around this I've made it so behaviors can be set to allow
planning while they run if they have the
AI_BEHAVIOR_CAN_PLAN_DURING_EXECUTION flag. If all remaining behaviors
on a controller have this flag, a new plan is made. If this plan is the
exact same as the plan that was currently being performed, nothing
happens. But if the plan is different, the current one is ended and the
new plan is executed. This means situations like this are handled
gracefully now. This will be required for basic bots.
## Why It's Good For The Game
More graceful handling of "continous" behaviors! :)
## Changelog
🆑 Capybara Holly
refactor: Allows datum AI to create new plans while a plan is still
executing
/🆑
Co-authored-by: Capybara <Capybara@CapybaraMailingServices.com>
Alexis