## About The Pull Request
Previously our code for getting the job associated with a trim involved
checking the assignment against every possible job's title:
8c3c9a6ea2/code/datums/id_trim/_id_trim.dm (L32-L36)
This, however, didn't work with departmental security officers, as their
job title doesn't match the trim assignment:
8c3c9a6ea2/code/modules/jobs/job_types/security_officer.dm (L1-L2)8c3c9a6ea2/code/datums/id_trim/jobs.dm (L1103-L1104)
Instead, we remove this code and replace it with a `/datum/id_trim/job`
subtype proc that just returns the `job` variable, which this subtype
has.
This fixes our problem.
We leave the parent `find_job()` proc just returning null, as to avoid
needing an `istype(...)` check where we call it, and as
`/datum/id_trim/job` is associated with _station_ jobs while there may
be cases where we want a non-station id trim to be able to return an
associated job.
## Why It's Good For The Game
Fixes#86887.
## Changelog
🆑
fix: Fixed trims which did have an associated job but whose assignment
didn't match a job title causing null jobs to be assigned to accounts.
This fixes departmental security officers not being able to purchase
things from the security vendors.
/🆑
## About The Pull Request
Closes#86905 by adding an action flag to prevent usage of certain moves
from inside of pipes. Should be assigned to most of our actions to be
honest.
## Why It's Good For The Game
Mindswapping from inside of pipes is extremely cheesy and has quite
literally no counterplay, permanently forcing someone into being a mouse
without them being able to react, do anything or even know about your
presence is not fun at all.
## Changelog
🆑
fix: Mindswap can no longer be used inside of pipes
/🆑
## About The Pull Request
This rebalances the Laser Musket and Heroic Laser Musket
Replaces glasses with 2 drinking glasses in the crafting recipe
Removes 2-handed demand
Standard shot damage slightly increased and stamina damage greatly
decreased
Heroic shot made a 3-round scatter shot, very powerful, damage and
stamina damage decreased to compensate
Crank-charge weapons, except the thermal revolvers, can be charged while
moving
Muskets can also be worn on jackets
## Why It's Good For The Game
These things were severely underused, and I always kinda wanted them to
be crankable while you moved, I just didn't know how. This should also
help the Militiamen ERT be less of a joke. I would appreciate
balanceposters giving some advice on the numbers if you're seeing this.
The heroic musket is incredibly rare, and SHOULD be pretty powerful.
## Changelog
🆑
balance: laser muskets have been rebalanced
balance: crank weapons can be charged while moving
/🆑
## About The Pull Request
123 changed files and multiple crashes after writing broken regex, I
replaced most remains of direct spans with macros. This cleans up the
code and makes it easier to work with in general, see justification for
the original PR. I also fixed a bunch of broken and/or unclosed spans
here too.
I intentionally avoided replacing spans with multiple classes (in most
cases) and spans in the middle of strings as it would impact readability
(in my opinion at least) and could be done later if required.
## Why It's Good For The Game
Cleaner code, actually using our macros, fixes borked HTML in some
places. See original PR.
## Changelog
Nothing player-facing
## About The Pull Request
This PR significantly enhances how zero-g movement works. Its no longer
locked to one of 8 directions, everything now has inertia and is
affected by weight. This means that throwing a piece of wire will no
longer completely reverse your movement direction, and that being thrown
out of mass driver no longer will slow you down to a halt at some point.
This leads to following gameplay changes:
* Guns now accelerate you. Ballistics have higher acceleration than
lasers, and higher calibers have higher acceleration than smaller ones.
This means that firing full-auto weapons in zero-g will make you drift
and accelerate significantly. While this can be a hilarious way to
travel in space, it makes using them trickier.
* Impacting a wall or an object while moving at high speeds will cause
you to violently crash into it as if you were thrown. Careful when
exploring!
* Jetpacks now have inertia. Changes introduced in #84712 have been
mostly reverted, although speed buff has been reduced to 0.3 instead of
0.5 (although this is compensated by new movement mechanics, so overall
speed should be roughly equal). All MODsuit jetpacks now possess the
speed boost. Advanced MODsuit jets (which has also been added back) and
captain's jetpack instead have higher acceleration and stabilization
power, providing much more precise control over your movement.
* Firing guns while moving on a jetpack will partially negate your
pack's acceleration, slowing you down. Non-advanced jetpacks'
stabilization is not enough to compensate for heavy caliber weaponry as
sniper rifles, shotguns or rocket launchers.
* You no longer instantly decelerate upon sliding along a wall. Instead,
it may take a few tiles if you are moving at extreme speeds. Passing
over lattices still allows you to grab onto them!
As space movement is angle-based instead of dir-based now, its much more
smooth than before due to using new movement logic.
Example of jetpack stabilization in action:
https://github.com/tgstation/tgstation/assets/44720187/6761a4fd-b7de-4523-97ea-38144b8aab41
And, of course, you can do this now.
**This pull request requires extensive gameplay testing before
merging**, as a large amount of numbers have been picked arbitrarily in
an attempt to keep consistency with previous behavior (guns and
normal-sized items applying 1 drift force, which is equal to what
everything applied before this PR). Jetpacks and impacts may also
require adjustments as to not be frustrating to use.
Closes#85165
## Why It's Good For The Game
Zero-G refactor - currently our zero-g movement is rather ugly and can
be uncomfortable to work with. A piece of cable being able to accelerate
you the same as a duffelbag full of items when thrown makes no sense,
and so does instantly changing directions. Inertia-based version is
smoother and more intuitive. This also makes being thrown into space
more of a hazard (possibly opening the door for explosive
decompressions?)
Jetpack inertia and gun changes - this is mostly a consequence of
inertia-based movement. However, zero-g combat being preferred during
modes like warops was an issue due to it negatively affecting everyone
without jetpacks which are in limited supply onboard. This reverts the
mobility changes which severely impacted space exploration, while making
zero-g combat more dangerous and having it require more skill to be a
viable option.
## What's left
- [x] Refactor moth wings to use jetpack code
- [x] Refactor functional wings to use jetpack code
- [x] Locate and fix a recursion runtime that sometimes occurs upon
splattering against a wall
- [x] Add craftable tethers and modify engineering MOD tethers to use
the same system
## Changelog
🆑
add: You can now craft tether anchors, which can be secured with a
wrench and attached to with right click. They won't let you drift into
space and you can adjust tether length/cut it via lmb/rmb/ctrl click on
the wire.
add: MOD tethers now remotely place and connect to tether anchors
instead of throwing you at where they landed.
balance: MOD tethers can now be used in gravity
balance: Jetpacks are now inertia-based.
balance: Guns can accelerate you significantly in zero-g.
balance: All jetpacks now give you equal speed buff, however advanced
MOD ion jets and captain's jetpack have higher acceleration/deceleration
values.
refactor: Refactored zero-g movement to be inertia-based and utilize
angles instead of directions.
/🆑
## About The Pull Request
Yeah, I've got the `SSticker.HasRoundStarted` check wrong.
## Why It's Good For The Game
Until proven otherwise, monkeys do not reproduce by mitosis.
## Changelog
🆑
fix: The Pun Pun job trait doesn't leave behind a fake (or is it?) Pun
Pun.
/🆑
## About The Pull Request
Removes particles from Slimed and Slime Food status effects to fix fps
lag in xenobio
## Why It's Good For The Game
Particles, when used in excessive density, lag the shit out of clients
because BYOND. Xenobiology not only creates a lot of particles using
both of these status effects, it also rapidly duplicates because of the
design of xenobiology. Ergo, massive lag as xenobiology scales up in
size over the round progression. This is bad for obvious reasons. Last
PR got ignored by both keyholders and maintainers #86076 so I'm remaking
it because letting an FPS fix stale out is incredibly bad.
Long-term for particles, because they're a dumpster fire from BYOND but
we don't want to restrict people from using the feature, we should have
a particle management subsystem that keeps track of particle density in
an area using the cell system to automatically approve/deny creation of
particles to avoid too high of clientside costs, and also automatically
handling using shared holder particles in nullspace and adding to
viscontents so we can use one particle everywhere it's needed without
creating multiple
ccing @armhulenn cuz they're a particle gamer
## Changelog
🆑
fix: Removes particles from Slimed and Slime Food status effects to fix
fps lag in xenobio
/🆑
## About The Pull Request
all audible emotes share a cooldown now, that means, for example:
emoting `*scream` will play a sound, then emoting `*cry`, if the
cooldown for `*scream` hasn't passed, will not play a sound for the
`*cry`, but will still play the emote. Note - all audible emotes have a
default audible cooldown of 2 seconds, unless overriden on some emotes.
## Why It's Good For The Game
- prevents people from spamming multiple audio emotes in quick
succession.
- allows us to add more emote sounds without fear of players abusing
them for spam.
- less audio from emotes makes the audible emotes more special and less
ear-fatigue-ing
- forces players to be more considerate with what audible emote they
use, increasing quality of their usage for roleplay.
## About The Pull Request
Previously the imaginary friend greeting message would be called on
`Login()`, but this meant that it could run before it actually linked
the `owner` value, thus putting nulls in the message where the owner's
name should've been.
This just changes it so `greet()` is only called on `Login()` if there's
already an owner linked, otherwise calling it when being attached to an
owner.
## Why It's Good For The Game
Better if the greeting message actually says whose imaginary friend you
are.
## Changelog
🆑
fix: The greeting message imaginary friends get upon becoming one
actually includes the owner's name, instead of displaying nothing where
it should've been.
/🆑
## About The Pull Request
This is one of the stupidest issues I had the displeasure of working
with and I still do not know concrete details behind the issue because
some of the code introduced in this (supposed-to-be) debug PR
accidentally fixed said issue. Essentially, under odd circumstances of
the user either being SSD or having their storage focus stolen by
something else, an observer who had their storage UI open via
autoobserve could break their UI by moving away because that improperly
removed the user from some lists. This is the primary theory judging
from what fixed the issue, but sadly there is no concrete info behind it
as all attempts to reproduce the bug, both locally and on live, have
failed.
Closes#85259
## Changelog
🆑
fix: Storage UI should no longer (not so much) randomly disappear,
hooray!
/🆑
## About The Pull Request
anything and everything from ghosts to supermatter damage was getting
soapbox speech, this adds a check for isliving so it only gives it to
mobs
## Why It's Good For The Game
bugs bugs bugs
## Changelog
🆑
fix: fixes soapbox being given to non-mobs
/🆑
## About The Pull Request
<details>
- renamed ai folder to announcer
-- announcer --
- moved vox_fem to announcer
- moved approachingTG to announcer
- separated the ambience folder into ambience and instrumental
-- ambience --
- created holy folder moved all related sounds there
- created engineering folder and moved all related sounds there
- created security folder and moved ambidet there
- created general folder and moved ambigen there
- created icemoon folder and moved all icebox-related ambience there
- created medical folder and moved all medbay-related ambi there
- created ruin folder and moves all ruins ambi there
- created beach folder and moved seag and shore there
- created lavaland folder and moved related ambi there
- created aurora_caelus folder and placed its ambi there
- created misc folder and moved the rest of the files that don't have a
specific category into it
-- instrumental --
- moved traitor folder here
- created lobby_music folder and placed our songs there (title0 not used
anywhere? - server-side modification?)
-- items --
- moved secdeath to hailer
- moved surgery to handling
-- effects --
- moved chemistry into effects
- moved hallucinations into effects
- moved health into effects
- moved magic into effects
-- vehicles --
- moved mecha into vehicles
created mobs folder
-- mobs --
- moved creatures folder into mobs
- moved voice into mobs
renamed creatures to non-humanoids
renamed voice to humanoids
-- non-humanoids--
created cyborg folder
created hiss folder
moved harmalarm.ogg to cyborg
-- humanoids --
-- misc --
moved ghostwhisper to misc
moved insane_low_laugh to misc
I give up trying to document this.
</details>
- [X] ambience
- [x] announcer
- [x] effects
- [X] instrumental
- [x] items
- [x] machines
- [x] misc
- [X] mobs
- [X] runtime
- [X] vehicles
- [ ] attributions
## Why It's Good For The Game
This folder is so disorganized that it's vomit inducing, will make it
easier to find and add new sounds, providng a minor structure to the
sound folder.
## Changelog
🆑 grungussuss
refactor: the sound folder in the source code has been reorganized,
please report any oddities with sounds playing or not playing
server: lobby music has been repathed to sound/music/lobby_music
/🆑
## About The Pull Request
This PR introduces three new fish that can be caught from deep fryers.
That's right, deep fryers are also fishing spots now. Is it silly? Yeah,
but this is more or less the reason I made a whole PR to make fish
edible. They've two gimmicks: one is that they're already fried, and
neither raw nor gorey and can be cut into nuggets. The other is that
they can evolve into the next type just by growing, no need of pairing
them with each other, starting from the 'fryish', then the 'fritterish'
(and its two variants: 'bernard-fish' and 'matthew-fish', big pun on the
english food company) and finally the 'nessie-fish' which is very rare
and big and you'd probably get 20 nuggets by cutting it alone.
Other than that, this PR adds a simple growth mechanic to fish, where
they get a bit larger each time they're fed. The gained size and weight
depends on several factors like hunger, their current size and weight
and how much until they hit the maximum cap of twice the initial size
and weight. This means bigger fish grow slowier, and it's better to feed
them once in a while but not every other second. Obviously size and
weight influence a lot of fish mechanics, so it's good to have a way to
increase these values outside of breeding RNG (which is very shallow).
TL;DR: Feed the fish once their hunger reaches 50% circa for maximum
growth.
Included in the PR are a few tidbits, like fixing a little mistake
around the 'picky eater' fish trait, more readable code around the
fish_growth component (unrelated to the aforementioned growth mechanic)
and hunger or adding the fish evolution datum for armored pikes (normal
pikes plus stinger trait, which I basically forgot to), and adjusting
how weight and size of offsprings is calculated.
## Why It's Good For The Game
First and foremost, a brand new on-station fishing spot that is not the
fishing portal, toilets (or the rare moisture traps in maint). Second, a
fish growth mechanic through which weight and size can be increased.
Third, a few code things. Four, little bugs, now fixed.
Fifth, have a screenshot of me fucking around to find out how many bites
it takes to eat all of the deepfried gargantuan nessie (53, and I had to
spawn another 10 humans to finish it):
## Changelog
🆑
add: You can now fish new, tasty treats by the station deep fryers.
add: You can now grow fish inside an aquarium by feeding them regularly
(at 50% hunger for maximum growth).
add: Added the evolution for pikes to armored pikes.
/🆑
## About The Pull Request
Diseases copy their instances, so they should be cleaned up afterwards
Closes#86800
## Changelog
🆑
fix: Fixed infective components not cleaning up disease datums after
themselves
/🆑
## About The Pull Request
bot modes werent correctly reflecting the bot's AI states. this pr fixes
that. also fixes some issues where the bot's AI might get stuck
inbetween switching modes
## Why It's Good For The Game
closes#86771
## Changelog
🆑
fix: botkeeper now displays bot's correct states!
/🆑
Fixes#86784
## About The Pull Request
Although some of the issues found were a direct result from #86692
(c698196766), there was still 40% of
length-related issues that wouldn't be covered anyways that are fixed in
this PR. I.E.:
* Name inputs without `MAX_NAME_LEN`
* Desc inputs without `MAX_DESC_LEN`
* Plaque inputs without `MAX_PLAQUE_LEN`
* Some people just screwed up the arguments so it would prefill
something like "40" in the `default` var because they didn't name their
vars.
To help me audit I added a lot of `max_length` named arguments to help
people understand it better. I think it might be kinder to have a
wrapper that handles adding `MAX_MESSAGE_LEN` in a lot of these cases
but I think there is some reason for a coder to be cognitive about input
texts? Let me know what you think. I didn't update anything
admin-related from what I can recall, let me know if anything needs to
be unlimited again.
## Why It's Good For The Game
The change to `INFINITY` notwithstanding, there were still an abundance
of issues that we needed to check up on. A lot of these are filtered on
down the line but it is clear that there needs to be something to catch
these issues. Maybe we could lint to make `max_length` a mandatory
argument? I don't know if that's necessary at all but I think that the
limit should be set by the invoker due to the wide arrangement of cases
that this proc could be used in.
This could all be a big nothingburger if the aforementioned PR is
reverted but a big chunk of cases fixed in this PR need to be fixed
regardless of that since people could put in 1024 character names for
stuff like guardians (or more now with the change). Consider this
"revert agnostic".
## Changelog
🆑
fix: A lot of instances where you could fill in 1024-character names
(normal limit is 42) have been patched out, along with too-long plaque
names, too-long descriptions, and more.
/🆑
## 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
setting full_recalc to false would delete the entire field. setting it
to true would double what it was meant to be
## Why It's Good For The Game
fixes advanced proximity sensors field calculations
## Changelog
🆑
/🆑
## About The Pull Request
Adds a new var called `wound_clothing` to `apply_damage` and
`receive_damage` which will be checked in `check_woundings_mods` if it
should also apply the damage to the jumpsuit. It's `TRUE` by default.
Changes `irradiated` and `body_temperature_damage` to not wound
clothing. This also removes the `10 >= damage` check for burns for
clothing damage as it was there to prevent freezing from harming clothes
which is no longer a problem.
## Why It's Good For The Game
Not all brute/burn should also the damage the clothes. This allows for
damage to specify if it should damage clothes or not. Radiation burns
should not shred my clothes. Code that prevents all damage equal or
below ten burn from damaging clothes is BAD, my clothes should BURN.
`TRUE` by default so everything else should work normally.
fix: #84046
## Changelog
🆑 Goat
balance: burn damage equal or under to ten will now damage your jumpsuit
(does not apply to internal temp damage)
fix: radiation burns no longer damage your jumpsuit.
code: added a new var to applying damage to set if it should apply
damage to clothes.
/🆑
## About The Pull Request
So, as you may know, I really like the bootleg weaponry this game has,
but after dealing with gun code for the crossbow, I wasnt inclined to
make more of it. However, when I'm playing ss13 I often have background
noise on, and one day I was listening to an age of empires game, which,
if you aren't aware, is basically a medival rts, featuring a weapon
called an "organ gun". Said organ gun is basically 8 or so muskets stuck
together firing at once. And well, given SS13 has pipeguns, also called
muskets, I couldnt pass up the pun of "pipe organ gun." And thats why
this pr exists. However, as I am noticing I have a habit of doing, I
tend to end up coding more than I ever initially planned.
So what does it add? Well, lets start with the pipe organ gun.
<img width="428" alt="image"
src="https://github.com/user-attachments/assets/0cb93fb9-6ed3-4cb1-a340-0b54832ac577">
The pipe organ gun is made from wood, pipes, iron, typical maints weapon
stuff. Where it differs is it isn't a handheld object - it's a machine
you push and pull around akin to say, the pirate cannons. It can hold up
to 8 pipegun shells, and launches them all at once when lit with
anything that ignites stuff, like a welder, match, torch, etc. It does a
lot of damage, but requires time to reload, and a smart enemy can just
lie down and ignore it. Or maybe it'll just roll 8 of the really bad
ammo types and do nothing, who knows.
https://github.com/user-attachments/assets/5ee1353b-c965-4f47-aa22-4f5cfeb04c51
Initially I planned to use the cannon code as a base, but that presented
a lot of issues, as they need to use cannonballs (which arent ammo in
the traditonal sense), along with only being single shot among other
things. So I made an entire new type of structure called Mounted guns,
which are like cannons that can use conventional ballistic ammo, and
dont have any of the restrictions, and made to be customizable. You want
a gun that takes plasma bars as ammo and launches fireballs? it can do
that. You want to have a rebar ballista, that can shoot up to 3 rods at
once, but only needs to be loaded once? It can do that too. Hell, you
could probably just make full-on gun emplacements with some code
changes. If it's a projectile, it can shoot it, and if its an object, it
can use it as ammo. A list of the current stuff you can change is below.
<img width="510" alt="image"
src="https://github.com/user-attachments/assets/107abbc1-a004-4724-9627-a3388f92cd63">
Which leads me to the second gun I added, which is more of an example of
what can be done with the mounted_gun class.
The canister gatling spawns on the flying dutchman pirate ship, with
enough ammo for five shots.
<img width="453" alt="image"
src="https://github.com/user-attachments/assets/46fdc16e-813a-4e14-b25a-9cf49d245ca6">
Five shots may not sound like much at first - but thats because each
shot is a burst of 50 individual shrapnel bullets. It's unable to break
any walls or doors except for windows, but against anything that isnt a
structure... well, as shown below, they'll have a very bad day.
https://github.com/user-attachments/assets/3519c49d-97e6-4095-99cf-ee8039adbaba
If people like these concepts, I genuinely might add that engineering
rebar ballista.
## Why It's Good For The Game
As said above, I'm a big fan of the whole improvised armory concept ss13
has, and the fact the only "big" gun featured is the trash cannon (which
is locked behind maint loot) is a shame. I felt the pipe-organ gun was a
good compromise - as stated, its just eight pipeguns stuck together,
with all the strengths (high damage output) and weaknesses (slow reload,
needs to be dragged around, cant hit people on the floor, cant damage
walls) that it lacks. As for the canister gatling, I dont forsee it
being a massive problem, as it cant breach walls or doors, so it isn't
just a better cannon.
## Changelog
🆑 WebcomicArtist
add: Added pipe-organ gun: a buildable object akin to trash cannon that
takes pipegun rounds, and shoots up to 8 off at once.
add: Added The Canister Gatling, a rapid fire but non-destructive cannon
for skeleton pirates. Also Canister shot ammo.
sound: Added sounds for the above guns.
image: Added sprites for the guns as well.
code: Added a whole "mounted_gun" class that is basically cannons but
you aren't forced to use cannonballs as ammo and load them with
gunpowder.
/🆑
## About The Pull Request
Xenos can apparently use shenanigans such as
https://github.com/tgstation/tgstation/issues/86703 to put some items in
their hand, and there are likely methods like this dotted around the
codebase. However, the signal to put something in their hand is called
consistently across any process that would cause them to pick up or
otherwise have something to put in their hand, so instead I added
/datum/component/itempicky to xenos.
While I was in there, I expanded the functionality of itempicky; it can
run a callback to determine a condition that needs to be met now.
## Why It's Good For The Game
Fixes https://github.com/tgstation/tgstation/issues/86703
Expands a component's usefulness
## Changelog
🆑 Bisar
fix: Xenomorph restrictions on items they can pick up have had their
determining logic made more _robust_.
code: The itempicky component (restricts what can be picked up via a
whitelist) can now, optionally, have a callback fed to it to determine
cases of bypassing that whitelist.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
So, I've been looking into manually loading job traits today, and it
seems the buttons don't appear until you reconnect. Upon further
investigations, it turns out that the code doesn't support showing lobby
buttons outside of SSstation init. To add injury only up to three
buttons can be displayed for some stupid reason (the lack of code for x
offsets), plus the buttons aren't relocated when one is removed, thus
possibly leaving behind an empty gap.
This PR fixes all of that, while removing some crumbs of shitcode from
new players' HUDs and making sure to remove datum traits and references
are removed when the trait is deleted (usually never the case outside
VV).
## Why It's Good For The Game
Lobby buttons should ALWAYS be shown to the player if the relative trait
is loaded, the only exception being the conditions set by the trait
itself (for job traits is the job age and whether the game has started
or not), while the offsets of the lobby buttons should stay synced with
how many are being displayed to the new player at any given time, so if
a button is deleted, the others are relocated to avoid having leaving an
empty gap behind.
Beside, this is necessary for the lobby button for the playable pun pun
to show up during Monkey Day.
## Changelog
N/A, all backend.
## About The Pull Request
Earlier this day, I have found myelf adding a check to the fish petting
proc Ben added recently along with his aquarium UI rework, so I've
thought it'd be good if players could do it regardless of aquariums.
I've also added a couple lines to check if it's a safe environment and
the fish isn't dead, because petting a dead or drowning fish shouldn't
solicit much of a cute reaction.
Furthermore, petting aggressive fish comes with a coin flip where you
get your hand bitten half of the times. I think it's a pretty much
reasonable interaction.
Also, petting chasm crabs lowers their anger slightly, which determines
the behavior of the juvenile lobstrosity they grow to be.
## Why It's Good For The Game
Polishing a fish feature added by another contributor.
## Changelog
🆑
add: You can pet fish while holding them. Be wary of petting aggressive
fish.
/🆑
## About The Pull Request
You can now interact with the fishing portal generator with a multitool
to load it in the buffer and subsequently link fishing spots to it by
tapping them with the same multitool. The maximum number of fishing
spots that can be linked at once depends on the tier of the matter bins
of the machinery. Normally, while you can link fishing spots from other
z-levels, they can only be activated if they're on the same z-level as
the machinery (or if both are on station for multi-z stations). This
limitation can be bypassed by upgrading the machinery with a tier 3 or
higher capacitator.
While it's possible, I'm not spriting new fishing portal overlays and
icons for the radial menu for every fish source out there (yet). The
code is enough work for now.
This also comes with a unit test, because there is no such thing as too
many unit tests for fishing.
## Why It's Good For The Game
Fish portal generators are designed to let players fish a different
bunch of things while being able to be moved wherever you like, unlike a
lake or an ocean, with all the comfort of being able to able to catch
fish from distant locations. Allowing players to link other fishing
spots to it fits its design. It also means that you can go out and
explore, find more fishing spots and then return to the station without
having to detach yourself from the ongoing round for several more
minutes.
## Changelog
🆑
add: You can now link fishing portal generators to other fishing spots
with a multitool. The number of fishing spots that can be linked at once
and whether the link can be activated from different z levels depends on
the tier of the stock parts it's built with.
/🆑
---------
Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com>
## About The Pull Request
A foreword, I had to refactor a few bits of shitcode my past self added
first. For context, the "gone fishing" and "actively fishing" traits
only had one source, which is the fishing challenge itself, ad there was
no way to access the challenge from outside its code, except for a few
weakrefs which were being used as sources for the aforementioned traits
(the shitcode in a nutshell). There were also a few signals that I
didn't like because they were being sent to the harder-to-access
challenge datum rather than the user. So I scrapped the traits for a
couple signals to send to the user, then added a global list as a mean
to easily access the challenge datum, and lastly changed the code to
accomodate the titled feature (and allow the challenge to recalculate
its difficulty DURING the minigame phase)
Moving on to the actual feature: I've added a component that can be
added to objects on which mobs can be buckled to or items. When equipped
in the right slots or buckled to, the object will adjust the difficulty
of current and future fishing challenges by a certain amount (more often
than not positive, but there're many exceptions) as long as the object
isn't equipped or the user is unbuckled.
I've been having some fun adding component to a ton of clothes in the
game as well as chairs. Way too many objects to enumerate, so I'll give
you the general idea:
- each carp-themed article provides a slight positive modifier (easier)
- some (not all) doctor-related garbs provide a marginal positive
modifier each (fish doctor jokes)
- floortile camo clothes have positive modifiers
- Tuxedo, laceups, gowns provide negative modifier (more difficult)
- utility garbs such as bio/bomb/rad hoods and suits are quite bad. Riot
armor too.
- boxing gloves are very, very bad. Insulated gloves and haul gauntlets
are also very bad, to a lesser degree.
- **tackle** gloves are good. (pun intended)
- wizard garbs are good, because wizards are good at casting. (also a
pun)
- magboots slightly bad. Space suits bad.
- Blindfolds and welding protection are also bad. Gas masks marginally
bad.
- Pirate attire is nice to have. (I just vibed a little on this one)
- plastic chairs are quite versatile because they can be carried around,
but the mime chair is the best, followed by ratvarian chairs.
- Fishing toolboxes, analyzers and the fish catalog are a plus, because
they can be held.
- And the fishing hat, obviously (not as great as you'd think)
Some of these may be subject to change depending on what people say.
## Why It's Good For The Game
A hundred lines of fishing challenge code made ever-so-slightly less
awful, and a way to modify fishing diffculty beside skills and bait.
## Changelog
🆑
add: Your current clothes and what chair you sit on can now influence
the difficulty of fishing minigames. Having a bare minimum of fishing
skill will let you distinguish which objects can help and which won't,
so keep an eye out. Holding fishing toolboxes, fish analyzers or fish
catalogs can also help.
/🆑
## About The Pull Request
Closes#61216Closes#57516
Arcane gave greenlight on this PR as its unlikely that this'll be
cheesed or affect balance in any way, and in worst case scenario mass
account changes will just summon space IRS on the offending HoP
## Changelog
🆑
fix: Changing ID card's trim now properly adjusts linked bank account's
job, allowing you to receive bounties for your new job
/🆑
## About The Pull Request
makes "busser" id trim "Busser"
## Why It's Good For The Game
other job's the first letter is capital
## Changelog
🆑
spellcheck: busser is now Busser (with big B)
/🆑
## About The Pull Request
Another batch of changes to examine, ideas being courtesy of Melbert and
Swanni. When examining an item you will now see tags with tooltips
elaborating on their meaning instead of having each property displayed
in a separate line. Additionally, examines now use fieldsets, saving a
line previously spent on displaying an item's name and instead putting
it directly into the top outline. Embedding and slapcrafting also
display their properties as tags, and combat info now displays item's
sharpness.
Here are some examples, each tag previously taking up its own line.
Additionally, protection classes now better elaborate on items'
temperature protection properties and tell you the exact temperatures
that an item can withstand
## Why It's Good For The Game
Tags are a very intuitive system used in many games and we could benefit
from it too. Compressing seven lines of text into one while retaining
readability and all information within by using tooltips will majorly
cut down on chat space used by examines.
## Changelog
🆑
refactor: Refactored how examines display item properties. A lot of them
are now displayed as tags that you can hover over to receive details
about, like item size, resistances and materials an object is made of.
qol: Protection classes now better elaborate on thermal resistances of
items, displaying the exact temperatures they can protect you from.
/🆑
## About The Pull Request
This will fix#86668, caused by #86031
## Why It's Good For The Game
This will fix#86668, caused by #86031
## Changelog
🆑
fix: You once again need to right click to use tackling gloves.
/🆑
## About The Pull Request
when working on #86031 , i added some checks that were already being
handled earlier in the chain, serving nothing. thanks to melbert for
catching these
## Why It's Good For The Game
removes some duplicated checks
## About The Pull Request
This PR nerfs the mood event from fishing from 5 to 4. In exchange,
after catching a fish, you can release it in the appropriate fishing
spot for a minor positive mood event (if it's alive, or if the user has
either the morbid or naive traits). It also counts towards fish
population for fish that are limited in the amount of times they can be
catched. Mobs with the naive trait (clowns) get the positive mood event
even if the fish is dead or being released in a bad place like lava
Some fishing spots like toilets and moisture traps don't have this
option, but that's because they've their own interactions with fish
that'd otherwise be overridden by it.
This PR also fixes mobs with the morbid trait (coroners) not enjoying
aquarium in their own morbid ways and add a few touches pertaining the
naive trait like alternative chat messages when interacting with the
fish.
## Why It's Good For The Game
This gives players a way to get rid of unwanted fish without leaving it
to die on the floor, also it's in the spirit of recreational fishing.
## Changelog
🆑
fix: Fixed morbid mobs (coroners) not enjoying room beauty and aquariums
in their own weird ways.
add: You an now release fish after catching it for a positive moodlet
(or to repopulate certain fishing spot with rare fish).
/🆑
---------
Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
## About The Pull Request
The profound fisher component (for both mobs and gloves) as well as the
proc responsible for rolling rewards are now being tested too. This is
something I've meant to do in a while, #86633 just happened to kick it
off now.
## Why It's Good For The Game
More tests, fewer mistakes flying under the radar.
## Changelog
N/A
## About The Pull Request
GODMODE has a lot of sources that toggle it. From admin-stuff to status
effects, components, actions and mobs which are supposed to be
invincible. It's better off as a trait than a flag, so we can manage
these sources.
## Why It's Good For The Game
See above.
## Changelog
🆑
admin: godmode is now a datum trait instead of a bitflag. This means the
process for toggling it is a little different now.
/🆑
## About The Pull Request
Added a screentip to the element that shields and pillows use for
shoving mobs.
## Why It's Good For The Game
It helps.
## Changelog
🆑
qol: Add a screentip to shields and pillows' right-click function
(shoving people).
/🆑
## About The Pull Request
Fish (the item that you catch with a fishing rod) now has an edible
component attached to it, making it possible to eat them if you really
have to, at the cost of eventually killing and deleting the fish,
however, you normally shouldn't.
Along with the seafood and meat foodtypes flags, it possess the gore and
raw foodtypes too, making them pretty awful to eat unless you're a
(non-vegan) lizard, felinid, or wearing the strange bandana*, which can
only be found in the cqc kit case. Furthermore, it carry diseases like
the ones from food left on the floors for too long, so a strong stomach
is required to safely eat it even if you actually like it, dummy...
UNLESS you fry or grill it, thus killing the diseases (as well as the
fish) and removing both the gore and raw food types, then it becomes an
actually ok meal... UNLESS you're dumb enough to eat a pufferfish, a
donkfish or a slimefish.
That is more or less the general rule. A few fish stray for it. For
example, lavaloops are never raw (still gorey). The skeleton fish are
never edibles, and holodeck fish is, well, holographic and thus
disappears if you try to eat it.
*the strange bandana is a reference to MSG, and this is a reference to
the MGS3 fish eating animation.
This is WIP btw, I'll have to test it and add some then polish it.
## Why It's Good For The Game
Whole unprocessed fish should be technically edible, even if not safe to
eat nine times out of ten. Also I kinda need this if I want to add a
tasty fishing spot to the kitchen deepfriers.
## Changelog
🆑
add: Whole, unprocessed fish is now edible. However it's pretty much
reccomended to grill or fry it for over 30 spess seconds before
attempting to eat it.
fix: germ-covered, dirty food no longer tries to infect you through
contact.
/🆑
## About The Pull Request
Fixes https://github.com/NovaSector/NovaSector/issues/4391
It was an easy fix so why not. This override was in place specifically
to allow mimes to use the spell but did not take into consideration the
mute trait.
Mimes use `TRAIT_MIMING` not `TRAIT_MUTE`, so this should not have any
effect on the original intent.
## Why It's Good For The Game
Fixes an oversight.
## Changelog
🆑
fix: fixes being able to use chuunibyou shouts while mute
/🆑
## About The Pull Request
Adds the Syndicate Lab to the Icemoon ruin pool. This can spawn on
either the cave or deep cave layers. It's a fairly small ruin so it's
easily missed, but it is packed full of danger and treasure.
The outside of the lab is mostly covered in snow. There are a few small
gaps that may or may not be filled in by the cave generation algorithm.
From most angles, it blends into the ice moon enviroment. However, meson
glasses will reveal the structure at a glance.
This lab has multiple hostiles to provide threat, there's a turret near
the entrance (on the interior), a patrolling eviscerator, and two ranged
syndicate agents with shotguns. The ruin is pressurised by default, so
mining weapons are less effective.
As loot, the lab contains a Donk Co musket (single-shot combat shotgun,
like the old pipeguns), two syndicate explorer's suits, a syndeye disk,
a syndicate toolbox and some small gimmick items. The agents blow up on
death so you can't have their shotguns or gear.
## Why It's Good For The Game
I collected feedback for a while on ruins and a common complaint is that
Icebox's ruins are lacking in variety, especially in the loot and action
departments.
To address the loot issue, I've added a bunch of loot to this ruin that
previously could not spawn on Icebox. Mostly this is the fluffy and
gimmicky stuff currently exclusive to space ruins, like the Donk piñata
and anomaly releasers. Nothing especially powerful or round defining,
because the ruin can spawn close to the station and isn't particularly
hard to clear.
Threats are likewise all things that aren't usually avaliable on icebox.
Prepare for lasers, buckshot, slashing damage and all relevant wounds.
Without a syndicate card or agent ID the doors won't open and the ruin
is powered, so miners can die to hacking the door open, then getting run
over by a patrolling dedbot. Very funny. The ruin is designed not to be
easily rolled by mining gear, but it remains a viable option. Lasers are
designed to be particularly good here, to reward cooperation with
security.
## Changelog
🆑
add: Adds the Syndicate Lab to the Icemoon ruin pool.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
So, I buffed gorillas a while back for traitors to get more mileage out
of them, and outside of needing to adjust that one wizard spell I've
been overall pleased with the results. However, while I knew that
Geneticists were capable of turning themselves into gorillas without the
magilitis injector, I thought it came with great difficulty but hoo boy
I was wrong. Turns out, its quite easy to turn yourself into a gorilla
with the three roundstart genetics setups you start with, and all you
need a little bit of toxin-healing chems (which don't really have a
downside and can stack!) or a medibot to pull it off. People have been
using this to validhunt as the newly buffed gorillas as early as 7
minutes or less into the round, which I think sucks! So I'm here to
change it.
If you become a gorilla from genetics, you become a new subtype with
nerfed stats. The stats are as follows:
180 health (from 220)
Melee damage 15-18 (from 25-30)
Obj Damage 25 (from 40)
Speed 0.1 (from -0.1)
Paralyze chance 0 (from 20)
No limb ripping
## Why It's Good For The Game
It's very easy to become a gorilla right now with little to no effort
and to great effect, seeing as gorillas are pretty strong now. This
brings crew gorillas back in line to before gorillas got buffed for
traitor usage, which should ideally make this more balanced overall.
## Changelog
🆑
balance: Gorillas made from giving monkeys genetic damage are weaker
than their normal counterparts.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Stumbled upon this by accident. If you add a trait that **should**
prevent engraving from a source other than INNATE_TRAIT you'd probably
want it to actually work. This doesn't actually do anything at the
moment but could save someone a few hours in the future.
## Changelog
🆑
code: Non-innate engraving blockers should work now (none as of now)
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
when making able_to_run event based, we forgot to account for this!
## Why It's Good For The Game
closes#86614
## Changelog
🆑
fix: fixes basic AI that are supposed to pause during actions not
pausing
/🆑
## About The Pull Request
Closes#86603 by adding a dummy antag datum that will be added to
everyone who lost the trauma before losing the antag datum (i.e. from
being "cured" from trauma in one way or another)
Also added defines for obsession objectives
## Changelog
🆑
code: Minor obsession code cleanup
admin: Admins can now see players who were previously obsessed but had
been "cured" from the trauma
/🆑
## About The Pull Request
converts certain donk outpost objects to use SSqueuelinks instead of
globals
## Why It's Good For The Game
i dont think every cool ruin should have its own global vars + this
allows multiple of the ruin to be spawned without breaking if someone
wants to do that for some reason
its better to just do it like this
## Changelog
🆑
code: that one cool haunted donk outpost ruins tripwires and such use a
subsystem instead of globals. no real gameplay effect
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Previous Pull Request
#85308 reverted by #85929
~~Causes the round to not start when a player isn't eligible for any
jobs at a specific priority level due to runtimes trying to `pick()`
from an empty list aborting the entire job assignment stack.~~
(Fixed???? by
e0e9f2f430)
Maybe we should test merge this for a mo just to make sure no more
cheeky runtimes pop up before merging.
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
## About The Pull Request
Fixes psyker echolocation permanently breaking when in the vicinity of
holopad holograms or someone being fulton'd
Also fixes non humans that have human appearances (eg syndicate
commandos) being invisible to psykers.
Also also fixes a runtime related to fulton extraction that I found
while testing the above
## Why It's Good For The Game
My eyes!
## Changelog
🆑
fix: Echolocation no longer breaks when witnessing a hologram
fix: Echolocation no longer breaks when witnessing a fulton extraction
fix: Humanoid NPCs are no longer invisible to echolocation users
/🆑
