Commit Graph
4 Commits
Author SHA1 Message Date
ZergspowerandGitHub 27551e1caf Tweaks blindness to be more player friendly (#94323)
## About The Pull Request

So something i missed from when i played Goonstation a long while ago
was my blind characters, i tried recreating them in TGCode but found
that the blind quirk here is far more harsh to play visually. So i got
some help from Melbert and got a plan goin and here's the results.


![blinds](https://github.com/user-attachments/assets/d12bd5c1-e0cb-4997-835f-279076c6a665)

Players can see colors! But muted, this change is strictly for visual
enjoyment as the constant monochrome is just - i cant really describe
how much i hate seeing it for more than 15 minutes.

Secondly the flicker is gone from the quirk but remains for all the
temporary blindness, this is 100% Melberts code as they're a helluva lot
smarter than I am and I just nod and smile before pasting it. This did
entail creating a new fulscreen in the dmi, but i just copy/pasted the
existing one and took out the animated frames and named it as 'static'
so it wouldnt interfere with anything else using it.

## Why It's Good For The Game

Playing a blind character is great, however it causes some serious
eyestrain after prolonged playstyle

## Changelog
🆑 MrMelbert, Zergspower
qol: The world is now heavily desaturated while blind, rather than pure
monochrome, to give players some visual stimulus
qol: When blind, the brief flicker of the entire screen now only appears
for mobs temporarily blinded - ie, mobs blinded from quirk / trauma /
genetic mutation no longer experience it
/🆑
2025-12-10 20:42:56 +00:00
GhomandGitHub 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
SmArtKarandGitHub 845ed7459e Bravo Six, Going Dark: Refactors client colors to fix dupe issues and support filters (#89843)
## About The Pull Request

Completely refactored how client colors are handled. Now they're similar
to traits, having a source associated with them. Instead of adding and
removing by strict type (which makes client colors prone to getting
duplicated and not cleaned up) you remove a filter associated with a
specific source. Adding another client color with the same source as an
already existing one will replace the existing one if its of a different
type, or do nothing if they're the same (unless force is set to TRUE).
Client colors can also force filter splitting, putting all colors that
come before them, themselves, and all colors after them into separate
filters - this is useful to prevent mixing in filters which are supposed
to remove a certain color.

<details>

<summary>Example of how Perceptomatrix and nightmare vision goggles
combined before this PR:</summary>


![dreamseeker_fBOse2i0jq](https://github.com/user-attachments/assets/fb164e1f-ce8b-4a8c-8820-5db25e710056)

And this is after, as you can see nightmare vision effect's red is only
slightly tinted by perceptomatix instead of being literally halved.


![dreamseeker_U6A24fetK8](https://github.com/user-attachments/assets/8d8b3eb5-9f53-4646-bc56-0f5897013c6f)

</details>

Additionally, added support for custom filters (and not just colors) to
client color code to allow us to work with more colorspaces.

Also fixed weird blindness behavior, so this also 
Closes #89787

## Why It's Good For The Game

Makes code less ass to work with, fixes weird color mixing, etc.

## Changelog
🆑
fix: Fixed perceptomatix helmet allowing you to see even when
unconscious
refactor: Refactored how client colors are handled, ensuring that
certain effects like nightmare goggles don't disappear when another
vision-affecting piece of clothing is worn.
/🆑
2025-03-17 11:35:11 +00:00
tontyandGitHub e755854af2 Nearsighted severity sources (with unit test) + status_effect/grouped minor rework (#88591)
# About The Pull Request
## Nearsighted Sources
Nearsighted now associates/tracks severity applied by each source.
Previously, nearsighted only used a single variable which had to be
shared by every source, which caused problems for things like scarred
eyes which needed independent behaviour.

This implementation allows sources with different severity levels to
coexist without needing workarounds

There are now two different severity types for nearsightedness:
* Correctable: Can be mitigated with vision correction (like glasses)
* Absolute: Cannot be mitigated from any source, used for scarred eyes

Which can allow nearsighted sources to not be affected by vision
correction.
Also, since there is no more technical conflict between the two quirks,
I've made it so that nearsighted and scarred eye can be selected
together (as a QOL change)

There is also a new unit test for this new behaviour
(nearsighted_effect) that checks application and removal
## status_effect/grouped minor rework
Grouped status effects now have `source_added()` and `source_removed()`
procs, which are called whenever a source is added or removed from the
effect

I did this because the previous implementation was somewhat unwieldy. 
Inherited status effects would recieve the _currently existing_ effect
through merge_with_existing, and require them to modify the existing
effect's properties, which is odd and not intuitive to work with (the
proc's `src` was not the existing effect)
It not being called for every source also made users repeat code in
`on_creation()` and `merge_with_existing()` for every source added.

This new interface should prevent repetition and be generally more
intuitive to work with.

# Changelog

🆑
refactor: Nearsighted has been reworked to track severity applied from
each source, as well as allow "non-correctable" nearsightedness (for
things like scarred eyes).
qol: The above being possible now means that you can select the
Nearsighted and Scarred eye quirks together
fix: Any bug that would occur from becoming nearsighted with a scarred
eye should be fixed now
code: status_effect/grouped merging code has been improved (i hope)
/🆑
2025-01-15 14:29:38 +01:00