This is used to set the nuke disk's safety factor from applying on very
low pop player counts, as it's unlikely the disk can be secured.
I don't believe this precludes the event from being randomly chosen, but
it makes sure it wont be a certainty on very low pop when the disk
hasn't been secured from lack of players
Just to clarify this applies only at 9 population or lower.
## Why It's Good For The Game
On very very low pop, the disk is often unsecured, and.. more
importantly, a lone op is likely to have a very high chance of easily
succeeding as there is not enough crew to upkeep a watch on the relevant
areas.
This event is fun on higher populations, and needing to protect the disk
makes sense, but on very lowpop, I think it doens't quite work as
designed, as instead it just means a lot of low pop rounds will end due
to a loneop spawning if there's any ghosts about at all.
## Changelog
🆑 oranges
balance: Nuclear disk no longer needs to be secured at sub 10 population
/🆑
Productionizes #80615.
The core optimization is this:
```patch
- var/hint = to_delete.Destroy(arglist(args.Copy(2))) // Let our friend know they're about to get fucked up.
+ var/hint = to_delete.Destroy(force) // Let our friend know they're about to get fucked up.
```
We avoid a heap allocation in the form of copying the args over to a new
list. A/B testing shows this results in 33% better overtime, and in a
real round shaving off a full second of self time and 0.4 seconds of
overtime--both of these would be doubled in the event this is merged as
the new proc was only being run 50% of the time.
## About The Pull Request
Continuing the work of
https://github.com/tgstation/tgstation/pull/77850.
it started with finding one that was being missed and causing a
runtime...then I noticed a whole lot more. While I was doing this I
found callbacks that weren't being nulled in `Destroy()`, so I added
that wherever I found these spots as well as some general code cleanup.
There were a lot more of these than I initially hoped to encounter so
I'm labeling it as a refactor.
## Why It's Good For The Game
Fixes lots of runtimes, improves code resiliency.
## Changelog
🆑
refactor: fixed a bunch of instances of callbacks being qdeleted and
cleaned up related code
/🆑
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
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
### Refactor
Turns all the behavior for the nuke disk raising lone op probability
when unsecured into a new component, the "Keep Me Secure" component. As
an example (and really, I made it to test that the component was
actually working), there is a new admin plush called the "whiny plushie"
that will change icon depending on whether it is secure or not. Useful!
### Examine
I also added an examine message. Will explain below
## Why It's Good For The Game
The examine message was really what this entire pr's purpose was really
for.
>
[Capsandi](https://tgstation13.org/phpBB/memberlist.php?mode=viewprofile&u=7767)
wrote:
[↑](https://tgstation13.org/phpBB/viewtopic.php?p=665827#p665827)Wed Feb
15, 2023 2:42 pm
Someone needs to pr some sort of indicator as to whether the disk is
'secure' or not so players who don't know about the niche lone op
mechanic won't make the same intuitive assumption (though swat has been
trolled for putting it in the safe before).
I agree with this for the same reasons I did #73016 so I'll restate the
point with it here: A piece of banning a captain recently was that they
didn't secure the disk, but there is no indication in game that the disk
has special condiitons that trigger lone op, just that it should be kept
safe (which yeah, nuke ops want it). I'd rather remove the ambiguity of
a captain knowing this mechanic or not for the sake of the game, a
single examine for it is harmless
I'm considering this administration, not a feature. If maints want me to
take it out and have this be refactor only, that's fine with me
## Changelog
🆑
refactor: Refactors how nuclear activation disk works. Shouldn't notice
a whole lot but if you do, it might be because of this.
admin: Disk now has an examine message for whether it's secure or not,
to make it less ambiguous for players.
/🆑
