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.
## About The Pull Request
This does nothing currently, but will allow me to test for layering
issues on LIVE, rather then in just wallening.
Oh also I'm packaging in a fix to one of my macros that I wrote wrong,
as a joke
[removes SEE_BLACKNESS usage, because we actually cannot use it
effectively](c9a19dd7cc)
[c9a19dd](c9a19dd7cc)
Sidemap removes the ability to control it on a plane, so it basically
just means there's an uncontrollable black slate even if you have other
toggles set.
This just like, removes that, since it's silly
[fixes weird layering on solars and ai portraits. Pixel y was casuing
things to render below who
shouldn't](3885b9d9ed)
[3885b9d](3885b9d9ed)
[Fixes flicker
issues](2defc0ad20)
[2defc0a](2defc0ad20)
Offsetting the vis_contents'd objects down physically, and then up
visually resolves the confliciting that was going on between the text
and its display.
This resolves the existing reported flickering issues
[fixes plated food not appearing in
world](28a34c64f8)
[28a34c6](28a34c64f8)
pixel_y'd vis_contents strikes again. It's a tad hacky but we'll just
use pixel_z for this
[Adds wall and upper wall plane
masters](89fe2b4eb4)
[89fe2b4](89fe2b4eb4)
We use these + the floor and space planes to build a mask of all the
visible turfs.
Then we take that, stick it in a plane master, and mask the emissive
plane with it.
This solves the lighting fulldark screen object getting cut by emissives
Shifts some planes around to match this new layering. Also ensures we
only shift fullscreen objects if they don't object to it.
[compresses plane master
controllers](bd64cc196a)
[bd64cc1](bd64cc196a)
we don't use them for much rn, but we might in future so I'm keeping it
as a convienince thing
🆑
refactor: The logic of how we well, render things has changed. Make an
issue report if anything looks funky, particularly layers. PLEASE USE
YOUR EYES
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
I previously tested that footsteps worked when hearing them from a lower Z-level but forgot to test if you can see them while on a lower z-level.
It didn't occur to me that offsetted planecube planes wouldn't work with being over the fullscreen blindness mask past the top level but that makes sense in retrospect.
So the blindness effects (via play_fov_effect()) are now on the fullscreen plane. Partially reverted doing this with manually talking bubbles as well so they look normal again, and then added a FOV effect as well for chat bubbles.
NOTE: Runetext is in general also only above the blind mask on the highest station level and below on others for the same planecube issue but that's a whole other can of worms.
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
Adds a seethrough component!
Standing behind a big object with this component will make the object transparent:
https://youtu.be/nnyWMJakVtE
And no one else can see it:
And yes you can click through it thanks to the power of plane masters!
Standing behind a tree is a pretty big meme and people will have to either shift right click or bump into you to ever find you. This makes it so much better to implement big objects, since they no longer obscure the tiles behind them
It's also useful for existing big objects, like billboards and the likes
🆑
qol: You can now see through big trees when you stand behind them!
refactor: Adds a seethrough component to make it easier to add big stationairy objects without reducing visibility
/🆑
Info
This is done by sending an override overlay to the user that obscures the normal object and plays an animation.
It registers an ENTERED signal on specific turfs. Those tiles in which it hides stuff is defined as a list of list coordinates, for which I made a global list with some defines. It's really crappy and I'd appreciate some feedback on that
Adds the area plane to the game and colorblind plane master controllers
Mostly because it's actually used now, for weather, and should be
blurred/recolored
Sets the thermomachine on the game plane
I want it to have a dropshadow, and right now it's on the floor plane,
just from atmospherics, which I think is stupid
* Initial pipecrawl work
Ok so pipecrawl images were updating EVERY TIME YOU MOVED
This was not good mojo
What I've done here is twofold
First, I ensured pipecrawl updates only when the net changes. This
breaks the current implementation, but I intend on fixing that
Second, I moved our method of getting pipes to the spatial grid
This isn't that great at the moment, but I intend on adding support for
tracking entered/exited cells, which should make this much better
* Much faster pipecrawling processing, niceties
Adds a concept called a cell tracker datum.
It manages a list of cells a passed in bound is "inside", and when
queried will return a list of new cells, and old cells.
Because we only really care about maintaining an absolute window of
"CELLS WE ARE IN" and less about always removing cells we're not in, we
can manage a second window to prevent moving up and down on a cell line
causing a ton of updates.
Uses this concept to optimize pipecrawling significantly, from 3ms per
call before to roughly 0.03ms per call.
Also moves pipecrawl images to their own plane, so they don't overlap ui
elements
* Pipecrawling effects niceties, direction help
You can now move in more then one direction when pipecrawling
This works as expected, if you hold up and left, move up for a while,
and come to a fork, you'll go left
Added some effects to pipecrawling. It'll darken the lighting plane
slightly, so you get a nice effect instead of just fullbright.
Also added a color matrix and drop shadow to the pipe images, this way
they stand out a bit more.
You now glide between pipe moves, rather then moving instantly. This
doesn't effect your actual move rate, but it no longer feels jittery
with say, 60fps
* Bounds
* Fixes runtimes, cache something somethign sonic speed
* Reworks how being interested in the spatial grid is tracked
Rather then checking multiple variables on the atom to consider, we
instead check for the existence of a string key.
This key is used by a list on the spatial grid subsystem to retrive a
cached list of all of the atoms "types"
Doing this requires doing a bit of extra work in
important_recursive_contents code, but it allows us to separate being a
part of the spatial grid from using important recursive contents, which
is very nice.
As a consequence, I've had to unroll some lazylist macros in important
recursive contents logic. It's not ""that"" bad but it's not great
either.
Oh and this adds a slight cost to enter/exit cell, but it's minimal.
Basically, rather then checking for different features of a grid member,
we just iterate the list their string key points to. Very handy
So there's an added cost of a list copy and all, but we save the
headache of more types technically increasing the cost of
addition/removal.
I also made adding/removing from the grid into one "pulbic" proc rather then two
different ones for each operation, because it was starting to get silly
* waaa waa it doesn't compile
* chord -> coord
* Ensures important_recursive_contents is actually emptied on removal
* Removes soul
* Kyler's review
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Kyler's review 2
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Kyler's review 3
Moves some procs around, improves some documentation, catches a few
small issues
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Adds a colorblind accessability testing tool
I keep finding myself worrying about if things I create will be parsable
for colorblind people. So I've made a debug tool for approximating
different extreme forms of colorblindness.
It's very very much a hack. We can't do the proper correction required
to actually deal directly with long medium and short wavelengths of
light, so we need to rely on approximations. Part of that means say,
bright things being brighter then they ought to be. S not how people
actually experience things, but it's not something we can do anything
about in byond.
Anyway uh, it works by taking color matrixes, and using the plane master
grouping system floyd added to apply them to most all parts of the game
you would want to color correct.
There's some slight fragility here, but I couldn't think of a better way
of handling it.
We also need to deal with planes that have BLEND_MULTIPLY as their
blendmode, since that fucks up the filter. I've come up with a hack for
it, since I wanted to avoid breaking anything.
Oh and since I want it to apply to huds too I added plane masters to
represent them. I think that's about it.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
What does the PR do
This reworks how our rendering is handled, specifically moves away from plane masters as the end solution:
Instead we replace plane masters rendering directly to client with planes that render multiple planes onto them as objects in order to be able to affect multiple planes while treating them as a single object. This is done by relaying the plane using a "render relay" onto a "render plate" which acts as a plane master of plane masters of sorts, and since planes are rendered onto it as single objects any filters we apply to them will render over the planes, treating them as a single unit
image
Also cleaned up unused plane masters and render targets to reduce clutter, as well as removing a useless filter that was resulting from confusion due to said clutter.
Clientside performance testing showed no significant change, no effect on serverside performance as this is clientside.
Also added the blackness plane master so it can be relayed, side effect is that it can now be used to adjust how blackness is rendered
P2 should introduce rendering one plane to multiple render_plates, but i want to get this done before I finish that, though testing shows its feasible
Why It's Good For The Game
Allows more advanced effects.
As an example i made a grav anomaly effect in like 30 seconds for this video i will improve it once im awake properly:
https://streamable.com/lu98dz
Documentation images should be merged here after this pr is done
tgstation/documentation-assets#2
Changelog
cl
qol: grav anomalies now have a pretty effect
refactor: Rendering has been refactored, remember to report bugs
/cl
