## About The Pull Request
This PR solves the problem with entering a server with a different (from
English) layout and not being able to use chat binds.
so far, alas, you need to re-login with the English layout.
https://i.imgur.com/WjixRVv.mp4
## Why It's Good For The Game
Resolves an issue for servers based on this build.
## Changelog
🆑 Vishenka0704
fix: fixed different from english keyboard layout to use tgui chat
/🆑
## 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.
/🆑
## About The Pull Request
EMPs on robotic limbs will now disable them for 10-20 seconds rather
than causing a 10-20 second full stun on the user. Additionally, they
will damage the limb for a little brute and some burn.
Arm EMPs don't do anything special as the limb being disabled already
drops items.
Leg EMPs cause a 10-20 second knockdown, only really applicable if
there's only one robotic leg as two disabled legs KD you anyways.
Chest EMPs cause a 3-6 second standing-up paralyze, visible to the
player by a quite noticeable shaking of their body.
Head EMPs break the optical transponder circuits for 7.5-15 seconds,
effectively giving the user nightmare goggles vision with green instead
of red as the only remaining color.
Tacit approval for the PR at least existing.
## Why It's Good For The Game
Robotic limbs are not so strong that a glancing EMP that may not even
have been directed at you should stun you for ten, TEN seconds, or
worse, twenty. This is basically legacy stunning from the days of
super-stuns on soap, stunbatons, etc. The code for it was last touched
six years ago.
**_The stats as shown above are not even close to final. I really don't
know or care what the right stats should be in the end. and I'm fine
with making them a 10-20 second timer again. I just put some
reasonable-seeming numbers in as a placeholder. EMPs could also still
cause a short stun if that is deemed necessary. Hell, that could be the
chest effect!_**
## Changelog
🆑
balance: EMPs on robotic limbs will now disable them for 10-20 seconds
rather than causing a 10-20 second full stun on the user. Additionally,
they will damage the limb for a little brute and some burn.
EMPs on robotic limbs will now disable them for 10-20 seconds rather
than causing a 10-20 second full stun on the user. Additionally, they
will damage the limb for a little brute and some burn.
balance: Arm EMPs don't do anything special as the limb being disabled
already drops items.
balance: Leg EMPs cause a 10-20 second knockdown, only really applicable
if there's only one robotic leg as two disabled legs KD you anyways.
balance: Chest EMPs cause a 3-6 second standing-up paralyze, visible to
the player by a quite noticeable shaking of their body.
balance: Head EMPs break the optical transponder circuits for 7.5-15
seconds, effectively giving the user nightmare goggles vision with green
instead of red as the only remaining color.
/🆑
(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
## About The Pull Request
Hi.
This pr contains work that is a collaborative effort between myself,
Halcyon, Mqiib and `2cents#8442` for the original leg-work (Ha Ha, Get
it?), ultimately finished by myself.
Here's a preview!
And here's some side previews!
## Why It's Good For The Game
Lizard sprites have not been updated since their inception in 2016. They
will now be updated and be much more consistent with everything else.
Signed off by @optimumtact
## Changelog
🆑
imageadd: Lizards have been resprited, as well as Digitigrade sprites.
Please remember to update your colors to account for this.
/🆑
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.)
## 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.
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.
## 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
/🆑
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## 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.
/🆑
## About The Pull Request
Refactors regenerate organs to be slightly more intelligent in handling
organ changes and replacements.
Noteably:
- We don't remove organs that were modified by the owner; such as
changing out your heart for a cybernetic
- We early break out of the for loop if they aren't supposed to have an
organ there and remove it
- We check for the organ already being correct, and just healing it and
continuing if it is
Also changes the names of some of the organ helpers into snake_case
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
Firstly, this var was on `/mob`, even though only `/mob/living` and
`/mob/dead` could have ever used it, so who knows how much needless
memory it was consuming on stuff such as `oranges_ear` that would never
ever ever use something like this.
Edit: okay instead of memory it just polluted variable edit windows for
all /mob when it didn't need to. I like having a slim VV window
Secondly, it's a technical improvement over the previous system as we
are able to "track" where a suicide originates from, and how we can
track that from mob-to-mob-to-mob. Previously, the boolean `suiciding`
would only inform us if they had ever been connected to a mob that had
ever committed suicide, but now we are able to precisely determine which
mob gave them the trait that they must now apparently bear until the
round restarts.
## Why It's Good For The Game
Less memory usage, more indepth ability to track suicides in case you
really need that dexterity. Currently no implemented code could benefit
from using it, but it would be pretty neat if someone could figure out a
way to have someone be guilt-tripped whenever they look into a mirror
and seeing the reflection of their past life? This PR won't actually
help you code that and it'll probably require a bit more work, but it's
a possibility of some cool interactions you can do when you have this
information available to you.
## Changelog
🆑
refactor: Some aspects of how we track suicides from your living mob to
your observer have changed- please do let us know if anything has broken
via a GitHub Issue Report.
/🆑
There's probably some technical improvements that can be made in some
parts of the code I reworked to accommodate this change, do let me know
if you spot any easy ones (or fuckups). a lot of excess comes from the
fact that any step in the TRAIT framework trusts that you are passing in
a valid datum (or subtype) so that's a thing
## 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
/🆑
## 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
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.
/🆑
## 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>
Updating or resetting your preferences doesn't actually currently update
the movement/tgui say keybindings. This fixes that, although there's
still a weird heisenbug with NULL keybindings that we haven't been able
to reproduce at all from #73247
## About The Pull Request
Damn that's a long title.
Admin Verbs can be used in the verb bar with hyphens instead of spaces
again.
## Why It's Good For The Game
Admin muscle memory
## Changelog
## About The Pull Request
Basically all of the heavy lifting was done in #72919, but we do a few
key things here that I wasn't able to do then because it was just
fucking massive.
Player Facing Changes:
* hear_blind arg is now a default state and must be specifically
overridden. Pretty much every mob that wasn't a pAI or alien was lacking
this, so let's toss it in as a default now. Let me know if the generic
message I put in for /mob/living sucks and we can go from there.
Code Side Changes:
* suicide.dm now only contains code pertinent to the suicide verb, and
all subtype proc-overrides have been moved to an appropriate file
pertinent to that subtype.
* suicide.dm has also been organized a bit more to aid the previous
change.
* There is only one suicide verb now, implemented on /mob/living. All
the verb does is invoke the handle_suicide() proc, which does all of the
lifting.
* Leaning into *mumble mumble* object-oriented philosophy, the message
we send to the world on suicide is handled on subtype procs, rather than
be in the huge fuck-off message tree I implemented in the earlier PR. It
definitely makes the visible_message() proc not hard to read IMO. This
also means that we can take up a less footprint when we re-use certain
suicide messages (i.e. Silicon), which is nifty too.
i'm probably forgetting something but that's all of the big ones
## Why It's Good For The Game
There is now a very, very common framework for how suicide works across
all living mobs, and it's much easier to override how suicide is
handled. Certain subtypes do their own bullshit thing, but it's quite
easy to account for this on that case-by-case basis. The overall code
takes up a much less footprint that just makes it look nicer.
## Changelog
🆑
qol: Some mob suicides now have a message that shows to blind people or
people that didn't actually witness the suicide, pretty cool.
/🆑
## About The Pull Request
On the tin. There was a lot of needless copy-paste and a lot of
single-letter vars and weird indentation and... well just all of it was
at least eight years old. So, I decided to "abstract" as much as I could
of it out instead of piling onto the big copypaste clusterfuck for
implementing basic mob suicide.
## Why It's Good For The Game
Fixes#72903
Having more procs that can be easily repeatably called to the same
results is much better than having to transplant the same exact three
lines everywhere. It's also a good first step to further in-depth
behavior by allowing sub-type overrides of certain procs (which is quite
nice). Just feels more extensible overall for the next guy who wants to
add funny suicide behavior whenever they might come around.
There's probably a few better ways to do what I did, but I wrote code
comments explaining why I did what I did. I think there's a few ways to
make it more agnostic, but I think that'll be another can of worms that
will bloat out an already quite large PR. Let's just get the framework
set.
(this refactor should also make it quite easy to unit test suicide
actions 👀)
## Changelog
🆑
fix: All Mobs (including Basic mobs) are now able to suicide. (warning:
some exclusions remain)
/🆑
## About The Pull Request
When loading values from the savefile for keybinds, it overrode the
default values with null if not found.
## Why It's Good For The Game
Resolves https://github.com/tgstation/tgstation/issues/72804
## Changelog
## About The Pull Request
Part of a prior PR that was closed (#72562). This version does not add
the check in CI.
## Why It's Good For The Game
The work is already done, so I figured why not.
## Changelog
N/A Nothing player facing
Co-authored-by: Jeremiah Snow <jlsnow301@pm.me>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
### New Memories
- Added a memory for catching a fish
- Added a memory of who turned you into a revolutionary, this might be
very cool later on for mindreading purposes
- Added a memory for infusing with something
### Prisoner Tats
- Prisoner backgrounds now come with a certain amount of tattoos
depending on what you did. Negligence? Zero tats.
<details>
<summary>Mass Murderer?</summary>
BECOME
https://youtu.be/7xUtZzLBV5c?t=73
</details>
- Because I wanted someone covered head to toe in tats, there is now a
"Mass Murderer" background that comes with 6 tattoos, one for each limb.
## Why It's Good For The Game
## Changelog
🆑
add: Some prisoner backgrounds have more or less tattoos.
add: More Memories to collect involving fishing and getting converted
/🆑
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.
## About The Pull Request
Makes it to where if you connect as a guest preferences don't error out
the ass
Resolves https://github.com/tgstation/tgstation/issues/72268
## Why It's Good For The Game
Easier local debugging, and for servers that let guests join
## Changelog
🆑
server: Preferences now support guests
/🆑
## About The Pull Request
Closes#72141
Roundstart humans weren't in control of their mob by the time
`AssignQuirks` was called.
The call chain for roundstart goes `create_characters` ->
`equip_characters` -> `AssignQuirks` -> `transfer_characters`.
For latejoin, `create_character` -> `transfer_character` ->
`AssignQuirks`.
I could simply move around the call chain, but that feels much more
fragile and more liable to cause other issues to me. So instead, I
simply allowed add quirk to be passed a client, so that a client's
quirks can be applied to a mob they are not currently inhabiting.
In doing this, it became possible to show visual quirks on the prefs
dummy, like nearsighted glasses and heterochromia. So I put in a little
work to accomplish that as well.
Along side, some refactoring and documentation for quirk datums.
## Why It's Good For The Game
People get what they expect on roundstart.
## Changelog
🆑 Melbert
qol: The preview dummy in the preferences menu now shows some visual
quirks, like Heterochromia or nearsighted.
fix: Fixed some quirks which read a preference roundstart not applying
the preference.
refactor: Refactored some bits of quirk datums and the quirk application
process.
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## 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>
## About The Pull Request
- 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.*
## Why It's Good For The Game
- 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.
## Changelog
🆑 Melbert
refactor: Refactored how bar drinks set their icons. Juice boxes now use
the same system.
/🆑
## 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
/🆑
## About The Pull Request
### Fixes
- Right now, the DNA infuser does not gracefully swap brains. With this,
it will!
- Fixes locked variable not working. **THIS DOES REMOVE BURNT WINGS, AS
ORIGINALLY INTENDED**
- Infuser now respects moving inside of it as exiting, it was never
intended to get you stuck inside
- Carp lungs work as intended
- Carp jaws work as intended (200 hours of testing btw), via a new
helper for changing no_equip_flags
- Properly undefs all defines in carp file
- fixes some missing args for the brain
- infuser logic checks for edible components, not food subtype for GORE
check
### QoL
- Added a new sound to the DNA infuser
- Dragging mobs into the dna infuser will place them as the subject if
they're carbon
### UI
New UI as well, with some instructions
## Why It's Good For The Game
Bugfix good!
## Changelog
🆑
fix: fixed getting kicked out of your body sometimes when pursuing the
carp mutant
fix: and carp lungs working incorrectly
qol: better ui explanation on the infuser book
qol: can drag people into the infuser chamber
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## 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>
## 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>
## About The Pull Request
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.
## Why It's Good For The Game
`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.
## Changelog
🆑
refactor: Removed mutant_bodyparts.dmi and distributed its sprites in a
more sensible and granular manner.
/🆑
So i left over some basic `/whatever/proc/format` uses in the original
PR this fixes it.
Notable exceptions to the rule:
- Paths in add_verb/remove_verb, we need full path instead of a name
there to access verb metadata so we can't use proc ref macros there.
- regex.Replace, found out that it does not accept call by name. Instead
i added new REGEX_REPLACE_HANDLER so we can at least try to mark these.
There's still leftover global procs that do not use GLOBAL_PROC_REF but
they functionally equivalent so that's for later.
I don't see any reasonable way to grep for this. But if you got any
ideas please share.
## 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>
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
TODO:
- [x] DOCUMENT SHIT
- [x] UPDATE DOCUMENTATION
## About The Pull Request
Adds a new datum, which is intended to be a replacement for the stock
savefile type, json_savefile
As you can imagine, this is essentially just a wrapper around a json
file for reading/writing/manipulation that is intended to be a dropin
replacement for savefiles
It also have the ability to import stock savefiles and parse them into a
json tree
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Permission obtained from MSO and Mothblocks.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## 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. -->
Not player facing, tested locally exhaustively to ensure it doesnt break
shit
🆑
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: san7890 <the@san7890.com>
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
