Commit Graph

20 Commits

Author SHA1 Message Date
SyncIt21 81427cd5cf Unit tests, refactor & realignment for map loaded wall mounts (#93662)
## About The Pull Request
This 1st has to be PR'd so the integration tests can point out all
wallmounts that could not find a support structure to mount on. I then
will do many map edits to align them onto the closest atom

Yes we no longer use wall mount but atom mounted component. All objects
that are mounted on windows/tables & fences now also fall off when
destroyed

It'll probably be a WHILE before I can fix all wall mounts. Long day.
Expect me to misalign many stuff to fix failing CI so make sure to
provide suggestions when possible

Improved wallmount code overall
- Fixes #93793


## Changelog
🆑
fix: fixes all incorrectly maploded wall mounts that aren't actually
hanging on any support structure
fix: objects mounted on tables, windows & fences also fall off now when
destoryed
qol: lights can be mounted on windows
qol: cameras can be mounted on windows
qol: buttons can be mounted on tables
refactor: improved how wall mounts interact with objects as a whole
report bugs on github
/🆑
2025-11-18 22:37:12 -07:00
Ghom 999bde8f84 Most screen alerts now fit the player's hud style. (#93493)
## About The Pull Request
Most screen alerts that use the midnight hud style no longer have the
button baked in their icon. Other screen alerts with their own
background or shape (robot and mech alerts, atmos, heretic buffs or
debuffs etc.) are not affected. Also updated a couple sprites but didn't
spend too much time on them. Mostly reusing existing assets.

Montage of how the alerts look on threee different hud styles
(Operative, Trasen-Knox, Detective, ALSO I FIXED THE BUCKLED ALERT
ALREADY):
<img width="293" height="323" alt="image"
src="https://github.com/user-attachments/assets/3a2b972b-aa5a-4c27-a454-c8c39acf6e20"
/>
It looks only a smidge iffy on the syndicate since the top and bottom
borders aren't layered over all the overlays, but it isn't something to
worry about in this PR.

## Why It's Good For The Game
Screen alerts always had the midnight hud button baked in their icon
states (now overlays), which completely disregard the player's hud
setting, much unlike action alerts buttons. Melbert has also said that
it'd be nice if the code for action buttons could also be used in screen
alerts and viceversa, to slim things down. That's obviously not what I'm
doing today, but having most of the screen alerts already without the
baked background will surely help if we ever pursue that objective.

## Changelog

🆑
refactor: Refactored screen alerts a little. Most should now fit the
player's hud style. Report any issue.
imageadd: A few screen alerts have been polished/updated a little.
/🆑
2025-10-31 15:30:39 -06:00
Ghom b48b717730 Fish analyzer UI is a bit more reactive, also fixing a couple things with fish reproduction (#93461)
## About The Pull Request
The fish analyzer now uses ui_data to fetch hunger, health, size, weight
and breeding cooldown rather than ui_static_data, meaning these values
are updated in real time on the UI. It also calls
update_static_data_for_all_viewers() whenever the user scans a new fish
or aquarium or if fishes are added/removed to/from the aquarium, and
closes the UI if the scanned object is out of normal view or further
than 7 tiles away.

I've also reduced the breeding cooldown for newly spawned fish from two
times the standard cooldown (usually 2 minutes, hence 4 minutes) to 60%
of it. Offsprings still retain the usual 200% cooldown however. This
should make it a bit easier for people who want to use the aquarium with
fish acquired through means other than fish farming itself.

Lastly, this PR introduces a small unit test to make sure that the
stable population of most fish is higher than 1. This was the problem
with #93043, where you couldn't breed a slimefish with a lavaloop
because the stable population of the latter wasn't set. I'm sure that's
a problem with other fishes as well, and that explains some of the
confusion with the feature (that and its opacity as a whole I guess).

## Why It's Good For The Game
This will close #93043, improve the fish analyzer UI updates, make fish
farming etc. less problematic.

## Changelog

🆑
qol: The fish analyzer UI should update more reliably.
fix: Fixed some of the fishes being unable to reproduce.
balance: Fish acquired through means other than fish farming itself
takes less time to be able to reproduce.
/🆑
2025-10-23 13:45:49 +13:00
Ghom aa4cf2b136 The nullrod refactor (the carp-sie plushie is now actually a plushie) (#93311) 2025-10-10 13:42:33 +11:00
Ghom 4975174928 [NO GBP] Adds unit test checks for materials and processable comp & co. (#92194) 2025-07-30 13:17:12 +02:00
Ghom 7c703fc712 Food types are now passed down when cooking from recipes. (#89706)
## About The Pull Request
~~I have some beef with the cooking system.~~

Cooking recipes are coded in a way that disregard the possibility for
their components to have different foodtype flags than the ones you
would find normally find.
For example, if I wanted to make corned beef, but instead of a standard
steak, I used a killer tomato "steak", the result would still have the
meat food type, even if none of the components has it.

I've had to resort to a few hacky lines of code to manipulate the food
types from the edible component, but that can be easily fixed if #89687
is merged.

## Why It's Good For The Game
This also makes cooking recipes less strict about their food types and
can help us spot inconsistencies with recipes.

## Changelog

🆑
qol: Food types are now passed down when cooking from recipes. For
example, a plate of corned "beef" made from giant killer tomato slabs no
longer counts as meat but only vegetables now.
fix: Fixed a metric ton of inconsistencies with food types and recipes.
fix: Dank-pockets (the weed variant) can now be microwaved.
/🆑
2025-03-13 20:06:35 +01:00
MrMelbert 9b40e13f8b Makes dust animation look less 2006 (#87435)
## About The Pull Request

This was inspired by an effect I saw on Paradise but I sprited my own


https://github.com/user-attachments/assets/2130053c-a6ea-48e6-8b62-4c08563fd154

(Todo, make the skeleton appearing less jank)

## Why It's Good For The Game

1. Looks less 2006. 
2. The dust sprite will reflect the mob being dusted, since it's
literally just Your Sprite. Your clothes, species, etc.
3. All species and all mob types now animate being dusted - from corgi
to xenos, from borgs to lizards -, and we can even reuse this effect for
items being dusted if we so desire

## Changelog

🆑 Melbert
image: The animation for being dusted now takes into account your
sprite, rather than being a normal nude spaceman
/🆑
2024-11-12 10:31:03 +13:00
MrMelbert cef009e7c6 Refactor special_step_sounds out of existence, Human steps now depend on leg type, Digitigrade legs use claw footstep sfx (#87006)
## About The Pull Request

1. Deletes `special_step_sounds`. Unused anyways. 
2. Human footstep type is now determined by its legs. 
- This means a human with two different legs, with two different
footstep types, now alternate between footstep type every other step.
3. Digitigrade legs now use claw footstep sfx

## Why It's Good For The Game

Less random species vars, more dynamic human code, and a little bit more
immersion

## Changelog

🆑 Melbert
refactor: Refactored footsteps for humans. Human footstep sound effects
are now determined by your leg type. Report any oddities.
qol: Digitigrade legs now play claw footstep SFX. "plat plat" is dead,
long live "tap tap".
/🆑
2024-10-07 11:58:19 +02:00
LemonInTheDark e90a9b4b68 Flattens The Floor Plane (Camera Update Too) (#84350)
## About The Pull Request

Ok so like, side map right? It makes things higher up in the world
render above things lower down in the world.

Most of the time this is what we want, but it is NOT what we want for
floors.
Floors are allowed to be larger then 32x32, and if they are we want them
to render based off JUST their layer.
If we don't allow this grass turfs and others get cut off on their
bottom edge, which looks WEIRD.

In order to make this happen, we can add TOPDOWN_LAYER to every layer on
the floor plane and disable sidemap.

I've added documentation for this to VISUALS.md, and have also
implemented unit test errors to prevent mixing TOPDOWN layers with non
topdown planes (or vis versa).
This new test adds ~1 second to tests, which is I think a perfectly
scrumpulent number.

EDIT:

I nerd sniped myself and implemented sidemap layering and lighting for
cameras (also larger then 32x32 icon support for getflat)
The lighting isn't perfect, we don't handle things displaying in the
void all that well (I am convinced getflat blending is broken but I have
no debugger so I can't fix it properly), but it'll do.

This came up cause I had to fix another layering issue in cameras and
thought I might as well go all in.

![image](https://github.com/tgstation/tgstation/assets/58055496/601b422c-f6aa-42ba-bcd9-b1faebe236e3)


## Why It's Good For The Game

Old:

![image](https://github.com/tgstation/tgstation/assets/58055496/d4102386-420d-4346-b05c-b819e62d98d0)

New:

![image](https://github.com/tgstation/tgstation/assets/58055496/1f5e303e-adee-427d-8fe3-76c8f2dbe098)


## Changelog
🆑
fix: Grass turfs will render properly now. Reworked how floors render,
please report any bugs!
fix: Cameras now properly capture lighting
fix: The layering seen in photos should better match the actual game
/🆑
2024-07-04 12:10:41 -07:00
Ghom 95b7fa1fb7 Add a unit test to check that maploaded simple/basic mobs are in an environment they can survive in. (#82180)
## About The Pull Request
I've recently noticed that the maploaded penguins from the snowdin away
mission were dying from unsafe atmos/temperature. This sparked the idea
of making a (focus only) unit test that would prevent this sort of
issues from happening.

This PR also implements the usage of the `atmos_requirements` and
`body_temp_sensitive` elements for simple animals too, cutting down the
copypaste.

## Why It's Good For The Game
More unit tests to make sure things are done correctly.

## Changelog

🆑
fix: Made sure that mapped critters (i.e. penguins on the snow cabin
away mission) can survive in the environment they're spawned in.
/🆑
2024-03-27 16:01:56 -06:00
Ghom 5b793ee714 Actually fixing fishable contents for some sources. (#78030)
## About The Pull Request
During my first fishing related PR, I hadn't yet know that for the
`fish_counts` var to work, its contents also had to be within the
`fish_table` list, thus I ended up adding stuff that's not actually
fishable. Also there was no unit test to enforce that design, which is
lame.

## Why It's Good For The Game
Fixing the issues explained above. Basically #78019 but done right.

## Changelog

🆑
fix: You can now actually fish soggy wallets from toilets, rare ores on
ice moon, some boney stuff in oil puddles (good luck finding them) and
lube-fishes by the seawater.
/🆑
2023-09-02 16:21:09 +01:00
LemonInTheDark cfc4e960bc Properly unreg's turf changed when space openspace is deleted (#76501)
## About The Pull Request

Openspace tracks the turf below for starlight purposes The trouble is if
a turf is replaced by another, all its signal registers still persist

I forgot about this, so we'd get runtimes when a
/turf/open/space/openspace was replaced, and the turf below it changed

## Why It's Good For The Game

Less random runtimes
2023-07-08 00:02:18 +01:00
san7890 d8058f1245 Datumizes out jobconfig.toml (extensibility edition) (#76102)
## About The Pull Request

Hey there,

#75992 (fc54fd6a60) made me realize just
how wacky the job config system is to people trying to add more new
stuff to it, so I finally got the motivation to fix it up.

The gist is that it does all of the same stuff on the front-end as you
would expect, but instead of having to modify core generation code to
create/recreate the files, it instead uses a robust series of getters
and setters. It's much better to use these getters and setters because
we can apply needed game logic (like ensuring that the age that the
server operator puts in is actually sane, and not completely out of
bounds (if you want to permanently price people out of a position, just
set it to 0)). The getters are also nifty too, because they let me atone
for an early mistake I made with how assistants are meant to work with
"unlimited" nonsense.

All a new coder who wants to add stuff to the config needs to do now is
create the define, create the datum, add the procs for the datums, and
that's it! They don't have to do any of the wacky stuff or account for
weird stuff or do any weird copypasta, it's all handled by the system.
One datum is all you need, quite neat.

This also fixes some issues in #75992 that probably weren't discovered
in testing, but the only good way to fix it was a retune+refactor, which
is included in this PR.
## Why It's Good For The Game

Much more extensible, ensuring this system actually works as fully
intended, etc.

I fixed up the documentation (they didn't regenerate the job config
after they updated the code-side documentation) and some weird spacing
stuff that I missed in my review of that aforementioned PR. Everything
should work as expected, it's been tested quite a bit. It's also in its
own folder now, which is neat because we can share the local defines and
split all this stuff out of the already-quite-large SSjob file.
## Changelog
🆑
server: job_config.toml should now comply with reload-configuration
verb, meaning you can hot-reload the configuration from disk and have it
apply ingame automatically.
config: The documentation for setting Minimum Character Age on a per-Job
basis has been altered to be more explicit.
fix: The Minimum Character Age configuration entry is now sanitized to
ensure that it's within the codebase-defined ages, since there's no
(legitimate) way to get a character outside of those ages anyways.
Invalid values will log to the config log.
/🆑

---------

Co-authored-by: Jacquerel <hnevard@gmail.com>
2023-07-04 23:57:16 +00:00
MrMelbert 6085e3b5ee Reagent soup / Soup rework / Stoves - A kitchen expansion (#74205)
## About The Pull Request


![image](https://user-images.githubusercontent.com/51863163/227391708-8de28b68-149f-4e02-a2d3-22f6e3067784.png)

**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.
/🆑
2023-04-07 19:42:49 -06:00
OrionTheFox b2e53feee2 Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart (#73678)
## 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.)

![F99cOII1XJ](https://user-images.githubusercontent.com/76465278/221503786-63dc6980-a48b-4290-b891-23c0499500ff.png)

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.,.,)
![dreamseeker_36PwO4HSLO](https://user-images.githubusercontent.com/76465278/221544806-3c5ae33a-1360-49e0-ba80-afea6c0a9339.gif)



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.
/🆑
2023-03-05 12:17:41 -08:00
LemonInTheDark 63eaec9a58 Adds a unit test to detect double stacked lights (#73650)
## 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
2023-02-26 19:37:51 -05:00
LemonInTheDark ab307032ed Nightvision Rework (In the name of color) (#73094)
## 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


![image](https://user-images.githubusercontent.com/58055496/215683654-587fb00f-ebb8-4c83-962d-a1b2bf429c4a.png)

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.
/🆑
2023-02-17 18:10:39 -07:00
Mothblocks f960967cea Avoid creating string list of turf platings, rename some of the APIs, and improve focused test support - 160ms+ (more on prod) of init savings (#72056)
Looking at some stuff that uses `Join` right now as targets, this one's
pretty straight forward.

`/turf/open/floor/Initialize`, called 20,000 times without ruins,
creates a string list of the broken and burnt states. This carries the
fixed cost of `Join`, which is very expensive, as well as some (not
crazy, but not negligible) proc overhead.

These vars were used for effectively nothing, and have been replaced
with just using the list when necessary, which only adds an extra
millisecond of cost to update_overlays.

This was also used to automatically set `broken` and `burnt` at runtime.
However, this looks like it has gone completely unused. Adds a unit test
which adds it as a static field to the only type that cared about it,
which was abductor tiles, which is wrong anyway, but Whatever. I want to
support people making a subtype of floor tiles that are pre-broken
without it messing up stuff silently, so the test is there.

While I'm at it, renames `setup_broken_states` and `setup_burnt_states`
to remove `setup_`, since they don't really do that anymore (and never
did).

Also also, adds support for `PERFORM_ALL_TESTS` to work with multiple
focuses.

For reviewing, basically all of the changes are in floor.dm, aside from
test stuff, which is unit_test.dm.
2022-12-26 22:03:31 -08:00
Mothblocks 453080d3fc Moves space initialization check to unit test - Saves 0.065s of init time (#71796)
This hasn't been hit in a long time and this is an extremely hot proc,
doing these checks in unit tests should catch any cases, though
unlikely.

This has zero cost at runtime because `if (FALSE)` statically compiles
out.
2022-12-12 23:31:36 -08:00
Mothblocks 8ace31bde4 Allows for offloaded tests to be focused (#71719)
Focusing a test through TEST_FOCUS allows you to only run that one test.
It's very useful for developing. However, we have a bunch of offloaded
tests in `#ifdef UNIT_TESTS` that would not be focused. This changes it
so that those tests will now only run if either no test is focused, or
if their specific "focus only" test is focused.

This is done through a `PERFORM_ALL_TESTS` macro that replaces the
`#ifdef UNIT_TESTS`. This is completely free because `if (FALSE)`
constant folds.

Hide whitespace mode recommended.
2022-12-07 02:58:33 -08:00