* Confine Elevator Music to Elevators (#75464)
Refactors elevator music to originate from an abstract object rather
than the elevator control panel.
Elevator music is applied while you are within a certain radius of this
object and cuts off immediately upon exiting (largely because as far as
I know you can't obtain playing sounds to fade them out in byond).
As a side-effect of this refactor it also isn't audible to ghosts at
all.
* Confine Elevator Music to Elevators
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Mark client as QDELING (#75576)
Clients will now be marked QDELING while in the process of deleting.
Necessary for #75445
* Mark client as QDELING
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Makes chat helper procs async (#75414)
As they are and fixes some SHOULD_NOT_SLEEP hits
See #75232
* Makes chat helper procs async
---------
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
* Fix SHOULD_NOT_SLEEP hit in /client/Destroy() (#75241)
See #75232
* Fix SHOULD_NOT_SLEEP hit in /client/Destroy()
---------
Co-authored-by: Jordan Dominion <Cyberboss@users.noreply.github.com>
* Allows Export of your Preferences JSON File (#75014)
## About The Pull Request
Hey there,
This was spoken about in #70492 (specifically
https://github.com/tgstation/tgstation/pull/70492#issuecomment-1278069607),
and I have been waiting for this to be implemented for some time. It
never got implemented, so I decided to code it myself.
Basically, **if the server host doesn't disable it**, you are free to
export your JSONs as a player, right from the stat-panel. It's a pretty
JSON on 515 versions, too!
It's right here:
Here's what the prettified JSON looks like on 515.
There's a cooldown (default to 10 seconds) between exporting your
preferences.
#### Why is this config?
It's because in the past, a server host could always just file-share the
.sav or .json or whatever to the player, but they would have to do the
explicit option of actually bothering to make the files accessible to
the player. In that same line of logic, the server operator will have to
explicitly make the files accessible. This is mostly because I'm not
sure how good `ftp()` is at being a player function and wanted to have
some sort of cap/control somehow in case an exploit vector is detected
or it's just plain spammed by bots, so we'll just leave it up to the
direct providers of this data to elect if they wish to provide the data
or not.
## Why It's Good For The Game
Players don't have to log into Server A to remember what hairstyle they
loved using when they want to swap to Server B! That's amazing actually.
I always forget what ponytail my character has, and it'll be nice to
have the hairstyle in a readily accessible place (after I prettify the
JSON for myself).
It's also more convenient for server hosts to make player data like this
accessible if they really want to, too.
If we ever add an _import_ feature in the future (which would have to be
done with a LOT of care), this will also be useful. I wouldn't advise it
though having taken a precursory look at how much goes into it while
trying to ascertain the scope of this PR.
## Changelog
🆑
qol: The game now supports export of your preferences into a JSON file!
The verb (export-preferences) should now be available in the OOC tab of
your stat-panel if enabled by server operators.
server: Exporting player preferences is controlled by a configuration
option, 'FORBID_PREFERENCES_EXPORT'. If you do not wish to let clients
access the ftp() function to their own preferences file (probably for
bandwidth reasons?) you should uncomment this or add it to your config
somehow.
config: Server operators are also able to set the cooldown between
requests to download the JSON Preferences file via the
'SECONDS_COOLDOWN_FOR_PREFERENCES_EXPORT' config option.
/🆑
* Allows Export of your Preferences JSON File
---------
Co-authored-by: san7890 <the@san7890.com>
* Fix code not compiling on prod. (#74589)
(at)Mothblocks idea: make alt_tests a yml file and allow more generic alt
tests, like defines and shit. or we can put this on integration tests
and let windows build cover the normal/dev build case of preload_rsc = 1
* Fix code not compiling on prod.
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Increase first connect responsiveness by delaying vox sound preload (#74559)
These were getting sent too early and clogged up the queue of resources
to send the client, delaying chat load if the client had no byond rsc
cache and the cdn was not enabled.
Also this way if the cdn rsc download happens quick enough than these
calls can become noops. (if byond isn't smart enough to do that now, it
will be.)
* Increase first connect responsiveness by delaying vox sound preload
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Adds VERB_REF and derivative (#74500)
## About The Pull Request
Apparently in (one) place in the codebase, we were still using stuff
like `.verb/example_verb` for stuff like `INVOKE_ASYNC()` and
`CALLBACK()`s, and I'm pretty sure this is one of those things that are
being phased out in 515 (like we had to deal with in
4d6a8bc537), so let's give it the same
treatment as we did `PROC_REF` in November 2022.
In order to make this work, I created a generic backend of define
macros, and then moved two things: `PROC_REF` and `VERB_REF` to just
leverage that backend as needed. This was done just so we didn't have to
copy-paste code in case we needed to update these macros in the future,
let me know if I should approach this a different way.
## Why It's Good For The Game
code don't break (or at least the compile-time assertions won't break)
when we inevitably fully shift to 515. whoopie!
## Changelog
Nothing players should be concerned about.
* Adds VERB_REF and derivative
---------
Co-authored-by: san7890 <the@san7890.com>
* Clients can't OOC until they have fully gone through `New()` (#74493)
People are able to send OOC messages before `client/New()` is able to
fully set itself up. Let's guard against this by re-using the variable
we set at the end of New() and blocking any usage of the OOC verb if
they aren't set up. I made it a define so we can use it in other spots
as well if the occasion should call for it.
Define included in this PR can be (and probably should be when someone
has time) replicated in other spots where we need it.
* Clients can't OOC until they have fully gone through `New()`
---------
Co-authored-by: san7890 <the@san7890.com>
* Fixes floating point inaccuracies in numeric preferences (#74384)
## About The Pull Request
Floating point inaccuracy fun.
Since it's possible to have a `minimum`,`maximum`, and `step` that are
floats we need to round everything to `step` to ensure the comparison
operations work.
If we do not do this, there is no guarantee that `if(min <= number &&
number <= max)` will work correctly.
For example, in the linked issues, this manifested as the minimum value
(0.8) being considered invalid when the input was also 0.8.
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/9507
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/14394
## Why It's Good For The Game
Fixes an obscure bug that has gone unnoticed for a couple years.
## Changelog
🆑
fix: fixes floating point inaccuracies in numeric prefs
/🆑
* Fixes floating point inaccuracies in numeric preferences
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Adds preference for "Tagger" paint color. (#74281)
## About The Pull Request
Per the title, this PR allows you to pick your starting paint color from
the "Tagger" quirk on the character preferences menu.
This replaces the starting color being random; it does not prevent you
from changing the color later as normal.
## Why It's Good For The Game
It's a minor quality of life change. This will mostly be helpful to
players who have some "signature" color they like to use, to prevent
having to manually select it (and possibly input a color code) every
round. It will be of less relevance to those who tend to select new
colors every round anyway.
Possible downsides are mainly adding another pref to the menu, although
this shouldn't be too much of an annoyance since it only appears if you
already have the relevant quirk. It does also remove the _ability_ to
have a randomly-chosen paint color, though I'm not sure if that matters.
## Changelog
🆑
qol: you can choose your default paint color for the "Tagger" quirk from
prefs.
/🆑
* Adds preference for "Tagger" paint color.
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
* Splits mutant_bodyparts.dmi into several subfiles. (#71408)
Splits the `mutant_bodyparts.dmi` file up, as was suggested, but not
implemented, in #69302.
The following new files were created in the `icons\mob\species` folder,
containing the listed sprites:
- `lizard\lizard_misc.dmi`: Snouts, horns, frills, and body markings.
Anything I didn't feel needed an entire file to itself.
- `lizard\lizard_spines.dmi`: Lizard spines, both animated and not.
- `lizard\lizard_tails.dmi`: Lizard tails, both animated and not.
- `human\cat_features.dmi`: Felinid ears and tails.
- `monkey\monkey_tail.dmi`: The monkey tail.
- `mush_cap.dmi`: The lone mushperson cap, so easily forgotten.
Additionally, I moved `wings.dmi` from `mob\clothing` to `mob\species`.
I'm not sure what it was doing there.
`mutant_bodyparts.dmi` was something of a mess, with parts from four
different species thrown together haphazardly. It probably made sense in
earlier days when "mutant humans" were few and far between, but
splitting it up makes it more intuitive to find these sprites, and
brings it in line with other species - namely, moths. It also means that
any future sprites of these types added will not bloat an oversized file
even more.
Moving the wings file to the species folder just makes sense, because
wings are not a type of clothing.
🆑
refactor: Removed mutant_bodyparts.dmi and distributed its sprites in a
more sensible and granular manner.
/🆑
* External Organ Rework: new bodypart_overlay system (#72734)
Bodypart overlays are now drawn by the new /datum/bodypart_overlay
datum.
External organs no longer draw anything and instead add a special
/datum/bodypart_overlay/mutant to the bodypart, which draws everything
Makes it way easier to add custom overlays to limbs, since the whole
system is now modularized and external organs are just one
implementation of it
I haven't moved anything but external organs to this new system, I'll
move eyes, bodymarkings, hair, lipstick etc to this later
New pipeline is as follows:
- External organ added to limb
- External organ adds /datum/bodypart_overlay/mutant to limb to
bodypart_overlays
- Limb updates its icon, looks for all /datum/bodypart_overlay in
bodypart_overlays
- Very cool new overlay on your limb!
closes#71820🆑
refactor: External organs have been near-completely refactored.
admin: Admin-spawned external organs will load with a random icon and
color
fix: fixes angel wings not working for non-humans (it was so fucking
broken)
fix: fixes external organs being invisible if they werent initialized
with a human
/🆑
External organs are cool but are pretty limited in some ways. Making
stuff like synthetic organs is kinda fucked. I tried and it was dogshit.
Now you can just give an icon state and icon and you're good (using
/datum/bodypart_accessory/simple)
Stuff like eyes, cat ears and hair seem like good choices for extorgans,
but don't quite work for it because their icons work a lot differently.
This solves for it completely since any organ (or object or whatever)
can add it's own icon to a bodypart.
Want to add an iron plate to someones head? Go ahead. Want a heart to
stick out of someones chest? No problem.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Makes the whole thing compile, although it most likely doesn't work
* Whoopsie daisy
* Now it's starting to work
* ok monkey
* Fixes tails some more
* Moth wings should be wings not moth wings
* Podpeople hair, yeah.
* Okay no more handle_mutant_bodyparts()
* Removed an useless variable from is_hidden()
* Fixes some more can_draw_on_bodypart (I'm gonna have to fix it upstream too)
* Removes the second useless argument of is_hidden()
* No, cat tails are no longer allowed to be snowflake
* Removes some useless variables from humans
* Whoops I forgot to commit this one
* How did I miss this one?
* Okay, yeah, tails and some other stuff show up now. Pod people hair too. Just many of them don't. Good enough for today.
* Okay so after a lot of pain and suffering, many mutant_bodyparts are now functional
* Everything works, except for ears, some of the taur layering, and moth markings (which never worked it seems)
* Alright skintones seem to work rather well now(?)
* Okay, my bad, now they do
* Moth markings can't be selected and won't be added anymore (since they're broken and integrated into the regular markings system anyway)
* Spines are no longer just matching the color of the limb they're attached to
* Moves taur organ and bodypart_overlay out of the sprite_accessory file for taurs, and fixes the taur rendering
* Linters moment
* Alright, spines are working and overlaying properly now
They just need to have a FRONT overlay for the /tg/ ones if we want them to display above the lizard tails, we already have that for vox spines thankfully.
* Disables moth_markings for good
* Fixes some rendering bugs
* Makes ears work (almost, rest of the code has MODsuit stuff in it too :( )
* Made the MODsuit overlays work :)
* Fixed horns and spines
* Fixes all of the screenshot tests
* Removes the Body Markings option from Appearances, use Augments+ instead (because that one works and is just better)
* Bye bye handle_mutant_bodyparts(), I won't miss you :)
* Forgot to take this out, whoops
* Fixes the moth antennae being unticked
* Removes some commented code in a modular file
* Fixes part of the create_and_destroy unit test
* Fixes a pretty big issue that caused some sprite_accessories to be removed from the global list because of the alter_form action (deep copies ftw)
* Fixes the runtimes related to pod_hair
* Gives the vox a better look in the prefs menu
* Fixes the appearance of functional wings
* Makes synths able to access their robotic wings
* Podpeople don't cause runtimes during CI anymore
* Fixes the random appearance of locked functional wings
* Fixed cat and lizard tails using the /tg/ sprites (we have slightly modified ones)
* Fixes the coloring on multi-colored sprites
* Fixes the code for the screenshot of the mammal screenshots and preview, so it has a tail
* Fixes the screenshot tests for a few species
* Fixes tails going invisible when wagging
* Fixes a runtime with horns
* Fixes showing/hiding mutant bodyparts not working at all
* (Hopefully) fully fixes all the issues related to extra and extra2-related icon_states.
* Fixes synth stuff and starts working on pod hair again
* I DID IT PODPEOPLE HAVE HAIR AGAIN
* Fixes the podpeople hair showing up on more than just podpeople
* Fixes the IPC screens showing up on species outside of synthetics
* Fixes a runtime in the pod_hair and the synth_screen's apply_to_human
* Updates the screenshots for podpeople and synths
* Fixes an issue with a certain type of organs
* Fixes another runtime, whoops
* Fixes the markings from /tg/'s Body Markings not being available in our markings system
* Re-adds support for taur-variants of certain mutant bodyparts
* Hopefully fixes a few more runtimes
* Adds some debug variable in the code for now, likely to be removed later if really necessary. This will make my life easier.
* Whoops, that needed to be backwards. :clown:
* Fixes the top snouts not rendering at all
* Fixes the issues where bodytypes weren't handled properly, and thus snouts were getting squished
* Fixes the weird placement of the Xeno Head Emissives in the prefs menu
* Removes a no-longer-necessary override of post_set_preference() in the limbs_and_markings middleware
* Reverts an unnecessary SKYRAT EDIT inside of commented out code
* No longer creates a new body every time we change prefs in the prefs menu, we reusing now lads
I know there's commented out code but I'm going to remove that in another commit
* Removed some more dead code.
* Fixes jellyfish ears being all white
* Fixes plasmaman limbs not displaying because I accidentally hardcoded the limb_id for all augments to "robotic"
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Nightvision Rework (In the name of color) (#73094)
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.
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
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.
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
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>
filter transitions.
Found this when testing this pr, seemed silly.
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.
color with a sprite
This is to support the above
We relay this plane to lighting mask so openspace can like, have
lighting
vision goggles and such
Side affect of removing see_in_dark. This logic is a bit weak atm, needs
some work.
It's a dupe of the nightvision action button, and newly redundant since
I've removed all uses of it
trasnparent won't render
These sucked
Also transparent stuff should never render, if it does you'll get white
blobs which suck
</details>
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.
<!-- 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.
/🆑
* modular edits
* see_in_dark
* [MIRROR] Adds a unit test to detect double stacked lights [MDB IGNORE] (#19564)
* Adds a unit test to detect double stacked lights
* we really need to get that night vision pr done
* lints fixes
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Update augments_eyes.dm
* Update augments_eyes.dm
* eeee
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: SkyratBot <59378654+SkyratBot@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Fix lack of to_chat_immediate in client code that disconnects clients. (#73575)
these clients are about to be disconnected, they can't wait for the mc
to tick next
* Fix lack of to_chat_immediate in client code that disconnects clients.
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Adds a config option for warning clients about older builds (not just older versions) (#73549)
## About The Pull Request
MSO was being tsundere about this and it seemed useful, so here we go
## Changelog
🆑
config: Added a warning build config setting, you can now lightly
repremand but not block clients with older builds but fine major
versions
/🆑
* Adds a config option for warning clients about older builds (not just older versions)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Reworked PDA menu & NtOS themes (#73070)
## About The Pull Request
This is a port/rework of
https://github.com/yogstation13/Yogstation/pull/15735 - I changed a lot
of how it acted (some themes are locked behind maintenance apps).
The original author allowed this port to happen, and I really liked how
it looked there so I'd like to add it here.
### Applications
Removes the hardware configurator application, as all it did was show
you your space and battery now that all hardware was removed. These are
things your PC does by default, so it was just a waste of space.
Adds a Theme manager application instead, which allows you to change
your PDA's theme at will.
Adds a new Maintenance application that will give a new theme, however
it will also increase the size of the theme manager app itself as it's
bloatware.
### Menu
There's now a bar at the top of the menu showing 'special' tablet apps
which, for one reason or another, should stand out from the rest of the
apps. Currently this is PDA messenger and the Theme manager
Flashlight and Flashlight color is now only an icon, and is shown on the
same line as Updating you ID
https://cdn.discordapp.com/attachments/961874788706574386/1069621173693972551/2023-01-30_09-10-52.mov
### Themes
Adds a lot of themes to choose from, although SOME are hidden behind
Maintenance applications, which will give you a random theme. These are
bloatware however, so they come with some extra cost to the app's
required space storage.
Themes are now supported on ALL APPLICATIONS! If you have a computer
theme, you will have that theme in EVERY app you enter, rather than just
a select few.
ALSO also, emagging the tablet will automatically set & unlock the
Syndicate theme, which makes your PDA obvious but you can disguise it if
you wish through just re-painting it to something else.
https://cdn.discordapp.com/attachments/828923843829432340/1069565383155122266/2023-01-30_05-29-53.mov
### Preferences
This also adds a pref for theme, reworking the ringtone code to work
with it as well. I also removed 2 entirely unused PDA prefs just 'cause.
Screenshot not up-to-date, they now have proper names.
### Other stuff
Made defines for device_themes
Added support for special app-side checks to download files
Fixed programs downloading themselves TWICE because defines all had the
same definition
Removes the Chemistry computer disk as it was empty due to chemistry
app's removal
Removes the 'run_emag' proc, since apps can directly refer to the
computer to check for emag status instead.
Moved over and added better documentation on data computer files, and
moved the ordnance ones to the same file as the others.
## Why It's Good For The Game
It makes PDAs a lot more customizable while adding more features to
maintenance applications. I think the themes look cool and it fits with
PDAs being "personal" anyways.
I also explained most of my other arguments in the about section, such
as the hardware configuration application.
## Changelog
🆑 Chubbygummibear & JohnFulpWillard
add: A ton of new NtOS themes, which are accessible by the new Themify
application that comes with all PCs.
add: Emagging a PC now defaults it to the Syndicate option (and adds it
to go back to it if you wish)
add: There's a new maintenance app that gives you rarer themes
qol: The NtOS Main menu was moved around, added "header" applications
that are shown where the Flashlight is, such as your Theme manager and
PDA messenger.
code: Made defines for device_themes
code: Added support for special app-side checks to download files
code: Removes the 'run_emag' proc, since apps can directly refer to the
computer to check for emag status instead.
fix: Programs no longer download twice.
del: Removes the Chemistry computer disk as it was empty due to
chemistry app's removal
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Reworked PDA menu & NtOS themes
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* literally just hook asay into tgui say (#73212)
## About The Pull Request
pressing f3 now opens asay in tgui say
## Why It's Good For The Game
also fixes double-escaped special characters caused by #72407 and
finally gets rid of the gross regular tgui input popup
## Changelog
🆑
fix: asays are no longer double-escaped
admin: asay now uses tgui say
/🆑
---------
Co-authored-by: Scriptis <scriptis@ duck.com>
* literally just hook asay into tgui say
---------
Co-authored-by: scriptis <scriptif@gmail.com>
Co-authored-by: Scriptis <scriptis@ duck.com>
* Quirks are passed an incoming client when applied, allowing quirks to read preferences in `add` and `add_unique`. Renders visual quirks on the preference menu dummy.
* fixes quirk order to match upstream
* Modular quirk updates
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
Admin alert for communications console messages (#72412)
Adds an audio alert when a CentCom or Syndicate communications console
message is sent, for things such as ERT requests.
It is optional and can be toggled in the Game Preferences menu.
Also fixes an incorrect line in the prefs readme.md
Less missing CentCom messages because you're busy doing other things,
less complaining that you're ignoring them.
* Refactors bar drink icons into datum singletons / unit tests them (#71810)
- Refactors bar drink icons.
- Juice boxes no longer have a hard-coded list of a bunch of reagent
types in their update state, and use a system similar to bar drinks.
- Glass and shot glass icon information are no longer stored on the
drink. Instead, they are now stored in glass style datums. These datums
store name, description, icon, and icon state of a certain container +
reagent type.
- Glass styles are applied via the `takes_reagent_appearance` component.
Glasses, shot glasses, and juice boxes have this component.
- This comes with support for being able to have drink icons from
different files, rather than requiring the drinks DMI.
- The britmug is now a subtype of mug.
- 1 new icon: britmug filled.
- Various small code clean-up around drink reagents.
- Unit tests icon state setups for glass styles as well as all `/drink`
reagent container subtypes.
- Splits up the massive `drinks.dmi` into separate files.
*Disclaimer: Much of the drinking glass datums were written via script
automatically, so there may be errors present.*
- Much easier to add new drink styles, much more modular.
- It is no longer necessary for new drinks to be added to the massive
`drinks.dmi`. People working with drinks in the future can simply add
their glass style datum and point it to their file wherever it may be.
- Expandable system. Adding a new type of reagent container that works
similarly to bar drinks but for different types of icons is a breeze.
- Ensures going forward no bar drinks have invisible sprites.
🆑 Melbert
refactor: Refactored how bar drinks set their icons. Juice boxes now use
the same system.
/🆑
* Well that's all of them, unit tests prove me wrong
* now its a mapping pr lmao
* SHUT THE FUCK UP
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
Co-authored-by: Jolly-66 <70232195+Jolly-66@users.noreply.github.com>
* Pride pin quirk + pins can be infinitely reskinned (v2) (#72143)
## About The Pull Request
Neutral pride pin quirk added. Pride pins can be infinitely reskinned
now. Changes "sexuality" to "pride" in description of pin.
## Why It's Good For The Game
Pride pins are cute and having to buy them every round is a chore. Pride
pins are purely cosmetic and have no reason to be locked into only being
reskinned once.
## Changelog
🆑
add: Pride pin quirk! Start the shift off with a pride pin in-hand.
qol: Pride pins can be infinitely reskinned now.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Pride pin quirk + pins can be infinitely reskinned (v2)
Co-authored-by: iwishforducks <65363339+iwishforducks@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* What am I looking at?
* Okay, now limbs and switching to the three other types of synth!
* Hey, it compiles, but *definitely* doesn't work!
* Has a slight chance of working now!
* Actually compiles properly now!
* Nice one, dork
* Fuck limb code.
* And this is the story behind where the last 8 hours of my life went!
* My code will now throw the rattle if you do dumbdumb.
* I'M SORRY, MODULARITY
* Final code, maybe?
* Hmm, yes, today I will leave debug logs in my commits.
* Hmmm, maybe not enable that by default.
* Oh yea, nice one, dork.
* Oh yea, digitigrade exists. Also fixes all known runtimes. Also fixes me forgetting a couple of *very* important things.
* I feel special.
* Small bit of code cleanup!
* Android parts!
* Go away Blueshift compile error!
* E
* More code fixes!
* Synthliz fix
* Haha, shitcode go brrrr
* AAAAAAAAAAAAAAA
* Fix screenshot tests!
* Listen here you little shit-
* idontknowwhythisisbreakingantennasbutyoucankeepthenameiguess
* FUCK
* Turns out some antennas *do* use more than one colour, ugh.
* Nice one, genius.
* Address reviews, and also change IPC antennas to tri_bool instead of toggle- woops!
* Now that I know roughly how sprite accessories work, let's fix this at long last so I can finally get this merged.
* Oh yea, this!
* Oops, nice catch, unit tests!
* Very cool, PDA update
* Yeet!
* Apply suggestions!
* Oops!
* WHY DIDN'T YOU COMMIT
* I'm getting tired of fixing these conflicts.
* Ugh.
* Fix my shitcode, also make erp genitals check less intensive
* FUCK
* I am still suffering
* Fix
* e
* Fucking LEGS
* Fucking GREYSCALE
* REMOVE THIS BEFORE MERGE, DUMBASS
* Nevermind, this is unironically the best way to do it due to how our really weird prefscode works... pain.
* Stupid organic interface code edit
* Adds logic to provide leniency for drag clicks (#71082)
## About The Pull Request
Ok so like, in byond. if you click on something and release the click
without moving off its sprite, that counts as a "click"
If you however move your mouse off its sprite, or it does so on its own,
any further releases count as dragdrops.
We already have logic for catching drag -> mouse back over sprite. The
code I'm adding here basically is just a bit nicer about how exact you
need to be
I'm adding tweakable values for how much your mouse is allowed to move
(This isn't perfect currently, since if the target itself moves we don't
care, need to work on this) in a short time period. If you meet these
cases, we instead call it a click.
They're globs for now cause I don't have a good feel for em, will tweak
over time. I want to reduce dumb clickspam and click dragging moving
mobs/drifting items by accident.
Oh also fixed a bug in ai behaviors that came from not knowing what
get_active_hand did
Fixes a monkey behavior of using their held item
It turns out it never worked, and the only reason it didn't runtime was
because of an if() check that got passed the result of an invalid proc
call. this fixes that
## Why It's Good For The Game
Spam clicking and drag clicking are stupid. they should be less stupid
## Changelog
🆑
add: Adds a grace period for hit detection, between clicking ON someone,
and then moving your mouse off before releasing the click. It's short,
hopefully it helps with stupid
/🆑
* Adds logic to provide leniency for drag clicks
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Psykers (#71566)
## About The Pull Request
Finishes #66471
At burden level nine (or through a deadly genetic breakdown), you now
turn into a psyker.
This splits your skull in half and transforms it into a weird fleshy
mass. You become blind, but your skull is perfectly suited for sending
out psychic waves. You get potent psy abilities.
First one is brainwave echolocation, inspired by Gehennites (but not as
laggy).
Secondly, you get the ability of Psychic Walls, which act similarly to
wizard ones, but last shorter, and cause projectiles to ricochet off
them.
Thirdly, you get a projectile boost ability, this temporarily lets you
fire guns twice as fast and gives them homing to the target you clicked.
Lastly, you get the ability of psychic projection. This terrifies the
victim, fucking their screen up and causing them to rapidfire any gun
they have in their general direction (they'll probably miss you)
With most of the abilities being based around guns, a burden level nine
chaplain now gets a new rite, Transmogrify. This lets them turn their
null rod into a 5-shot 18 damage .77 revolver. The revolver possesses a
weaker version of antimagic (protects against mind and unholy spells,
but not wizard/cult ones). It is reloaded by a prayer action (can also
only be performed by a max burdened person).
General Video: https://streamable.com/w3kkrk
Psychic Projection Video: https://streamable.com/4ibu7o
## Why It's Good For The Game
Rewards the burdened chaplain with some pretty cool stuff for going
through hell like losing half his limbs, cause the current psychics dont
cut it as much as probably necessary, adds echolocation which can be
used for neat stuff in the future (bat organs for DNA infuser for
example).
## Changelog
🆑 Fikou, sprites from Halcyon, some old code from Basilman and
Armhulen.
refactor: Honorbound and Burdened mutations are brain traumas now.
add: Psykers. Become a psyker through the path of the burdened, or a
genetic breakdown.
add: Echolocation Component.
/🆑
Co-authored-by: tralezab <spamqetuo2@ gmail.com>
Co-authored-by: tralezab <40974010+tralezab@ users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
* Psykers
* commented out stuff is now in
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: tralezab <spamqetuo2@ gmail.com>
Co-authored-by: tralezab <40974010+tralezab@ users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
Co-authored-by: John Doe <gamingskeleton3@gmail.com>
* Adds a preference that disables intensive rendering on different multiz layers (#71218)
## About The Pull Request
It's kinda hacky, but it is nearly the same as just rendering one z
layer.
We allow people to ENTIRELY REMOVE most plane masters from their screen.
This has the side effect of disabling most visual effects (AO is a big
one) which saves a LOT of gpu.
We rely on planes being essentially layers to ensure things render in
the proper order. (outside of some hackyness required to make parallax
work)
I've kept parallax and lighting enabled, so visuals will still look
better then multiz pre plane cube.
It does also mean that things like FOV don't work, but honestly they
didn't work PRE plane cube, and FOV's implementation makes me mad so I
have a hard time caring.
Reduces gpu usage on my machine on tram from 47% to 32%, just above the
27% I get on meta.
I'm happy with this.
Oh also turns out the parallaxing had almost no cost. Need to remove it
as a side effect of what I'm doing but if I could keep it I would.
There's still room for in between performance options, like disabling
things like AO on lower z layers, but I didn't expect it to make a huge
impact, so I left things as is
Also fixes a bug with paper bins not respecting z layer. It came up in
testing and annoyed me
## Why It's Good For The Game
Ensures we can make multiz maps without running into client performance
issues, allows users to customize performance and visual quality.
## Changelog
🆑
add: Adds a new rendering option to the gameplay preferences. You can
now limit the rendering intensity of multiz levels. This will make
things look a bit worse, but run a LOT better. Try it out if your
machine chokes on icebox or somethin.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Adds a preference that disables intensive rendering on different multiz layers
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* JSON Savefiles | Player Saves use JSON
* few fixups
* yeah this will need a migration in the future to use a different tree for skyrat stuff
* this can be null
* forgot to sanitize these ones
* TM st
* get it working
* Update code/modules/client/preferences_savefile.dm
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Particle editor (#71110)
## About The Pull Request
Demo: https://streamable.com/wnj3mf
Features:
- Full support for most gradients/vectors/numbers/generators/transforms
( I might have forgotten some of the more esoteric ones)
- A "tutorial" section that explains the different rand/generation types
and how physics works with pictures
- Button for viewing what each var does
- Selecting a particle type to set immediately
- The generator types use defines now
Not included:
Color matrix support for color generators (I'm sorry but hell no)
Special thanks to @ jlsnow301 for explaining js things to me
## Why It's Good For The Game
Making cool stuf
## Changelog
🆑
refactor: Added a particle editor to VV dropdown which can be used by
coders and admins to edit particle values on the fly easily.
/🆑
Co-authored-by: TiviPlus <572233640+TiviPlus@ users.noreply.com>
* Particle editor
Co-authored-by: TiviPlus <57223640+TiviPlus@users.noreply.github.com>
Co-authored-by: TiviPlus <572233640+TiviPlus@ users.noreply.com>
Crop moth wings to 32x32, saving about 0.18s in init time (yes really) (#71243)
Crops all moth wings to 32x32 and saves the very expensive Crop cost in the preference icon generation for moth wings.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
