* [NO GBP] Fixes blindness icons on lower station z-levels (#70608)
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.
* [NO GBP] Fixes blindness icons on lower station z-levels
Co-authored-by: Tastyfish <crazychris32@gmail.com>
* Cleans up the fallout from plane cube (#70235)
* Cleans up the fallout from plane cube
Alright.
Makes cleaning bubbles respect planes
Adds support for updating overlays on move, fixing an issue with pointing at items
Adds better error messages for failing to provide args for mutable_appearance()
Fixes a bug where string overlays were not respecting insertion order
* Adds documentation for offset spokesman and offset_const
* Better stack trace
* Removes some redundant uses of cached MAs
At this scale, attempting to cache MAs like this has 0 impact on anything
And just makes things more messy then they need to be
* ensures fullscreen objects START offset, so things are always proper
* ensures chatmessages always have the right offset
* fixes compile
* whoops, the above lighting plane should actually be ABOVE the lighting plane
* fixes compile, also cleans up the fire overlay a tad
* Adds a unit test for plane masters that are shrunk by multiz being double shrunk
This is slightly hacky because of how I'm handing the plane master
group, but it's not THAT bad, and gives me some real good coverage
* Properly targets the seethrough plane at the game world plate. This fixes unit tests, and also just makes more sense
* whoops
* oh
* adds datum support for allocate(), cleans up a harddel from testing
* Makes camera chunks index at 1, and also makes them support non powers of two sizes, since that was unneeded
* fixes runtime in allocate
* Cleans up the fallout from plane cube
* liquid tweaks
* oop
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Adds seethrough component (#69642)
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 seethrough component
Co-authored-by: Time-Green <timkoster1@hotmail.com>
* Fixes our rendering for 514.1587 (#69778)
About The Pull Request
Ok so we have a blackness plane master right? it's setup to catch byond darkness but it doesn't rn cause we don't got the sight flags set.
So what it does is just sit there and do NOTHING.
BUT some genius put a color var on it, prob meant to just make it fully black.
But I think they just wrote it wrong, because byond just treats it as "make this plane have alpha 255 everywhere"
The problem is it's got zip on it, so if it actually worked this would black out everything below plane 0.
BUT it didn't work before, because setting anything on non overlay PMs broke them, and made them invis.
Then lummy fixed that, and now we get this.
I've fixed this bug by just removing the color set. It's not actually used for anything so outside this accidential working as intended behavior, it effects nothing, and doesn't actually impact darkness even if we used the sight flag. (I know this because I did this same thing in my multiz pr, which uses the sightflag)
Anyho I think they just wrote it wrong, because byond just treats it as "make this plane have alpha 255 everywhere"
We support 514.1587 now, so that's nice (NOT FOR RUNTIME THO CAUSE IT BROKE ?. LUMMOX ALSO KNOWS THIS)
Fixes#69774
Changelog
cl
fix: Hey, we support byond version 514.1587 now. You can upgrade if you'd like. I hope.
/cl
* Fixes our rendering for 514.1587
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Fixes 118(give or take) cases of mapload not being passed to initilaize (#69107)
fixes 114 cases of mapload not being passed to initilaize
* Fixes 118(give or take) cases of mapload not being passed to initilaize
* Fixes a lot (give or take) cases of mapload not being passed to initilaize
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* Ventcrawling improvements, performance and visual (#66709)
* 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>
* Ventcrawling improvements, performance and visual
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Kylerace <kylerlumpkin1@ gmail.com>
* Fixes hud objects being hidden by blindness (#65385)
They have a higher plane then fullscreen overlays, but unfortunately for
me, they were rendering to the game plane, which is below
RENDER_PLANE_NON_GAME. I was therefore getting hit in the nuts.
Hate this timeline
* Fixes hud objects being hidden by blindness
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* Adds a colorblind accessability testing tool (#65217)
* 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>
* Adds a colorblind accessability testing tool
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Fix Transparent Floors Multi Z clipping (#63878)
Fixes#63770 (Objects on Lower Z level appearing on top Z level when under glass tiles)
This fixes some MultiZ issues that were discovered after I made #62875 (566b9ee1d8). I never setup a new plane for the transparent turfs and because of this any objects, icons, or sprites that were offset from the boundary of the turf would make any bottom Z level stuff appear on the current Z level.
We want stuff to look normal.
* Fix Transparent Floors Multi Z clipping
Co-authored-by: Tim <timothymtorres@gmail.com>
* Field of View and Blindness improvements [bounty + upstream push]
* Update death.dm
* almost done
* Update fov_handler.dm
* Face mouse when in combat mode, fix
* Fixes the category for the fov admin verb. #63401
* Fixes objects with bad planes and FoV bugs #63412
* pain
* there we go
* face pref
Co-authored-by: Azarak <azarak10@gmail.com>
* Fixes overlay lighting not having any color. (#62087)
The overlay lighting plane was never actually being drawn, only used as an alpha filter over the main lighting plane.
That's fine to do, but it only cuts away darkness, doesn't actually lay down any color.
So let's properly draw it too, so things look right
Fixes#61899
* Fixes overlay lighting not having any color
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>