## About The Pull Request
All usages of world.icon_size in code have been replaced with new
`ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on
context
Replaces some "32" magic numbers with the defines
A few bits of code have been modified to split up x/y math as well
## Why It's Good For The Game
Magic number bad, code more readable, code more flexible and I'm told
there's an access cost to doing world.icon_size so minor performance
gains
## Changelog
🆑 tonty
code: made some code relating to the world's icon size more readable
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Reworks sneezing. Instead of a range check that checks if you're facing
someone, it is now a skill check
https://github.com/tgstation/tgstation/assets/7501474/c11ffa16-9bd2-4ed1-8022-2094360657bc
All sneezes shoot projectiles, but depends on the virus if they're
infectious. Using the sneeze emote is the only method that doesn't shoot
a sneeze
## Why It's Good For The Game
I think the invisible infection mechanics are unfun. A lot of station
dangers challenge your knowledge and mechanical skill, while viruses are
gotten by being around people in a roleplay game. You can get a round
seriously ruined if you walk past someone with a sneezing virus and
don't immediately rush spaceillin or chemistry, which I don't think is
mechanically interesting.
Now if you get infected, it's a skill issue. Get good and dodge the
sneeze
Note that this is just one method of infection. I didn't touch coughing
and airborne viruses, which do constant area checks and infect everyone
around. I plan to, but not now. I'll probably make coughing do a cone or
something, and ignore the airborne viruses since they can't be modified
and are generally less broken
## Changelog
🆑
balance: You can now dodge sneezes
balance: Infectious simple diseases that use sneezes now infect with
sneezes and have lowered airborn transmission
balance: Damageless attacks, projectiles, hugs etc no longer drain
shields
/🆑
- [x] Make sneezes shoot to your cursor so you can either intentionally
sneeze on people or sneeze away from people if you react fast
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## 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.
/🆑
## About The Pull Request
apparently vis x and vis y dont exist unless the object is transformed
## Changelog
🆑
fix: sniper scope and kinesis should work without widescreen
/🆑
## About The Pull Request
Fixes#52946
This has been broken ever since #44112 which apparently removed the proc
in this component which selected a target for performance reasons and
just... didn't replace it with anything else? So it's been bricked ever
since.
In order to restore the removed mouse tracking behaviour I implemented
the pattern used in scoped weapons and the kinesis module. As this was
the third thing I could find to use this code, I abstracted it out into
an object where most of the shared behaviour lives. I tested those
things too and they still seem to do what they used to.
Here it is in action:
https://user-images.githubusercontent.com/7483112/221954852-22244bb1-7c87-452d-a9b0-ebed81c4c1ef.mp4
Because this spell now applies a full screen overlay in order to
function, it's really begging for someone to make some touhou-style art
with cards and patterns around the edge of the screen while you are in
aiming mode, but I'm not going to be the one to make it.
I tidied this component up and refactored it as best I could while I was
reworking it to use a full screen overlay but I am... not totally
confident that it should be a component at all given that it keeps being
created and destroyed. But also it has worked that way for like four
years now, so who am I to say.
Oh yeah also the icon for this spell broke, so I fixed it.
## Why It's Good For The Game
Makes a reasonably terrible wizard spell marginally less bad.
Maybe now that this component works, some other things can use it?
If we make a fourth thing which follows your cursor it won't need to
copy/paste code around.
## Changelog
🆑
fix: Spell Cards from the Wizard spell will now home in somewhat on the
target nearest to your cursor.
fix: The Spell Cards spell now displays the correct icon instead of a
big red "error" text.
/🆑
tonty