## About The Pull Request
Adds
- baseball bat
- 9mm pistol
- laser gun
- wooden baton
- toolbox
To monkey business weapon pool
## Why It's Good For The Game
Expands coverage to more weapon types - blunt weapons, stun weapons,
storage objects, ballistic firearms, and laser firearms
## About The Pull Request
The monkey business unit test was apparently not actually spawning
monkeys on the station like it was supposed to. It was trying to find
open turfs inside of area _typepaths_, which obviously do not contain
turfs. Functionally, this means it was summoning a number of monkeys
into the same turf of the unit test z-level equal to the number of areas
on the station map. Now it will actually place one monkey in every area
of the station itself.
This was an incidental discovery while trying to diagnose #79147 with
Jacquerel. We still don't know what's causing that one, and I doubt this
will do anything about it, but nonetheless the unit test wasn't working
right.
## Why It's Good For The Game
Makes a unit test do what it was actually intended to do, which is put a
bunch of monkeys all over the station and see if they ruin anything.
This might actually cause _more_ test failures since they're being put
in a less controlled environment, but we'll see.
## Changelog
Nothing player facing.
## About The Pull Request
Replaces weakref usage in AI blackboards with deleting signals
All blackboard var setting must go through setters rather than directly
## Why It's Good For The Game
This both makes it a ton easier to develop AI for, and also makes it
harder for hard deletes to sneak in, as has been seen with recent 515
prs showing hard deletes in AI blackboards
(To quantify "making it easier to develop AI", I found multiple bugs in
existing AI code due to the usage of weakrefs.)
I'm looking for `@Jacquerel` `@tralezab` 's opinions on the matter, also
maybe `@LemonInTheDark` if they're interested
## Changelog
🆑 Melbert
refactor: Mob ai refactored once again
/🆑
Get linters working again, I was never using the correct directory
expansion syntax for checks, so why some of them still worked anyway is
beyond me.
Fixes https://github.com/tgstation/tgstation/issues/71695
I knew this was redundant at first but kept it anyway because I thought
it was fine.
However, for some code I'm writing to make issues for flaky tests, this
is going to be an issue. I'm making sure it can intelligently create
collated issues for multiple failures (rather than generating an issue
for every individual shapeshift failure, for instance), but also a more
obviously titled issue if it's only one failure. With this assertion, it
always guarantees multiple failures, and would make issues harder to
read.
To be clear, runtimes during a test ALWAYS mean failure. This check was
never necessary, I just didn't mind it.
## About The Pull Request
Area contents isn't a real list, instead it involves filtering
everything in world
This is slow, and something we should have better support for.
So instead, lets manage a list of turfs inside our area. This is simple,
since we already move turfs by area contents anyway
This should speed up the uses I've found, and opens us up to using this
pattern more often, which should make dev work easier.
By nature this is a tad fragile, so I've added a unit test to double
check my work
Rather then instantly removing turfs from the contained_turfs list, we
enter them into a list of turfs to pull out, later.
Then we just use a getter for contained_turfs rather then a var read
This means we don't need to generate a lot of usage off removing turf by
turf from space, and can instead do it only when we need to
I've added a subsystem to manage this process as well, to ensure we
don't get any out of memory errors. It goes entry by entry, ensuring we
get no overtime.
This allows me to keep things like space clean, while keeping high
amounts of usage on a sepearate subsystem when convienient
As a part of this goal of keeping space's churn as low as possible, I've
setup code to ensure we do not add turfs to areas during a z level
increment adjacent mapload. this saves a LOT of time, but is a tad
messy
I've expanded where we use contained_turfs, including into some cases
that filter for objects in areas. need to see if this is sane or not.
Builds sortedAreas on demand, caching until we mark the cache as
violated
It's faster, and it also has the same behavior
I'm not posting speed changes cause frankly they're gonna be a bit
scattered and I'm scared to.
@Mothblocks if you'd like I can look into it. I think it'll pay for
itself just off `reg_in_areas_in_z` (I looked into it. it's really hard
to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds
(0.5 if you use the old master figure) faster. life is pain.)
## Why It's Good For The Game
Less stupid, more flexible, more speed
Co-authored-by: san7890 <the@san7890.com>
MrMelbert