6 Commits
Author SHA1 Message Date
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
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
ee271daf46 clickable alerts glow + the slimed status effect now actually tells you how to get it off without water in the description (#87902)
## About The Pull Request

 clickable alerts glow (regex: /atom/movable/screen/alert/.*/Click)

## Why It's Good For The Game

people are much more likely to look at the chat or anywhere else than
the status effect (really, its usually never worth reading 99% of them
so they end up ignored)

## Changelog
🆑
qol: alerts that do stuff when clicked glow gold
/🆑

---------

Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
2024-11-20 02:07:05 +01:00
MrMelbertandGitHub 239797a4ee Deletes misleading infinite define, adds defines for clearer status effect durations (#87842)
## About The Pull Request

1. Deletes `INFINTIE`, it is misleading and not at all a big number and
causes bugs
2. Adds `STATUS_EFFECT_PERMANENT` and `STATUS_EFFECT_NO_TICK` to make it
clearer what infinite status effects are
2024-11-12 17:24:27 +01:00
MrMelbertandGitHub 21d72c49c0 Blocks (most instances of) screen elements from entering base atom /Click (#82236)
## About The Pull Request

Fixes #76495

This PR prevents (most) screen elements from running base
`/atom/proc/Click` and `/mob/proc/ClickOn()` when clickend.

(The only exception I found to it was the cursor catcher for scopes.) 

Why?
Most, if not everything in `ClickOn` is considered "in world"
interacting. It abides by `incapacitated`, runs `faceAtom`, etc.
This means, currently, you can "interact" with screen elements using in
world elements. For example, TK-ing / pointing a gun at your mood face.

Right now this affects very little, but there is a large potential for
errors. All you have to do is forget a sanity check in `afterattack` and
suddenly you have an item that can affect your screen objects.
The only example I found was the `/item/godstaff`, which can color some
of your screen elements. But there may be more. Like guns.

Note: 
Many, many screen elements ALREADY do not fall down into atom click.
They simply don't call parent. Which is totally fine.
I am just ensuring ALL* screen elements do not fall down into atom
click.

## Changelog

🆑 Melbert
fix: Blocks mobs from trying to "physically" interact with some of their
hud elements, such as using Telekinesis or point a gun at your mood
meter.
/🆑
2024-03-26 14:55:20 -06:00
GhomandGitHub aa9caef0ed Fishing hook and reel line tweaks (also qol for the fish bounties) (#80599)
## About The Pull Request
This PR includes a series of small changes and additions to hooks and
reel lines, as well as the aforementioned bounties. My objective here is
to make the (base) hook and reel line feel more useful. Ditto with a few
other things.

Here's the list of changes:
- Almost all fishing rods come with a hook and reel line pre-installed.
The rod from the fishing toolbox comes with separate hook and reel line.
- Without a hook, you cannot fish. Without a reel line, the cast range
is reduced (from 5 to 3).
- Fishing with a reel line installed provides a mild boon to completion
speed by default.
- The sinewy reel line (craftable from lavaland mobs) can now be used to
fish on lava / liquid plasma, but it's a bit stiff and gives a mild
malus to completion speed.
- Unlike other hooks, the rescue and jawed hooks now allow you to cast a
line and reel in living mobs too, not only items. They even get a status
alert they can click to un-snag themselves, or move away far enough to
achieve the same effect.
- Master fishing rod buffed. It now comes with a flexible reel line and
weighted hook pre-installed, and can be cast further than other rods.
- On top of that, the jawed hook will slow down living mobs snagged by
it and is a bit harder to remove.
- when casting a line, it will now show the icon of the current hook as
projectile, not a generic one.
- Reeling now correctly checks movement resistance and anchorage.
- Reeling an object (or a mob) now plays a sound. Ditto for
installing/removing slotted items.
- A few balloon alert feedbacks.
- Minor code improvements.
- The jawed hook should look a smidge sharper.
- reel lines are now small items.

## Why It's Good For The Game
The base hook and reel line didn't do anything begin with, and you would
do just fine without them. In the end it's just a bit unintuitive for
them not to be a requirement.

Beside that, it makes sense for the rescue hook to be able to snag mobs,
so they may as well be used to drag people out of lava or liquid plasma.
As for the jawed hook, it always felt to me a bit underwhelming and a
bit of a filler I had cooked up on the moment. It really could have some
'tactical' utility in virtue of being one of those niche black market
items.

## Changelog

🆑
add: Most fishing rods come with a hook and line preinstalled. Fishing
toolboxes come with separate reel and lines as usual.
balance: Fishing hooks are now required to fish.
balance: Without a reel line, the range of fishing rods is reduced by
two tiles. Conversely, having one installed gives a mild buff to the
minigame completion speed.
balance: The craftable sinewy reel line can now be used to fish on lava
or liquid plasma, but it's a bit harder to use.
balance: The rare-to-find-in-maintenance master fishing rod now comes
with a flexible line and weighted hook preinstalled, and has better
range than other rods.
balance: Fishing reel lines are now small enough to fit pockets.
add: The rescue and jawed hook can now snag and reel in mobs, not only
items. The jawed hook also slows down when applied, a la beartrap.
qol: Fish bounties now accept filled (stasis) fish cases.
qol: Several balloon alerts for fishing rod interactions.
fix: Reeling in items (and mobs) now respects movement resistance and
anchorage.
fix: Fixed the fishing rod equipment UI being too small to fit its
components.
sound: Reeling in something now plays a sound.
/🆑
2024-01-17 04:37:52 -05:00