## About The Pull Request
So, I've been recently told that Skyrat uses the greyscale modify menu
for loadouts, and the new ui state kinda borked it. I honestly haven't
taken the possibility that the target could be anything but a subtype of
`/atom` (and still work) into account because much of the code assumes
the target is an atom. It's kinda crappy. Also I hadn't noticed we've an
`unlocked` variable, which makes `vv_mode` var superflous, so i'm going
to remove the latter.
* [NO GBP] Actually fixing the greyscale_modify_menu. (#77208)
## About The Pull Request
EDIT: So, I've to admit and bow my head: #77165 fucked up because I
hadn't properly tested the code. However, this time around, I can assure
you it's been tested.
## Why It's Good For The Game
Fixing my mistakes. This will fix#77246
## Changelog
N/A.
* [NO GBP] Actually fixing the greyscale_modify_menu.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
EDIT: So, I've to admit and bow my head: #77165 fucked up because I
hadn't properly tested the code. However, this time around, I can assure
you it's been tested.
## Why It's Good For The Game
Fixing my mistakes. This will fix#77246
## Changelog
N/A.
* Fixing the greyscale modify menu not sanitizing inputs. (#77165)
## About The Pull Request
exactly what it reads on the tin. Also the ui is now anchored to the
target and uses their state unless a specific one is set, so that it'll
correctly close or be unusable if the mob user is incapacitated or too
far.
## Why It's Good For The Game
this will fix#70444.
## Changelog
🆑
fix: Fixing some jank with the a greyscale modify menu, like inputs not
being sanitized.
/🆑
* Fixing the greyscale modify menu not sanitizing inputs.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
exactly what it reads on the tin. Also the ui is now anchored to the
target and uses their state unless a specific one is set, so that it'll
correctly close or be unusable if the mob user is incapacitated or too
far.
## Why It's Good For The Game
this will fix#70444.
## Changelog
🆑
fix: Fixing some jank with the a greyscale modify menu, like inputs not
being sanitized.
/🆑
* Refactors bardrone area based godmode into an element (#76619)
Let's this be used for more than just bardrones and for more than just
the exit shuttle in the future
* Refactors bardrone area based godmode into an element
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Always contracts lists when VVing GLOB (#76091)
## About The Pull Request
This takes render times from like 20 seconds to maybe 2 Most of the time
appears to be clientside rn, so the best we could do further would be
reducing the amount of shit that actually needs to render
So like, removing the E C M buttons (or at least adding a toggle to
render them), that sort of thing
## Why It's Good For The Game
A glob vv you can actually use
## Changelog
🆑
admin: VV for global vars will now load MUCH faster, in exchange lists
are now perma contracted in that particular pane
/🆑
* Always contracts lists when VVing GLOB
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
This takes render times from like 20 seconds to maybe 2 Most of the time
appears to be clientside rn, so the best we could do further would be
reducing the amount of shit that actually needs to render
So like, removing the E C M buttons (or at least adding a toggle to
render them), that sort of thing
## Why It's Good For The Game
A glob vv you can actually use
## Changelog
🆑
admin: VV for global vars will now load MUCH faster, in exchange lists
are now perma contracted in that particular pane
/🆑
* Corrects record_feedback()'s copy/paste comment (#74962)
## About The Pull Request
Corrects `record_feedback()`'s copy/paste comment.
## Pointless history
Originally being added in e2a8a5e, it kept its name and args for quite a
few years, that was until #32188 which had it renamed to
`record_feedback` and its args pretty much doubled. In between these
times the known copy/paste comment was already around, but that wasn't
updated, until now apparently.
* Corrects record_feedback()'s copy/paste comment
---------
Co-authored-by: Zandario <zandarioh@gmail.com>
## About The Pull Request
Corrects `record_feedback()`'s copy/paste comment.
## Pointless history
Originally being added in e2a8a5e, it kept its name and args for quite a
few years, that was until #32188 which had it renamed to
`record_feedback` and its args pretty much doubled. In between these
times the known copy/paste comment was already around, but that wasn't
updated, until now apparently.
## 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>
* Allows populating new vv'd lists (#74064)
You get an alert, and can continue to enter variables until you hit
cancel. Not sure if this is good ux or not, yell at me if not
## Why It's Good For The Game
Fikou asked me for it and that guy's pretty cool. Also it's annoying to
not be able to feed lists into procs
## Changelog
🆑
admin: You can now optionally populate new lists created via vv. hit
cancel to stop filling them up
/🆑
* Allows populating new vv'd lists
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
You get an alert, and can continue to enter variables until you hit
cancel. Not sure if this is good ux or not, yell at me if not
## Why It's Good For The Game
Fikou asked me for it and that guy's pretty cool. Also it's annoying to
not be able to feed lists into procs
## Changelog
🆑
admin: You can now optionally populate new lists created via vv. hit
cancel to stop filling them up
/🆑
## About The Pull Request
Fixes#73276
This is a followup PR from my series of biotype updates. Changed oxyloss
to default to ignoring biotype requirements. Fixes a bug in lung code
that was preventing mobs from suffocating under certain conditions.
~~Now biotype requirements for oxyloss are respected only when `forced`
is set to `FALSE`, which I have done for all applicable reagents. This
is more of a temporary fix for until the damage system gets a refactor
to better accommodate biotypes. @Time-Green and @LemonInTheDark would
know what I mean, we were just talking about this. There is a problem
with `MOB_ORGANIC` being the deafult and this is the ugly workaround.~~
Edit: I felt that oxyloss (which should be renamed to something else at
this point) should have its own flag to check what type of respiration
the mob's lungs can do. Because you can have organic mobs that breathe
different gases. It gets messy when you try to use the same flag for
everything.
So I refactored oxyloss to use a new lung flag, `respiration_type`,
which is automatically set based on the `safe_min_oxygen`,
`safe_min_plasma` etc variables within the lung code. This will allow
for individual lung types to dynamically determine whether they can take
oxyloss from reagents, or any other sources that pass the
`respiration_type` in the `adjustOxyLoss` proc.
## Why It's Good For The Game
Plasmamen can't breathe without plasma anymore. Humans can't breathe
without oxygen anymore. Etc.
Adds better handling for dealing with the 'oxyloss' damage type,
allowing it to be applied based on the type of gas being breathed by the
specific lung. The argumentless default is to apply it regardless of
respiration_type e.g. it behaves exactly as it did before.
## Changelog
🆑
fix: fixes oxyloss not being applied when there is a partial pressure of
0 (no more being able to breathe in space)
code: fixes any lingering damage-application issues related to non
MOB_ORGANIC biotypes
refactor: refactored lungs to have a respiration_type flag which is then
used by adjustOxyloss/setOxyloss to determine whether to take 'oxygen'
damage.
/🆑
## 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>
* Rescale SM health from 900 to 100, UI improvements, visual changes. (#72252)
Rescaling because i saw someone think that the number on the supermatter
UI are actually the percent damage over time, which is wrong.
Added delta symbol to damage and energy since they actually denote
change, not the actual value.
Chose the numbers that look good instead of doing a 1:1 rescale of the
old one (i.e. im dividing or multiplying things by 10 instead of 9). In
practice this means I'm lowering the damage cap but increasing damage
over the board for atmos (since it's mostly divisors). Lowered the
damage overall for external stuffs.
A bit of modification on the filter helpers to suit my needs. Added
documentation because I'm awesome.
* Rescale SM health from 900 to 100, UI improvements, visual changes.
Co-authored-by: vincentiusvin <54709710+vincentiusvin@users.noreply.github.com>
Rescaling because i saw someone think that the number on the supermatter
UI are actually the percent damage over time, which is wrong.
Added delta symbol to damage and energy since they actually denote
change, not the actual value.
Chose the numbers that look good instead of doing a 1:1 rescale of the
old one (i.e. im dividing or multiplying things by 10 instead of 9). In
practice this means I'm lowering the damage cap but increasing damage
over the board for atmos (since it's mostly divisors). Lowered the
damage overall for external stuffs.
A bit of modification on the filter helpers to suit my needs. Added
documentation because I'm awesome.
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.
* 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>
## 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>
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>
* Moves spawners and decals to a different init/delete scheme
Rather then fully creating and then immediately deleting these things,
we instead do the bare minimum.
This is faster, if in theory more fragile. We should be safe since any
errors should be caught in compile since this is very close to a
"static" action. It does mean these atoms cannot use signals, etc.
* Potentially saves init time, mostly cleans up a silly pattern
We use sleeps and INVOKE_ASYNC to ensure that handing back turfs doesn't
block a space reservation, but this by nature consumes up to the
threshold and a bit more of whatever working block we were in.
This is silly. Should just be a subsystem, so I made it one, with
support for awaiting its finish if you want to
* Optimizes garbage/proc/Queue slightly
Queue takes about 1.6 seconds to process 26k items right now.
The MASSIVE majority of this time is spent on using \ref
This is because \ref returns a string, and that string requires being
inserted into the global cache of strings we store
What I'm doing is caching the result of ANY \ref on the datum it's
applied to. This ensures previous uses will never decay from the string
tree.
This saves about 0.2 seconds of init
About The Pull Request
I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.)
This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering.
I'll do my best to keep this compact, but there's only so much I can do. Sorry brother.
Core idea
OK: first thing.
vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc.
This is bad. But how to do better?
It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly.
We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed.
But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect.
Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on).
That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly.
Everything else is just gravy.
About the Plane Cube
Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane.
We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live.
As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well.
Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you.
About Plane Master Groups
BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc)
Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc.
So we need to maintain a mirror of each plane for every map we have open.
This was quite messy, so I've refactored it (and maps too) to be a bit more modular.
Rather then storing a list of plane masters, we store a list of plane master group datums.
Each datum is in charge of the plane masters for its particular map, both creating them, and managing them.
Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to.
Much better then the hardcoded pattern we used to use. So much duplicated code man.
Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers.
image
In addition, I've added a debug ui for plane masters.
It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays.
It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live.
In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc.
It also comes with an info dump about the ui, and plane masters/relays in general.
Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible.
See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md.
"Landing" planes
Ok so I've explained the backend, but how do we actually land planes properly?
Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use.
This is just a lot of gruntwork, but it's occasionally more complex.
Sometimes we need to cache a list of z layer -> effect, and then use that.
Also a LOT of updating on z move. So much z move shit.
Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags.
This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday
I also need to update mob overlays on move.
I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order.
The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet.
It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point.
Behavior changes
We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it.
So instead we display the other side as a ui element. It's worse, but not that bad.
Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior.
The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane.
I don't really care, but it should be fixable, I think, given elbow grease.
Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think.
Why It's Good For The Game
<visual candy>
Fixes#65800Fixes#68461
Changelog
cl
refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it
admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb
/cl
* Fixes weakref resolving in View Variables not working (#69375)
m
* Fixes weakref resolving in View Variables not working
Co-authored-by: distributivgesetz <distributivgesetz93@gmail.com>
* adds location atom to deletion message (#69372)
Helps with debugging to know that a flash was deleted from engi borg #424 at robotics than just a flash was deleted at X,Y,Z.
* adds location atom to deletion message
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Adds linking tickets in asay, referencing mob datums in asay, improves asay ref code (#65634)
About The Pull Request
Continuing on the work started in #65154 and 61712, this PR expands what asay linking can be used for and improves the code for it. You can now link tickets in asay by saying #[ticket ID] like #1. This shows the ticket's status and who filed the ahelp. Might remove the ticket filer if it's not really useful.
This also fixes an oversight of mine with datum linking, with how mobs and certain other datums (armor datums, landmarks) don't follow the memory address format for their tag values. Datum linking now uses a @ [tag] format, so you can link to a mob by saying @ mob_702 and such.
dreamseeker_2022-03-22_21-51-41.png
Why It's Good For The Game
More robust admin tools
Changelog
cl Ryll/Shaps
admin: You can now link tickets in asay with #[ticket ID], like #1 and #5.
admin: asay datum linking now functions by saying '@ [datum's tag value]`, whether it's a normal datum (@ 0x2001169) or a mob (@ mob_702) or whatever else.
Discord_2022-03-16_23-38-09.png
(old pic)
* Adds linking tickets in asay, referencing mob datums in asay, improves asay ref code
Co-authored-by: Ryll Ryll <3589655+Ryll-Ryll@users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
About The Pull Request
Continuing on the work started in #65154 and 61712, this PR expands what asay linking can be used for and improves the code for it. You can now link tickets in asay by saying #[ticket ID] like #1. This shows the ticket's status and who filed the ahelp. Might remove the ticket filer if it's not really useful.
This also fixes an oversight of mine with datum linking, with how mobs and certain other datums (armor datums, landmarks) don't follow the memory address format for their tag values. Datum linking now uses a @[tag] format, so you can link to a mob by saying @mob_702 and such.
dreamseeker_2022-03-22_21-51-41.png
Why It's Good For The Game
More robust admin tools
Changelog
cl Ryll/Shaps
admin: You can now link tickets in asay with #[ticket ID], like #1 and #5.
admin: asay datum linking now functions by saying '@[datum's tag value]`, whether it's a normal datum (@0x2001169) or a mob (@mob_702) or whatever else.
Discord_2022-03-16_23-38-09.png
(old pic)
