Just in case we ever elongate initial queue times / stop doing churn,
let's ensure that the "are we done yet" check uses all queues except the
harddel, rather then just the check queue
This also swaps us over to using QDEL time rather then queue time, since
for the check queue these are NOT the same, and they were leading to
false positives here
Required post #62969. Life is pain.
Just another lightweight PR porting over a simple animal to the basic
mob framework with zero additional AI implementation (it's a killer
tomato- it spawns into the world to maul you. how much more intricate
does it need to be?).
unit tests turf icons to find... well, missing icons. honk.
fixes#75372
corrects a bunch of things messed up in #65504🆑 ShizCalev
code: Made a new unit test to find turfs with broken/missing icons!
Rejoice!
fix: Fixed a bunch of incorrect and missing turf icons.
/🆑
This was pretty simple since they didn't have too much custom behavior,
and whatever they did have already had AI behavior. I got really burned
out the last two times I wrote intricate AI action/decision behaviors so
I'm just taking it light and doing the bare minimum.
one day our shackles will be free of the simple animal scourge. they're
also a bit more intelligent, and i daresay a bit cuter too now.
also that lizard gib animation has been sitting there for god knows how
long completely unseen, so let's actually hook it into the mob.
## About The Pull Request
The high luminosity eyes item was extremely out of date, broken, and
full of copy paste code from atom lighting. Which is a shame because
they were cool.
On top of all that it was using a special light effect that was not very
performant. I got rid of all that, hooked it into atom lighting as a new
light type, and gave it a new TGUI as well because the old ui prompts
were not great either.
You can now pick a color at random if you want. You can also set the
color and range before surgically implanting them. No more being forced
to go through the color picker when you just want to change the range.
Functionally they should pretty much should be the same as before with
some bonus features (see below).
Closes https://github.com/tgstation/tgstation/issues/61041
Closes https://github.com/Skyrat-SS13/Skyrat-tg/issues/14685
This is 100% completed. I just finished fixing the slight translation
bug when going from 0->1 range (see above gif) and that was the last
thing on my bucket list. I happy enough with this at this point in time.
---
EDIT:
I have decided to add in one last new feature, and that is...
independent settings for eye color.
<details> <summary>You can now set eye color independently if you
wish</summary>
</details>
The eye color does not modify the light color in any way when set in
this manner, but it can be used for cosmetic purposes.
Kind of makes the item more like cybereyes from cyberpunk, which I think
are pretty neat!
</details>
### What I've done, in more detail:
- refactored high luminosity eyes so they use the atom lighting system
instead of the way they were doing it before
- the new light type, `MOVABLE_LIGHT_BEAM` behaves similarly to
directional lights, with some slight differences. it reuses the same
lighting overlay sprites but scales them vertically to produce a more
focused effect. The result can be seen above. This is in contrast to the
old way, which spawned `range` number of individual 32x32 overlays and
moved them around. This way should perform better as well as be more
maintainable.
- added a new TGUI interface for high luminosity eyes with buttons for
range, a text field for a color hex, a color picker and randomizer
- made the eye overlay emissive when the light is turned on
- range goes from 0 to 5. at range 0, the light overlay is turned off
and you are left with just the emissive eyes.
- added a cosmetic functionality to this item that lets you change the
color of your eyes independently of the lighting (and each other)
- fixed a bug with directional flashlights sometimes not updating their
lighting overlay if you pick them up without changing your direction
---
### Other Misc Fixes
Being able to dynamically set range back and forth exposed some logic
issues that had existed with directional light overlays and I have fixed
those. That is why there are some edits in that file that may not appear
readily obvious why they are there.
Apart from that, two other bugs that come to mind:
1) eye code was supposed to keep track of the eye color you had before
you got new eyes, but it was overwriting that every time you ran
refresh().
2) lighting was supposed to be turning off the light when range is set
to 0, but it was not doing that properly.
And of course besides that, there may have been a few instances of
finding typos/tidying up code
## Why It's Good For The Game
The code for this was like 6 years old and in desperate need of
updating. Now it works, and has a nicer UI.
## Changelog
🆑
fix: high luminosity eyes light overlays now follow the user correctly
qol: high luminosity eyes now have a tgui menu so you no longer have to
go through the color picker every time you want to change the range.
they also have a new setting that lets you change the color of your eyes
independently of the light color. You can now have cybernetic
heterochromia if you want
fix: directional flashlights when picked up will now always update their
cast light direction correctly no matter what dir you are facing
refactor: refactors high luminosity eye code to better make use of the
atom lighting system, adding a new light type 'MOVABLE_LIGHT_BEAM'
/🆑
This PR implements this design document:
https://hackmd.io/@Y6uzGFDGSXKRaWDNicSiEg/BkRr176st
Put briefly, this will remove every existing golem subtype and
consolidate golems into a single species with cool new sprites.
NOT implemented from that PR is the ability to eat Telecrystals, I
couldn't come up with an appropriate visual that can stack with the
existing ones, but that should be a reasonably trivial add for a future
artist & developer.
New Golems have a food-based mechanic where their hunger decays pretty
quickly and can only be replenished by eating minerals. They start
moving slower as they get hungrier, until eventually they become
completely immobilised and need to be rescued.
Eating different kinds of minerals will visually change your sprite and
give you a special effect in a similar way to old golems, but temporary.
While transformed, you can't eat any other kind of mineral which would
transform you (but can still consume glass).
To see the full list of effects, look at the hackmd above.
In service of these sprites working I have refactored the
`species/offset_features` feature by killing it and delegating that
responsibility to limbs instead. Rather than applying an offset to items
due to your species, it is due to your weird head or arms. This makes
overall more sense to me, but it inflates the code changes in this PR
somewhat.
It doesn't make a lot of sense to atomise unfortunately because that
code also seemed to be entirely unused until I tried to use it in this
PR, so you wouldn't be able to tell if my changes broke anything. I
might make a downstream sad by doing this.
All of the actual numbers in this PR are made up and only loosely
tested, it will need some testmerges to gather feedback about whether it
sucks or not.
Other relevant changes:
I reworked how bioscrambling works based off bodypart bodytypes, to
automatically exclude golem limbs in either direction. There's really no
way to have those work on humans or vice versa. Organs still fly though.
## About The Pull Request
Inspired by #74967 and #68459 , and the fact that Tramstation regresses
very often -
Adds a unit test, `required_map_items`, which ensures that certain
typepaths which should definitely be mapped onto every map is mapped
onto every map
It can also be used to ensure that items which should not be mapped in
multiple times are not, among other things.
I included a few examples -
- Min 1, max inf of each head of staff stamps
- Min 1, max 1 departmental order consoles
- Min 1, max inf comms console
- Min 1, max 1 Pun Pun
- Min 1, max 1 Poly
- Min 1, max 1 Ian
If, in the future, a mapper decides they (for some reason) do not want a
certain previously-required item on their map, the test can be adjusted
such that it allows excluding or something, but currently it should be
for items which require conscious thought about.
#### QA: Why not make this a linter?
I attempted to make this a linter before realizing two things
1. Someone might make a spawner which spawns the items, or they might
get placed in a locker, in any case this accounts for everything on init
2. Linters run on every map, non-station maps included
So I went with a test
## Why It's Good For The Game
#50468#61013#74967
Why is it always the CMO stamp?
## Changelog
Not necessary (unless I find a map missing something, then this will be
updated)
## About The Pull Request
https://github.com/tgstation/tgstation/pull/74985#issuecomment-1523773626
Tests that all jobs that have `spawn_position > 0` at roundstart have a
location to spawn at.
Also changes the failure message for
`get_default_roundstart_spawn_point` to send to `log_mapping` rather
than `log_world`, as it is a map error and log world doesn't really help
anyone. This would've been sufficient for the existing unit test
`log_mapping`, but that unit test expects that the log has an areacoord
supplied, which we can't really do, given we're reporting a _lack_ of
something.
## Why It's Good For The Game
Stops maps from regressing and dumping people on the latejoin shuttle
roundstart.
## Changelog
~~Not necessary unless I find a map which forgot a landmark~~
🆑 Melbert
fix: Tramstation Robotics and RD now spawn in their departments
roundstart
fix: Birdboat detective now spawns in their office
/🆑
## About The Pull Request
Adds a latejoin form of Changeling flavored as a stowaway.
## Why It's Good For The Game
We don't have a latejoin form of Changelings. It ups the paranoia that
anyone can be a Changeling, latejoin or not. They're also one of the few
non-progression antagonists which would work perfectly as a late join.
## Changelog
🆑
add: Stowaway Changelings will now appear as a late join form of
Changeling.
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
basically ex_act's implementation on basic mobs would call parent and
then react to it's value, this is presumably to do the first check about
space vine mutations and whatever. the problem is that the `/mob/living`
implementation would itself also call parent, and that would always
return null because `/atom/proc/ex_act` doesn't have a set return value.
So, this simply would _always_ early return, with ex_act presumably
*never* working on basic mobs for at least four months now.
I decided to then change up the return values for pretty much all
implementations of `ex_act()` since there was no rhyme or reason to
returning null/FALSE/TRUE, and documenting why it's like that.
Just to make sure I wasn't breaking anything doing this (at least on
base implementations), I wrote a unit test for all of the three major
physical types in game (objs, mobs, turfs) because i am a paranoid
fuckar. we should be good to go now though.
## Why It's Good For The Game
i noticed this because placing c4's on sargeant araneus wouldn't
actually damage it whatsoever. now it actually does the stated 30
damage, but araneus has like 250 health so it doesn't actually matter in
the long run. whatever at least it does the damn 30 now.
also adds a unit test for this specific case as well as a range of other
cases to ensure this stuff doesn't silently break in this way anymore
## About The Pull Request
Turns out that Russian mobs are literally just Syndicate mobs, so I made
them subtypes of Syndicate basic mobs. This means we don't have to
maintain these two different mobs just to do the exact same thing.
I also removed unused subtypes of it so it's not clogging up.
Also this PR is inspired by a CI failure in [Birdshot
here](https://github.com/tgstation/tgstation/actions/runs/4841059293/jobs/8627176442?pr=75042)
## Why It's Good For The Game
I mostly explained in the About section, but this just helps future
maintaining by making these already copy-pastes of eachother, at least a
subtype instead.
## Changelog
🆑
refactor: Russian mobs are now subtypes of Syndicate basic mobs.
/🆑
- Removes unnecessary real global vars.
- Adds comments pointing to the init order defined in
/code/game/world.dm.
- Prevent people using `GLOBAL_REAL_VAR` and `GLOBAL_REAL` to circumvent
init order.
- Properly type `PROFILE_STORE` real global.
- Refactored `make_datum_references_lists()` and moved the call to it
into `GLOB` init with duct tape.
- Renamed `GLOB.admin_log` to `GLOB.admin_activities` as it wasn't
actually a log file.
- Whitelist loading happens in config.
- Renamed `SSdbcore`'s `SetRoundID()` to `InitializeRound()`. Now
handles calling `CheckSchemaVersion()`.
- Created macro for setting up log `GLOB`s.
- Removed log line for `GLOB` count.
- Moved call to `make_datum_reference_lists()` to
`/datum/controller/global_vars/Initialize()`. I slimmed it down where
possible too.
- Updated comments about world init order.
- Move `load_admins()` call to after log setup.
- Removes unused function `gib_stack_trace()`.
- Removes a bunch of unused log `GLOB`s.
- Unlocks the secrets of the universe by finally making the first
executed line of code deterministic.
No functional changes. Closes#74792
Testmerge thoroughly.
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Replaces weakref usage in AI blackboards with deleting signals
All blackboard var setting must go through setters rather than directly
## Why It's Good For The Game
This both makes it a ton easier to develop AI for, and also makes it
harder for hard deletes to sneak in, as has been seen with recent 515
prs showing hard deletes in AI blackboards
(To quantify "making it easier to develop AI", I found multiple bugs in
existing AI code due to the usage of weakrefs.)
I'm looking for `@Jacquerel` `@tralezab` 's opinions on the matter, also
maybe `@LemonInTheDark` if they're interested
## Changelog
🆑 Melbert
refactor: Mob ai refactored once again
/🆑
## About The Pull Request
deers only show up in the BEPIS but i decided that they would be easy
enough to turn into a basic mob (they were). it was so easy in fact that
i decided to dip my toes into coding AI behavior, and made them freeze
up whenever they see a vehicle. this required a lot of code in a bunch
of places that i was quite unfamiliar with before starting this project,
so do let me know if i glonked up anywhere and i can work on smoothing
it out.
## Why It's Good For The Game
one less simple animal on the list. deers staring at headlights is
pretty cool i think, neato interaction for when you do get them beyond
the joke the bepis makes
i'm also amenable to dropping the whole "deer in headlights" code if you
don't like that for w/e reason- just wanted to make them basic at the
very least
## Changelog
🆑
add: If you ever happen upon a wild deer, try not to ride your fancy
vehicles too close to it as it'll freeze up like a... you know where I'm
going with this.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
refactors poles and trees into basic mobs. If trees now see you holding
a chainsaw, hatchet, or some wood they will get angry and knock you out
for longer. Poles will run around giving some of their charge to APCs
they find along the way. i did them both in this PR coz poles were a
subtype of trees.
## Why It's Good For The Game
refactor
## Changelog
🆑
refactor: refactors trees into basic mobs
refactor: refactors poles into basic mobs
add: If trees now see you holding a chainsaw, hatchet, or some wood they
will get angry and knock you out for longer
add: Poles will run around giving some of their charge to APCs they find
along the way
fix: cells charged by the pole will now have their icon correctly
updated to reflect their charge
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Turns Space Bats into a basic mob, why not.
I also noticed some retaliate mobs weren't in the retaliate folder, and
moved them over. I didn't move goats over because they're in a large
file and didn't want to really expand much on this PR that I just wanted
to focus on just bats.
## Why It's Good For The Game
I was just messing around with some bat stuff and thought I might as
well make them basic mobs.
## Changelog
🆑
code: Space Bats are now Basic mobs.
/🆑
## About The Pull Request
Fixes#74571
Init order memes.
All carbons innately gained the trait `TRAIT_AGEUSIA` in initialize due
to not having a tongue
Then, their organs would be created and their initial tongue would
remove this trait
But at some point init order changed, unsure when
This caused this trait to be applied at an inappropriate time, causing
all spawned carbons to be tastebud-less until their tongue was changed
## Why It's Good For The Game
mmmm
## Changelog
🆑 Melbert
fix: You can now taste once again, without requiring your tongue be
surgically replaced or reattached
/🆑
## About The Pull Request
Requires #74562 and #74556 be merged first.
Unit tests cult conversion and throws in a case for rev AOE flashes
## Changelog
Not necessary
---------
Co-authored-by: san7890 <the@san7890.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'
The check queue is 5 minutes long because that's the longest a client
can hold onto a reference. Without clients, we can drastically decrease
the time we have to wait. This lowers the time down to 10 seconds
(though everything right now deletes in 5).
This will represent a 5 minute decrease in CI across the board, freeing
up runners.
Makes a few changes to stuff that was being held for more than 10
seconds.
- `VARSET_CALLBACK` now works through weakrefs, to allow for pAIs to
have their holochassis init timers.
- Nar'Sie cleans herself up in GLOB.cult_narsie if she's deleted.
- "Spooky portals" no longer hold onto a reference for 2 minutes.
- `poll_candidates` short circuits to an empty list if there are no
candidates, to avoid several 30 second+ long timers
Originally this was going to be a more clever hack from @MrStonedOne
about short circuiting if everything deletes before the wait, but we
realized that basically nothing actually holds onto references for that
long without clients, and that nothing really should anyway
## About The Pull Request
Lets mappers do their thing without causing needless grief
Lets mappers mark areas as a goal area for atmos connectivity, aswell as
starting points
There are four landmarks added.
- Goal
- Start
- Ignore
- Station Areas
Goal and start are fairly self explanatory, note that not having any
goals will default to using all station areas, with a notice. If you
intend for that to happen place the Station Areas landmark somewhere on
the map, preferably near the top left of the map.
The ignore marker allows you to mark an area as ignored for purposes of
connectivity. If you purposefully want a disconnected room off in near
space for example.
## Why It's Good For The Game
Alternative of and closes
https://github.com/tgstation/tgstation/pull/74444
More workability for mappers
## About The Pull Request
It's helpful to know what icons we have, and if any are invalid
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
**This PR:**
- Reworks most* existing soup into reagents.
- Adds Stoves and Ranges. Ranges replace most* existing ovens.
- Adds soup pots, to cook soup
**How does it work?**
In the kitchen you will find a stove now.
Stoves act as a "reagent container heater", essentially a chem heater.
You can set a pot onto the stove.
To make soup, visit the cooking recipe book for a guide. Most recipes
are the same as before, just tweaked slightly - Add water to the pot (50
units for 1 batch generally), then add all the corresponding ingredients
to the pot. Set the pot out on the stove and right click it to turn it
on. If the recipe's correct, shortly it will start to mix and give you
soup!
One soup recipe will give you roughly 3 servings of soup. You can pour
our the soup into a bowl using a ladle or just by pouring it manually.
Of note: **All of the reagent contents of the ingredient are transferred
into the soup.** Better, more nutrient rich ingredients produces more
soup, and poisoned produce will pass it on.
If you place the soup into a chem master, you will notice it's roughly
half "soup reagent" and half a variety of reagents, including nutriments
/ proteins. This is your soup! It is recommended you serve your soup
with the reagents included, as they make up more nutrition for the
customer, however you can separate it out if you're picky.
**Todo:**
- [x] Fill out the PR body a bit more
- [x] Mapping (wait for big merge conflict pr to go past)
- [x] Soup colors
- [x] Balance pass over for soup recipes
- [x] TODOs
- [ ] Unit tests
- [x] Cullen Skink's recipe is invalid
- [x] Try to see if there's an easy way to prevent soup from fattening
you up too easy.
## Why it's good for the game
Adds some more depth to the kitchen and moves chef away from the
click-button-get-food style that exists.
Allows for inherently custom soups by the way of making it reagents, so
no need to support custom soup food items.
## Changelog
🆑 Melbert, stove and pot sprites by Kryson, ladle sprite by Kinneb
add: Kitchens are now stocked with Ranges.
add: You can now print (and create) Stoves.
add: The dinnerware vendor now dispenses ladles.
add: Spoons can now actually spoon... things.
add: Soup has been reworked entirely. Soups are now reagents, cooked via
a soup pot on a Stove or Range. Simply add water and your required
items, then apply heat. Be careful not to boil over!
add: Stoves, Ranges, and Griddles will now heat up their surroundings -
don't turn them on around plasma!
fix: Fixes being able to cook in an Oven while the room is depowered
qol: Hitting a customer bot with an incorrect recipe no longer counts as
a hostile attack leading to your demise shortly after
refactor: Customer bots that request a reagent now use custom orders
code: Cut down a lot of code in the crafting menu code, and removes some
ugly ispaths
del: Soup is no longer food items, so can't appear in random food pools
(at least not yet).
balance: Virus Food recipe now requires you cool it to 200k.
/🆑
## About The Pull Request
Hi.
This pr contains work that is a collaborative effort between myself,
Halcyon, Mqiib and `2cents#8442` for the original leg-work (Ha Ha, Get
it?), ultimately finished by myself.
Here's a preview!
And here's some side previews!
## Why It's Good For The Game
Lizard sprites have not been updated since their inception in 2016. They
will now be updated and be much more consistent with everything else.
Signed off by @optimumtact
## Changelog
🆑
imageadd: Lizards have been resprited, as well as Digitigrade sprites.
Please remember to update your colors to account for this.
/🆑
## About The Pull Request
- Signallizes head revolutionary flash conversion code, moving it out of
core flash code.
- Removes "tacticool" flashing from head revs, but they can still
convert from any direction
- Fixes April Fools "You son of a bitch! I'm in" force say never
working.
- Revs are muted on conversion so they couldn't talk.
- Fixed by only muting revs on non-holidays
- Cultists are unconscious on conversion so they couldn't talk
- Fixed by only unconscious-ing cultists on non-holidays
- Brainwash victims are more often than not unconscious / asleep so they
couldn't talk
- Just left this one.
- Reduced the chance of them occurring and limits it to April Fools only
- A 1% chance of the force says ocurring means they will happen pretty
much once a week, given multiple rev / cult rounds happen every week and
on average like, 20 people are converted. A little absurd, it's good
that it never worked?
## Why It's Good For The Game
Antag code in core item code is bad
It's funny this meme has existed for like 2, 3 years now? No one's
tested it, it's never worked
## Changelog
🆑 Melbert
refactor: Removes Rev code from core flash code
fix: Getting converted on April Fools now triggers the meme force say as
always intended
del: The meme force say can no longer trigger on any day (it didn't work
before anyways)
/🆑
## About The Pull Request
The icon state was improperly named, so it didn't actually exist.
This fixes that.
## Why It's Good For The Game
Fixes a bug
## Changelog
🆑
fix: Slimes' mischievous emote now works.
/🆑
## About The Pull Request
Ensures that we don't get station areas which are disconnected
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
"Drake, why is this room depressurized?"
## Changelog
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
Refactors regenerate organs to be slightly more intelligent in handling
organ changes and replacements.
Noteably:
- We don't remove organs that were modified by the owner; such as
changing out your heart for a cybernetic
- We early break out of the for loop if they aren't supposed to have an
organ there and remove it
- We check for the organ already being correct, and just healing it and
continuing if it is
Also changes the names of some of the organ helpers into snake_case
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
This is a continuation of
https://github.com/tgstation/tgstation/pull/74085 - I announced in the
comments there that this would be my next PR, and this is it.
Removes SSnetwork, ``/datum/ntnet``,
``/datum/component/ntnet_interface``, ``var/network_root_id``, the
network unit test, and a lot of other things related to networks.
- NTNet circuits now check for an Ntnet relay, and uses signals to
operate.
- Logs in Wirecarp is now only for PDA and Ntnet Relay things, so you
can no longer see what ruins exist using it (why should Wirecarp know
that Oldstation spawned? The flavor is that they dont know its there).
- Removed it from MULEbots entirely, I don't think it even did anything
for them? Botkeeper seems to work without it, so it's possibly there
from pre-tgui PDAs.
- Moves assigning random names to a base proc instead of being tied to
network, this is things like random-naming scrubbers/vents. The behavior
hasn't changed at all.
- Makes Ntos work for consoles when relays are down, as the comments
said they're supposed to (because they're wired). I think this was an
accidental change on my part, so this is a revert of that.
## Why It's Good For The Game
Ntnet is ancient code that hasn't given us much that we can't do with
already existing alternatives, we've been slowly moving away from it for
init times, and though a large portion of that was limited to airlocks,
I still don't think this is a system worth keeping around.
It's way too complex to expect feature coders to do anything with it,
and too old with better alternatives for anyone to want to improve any
of it.
## Changelog
🆑
fix: Computers are now properly connected to Ethernet, and can use Ntos
when Relays are down.
refactor: Removes Ntnet and Ntnet interfaces, which was only used by
Ntnet circuits (which now directly checks for a Relay to work) and
MULEbots, which did nothing with it.
balance: Wirecarp no longer tells you what ruins spawned in a round,
instead it's limited to PDA logs, and tells you the source too. This
means the RD can catch someone running illegal programs if they don't
make any attempt at hiding it.
qol: Wirecarp logs is now set to save 300 at once, instead of 100 and
being increased to 300 by the RD during the round. This is pretty
insignificant, since there's no reason to NOT want as many logs as
possible.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
### How things work
As things currently stand, when a mob breaths several things happen
(simplified to focus on the stupid)
We assert the existance of all possible breathable gases, and pull
partial pressures for them
Then we walk through all possible interactions lungs could have with
these gases, one by one, and see if they're happening or not
As we go we are forced to cleanup potential alerts caused by the
previous breath, even if those effects never actually happen
At the end we clear out all the unused gas ids, and handle the
temperature of the breath.
### What sucks
There's I'd say 3 different types of gas reactions.
- You can "need" a gas to survive. o2, n2 and plasma all fall into this
category
- A gas can do something to you while it's in your system. This applies
to most gas types
- Variation on the previous, some gases do cleanup when they're not in
your system, or when there isn't much of them in the first place
The main headache here is that second one, constantly cleaning up
potential side effects sucks, and fixing it would require a lot of dummy
variables
There's other suckage too.
Needing to constantly check for a gas type even if it isn't there is
stupid, and leads to wasted time It's also really annoying to do
subtypes in this system.
There is what amounts to a hook proc you can override, but you can't
override the reaction to a gas type.
It also just like, sucks to add new gases. one mega proc smells real
stupid.
### Improvements
In the interest of speed:
- I'd like to build a system that doesn't require manually checking for
gas
- Reacting to gas "disappearing" should be promoted by the system,
instead of being hacky.
- I would like to avoid needing to assert the existence of all possible
gases, as this is slow on both the assert and the garbage collect.
In the interest of dev ergonomics:
- It should be easy to define a new gas reaction
- It should be easy for subtypes to implement their own gas reactions.
The current method of vars on the lung is all tangled up and not really
undoable as of now, but I'd like to not require it
- It should be possible to fully override how a gas is handled
### What I've Done
Lungs have 3 lists of proc paths stored on them
Each list handles a different way the lung might want to interact with a
gas.
There's a list for always processing on a gas (we use this for stuff
that's breathed), a list for handling a gas in our breath, and a list
for reacting to a gas previously being in our breath, but not any more.
Lungs fill out these lists using a helper proc during Initialize()
Then, when it comes time to breath, we loop over the gas in the breath
and react to it.
We also keep track of the previous list of partial pressures, which we
calculate for free here, and use that to figure out when to call the
loss reactions.
This proc pattern allows for overrides, easy reactions to removals,
lower indentation code and early returns, and better organization of
signal handlers
It's also significantly faster. Ballpark 4x faster
### Misc
Removes support for breathing co2, and dying from n2 poisoning.
They were both unused, and I think it's cringe to clutter these procs
even further
Added "do we even have oxyloss" checks to most cases of passive
breathing.
This is a significant save, since redundant adjustoxy's are decently
expensive at the volume of calls we have here.
Fixes a bug with breathing out if no gas is passed in, assigning a var
to another var doesn't perform a copy
Rewrote breathe_gas_volume() slightly to insert gas into an immutable
mix stored on the lung, rather then one passed in
This avoids passing of a gas_mixture around just to fill a hole.
I may change my mind on this, since it would be nice to have support for
temperature changing from a hot/cold breath.
Not gonna be done off bodytemp tho lord no.
Uses merge() instead of a hard coded version to move the gas ids over.
This is slightly slower with lower gas counts but supports more things
in future and is also just easier to read.
## Why It's Good For The Game
Faster, easier to work with and read (imo)
Profiles:
[breath_results_old.txt](https://github.com/tgstation/tgstation/files/11068247/breath_results_old.txt)
[breath_results_pre_master.txt](https://github.com/tgstation/tgstation/files/11068248/breath_results_new.txt)
[breath_results_new.txt](https://github.com/tgstation/tgstation/files/11068349/breath_results_new.txt)
(These profiles were initially missing #73026. Merging this brings the
savings from 16% to 12%. Life is pain)
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Removes NtNet softwaredownload/communication because they did nothing,
so this also removes the feature to shut them off from Wirecarp
I removed tablets from being added to networks, Tablets already generate
logs for actions they do, which is already enough for the effects it has
in-game (just being visible to Wirecarp), once NtNet is deleted from
everything else then we can move it to ModPCs and limit logging to only
ModPC actions.
Fixes shutting off ntnet relays from Wirecarp, now you can properly shut
off Ntnet, and the warning that it kicks you out of the program is now
true.
Gives the Holodeck it's own network root define and fixes Syndicate
network showing up on Wirecarp
Wirecarp's PDA logs now shows the source of an action
## Why It's Good For The Game
Moves ModPCs further from NTNet so we can move towards deleting it
entirely
Makes Wirecarp more responsible and trustworthy
Removes useless stuff that never gets used, simplifying a overthought
overcomplicated system.
## Changelog
🆑
balance: Wirecarp now properly shuts off NtNet remotely.
balance: Wirecarp now shows the source of a PDA that does an action.
fix: Wirecarp can no longer be used to see if Nukies exist through their
networks.
del: Removes Software downloading and communication Ntnet networks, as
they were pretty worthless.
/🆑
## About The Pull Request
This PR adds a new unit test for all organs, a new unit test for lungs,
and includes improvements for the existing breath and organ_set_bonus
tests. Using the tests, I was able to root out bugs in the organs. This
PR includes an advanced refactor of several developer-facing functions.
This PR certainly represents a "quality pass" for organs which will make
them easier to develop from now on.
### Synopsis of changes:
1. Fixed many fundamental bugs in organ code, especially in
`Insert()`/`Remove()` and their overrides.
2. Added two new procs to `/obj/item/organ` named `on_insert` and
`on_remove`, each being called after `Insert()`/`Remove()`.
3. Added `organ_effects` lazylist to `/obj/item/organ`. Converted
`organ_traits` to lazylist. 2x less empty lists per organ.
4. Adding `SHOULD_CALL_PARENT(TRUE)` to `Insert()`/`Remove()` was very
beneficial to stability and overall code health.
5. Created unit test `organ_sanity` for all usable organs in the game.
Tests insertion and removal.
6. Created unit test `lungs_sanity` for
`/obj/item/organ/internal/lungs`.
7. Improved `breath_sanity` unit tests with additional tests and
conditions.
8. Improved `organ_set_bonus_sanity` unit tests with better
documentation and maintainable code.
---
### Granular bug/fix list:
- A lot of organs are overriding `Insert()` to apply unique
side-effects, but aren't checking the return value of the parent proc
which causes the activation of side-effects even if the insertion
technically fails. I noticed the use-case of applying "unique
side-effects" is repeated across a lot of organs in the game, and by
overriding `Insert()` the potential for bugs is very high; I solved this
problem with inversion-of-control by adding two new procs to
`/obj/item/organ` named `on_insert` and `on_remove`, each being called
after `Insert()` and `Remove()` succeed.
- Many organs, such as abductor "glands", cursed heart, demon heart,
alien hive-node, alien plasma-vessel, etc, were not returning their
parent's `Insert()` proc return value at all, and as a result those
organs `Insert()`s were always returning `null`. I have been mopping
those bugs up in my last few PRs, and now the unit test reveals it all.
Functions such as those in surgery expect a truthy value to be returned
from `Insert()` to represent insertion success, and otherwise it
force-moves the organ out of the mob.
- Fixed abductor "glands" which had a hard-del bug due to their
`Remove()` not calling the parent proc.
- Fixed cybernetic arm implants which had a hard-del bug due to
`Remove()` not resetting their `hand` variable to `null`.
- Fixed lungs gas exchange implementation, which was allowing exhaled
gases to feedback into the inhaled gases, which caused Humans to inhale
much more gas than intended and not exhale expected gases.
### Overview of the `organ_sanity` unit test:
- The new `organ_sanity` unit test gathers all "usable" organs in the
game and tests to see if their `Insert()` and `Remove()` functions
behave as we expect them to.
- Some organs, such as the Nightmare Brain, cause the mob's species to
change which subsequently swaps out all of their organs; the unit test
accounts for these organs via the typecache `species_changing_organs`.
- Some organs are not usable in-game and can't be unit tested, so the
unit test accounts for them via the typecache `test_organ_blacklist`.
### Overview of the `lungs_sanity` unit test:
- This unit test focuses on `/obj/item/organ/internal/lungs` including
Plasmaman and Ashwalker lungs. The test focuses on testing the lungs'
`check_breath()` proc.
- The tests are composed of calling `check_breath` with different gas
mixes to test breathing and suffocation.
- Includes gas exchange test for inhaled/exhaled gases, such as O2 to
CO2.
### Improvements to the `breath_sanity` unit tests:
- Added additional tests for suffocation with empty internals, pure
Nitrogen internals, and a gas-less turf.
- Includes slightly more reliable tests for internals tanks.
## Why It's Good For The Game
**Organs and Lungs were mostly untested. Too many refactors have been
submitted without the addition of unit tests to prove the code works at
all.** Time to stop. _Time to get some help_. Due to how bad the code
health is in organs, any time we've tried to work with them some sort of
bug caused them to blow up in our faces. I am trying to fix some of that
by establishing some standard testing for organs. These tests have
revealed and allowed me to fix lot of basic developer errors/oversights,
as well as a few severe bugs.
## Changelog
🆑 A.C.M.O.
fix: Fixed lungs gas exchange implementation, so you always inhale and
exhale the correct gases.
fix: Fixed a large quantity of hard-deletes which were being caused by
organs and cybernetic organs.
fix: Fixed many organs which were applying side-effects regardless of
whether or not the insertion failed.
code: Added unit tests for Organs.
code: Added unit tests for Lungs.
code: Improved unit tests for breathing.
code: Improved unit tests for DNA Infuser organs.
/🆑
On the tin, doing it like this means we can reduce our overall line
fingerprint whenever we have to add two or more traits from the same
source on the same target. Especially helps when we get to the 4+ range
of traits, a breath of fresh air even.
Doesn't mean we have to do for loops, as that's already handled within
the define as well. I replaced some of the checks with `length()`
checks, let me know if I should switch it over to something else (maybe
`islist()`)? We stack_trace whenever we're not passed a list reference
on purpose, and sometimes var/lists are null by default (or just empty,
making this redundant).
## Why It's Good For The Game
I commonly feel the urge to write "use `AddTraits()`" or something in
reviews, then am sad when I remember it doesn't exist. I will no longer
be sad.
Can ensure a lot more trait safety as well by using static lists- when
both ADD_TRAIT_LIST and REMOVE_TRAIT_LIST re-use the same list, you are
confident (from a static point of view) that everything that you want to
be adding/removing works.
I may have missed a few things where this could be used, but both macros
implemented in this PR still use the same framework that was being used
in the last four years- so stuff won't break if left untouched. Just a
nifty new tool for developers.
also fixed up some code in the area, numerous bugs were found and
exploded
## About The Pull Request
regenerate organs never removed invalid organs when regenerating
## Why It's Good For The Game
Fixes https://github.com/tgstation/tgstation/issues/73640
adds a unit test to prevent regressions in the future
## Changelog
🆑
fix: Plasmamen don't have hearts, again
/🆑
## About The Pull Request
Stabilized gold extracts can now summon basicmobs,
Also, summoned familiars become friendly to the owner, which stops stuff
like mice running away.
## Why It's Good For The Game
They can now make cool basicmob carp and stuff
Fixes#74008
## Changelog
🆑
fix: Stabilized gold extracts can now spawn basicmobs
/🆑
Internal_organs now also contains external organs, so the naming was
incorrect
Requested by @tralezab in #72734
Also removed some now incorrect 'as anythings' that assumed everything
in the internal_organs list was an internal_organ (which is a lie since
I put extorgans in there which means runtimes and unintentionakl
behaviour
🆑
fix: fixes deadly harvesting just taking harmless extorgans
code: renames internal_organs to organs now that it can also contain
external_organs
/🆑
## About The Pull Request
In this PR, some of the traitor objectives are rebalanced to be more
consistent with scaling risk.
Abstract traitor objectives have had their telecrystal reward and
progression rewards moved to their non-abstract types and it's now
enforced that abstract objectives should not have these values set.
Additionally, it's encouraged that people don't set progression_minimum
on abstract types either, but I can see the usecase in doing so with
final objectives and assassinate objectives. This is why it's fine to
set progression_minimum on an abstract type as long as any of the
derivatives of that abstract type do not redefine the progression
minimum to avoid consistency errors when tweaking progression minimum
values. Setting the progression minimum on an abstract type means that
all derivatives of that abstract type should be unlocked at roughly the
same time.
## Why It's Good For The Game
The rebalances are so that same risk objectives of different types are
worth around the same amount. Repeatables should roughly award the same
amount of TC when it comes to comparing the risk, but the progression
rewards can vary.
The new standard enforcement on abstract traitor objectives is more so
for robustness and ease of balance, as it's easier to lose consistency
when rebalancing values between two objectives, because one of the
objectives derive their rewards from an abstract type. Generally
speaking, rewards from objectives of different risk level should not be
the same and it's easier to enforce this if developers have to
explicitly declare the rewards of the objectives they add.
This doesn't mean each objective has to declare explicitly what their
reward is. Derivatives that subtype off of non-abstract types can still
copy the rewards from their parent.
The progression minimum is fine to be set on abstract objectives as long
as derivatives don't change the progression minimum. If they do, then
it's better for consistency to declare the progression minimum on each
type rather than the abstract type so that higher-tier objectives don't
accidentally end up with a lower progression minimum when it comes to
rebalancing. Of course, this isn't a set rule on, but it's something I'm
going to try and enforce, when it makes sense, going forward, even if it
may increase the number of lines of code each traitor objective file may
have. Maintainability and robustness beat optimization.
## Changelog
🆑
code: Abstract types don't hold telecrystal rewards or progression
rewards anymore, this has been moved to the non-abstract types.
balance: Rebalances rewards from repeatable traitor objectives to be
more consistent with each other.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
So, this spiraled from one missing icon being fixed to an entire check
for said icons.
Several icon files no longer use error icons because its assumed that
the checks will handle any missing ones, but the checks don't apply to
emissives nor overlays at all. This led to the radsuit having an
emissive but no icon_state for it - a relic of the old radsuit. This was
only noticed because of a downstream with an error icon appearing for
it...
I was curious how many were actually having the same issue, so I made a
small little stack_trace in the mutable_appearance proc.
There were like, 2k. Lots of them were icons named, like, "transparent"
or "blank" too...
I moved that check to the emissives proc because I semi-understand that
system so could actually fix it, and it moved to around fourty
roundstart. Much more achievable.
(The error usually has more info if you click on it, including the item
that caused it. I dunno how to add that to the check itself because of
where it's located, though.)
This fixes all the ones I could find, including...
Nonexistant icons that shouldn't be adding emissives on:
- Empty Barsign
- Radsuit
- Mass Driver Controllers
- Telescreens
- Aux Base Consoles
- PanDEMIC
- Kobayashi computer (holodeck)
- Abductor camera console
- Syndie drop pod
- BSA controller
Entirely missing icons on:
- Pwr Game Vendor (this was just misnamed)
- Generic Soda Vendor
- Engivend
- Security Laptop (proud of this one.,.,)
There are no doubt more of them hidden about, but I don't really know
what I'm doing... If there's a check that'd be better than this, please
review telling me what to change <3
## Why It's Good For The Game
Fixes missing icons, fixes attempts to add icons where we don't need
them, and adds a check to help fix more of the two issues as they occur.
## Changelog
🆑
fix: fixed missing emissives on the Engivend, Pwr-Game Soda, and generic
Soda vendors. Also fixed the seclaptop having no valid screen icon!
fix: fixed a few items trying to apply emissives when they shouldn't.
code: added a stack_trace for emissives with missing icon states.
/🆑
## About The Pull Request
- Same issue as Ethereals. Owner was `null`ed because the heart was
recreated. I opted for a more permanent solution, that being introducing
a new flag to avoid recreating organs.
- Adds some unit tests for fully heal stuff to make sure it works.
## Why It's Good For The Game
More cases of revival working as expected
## Changelog
🆑 Melbert
fix: Nightmare revival acts less funky - stops it from re-creating the
Light Eater.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Let me paint you a story.
A long time ago monkeys once rested their feet on the floor, this was a
time of bliss and peace. But sometime around the horrors of making
monkeys subtypes of humans did an atrocity occur.
**The monkeys were moved up.**
I thought this was bad, and alot of people on the forum tended to agree
with me
This was do to some purpose of adjusting them so it could be easier to
fit item sprites onto them instead of preforming the hours of work
refractoring to make the heights of the items dynamic and adjustable. A
simple pixel shift may have sufficed, but you see, such a change would
NEVER allow the frankensteining of monkey and human features together.
This is that refractor.
In essence, the following is now true.
A top_offset can now be generated for a human based on a varible on
their chest and legs. By default, and as is true with human legs and
chests, this variable is ZERO by default. Monkey legs and chest have
NEGATIVE values proportionate and onto how much smaller their sprite is
compared to humans. Other bodyparts, as well as any other accociated
overlays, or clothing will automatically be offset to this axis. THIS
MEANS THAT MONKEYS ARE ON THE FLOOR. But is means something else too.
Something more freakish,
**What abominable monsters**, unreachable by players as long as we can't
stitch monkeys and humans together (oh but just wait until the feature
freeze ends)
Oh but you might be thinking, if legs can make a mob go down.
can it make a mob
**go**
**up??**
**OH NO**
These lads are stepping, and have been implemented solely for proof of
concept as a way to flex the system I have created and remain
inaccessible without admin intervention.
But really, when all is said and done, all this PR does in terms of
player facing changes is move the monkey back down.
Oh and fixed monkey husked which have been broken for who knows how
long.
## Why It's Good For The Game
The monkey is restored to its original position. Tools now exist to have
legs and torsos of varying heights. Monkey Husking is fixed.
## Changelog
🆑 itseasytosee
fix: Monkeys ues the proper husk sprites.
imageadd: The monkey has been moved back down to its lower, more
submissive position.
refactor: Your bodyparts are now dynamically rendered at a height
relevant to the length of your legs and torso, what does this mean for
you? Not much to be honest, but you might see a monkey pop up a bit if
you cut its legs off.
admin: The Tallboy is here
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
They make me sad and we should test for them
I use dir here to prevent like, bulb + bar stuff, idk if that's wanted
or not tho
## About The Pull Request
Fixes#73491
Every time I have used this ability lately it's been fucked.
It would vanish from my actions at arbitrary moments, and also sometimes
transform me into a horrible monkey-man thing instead of a monkey. This
is a shame because being able to become a monkey can be pretty fun, even
if it makes you very vulnerable to being butchered.
Refactoring it into being one action instead of two actions which add
and remove each other fixes the part where the action just disappears.
It reliably sticks between transformations now, regardless of whether or
not they were voluntary.
I also noticed that when I was turning into a monkey it wasn't dropping
the changeling "fake clothes" outfit pieces I had on as a human, leading
to a really fucked up looking monkey. I fixed this by adding `force =
TRUE` in the drop to ground proc in the check for if the equipment you
have is still valid after your species changes. I don't _think_ this has
any side effects but I never do and then someone finds some.
For good measure I also made all of the changeling equipment abilities
which don't work if you are a monkey detect if you become a monkey and
retract themselves.
I also noticed that for a long time Last Resort has been trying and
failing to give you Lesser Form (well, Human Form rather) as a Headcrab,
so I fixed that and now you actually get the ability.
Finally I did a _little_ bit of housekeeping in general on the
changeling actions, mostly balloon alerts. I think these definitely need
more attention than I gave them though. I left a lot of the `to_chat`s
in place because many of them give information you want to be a little
sticky, or refer back to in order to double check what you just did.
I also added a unit test which flips back and forth a few times to
ensure the ability still works.
This required adding an "instant" flag to the monkeyize/humanize procs
to skip the timers, and idenitified a couple of weird issues.
First point: Humanising a monkey would remove the monkey mutation and
then call humanise again, which would not skip itself because it still
regarded you as being a monkey. I changed the order of operations here
slightly so that it will early return.
Second point: Calling `domutcheck` on `human/consistent` would runtime
because we skip the bit which sets up any mutations in their DNA. This
is a part of changeling transformation, so I just made it return
instantly.
## Why It's Good For The Game
You can use this ability again without getting stuck permanently as a
monkey, or it just deleting itself from your list of abilities for no
reason.
Turning into a monkey with fake outfit pieces on won't turn you into an
abomination.
## Changelog
🆑
refactor: Changeling's Lesser Form is now one ability instead of two
which keep swapping, which should consistently turn you back and forth
without deleting itself from your action bar.
fix: Hatching from an egg left by a Last Resort headcrab should
correctly grant you Lesser Form in addition to your other abilities.
fix: Turning into a monkey while using the Changeling space suit won't
leave you as a monkey with a weird inflated head.
qol: Using lesser form as a monkey with only one stored DNA profile will
skip asking which profile you want and will simply transform you
immediately into the only option.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Reverts tgstation/tgstation#73159
Pretty sure this wasn't supposed to be merged, considering it disabled a
test, a workflow run, and implements an atom New override
New regression in init times. Closes
https://github.com/tgstation/dev-cycles-initiative/issues/32. CC @Fikou
- Instead of creating a human and icon for *every* cardboard cutout when
initialized, only creates the one we're actually using. When you're
about to use a crayon, creates all of them.
- Instead of using getFlatIcon, uses appearances directly.
## 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.
/🆑
We shouldn't really be invoking the proc itself because then we don't
pass along the failing line/file to our consumers, let's use the macro
in all instances that really need it.
I noticed people were invoking the `Fail()` proc directly rather than
using `TEST_FAIL` instead, so they weren't getting those neat
annotations on their failing code because we never passed along the
failing line/file to actually apply those annotations. That's silly. We
don't even return on `TEST_FAIL` either, so there's no reason to not do
this (only upsides wahoo).
