## About The Pull Request
Port of https://github.com/shiptest-ss13/Shiptest/pull/3330
Partial port of https://github.com/shiptest-ss13/Shiptest/pull/1601
Makes two changes to how guns handle recoil.
- Changes recoil from an erratic shaking to a kicking of your screen
relative to your firing angle
- Adds a small cosmetic recoil to all ballistics (with an accompanying
pref option to tweak or disable it)
Primary recoil still is only used as a balance lever for a very small
handful of guns (and sawoff)
## Why It's Good For The Game
Cosmetic recoil makes guns feel a lot more punchier. People who think
its a competitive disadvantage (nerds/loosers) or people with a
legitimate sickness to screen shake or similar can just turn it off.
Old recoil was just reused explosion, while new recoil feels like its
actually recoil
## About The Pull Request
Implements https://hackmd.io/@tgstation/SkeUS7lSp , rewriting Dynamic
from the ground-up
- Dynamic configuration is now vastly streamlined, making it far far far
easier to understand and edit
- Threat is gone entirely; round chaos is now determined by dynamic
tiers
- There's 5 dynamic tiers, 0 to 4.
- 0 is a pure greenshift.
- Tiers are just picked via weight - "16% chance of getting a high chaos
round".
- Tiers have min pop ranges. "Tier 4 (high chaos) requires 25 pop to be
selected".
- Tier determines how much of every ruleset is picked. "Tier 4 (High
Chaos) will pick 3-4 roundstart[1], 1-2 light, 1-2 heavy, and 2-3
latejoins".
- The number of rulesets picked depends on how many people are in the
server - this is also configurable[2]. As an example, a tier that
demands "1-3" rulesets will not spawn 3 rulesets if population <= 40 and
will not spawn 2 rulesets if population <= 25.
- Tiers also determine time before light, heavy, and latejoin rulesets
are picked, as well as the cooldown range between spawns. More chaotic
tiers may send midrounds sooner or wait less time between sending them.
- On the ruleset side of things, "requirements", "scaling", and
"enemies" is gone.
- You can configure a ruleset's min pop and weight flat, or per tier.
- For example a ruleset like Obsession is weighted higher for tiers 1-2
and lower for tiers 3-4.
- Rather than scaling up, roundstart rulesets can just be selected
multiple times.
- Rulesets also have `min_antag_cap` and `max_antag_cap`.
`min_antag_cap` determines how many candidates are needed for it to run,
and `max_antag_cap` determines how many candidates are selected.
- Rulesets attempt to run every 2.5 minutes. [3]
- Light rulesets will ALWAYS be picked before heavy rulesets. [4]
- Light injection chance is no longer 100%, heavy injection chance
formula has been simplified.
- Chance simply scales based on number of dead players / total number
off players, with a flag 50% chance if no antags exist. [5]
[1] This does not guarantee you will actually GET 3-4 roundstart
rulesets. If a roundstart ruleset is picked, and it ends up being unable
to execute (such as "not enough candidates", that slot is effectively a
wash.) This might be revisited.
[2] Currently, this is a hard limit - below X pop, you WILL get a
quarter or a half of the rulesets. This might be revisited to just be
weighted - you are just MORE LIKELY to get a quarter or a half.
[3] Little worried about accidentally frontloading everything so we'll
see about this
[4] This may be revisited but in most contexts it seems sensible.
[5] This may also be revisited, I'm not 100% sure what the best / most
simple way to tackle midround chances is.
Other implementation details
- The process of making rulesets has been streamlined as well. Many
rulesets only amount to a definition and `assign_role`.
- Dynamic.json -> Dynamic.toml
- Dynamic event hijacked was ripped out entirely.
- Most midround antag random events are now dynamic rulesets. Fugitives,
Morphs, Slaughter Demons, etc.
- The 1 weight slaughter demon event is gone. RIP in peace.
- There is now a hidden midround event that simply adds +1 latejoin, +1
light, or +1 heavy ruleset.
- `mind.special_role` is dead. Minds have a lazylist of special roles
now but it's essentially only used for traitor panel.
- Revs refactored almost entirely. Revs can now exist without a dynamic
ruleset.
- Cult refactored a tiny bit.
- Antag datums cleaned up.
- Pre round setup is less centralized on Dynamic.
- Admins have a whole panel for interfacing with dynamic. It's pretty
slapdash I'm sure someone could make a nicer looking one.
- Maybe some other things.
## Why It's Good For The Game
See readme for more info.
Will you see a massive change in how rounds play out? My hunch says
rounds will spawn less rulesets on average, but it's ultimately to how
it's configured
## Changelog
🆑 Melbert
refactor: Dynamic rewritten entirely, report any strange rounds
config: Dynamic config reworked, it's now a TOML file
refactor: Refactored antag roles somewhat, report any oddities
refactor: Refactored Revolution entirely, report any oddities
del: Deleted most midround events that spawn antags - they use dynamic
rulesets now
add: Dynamic rulesets can now be false alarms
add: Adds a random event that gives dynamic the ability to run another
ruleset later
admin: Adds a panel for messing around with dynamic
admin: Adds a panel for chance for every dynamic ruleset to be selected
admin: You can spawn revs without using dynamic now
fix: Nuke team leaders get their fun title back
/🆑
## About The Pull Request
Blocks dead mobs (observers and new players) from `Offer Control to
Ghosts`
## Why It's Good For The Game
Doesn't do nothin'
## Changelog
🆑 Melbert
admin: VV stops you from offering control of a ghost to ghosts
/🆑
## About The Pull Request
Converts `/datum/player_details` into `/datum/persistent_client`.
Persistent Clients persist across connections. The only time a mob's
persistent client will change is if the ckey it's bound to logs into a
different mob, or the mob is deleted (duh).
Also adds PossessByPlayer() so that transfering mob control is cleaner
and makes more immediate sense if you don't know byond-fu.
## Why It's Good For The Game
Clients are an abstract representation of a connection that can be
dropped at almost any moment so putting things that should be stable to
access at any time onto an undying object is ideal. This allows for
future expansions like abstracting away client.screen and managing
everything cleanly.
## About The Pull Request
This implements a new, minor, but flavorful system to IDs -- Honorifics.
Does going by your full name not suit you? Do you demand respect for the
position on Space Station 13 that you've earned and want to be addressed
by your title? Do you take yourself WAY too seriously? This is for you.
Toggled by ctrl-clicking your ID, honorifics append a title to your name
depending on your position. Certain titles (Captain, Officer, Doctor,
etc.) will only append to the start (replacing or including the
first/last name), while others (PhD., Esq.) can only be appended at the
end.
Each job TRIM has a set honorific and positions it can be assigned to. A
doctor can be "Doctor Peterson" or "Doctor Peterson Bungle" or "Doctor
Bungle". A Lawyer can only choose to be "Peterson Bungle, Esq.".
This will only occur when the speaker's voice is the same identity as
the one written on the ID's registered name. This should not interfere
with Unknown voice obfuscation, stolen ID shenanigans, or anything
gameplay-oriented. Hopefully.
This feature is also mononym friendly!
This also makes `first_name()` and `last_name()` global procs, and adds
one to check if a passed string has spaces/dashes/whitespace/whatever.
All of this is compatible with ID name changes, but the voice name must
align with the card name to display the honorific. If you are "Peter
Stinkypants" with your honorific set to display "Doctor Stinkypants",
and your ID's registered name is changed to "Peter Stinker", you show up
as "Peter Stinkypants (as Peter Stinker)" with no honorific provided. If
you become "Peter Stinker" and have a "Peter Stinker" ID, you will show
up as "Doctor Stinker" once again.
That all make sense? Great.
<details>
<summary>So about the ID name stuff...</summary>
<br>
So, when you activate an honorific on your ID, it DOES change the actual
object's name. Not the registered name, but the ID's name will go from
"Peter Dawson's ID card" to "Captain Dawson's ID card" when an honorific
is applied. This, as far as I've tested, does not mess with anything
important, but I can totally see it doing so in a way that makes
ctrl-Fing through logs harder than it needs to be. This could probably
be changed without too much effort so if the issue does arise I can fix
it. If not I am totally fine with reverting this PR until I can make it
work (if I can at all).
<br>
Admittedly this doesn't have much testing with holopads/radios, but I'm
confident the message composure is handled well enough to only display
the right names under the right circumstances. If this fucks up logging
or naming in any way tell me ASAP because I have a sinking feeling it
will in a way more catastrophic than I could ever predict. This PR has
been tested thoroughly but I have my limits.
</details>
## About The Pull Request
Was just scrolling through the Paradise github since they seem to have
more work done for 516 to see if there's anything I can port over, found
this and thought why not.
Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105
Specifically, updaing all hrefs to use the internal ``byond://``, and
adding it to grep.
## Why It's Good For The Game
More work towards 516.
## Changelog
Nothing player-facing.
## About The Pull Request
All usages of world.icon_size in code have been replaced with new
`ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on
context
Replaces some "32" magic numbers with the defines
A few bits of code have been modified to split up x/y math as well
## Why It's Good For The Game
Magic number bad, code more readable, code more flexible and I'm told
there's an access cost to doing world.icon_size so minor performance
gains
## Changelog
🆑 tonty
code: made some code relating to the world's icon size more readable
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Currently to check for Silicon access, we do:
``if is silicon or is admin ghost or has unlimited silicon privileges or
has machine remote in hand``
What has unlimited silicon privileges? Bots, Drones, and admin ghosts.
To check for AI access, it just checks for AI instead of silicon, and
doesnt check for unlimited silicon privileges.
This was kinda silly, so I thought I should make this a little easier to
understand.
Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or
``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost,
since now instead of being a var on the client, we moved it to using the
same trait but giving it to the client instead, but since we have to
keep parity with previous functionality (admins can spawn in and not
have this on, it only works while as a ghost), I kept previous checks as
well.
No more type checks, removes a silly var on the mob level and another on
the client.
Now while I was doing this, I found a lot of tgui's ``ui_act`` still
uses ``usr`` and the wrong args, so I fixed those wherever I saw them,
and used a mass replace for the args.
Other changes:
- machinery's ``ui_act`` from
https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced
with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin
ghosts no longer get kicked off things not on cameras. This was my
fault, I overlooked this when adding Human AI.
- Human AI's wand gives AI control as long as it's in your hand, you can
swap to your offhand. I hope this doesn't end up going horribly,
otherwise I'll revert this part. It should let human AIs not have their
UI closed on them when swapping to eat food or use their door wand or
whatnot.
- Bots previously had special checks to scan reagents and be
unobservant, I replaced this with giving them the trait. I also fixed an
instance of unobservant not being used, so now statues don't affect the
basic creature, whatever that is.
## Why It's Good For The Game
This is an easier to understand way of handling silicon access and makes
these mobs more consistent between eachother.
Other than what I've mentioned above, this should have no impact on
gameplay itself.
## Changelog
🆑
fix: Statues don't count as eyes to creatures.
fix: Human AIs and Admin ghosts no longer get kicked off of machines
that aren't on cameranets.
/🆑
## About The Pull Request
We be addin' peg legs an' peg arms, makin' 'em craftable fer all ye
scurvy dogs. Ye can attach 'em yerselves, no need fer a surgeon's touch,
usin' the mighty ligament hook code. There be tons o' balance tweaks an'
special properties fer these limbs. Yarrrrr!
## Why It's Good For The Game
Arrr, this be givin' ye a ghetto alternative to headin' to medbay when
yer limbs be blown off. Plus, the potential fer pirate RP be fantastic!
Who doesn’t want peg limbs? If ye think otherwise, ye be lyin’ ,and
ye'll be walkin’ the plank! Yarrrrr!
## Changelog
🆑 Hacks-The-Doors (coding) & Septicchlorine (spriting)
add: craftable peg limbs (2 planks) which are attachable without surgery
bal: peg limbs take 1.5x burn and 1.3x brute, and do reduced damage
bal: peg limbs have chunky fingers (like insuls, but per limb)
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: septic <105231896+septoBismol@users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
Currently, if you handcuff someone and they only have sign language
available to speak in (mute, no tongue, nearby people are deaf, you have
bronchitis(?)), they are rendered totally unable to communicate with
anything but emotes. This is stifling to trying to roleplay with nearby
people who want to keep you cuffed for whatever reason (security,
antagonists, weirdos who keep hugging you, etc).
So instead, I've made it so that if you use sign language while
handcuffed, you are still able to sign, but to a much more limited
degree (3 - 5 words per message).
If you're put in a straightjacket, you're still totally unable to use
sign language.
Additionally, I spruced up the messages that sign language uses to
signify tone (?, !) and added one for EXCLAIMED QUESTIONS?! I also made
the emotes work as emotes, rather than the small (easily missable)
messages in the chat box. These emotes will not fire if you sign with
tone while cuffed, to avoid you becoming a spam machine.
## Why It's Good For The Game
It lets cuffed sign language users communicate, which is usually a
pretty good thing when it comes to improving a scene for both them and
the people they're playing with.
It improves the descriptiveness of the inquisitive and exclamatory tone
messaging for sign language users, and also adds one for a combination
of the two tones.
## Changelog
🆑
qol: Sign language users can now sign in cuffs, but to a very limited
degree. They also have more descriptive emotes for questions,
exclamations, and a combination of the two.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
When I made SSpolling, jlsnow gave me his blessing to delete the orbit
polling component [where you orbit something for 20 seconds before it
chooses a ghost from the orbiters]
It's only used in a few places like soulstones replacing
jobbanned/inactive players, etc.
Also upgraded SSpolling; you can now place a little icon on the sides in
the chat message, chat message looks a lot nicer, the alert pic and the
jump target don't have to be the same anymore, and I made it be able to
pre-pick candidates since 90% of the use cases would just want 1
candidate
Also prints to chat who the chosen one was
Also made slime intelligence potions ask the user for a reason, which
will be displayed in the alert poll
## About The Pull Request
This PR makes it so that the `can_hear` proc will return `FALSE` if the
proc is called on a non-carbon that has the deaf trait.
## Why It's Good For The Game
This makes it so that non-carbon mobs can have the TRAIT_DEAF added to
them and it will now work. There isn't anything that would currently
utilize this on here. But, I do have a project downstream where
TRAIT_DEAF is added to a non-carbon mob.
## Changelog
🆑
code: TRAIT_DEAF now works on non-carbon mobs
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Revived my old PR https://github.com/tgstation/tgstation/pull/68901
Replaces the annoying tgui alert popup "Do you want to be X? | Yes | No
| Never for this round" that is hard to read and steals window focus,
with a nice clean alert in the top right that counts down. If it's the
same event/mob they stack with 2x, 3x, etc. It also shows how many
candidates/ghosts are signed up.
The poll alerts have screentips too, they countdown and show if you're
signed up, how many people are signed up, if you chose "never for this
round" (which is cancelable)
## Why It's Good For The Game
Way easier to see what role is available, you get a nice pic of the role
and get it's name in big text, you can cancel "never for this round",
and you can cancel signing up for a role before the timer is up
## Changelog
🆑
refactor: Ghost roles now offer ghosts a clickable poll button. Ghosts
can select a role, deselect it, alt-click it for "Never For This Round",
can cancel "Never", can see the countdown, and can see how many other
people are signed up for the role poll.
/🆑
## About The Pull Request
I'm still not satisfied with how ghost notifications work. This gives
every notification with a source (99% of all notifications, in other
words) a link to jump/orbit. Currently, notifications with "play"
interactions would only get the interact link, so jumping to the source
was pretty annoying.
It removes posting the entire message in the alert tooltip, as some got
pretty lengthy and it didn't seem to fit. To replace this, they will
always use headers
After:
NOTIFY_JUMP and NOTIFY_ORBIT have been merged, since the only difference
seems to be whether it's a turf. The result shaves off some redundant
lines of code, since most-every usage of notify_ghosts uses
NOTIFY_ORBIT.
## Why It's Good For The Game
More standardization for the ghost notification system. Adds a few alert
headers that never had them. All in all, makes it easier for creators to
throw alerts at ghosts
## Changelog
🆑
qol: Nearly every ghost alert should now feature a "VIEW" button, even
those with click interaction.
del: Ghost alerts no longer show the entire message in the tooltip,
instead have been replaced with titles.
/🆑
## About The Pull Request
Sets up moveloops to better catch issues with duplicated loops
Letting people modify the timer var AND have it track what bucket we're
in was a bad idea.
So instead let's store the queued time separate. Also makes
allowed_to_move return true/false instead of flags
This fixed? the null loop issue locally, I honestly have no damn idea
why. I'm gonna be working on the rest of ci here, left trackers so if it
pops up between now and merge I'll know what the issue is.
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
## About The Pull Request
During the notify ghosts refactor I was unsure why we were creating a
custom overlay for each ghost alert when new_master did the same. Turns
out - it resets icons, which is useful here. This also caused #79415.
The original notify ghosts was performing this transformation operation
O(n), which I've made O(1)
## Why It's Good For The Game
Fixes#79415
## Changelog
🆑
fix: The screen alert should no longer break ghost UI when it's huge
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
This helps clean up my favorite helper proc in the whole codebase,
`notify_ghosts()`.
The notify_suiciders, ignore_mapload, and flashwindow args are GONE.
They have been replaced with the notify_flags bitflag argument. This was
intended to make deadchat announcements a bitflag argument too, but
those got reverted right before I originally wanted to submit this PR.
The on-screen popup now shows the notification body when you hover it
with your mouse again. The format is now `[notify_ghosts message] --
[click action (orbit/jump/play)]`
Every single `notify_ghosts()` call has been changed to multiline format
and has been given trailing commas. Pretty!
## Why It's Good For The Game
Cleans up a proc that is very popular and going through a lot of changes
at the time.
Allows for further flexibility when this proc inevitably gets tweaked or
improved. 12 -> 10 args is an improvement, and it doesn't impact the
helper's flexibility at all.
## Changelog
🆑 Rhials
code: The notify_ghosts proc has been cleaned up. Please report any
abnormal changes in deadchat notification behavior.
qol: The on-screen deadchat popups now contain the notification blurb
when hovered with your mouse again.
/🆑
## About The Pull Request
The way we add multiple actions has been very unstandardized, with
several implementations of this code doing certain things wrongly (i.e.
not nullchecking `ai_controller`), so let's do something in the vein of
#74037 and just make one nice big ol' proc that catches a lot of these
cases. There are still a few things that simply can't be done here, but
this gets the most generic "give my mob some actions and also maybe tell
the AI about it" stuff done.
This is only useful in cases where we don't ever need to reference the
ability ever again when it's added. In an ideal world we would never
need to reference the ability again and it would all be self-contained,
but this is not an ideal world. However, a lot of the latticework has
been built around certain implementations of this behavior making
refactoring it just a bit easier.
I also did a lot of auditing on `Destroy()` stuff, because
`/datum/action`s listen to signals when their parent is `qdel`ing, so we
don't need to neither hold nor clear references on our mob's
`Destroy()`. This was all cleaned up now because even if we couldn't use
`grant_multiple_actions()` (the new proc I add in this PR), it's just
not useful at all and will further hinder efforts to implement this new
proc.
Also also, I noticed in some places (such as megafauna) that we were
initializing a lot of datum actions _in nullspace_. We didn't pass the
`src` argument to `New()`. I quickly fixed that, as well as got rid of
the useless types we had going on.
Also also also, I added a define macro to handle some of the cases that
melbert was speaking about in his review down below. All you need to do
is invoke the define on the typepath, and you should be good to go from
there. There's probably a better way to do it, lmk though. we do the
whole `do while` thing in order to prevent code leakages.
## Why It's Good For The Game
* Very easy to change the implementation. In case we need to do
something different in how we add actions or anything like that, we can
simply just edit instances where this proc is located.
* Standardizes addition behavior. There's a lot of cases like the
aforementioned not-null-checking `ai_controller` that we really need to
look out for, so having it all in one accessible proc ensures standard
behavior.
* Reduces copy-pasta. A lot of mobs had their own individual
implementation of this, so let's just clean up all those lines of code.
## Changelog
🆑
refactor: The way mobs get specialized actions (like revenants shocking
lights or regal rats summoning rats to their side when you slap them)
have been modified, please report any bugs.
/🆑
This doesn't touch the following case FTR:
* Instances where we need to do work on the `/datum/action` after we
`Grant()` it, like if we were to edit some variable on the action or if
we need to call procs on said action. I don't like how the current code
is so reliant on storing a variable to it, but that's a windmill to
attack another time.
## About The Pull Request
Fixes#78721
This PR does a handful of things behind the scenes to increase the
consistency of shapechange health tracking.
First of all we adjust the order of operations taken when you restore
the original body. The implementation as-was would remove the status
effect midway through and null a bunch of variables we tried to continue
using. This would result in several runtimes and code failing to run,
with the upshot that untransforming upon death would leave the caster
completely alive, with the corpse of its transformed shape at its feet.
Oops.
Additionally while testing this I realised that transferring the damagew
as also kind of fucked.
We wouldn't bother to do it at _all_ if you died, which is a shame, so I
made it simply heal you instead of reviving you so we can always do it.
Then as noted in the linked issue, we were applying all transferred
damage to a single limb, which could exceed the health of the limb and
remove damage. Now we spread it around the body.
Finally, applying damage to a human using the "force" flag would often
actually apply less damage to their _health_ than expected. This is
because arms and legs contribute only 75% of their damage taken to a
mob's overall health.
Now instead of reading `health` we read `total damage` which ignores the
limb damage modifier.
The end result of this is that if you transform into a corgi, take 50%
of your health, and transform back then you will have 50% of your health
as a human.
Previously the result would be that you'd have ~63%, then transforming
into a corgi would leave you with ~63% of a corgi's health, then
transforming back into a human would leave you at about 71%... and so on
and so forth. Now it doesn't do that.
## Changelog
🆑
fix: Dying when using (most) shapeshift spells will now kill you rather
than having you pop out of the corpse of your previous form.
fix: Damage will now be accurately carried between forms rather than
being slightly reduced upon each transformation.
/🆑
## About The Pull Request
#79139 turned out to be quite annoying, it wasn't taken into account
that these alerts can stack (ie: spiders).
Of course, I poked around the code and found some inconsistencies in the
process. For instance, there were usages of Topic for custom action
behavior which could've been consolidated. There were other instances
where jump (the default action) doesn't give a link at all, which I
think it should anyway, since the screen toast gives you this.
I've standardized it more, meaning you can use "NOTIFY_PLAY" without
writing a custom link and topic handler (for instance, MMIs)
## Why It's Good For The Game
Fixes#79198Fixes#79195
## Changelog
🆑
fix: Ghost alerts have been tuned down a bit.
/🆑
## About The Pull Request
Valentines and ERTs will no longer get mood boosts from traitor moodener
items
Closes#73432
## Why It's Good For The Game
bugge
## Changelog
🆑
fix: Valentines and ERTs will no longer get mood boosts from traitor
moodener items
/🆑
## About The Pull Request
Refactors livers so special chemical handling can be done by them,
instead of the species datum.
Plasmamen, skeletons and golems all use the liver for all their species
specific chem handling now.
## Why It's Good For The Game
SPECIES DATUM I HATE YOU!
Also, being able to handle reagents like any species if you have their
liver is REALLY FREAKING COOL and allows for emergent gameplay by mixing
various organs from various sources.
## Changelog
🆑
refactor: Mutant livers can now handle chemicals in special ways.
Currently, only plasmaman, skeleton and golem livers do it. Every other
species is the same.
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
## About The Pull Request
Converts all logging, excluding perf and investigate, to json.
I focused on making the system as easy to use and as easy to add new
categories as possible.
Due to issues related to logging to world at global creation logger is
now a byond real, which is created directly before Master
Log categories support versioning, secret flagging, and sub-category
filtering. Although all of this is entirely optional for coders.
If you ever want to add a new category and use it, all you need to do is
make the barebones category datum and the define.
I've kept existing procs such as log_game, and simply turned them into a
wrapper for Logger.Log(xxx, ...)
## Why It's Good For The Game
Makes processing and filtering logs much easier in the future, while
only minimally downgrading log crawling experience.
I am also working on a log viewer frontend for admin usage however that
will take a little bit longer to finish up.
Also makes special logging and data tracking much easier thanks to a
data list processing implementation and handling
## Changelog
🆑
server: All logs are now formatted in json, excluding perf and
investigations
/🆑
---------
Signed-off-by: GitHub <noreply@github.com>
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
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
Firstly, this var was on `/mob`, even though only `/mob/living` and
`/mob/dead` could have ever used it, so who knows how much needless
memory it was consuming on stuff such as `oranges_ear` that would never
ever ever use something like this.
Edit: okay instead of memory it just polluted variable edit windows for
all /mob when it didn't need to. I like having a slim VV window
Secondly, it's a technical improvement over the previous system as we
are able to "track" where a suicide originates from, and how we can
track that from mob-to-mob-to-mob. Previously, the boolean `suiciding`
would only inform us if they had ever been connected to a mob that had
ever committed suicide, but now we are able to precisely determine which
mob gave them the trait that they must now apparently bear until the
round restarts.
## Why It's Good For The Game
Less memory usage, more indepth ability to track suicides in case you
really need that dexterity. Currently no implemented code could benefit
from using it, but it would be pretty neat if someone could figure out a
way to have someone be guilt-tripped whenever they look into a mirror
and seeing the reflection of their past life? This PR won't actually
help you code that and it'll probably require a bit more work, but it's
a possibility of some cool interactions you can do when you have this
information available to you.
## Changelog
🆑
refactor: Some aspects of how we track suicides from your living mob to
your observer have changed- please do let us know if anything has broken
via a GitHub Issue Report.
/🆑
There's probably some technical improvements that can be made in some
parts of the code I reworked to accommodate this change, do let me know
if you spot any easy ones (or fuckups). a lot of excess comes from the
fact that any step in the TRAIT framework trusts that you are passing in
a valid datum (or subtype) so that's a thing
## About The Pull Request
Relies on #72886 for some render relay expansion I use for light_mask
stuff.
Hello bestie! Night vision pissed me off, so I've come to burn this
place to the ground.
Two sections to discuss here. First we'll talk about see_in_dark and why
I hate it, second we'll discuss the lighting plane and how we brighten
it, plus introducing color to the party.
### `see_in_dark` and why it kinda sucks
https://www.byond.com/docs/ref/#/mob/var/see_in_dark
See in dark lets us control how far away from us a turf can be before we
hide it/its contents if it's dark (not got luminosity set)
We currently set it semi inconsistently to provide nightvision to mobs.
The trouble is stuff that produces light != stuff that sets luminosity.
The worst case of this can be seen by walking out of escape on icebox,
where you'll see this
Snow draws above the lighting plane, so the snow will intermittently
draw, depending on see_in_dark and the luminosity from tracking lights.
This would in theory be solvable by modifying the area, but the same
problem applies across many things in the codebase.
As things currently stand, to be emissive you NEED to have a light on
your tile. People are bad at this, and honestly it's a bit much to
expect of them. An emissive overlay on a canister shouldn't need an
element or something and a list on turfs to manage it.
This gets worse when you factor in the patterns I'm using to avoid
drawing lights above nothing, which leads to lights that should show,
but are misoffset because their parent pixel offsets.
It's silly. We do it so we can have things like mesons without just
handing out night vision, but even there the effect of just hiding
objects and mobs looks baddddddd when moving. It's always bothered me.
I'll complain about mesons more later, but really just like, they're too
bright as it is.
I'm proposing here that rather then manually hiding stuff based off
distance from the player, we can instead show/hide using just the
lighting plane. This means things like mesons are gonna get dimmer, but
that's fine because they suck.
It does have some side effects, things like view() on mobs won't hide
stuff in darkness, but that's fine because none actually thinks about
view like that, I think.
Oh and I added a case to prevent examining stuff that's in darkness, and
not right next to you when you don't have enough nightvision, to match
the old behavior `see_in_dark` gave us.
Now I'd like to go on a mild tangent about color, please bare with me
### Color and why `lighting_alpha` REALLY sucks
You ever walk around with mesons on when there's a fire going, or an
ethereal or firelocks down.
You notice how there isn't really much color to our lights? Doesn't that
suck?
It's because the way we go about brighting lighting is by making
everything on the lighting plane transparent.
This is fine for brightening things, but it ends up looking kinda crummy
in the end and leads to really washed out colors that should be bright.
Playing engineer or miner gets fucking depressing.
The central idea of this pr, that everything else falls out of, is
instead of making the plane more transparent, we can use color matrixes
to make things AT LEAST x bright.
https://www.byond.com/docs/ref/#/{notes}/color-matrix
Brief recap for color matrixes, fully expanded they're a set of 20
different values in a list
Units generally scale 0-1 as multipliers, though since it's
multiplication in order to make an rgb(1,1,1) pixel fullbright you would
need to use 255s.
A "unit matrix" for color looks like this:
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0, 0, 0, 0
)
```
The first four rows are how much each r, g, b and a impact r, g, b and
well a.
So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of
r. and 0 units of green, blue and alpha, and so on.
A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green
component, and leave red, blue and alpha alone, shifting any red of
whatever it's applied to a green.
Using these we can essentially color transform our world. It's a fun
tool. But there's more.
That last row there doesn't take a variable input like the others.
Instead, it ADDS some fraction of 255 to red, green, blue and alpha.
So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it
could possibly be.
This is what we're going to exploit here. You see all these values
accept negative multipliers, so we can lower colors down instead of
raising them up!
The key idea is using color matrix filters
https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these
operations together.
Pulling alllll the way back, we want to brighten darkness without
affecting brighter colors.
Lower rgb values are darker, higher ones are brighter. This relationship
isn't really linear because of suffering reasons, but it's good enough
for this.
Let's try chaining some matrixes on the lighting plane, which is bright
where fullbright, and dark where dark.
Take a list like this
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
-0.2, -0.2, -0.2, 0
)
```
That would darken the lighting a bit, but negative values will get
rounded to 0
A subsequent raising by the same amount
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.2, 0.2, 0.2, 0
)
```
Will essentially threshold our brightness at that value.
This ensures we aren't washing out colors when we make things brighter,
while leaving higher values unaffected since they basically just had a
constant subtracted and then readded.
### But wait, there's more
You may have noticed, we gain access to individual color components
here.
This means not only can we darken and lighten by thresholds, we can
COLOR those thresholds.
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.1, 0.2, 0.1, 0
)
```
Something like the above, if applied with its inverse, would tint the
darkness green.
The delta between the different scalars will determine how vivid the
color is, and the actual value will impact the brightness.
Something that's always bothered me about nightvision is it's just
greyscale for the most part, there isn't any color to it.
There was an old idea of coloring the game plane to match their lenses,
but if you've ever played with the colorblind quirk you know that gets
headachey really fast.
So instead of that, lets color just the darkness that these glasses
produce.
It provides some reminder that you're wearing them, instead of just
being something you forget about while playing, and provides a reason to
use flashlights and such since they can give you a clearer, less tinted
view of things while retaining the ability to look around things.
I've so far applied this pattern to JUST headwear for humans (also those
mining wisps)
I'm planning on furthering it to mobs that use nightvision, but I wanted
to get this up cause I don't wanna pr it the day before the freeze.
Mesons are green, sec night vision is red, thermals orange, etc.
I think the effect this gives is really really nice.
I've tuned most things to work for the station, though mesons works for
lavaland for obvious reasons.
I've tuned things significantly darker then we have them set currently,
since I really hate flat lighting and this system suffers when
interacting with it.
My goal with these is to give you a rough idea of what's around you,
without a good eye for detail.
That's the difference between say, mesons, and night vision. One helps
you see outlines, the other gives you detail and prevents missing
someone in the darkness.
It's hard to balance this precisely because of different colored
backgrounds (looking at you icebox)
More can be done on this front in future but I'm quite happy with things
as of now
### **EDIT**
I have since expanded to all uses of nightvision, coloring most all of
them.
Along the way I turned some toggleable nightvision into just one level.
Fullbright sucks, and I'd rather just have one "good" value.
I've kept it for a few cases, mostly eyes you rip out of mobs.
Impacted mobs are nightmares, aliens, zombies, revenants, states and
sort of stands.
I've done a pass on all mobs and items that impact nightvision and added
what I thought was the right level of color to them. This includes stuff
like blobs and shuttle control consoles
As with glasses much of this was around reducing vision, though I kept
it stronger here, since many of these mobs rely on it for engaging with
the game
<details>
<summary>
Technical Changes
</summary>
#### Adds filter proc (the ones that act like templates) support to
filter transitions.
Found this when testing this pr, seemed silly.
#### Makes our emissive mask mask all light instead
This avoids dumbass overlay lighting lighting up wallmounts.
We switch modes if some turfflags are set, to accomplish the same thing
with more overhead, and support showing things through the darkness.
Also fixes a bug where you'd only get one fullscreen object per mob, so
opening and closing a submap would take it away
Also also fixes the lighting backdrop not actually spanning the screen.
It doesn't actually do anything anymore because of the fullscreen light
we have, but just in case that's unsued.
Needs cleanup in future.
#### Moves openspace to its own plane that doesn't draw, maxing its
color with a sprite
This is to support the above
We relay this plane to lighting mask so openspace can like, have
lighting
#### Changes our definition of nightvision to the light cutoff of night
vision goggles and such
Side affect of removing see_in_dark. This logic is a bit weak atm, needs
some work.
#### Removes the nightvision spell
It's a dupe of the nightvision action button, and newly redundant since
I've removed all uses of it
#### Cleans up existing plane master critical defines, ensures
trasnparent won't render
These sucked
Also transparent stuff should never render, if it does you'll get white
blobs which suck
</details>
## Why It's Good For The Game
Videos! (Github doesn't like using a summary here I'm sorry)
<details>
Demonstration of ghost lighting, and color
https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4
Engi-glass mesons and walking in maint (Potentially overtuned, yellow is
hard)
https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4
Diagnostic nightvision goggles and see_in_dark not hiding emissives
https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4
Sec nightvision (I just think it looks neat)
https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4
Medical nightvision goggles and other colors
https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4
Miner mesons and mobs hiding in lavaland (This is basically the darkest
possible environment)
https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4
Thermal goggles and coloring displayed mobs
https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4
</details>
I think it's pretty, and see_in_dark sucks butt.
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: The darkness that glasses and hud goggles that impact your
nightvision (think mesons, nightvision goggles, etc) lighten is now
tinted to match the glasses. S pretty IMO, and hopefully it helps with
forgetting you're wearing X.
balance: Nightvision is darker. I think bright looks bad, and things
like mesons do way too much
balance: Mesons (and mobs in general) no longer have a static distance
you can see stuff in the dark. If a tile is lit, you can now see it.
fix: Nightvision no longer dims colored lights, instead simply
thresholding off bits of darkness that are dimmer then some level.
/🆑
# Don't merge this without leading the headmins know so they can update
the server configs
### For headmins:
The following roles need to be updated:
- "Obsession" -> `/datum/antagonist/obessed`
- "Heretic" -> `/datum/antagonist/heretic` (Though this one will still
work, change it to message them on spawn)
- "Headslug Changeling" -> `/datum/antagonist/changeling/headslug`
- "Pyroclastic Anomaly Slime" -> `/datum/antagonist/pyro_slime` (Though
this one will still work, technically, change it to message them on
spawn)
## About The Pull Request
So, we have this whole system in the code to allow all mob typepaths,
species typepaths, and even antag datum typepaths to have a set policy
But we like, don't use it? For some reason we rather set a million
`get_policy` calls than use this. They're all stuck in the policy verb
and not sent to the player in any obvious.
(Also, it's super fragile, which I hate. Change the typepath and the
policy silently fails. Maybe someone can change that afterwards)
This PR updates that. All antag datums will check in `on_gain` for
policy to show to the player if there's any.
It doesn't solve the entire issue. Mob policy and species policy is not
conveyed to the player in any way BESIDES the policy verb which no one
uses. So people have no idea that it's a thing. But it helps a bit.
## Why It's Good For The Game
Better ways to convey to players how they should be playing.
Also Valentines day, because... it's crazy.
## Changelog
🆑 Melbert
config: Policy.json config got updated. The following values need to be
updated:
config: "Obsession" -> /datum/antagonist/obessed
config: "Heretic" -> /datum/antagonist/heretic
config: "Headslug Changeling" -> /datum/antagonist/changeling/headslug
config: "Pyroclastic Anomaly Slime" -> /datum/antagonist/pyro_slime
config: ALL antags in the policy.json file will now get notified of any
existing policy set by the admin team, rather than only a handful.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Tim <timothymtorres@gmail.com>
## About The Pull Request
Part of a prior PR that was closed (#72562). This version does not add
the check in CI.
## Why It's Good For The Game
The work is already done, so I figured why not.
## Changelog
N/A Nothing player facing
Co-authored-by: Jeremiah Snow <jlsnow301@pm.me>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
- Nearsighted is now a grouped status effect.
- Blindness is now a grouped status effect.
- Eye handling of blindness has improved.
- When eyes are removed, they now cause you to become blind, rather than
handling it in `update_tint`.
- Being ahealed no longer blinds you for one tick, meaning that black
overlay on aheal is gone.
- Temporary Blindness is now a status effect.
- Both Nearsightedness and Blindness have been exorcised from mob vars
and life chains. This means that we've finally cut 2 procs from life,
`handle_status_effect` and `handle_traits`, and moved both to event
based processing. Wooo optimizations.
- Swapped pacifism status effect to use apply and set helpers.
- Removed an unused admin toggle that disabled welding helmet tint but
also tint from every clothing item and also blindness from losing your
eyes.
- Clothes now generally all blind their mob more consistently.
- Oculine, eye surgery, and sensory restoration are now no longer the
only way to fix blindness from eye damage. If your eyes are healed
through any other means, it will also heal your blindness.
- Some things that made you blind, such as ling blind sting, no longer
just flat made you blind from eye damage forever. They now cause eye
damage directly, which in turn makes you blind from eye damage, as
expected.
- Pacifists can't eyestab anymore. Eyestabs now have a limit on the
amount of blur applied.
- Refactored some `is_x_covered` procs to accept flags rather than have
a lot of arguments for some silly reason.
- Unit tests for blindness.
## Why It's Good For The Game
Blindness was exceptionally poorly handled prior, primarily due to the
fact that it was tied to the mob instead of separated out
On top of that the system put a LOT of faith in proper handling of
blindness on the coder's end which was misplaced evidently. Many places
didn't update or handle blindness correctly, or just let people
perma-blind.
Deferring it to a status effect improves this a lot
## Changelog
🆑 Melbert
refactor: Refactored blindness and nearsightedness. Important to note is
that all mobs are naturally blind until their eyes are actually created.
refactor: Refactored "is covered" procs
fix: Less sources of blindness now cause permanent blindness. Includes
the "Blind" Spell and "Blind Sting" from changelings.
admin: Ahealing someone no longer flashes the blind overlay for 1 tick.
admin: I removed an unused (sort of) inaccessible admin verb that
allowed you to toggle the tint from all welding helmets (and clothing)
(and lack of eyes) in existence, let me know if you want similar back
balance: Changeling "Blind Sting" now causes eye damage (enough to
blind) rather than arbitrarily forcing blindness.
balance: Visionloss virus symptom now causes eye damage (enough to
blind) rather than arbitrarily forcing blindness.
balance: Oculine has been reworked slightly. Prior, Oculine arbitrarily
healed blindness and nearsightedness from eye damage reagrdless of how
damaged the eyes were, and applied blur on success. Now, Oculine just
heals eye damage, and blindness / nearsightedness is restored in the
process. There is now a probability every tick that eye blur is applied
based on how pure the oculine is while healing very damaged eyes.
balance: Pacifists can no longer eyestab.
balance: Any clothing item that covers your eyes contributes to getting
the bonus while sleeping, and to removing temporary blindness faster
/🆑
holoparasite types have improved code
admins can now give someone a holoparasite through a new menu in vv
dropdown
alt click holopara abilities were moved to right click (support's beacon
wasn't, but support's heal mode was)
holoparas have less hardcoded stuff so admins can edit them easier
holoparasites now get their light color from their guardian color
holoparasites no longer have the hostile faction, things will attack
them
holoparasites now have a damage overlay, so you can see how much your
summoner is damaged
holoparasite health updating is now event based rather than running on
life, so you'll see health changes everytime they happen, rather than
every 2 seconds
holoparasites fly properly again (they cant spacewalk, but count as
flying for stuff like chasms)
holoparasite creation now uses a radial menu with tooltips for each
subtype. it also shows ghosts which type you picked
holoparasites can no longer be fugu'd
adds support for ownerless holoparasites
fixes mildly related bugs along the way
## About The Pull Request
This PR is a continuing refactor of and fixes bugs introduced by my
prior PR #71864
Due to many functions in reagents having been implemented on top of
prior buggy code, their new behaviors are not as expected in-game, and
as a result reagents damage/heal robotic/cybernetic bodyparts/organs
when not appropriate; bugs like healing robotic arms with Libital is
currently possible.
To fix the errant behaviors in the newly debugged code, I have added
three variables to `datum/reagent` which are used throughout reagent
code, mainly inside of `on_mob_life` etc:
- `affected_bodytype = BODYTYPE_ORGANIC` - Used if the reagent
damages/heals bodyparts (Brute/Fire) of an affected mob.
- `affected_biotype = MOB_ORGANIC` - Used if the reagent damages/heals
generic damage (Toxin/Oxygen) of an affected mob.
- `affected_organtype = ORGAN_ORGANIC` - Used if the reagent
damages/heals organ damage of an affected mob.
The diff is large, and I have refactored the readability/maintainability
around the sections of code I was modifying. At one point I chose to
perform a quality pass on reagents because I found it quite hard to
maintain reagents code in its current state. This PR also replaces many
single-letter variables with more descriptive and readable variable
names. I also found and fixed a stray tab which was located in the
flavortext of `proc/item_heal_robotic`
## Why It's Good For The Game
Due to an old bug being fixed recently by PR #71864 a lot of
healing/damaging reagents now have an effect on robotic bodyparts. This
PR corrects the issue and changes reagents to explicitly define the body
type, bio type, and organ type which they can affect with
helaing/damage. This PR replaces a lot of single-letter variable names
with more descriptive names. I also fixed a small typo in
`item_heal_robotic` which was inserting an extra tab.
## Changelog
🆑
fix: Fixed a stray-tab typo in "item_heal_robotic"
fix: Fixed reagents and other effects which were inappropriately
affecting robotic limbs.
code: Refactored all of reagents code to be more readable and
maintainable.
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## About The Pull Request
This changes stamina damage from a damage that affects limbs (like brute
and burn) to a damage that affects the body at whole (such as tox or
oxy)
Stamina being run like brute or burn is rooted all the way back to when
it was halloss, and used exclusively for holodeck items and
hallucinations.
Most coders probably didn't even know that stamina worked like this, and
most implimentatiosn of stmaina mechanics use a generic "adjust stamina"
or a "apply_damage(type = stamina zone - body_zone_chest)" to avoid the
issues that come when stamina is evenly distributed among limbs (and
some limbs only count as a fraction to stamina damage total)
The only thing that is truly lost here, is disabling limbs (arms and
legs) with stamina damage, by aiming specifically at them with disablers
(batons always apply their stamina damage to the chest, no matter where
they hit) our through smashing limbs on tables.
The idea of making an opponent drop a weapon out of pain is fun, but
stamina doesn't support it, or make sense in context.
A depth filled limb-based pain system that has interactions with
painkillers and replaces damage based move slowdown would be fun, and
maybe something that could be implemented in the future.
## Why It's Good For The Game
The biggest draw here, is that it will make stamina easier to maintain
## Changelog
🆑 itseasytosee
code: Stamina no longer affects individual limbs.
/🆑
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Refactors hallucinations slightly, organizes them
* Refactors hallucination into a status effect
* Further hallucination proper refactoring
* Refactors battle hallucinations
* Refactors "fake item other" hallucination
* Gets it a bit closer to working state
* Refactors screwydoll and fake alerts
* Refactors fake inhand items
* Refactors a few more.
- Fake death
- Fake messages
- Fake sounds
- Projectiles
* Refactoring delusions, hallucination effects
* Furthering the hallucination status effect
- removes copypaste of hallucination pulses
* Almost finalizes the changeover to status effect
* Last staus effect stuff
* Delusion business
* Airlocks, fire, and more delusion stuff
* Finishes screwyhud. It compiles now!
* Swaps screwyhud over to a grouped status effect
* Removes hal_screwyhud
* Comment
* Bugfixing
* image cleaning
* Get rid of this it came back
* What if I finished this branch?
* Oops
* Messing with the randomness
* Mass hallucination tweaks
* +
* Some more mass tweaks
* Review
* Updates
* Unit tests hallucination icons
* More tweaks
* Move folder
* Another re-name
* Minor tweaks
* Anomaly unity
* Mass hallucination buffs
* t
* Sig
* Merge
* Lints
* Unit test already coming in clutch
* Another failure
* Use named args for cause_hallucination via some define trickery
* Some cleanup
* This is better
* adds some hallucinations
* Oops
* More sounds
* Tweaks
* Some additional documentation
* Flash
* Fixes mass hallucination
* Json changes
* Updates documentation
* Json conflicts
* Makes it work
* Missed that one too
* Helpers
* More signalization (WIP)
* Fixes bump
* Missed a helper use
* Dumb
refactor: A bunch of things that used to not do anything (or just fall back on the chest) when targeting a limb that someone was missing will now be far more likely to attack another limb!
ran_zone() returns all possible zones a mob CAN have, even if they've already lost the limb.
This can result in attempting to target bodyparts that do not exist, and requires additional sanity checking (and in most cases, coders typically just default to targeting the chest which is boring.)
This adds a helper that will now randomly pick from the zones/bodyparts that the mob DOES have, and return one of them. This'll allow a bit more dynamic functionality since you won't always fall back on the chest as a target.
cl ShizCalev
qol: Added a new mob helper complementary to ran_zone() called get_random_valid_zone(), which can only return zones/bodyparts that a mob DOES have.
/cl
makes the nuke op player with the most nuke ops playtime the leader
makes the leader start with loud mode on on their radio
idea for that second one from BeeStation/BeeStation-Hornet#6631
making the most playtime nuke op the leader prevents 1st time players from rolling it, they will generally be more competent, and able to be entrusted, just like you can trust a head of staff more. a player with more competency will also probably be better at actually leading and not just clicking a button to open the ship, if they try.
the radio is a tiny change to make the leader matter more, and able to give better leadership, because im pretty sure most people dont even realize the leader has access to loud mode
* put logging procs into their own files
* Moving more procs into their own files
* Moving talk
* The last of the logging
* ticks shuttle.dm
Co-authored-by: tattle <article.disaster@gmail.com>
FalloutFalcon
