* Fixes emissive blockers sometimes being put in an atom's contents (#74618)
## About The Pull Request
This is a weird one. When `EMISSIVE_BLOCK_UNIQUE` is set for an atom, it
causes the emissive blocker to be placed in the atom's `contents`. I
don't think this was intended can can potentially cause all kinds of
issues like in the linked one.
@ LemonInTheDark what say you?
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/20431
## Why It's Good For The Game
Bug fix?
## Changelog
🆑
fix: fixes emissive blockers sometimes being put in an atom's contents
/🆑
* Fixes emissive blockers sometimes being put in an atom's contents
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart (#73678)
## About The Pull Request
So, this spiraled from one missing icon being fixed to an entire check
for said icons.
Several icon files no longer use error icons because its assumed that
the checks will handle any missing ones, but the checks don't apply to
emissives nor overlays at all. This led to the radsuit having an
emissive but no icon_state for it - a relic of the old radsuit. This was
only noticed because of a downstream with an error icon appearing for
it...
I was curious how many were actually having the same issue, so I made a
small little stack_trace in the mutable_appearance proc.
There were like, 2k. Lots of them were icons named, like, "transparent"
or "blank" too...
I moved that check to the emissives proc because I semi-understand that
system so could actually fix it, and it moved to around fourty
roundstart. Much more achievable.
(The error usually has more info if you click on it, including the item
that caused it. I dunno how to add that to the check itself because of
where it's located, though.)
This fixes all the ones I could find, including...
Nonexistant icons that shouldn't be adding emissives on:
- Empty Barsign
- Radsuit
- Mass Driver Controllers
- Telescreens
- Aux Base Consoles
- PanDEMIC
- Kobayashi computer (holodeck)
- Abductor camera console
- Syndie drop pod
- BSA controller
Entirely missing icons on:
- Pwr Game Vendor (this was just misnamed)
- Generic Soda Vendor
- Engivend
- Security Laptop (proud of this one.,.,)
There are no doubt more of them hidden about, but I don't really know
what I'm doing... If there's a check that'd be better than this, please
review telling me what to change <3
## Why It's Good For The Game
Fixes missing icons, fixes attempts to add icons where we don't need
them, and adds a check to help fix more of the two issues as they occur.
## Changelog
🆑
fix: fixed missing emissives on the Engivend, Pwr-Game Soda, and generic
Soda vendors. Also fixed the seclaptop having no valid screen icon!
fix: fixed a few items trying to apply emissives when they shouldn't.
code: added a stack_trace for emissives with missing icon states.
/🆑
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart
* Update cryopod.dm
---------
Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Starlight Polish (Space is blue!) (#72886)
<!-- 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. -->
## About The Pull Request
Adds support to underlays to realize_overlays
Ensures decals properly handle plane offsets
Fixes space lighting double applying if it's changeturf'd into. this
will be important later
Makes solar vis_contents block emissives as expected
Moves transit tube overlays to update_overlays, adds emissive blockers
to them
#### Adds render steps
An expansion on render_target based emissive blockers.
They allow us to hijack an object's appearance and draw it somewhere
else, or even modify it, THEN draw it somewhere else.
They chain quite nicely
Fixes shuttles deleting z holder objects
#### Makes space emissive, makes walls and floors block emissives
The core idea here goes like this:
We make space glow, and give its overlays some color
This way, the tile and space parallax remain fullbright, along with
anything that doesn't block emissives, but anything that does block
emissives will instead get shaded the color of starlight
This requires a bit of extra work, see later
This is done automatically with render relays, which now support
specifiying layer and color (Need to make an editor for these one of
these days)
The emissive blocking floor stuff requires making a second render plate
to prevent double scaling
Also adds some new layering defines for lighting, and ensures all turf
lights have a layer. We'll get to this soon
#### Makes things in space blue
We color them the same as starlight, by taking advantage of space being
emissive
This means that things in space that block emissive will block it
correctly and be colored blue by the light overlay, but space itself
will remain fullbright
This does require redefining what always_lit means, but nothing but
cordons use that so it's fineee
#### Makes glass above space glow, and some other stuff
Glass tiles that sit above space will now shine light with matching
color to the glasses color. This includes mat tiles.
Glass tiles (not mat because they have no alpha) also only partially
block emissives.
Adds a new proc that uses render steps to acomplish this, essentially
we're cutting out bits below X alpha and drawing what remains as an
emissive.
#### Modifies partial space showing to support glow
Essentially, alongside displaying space as an underlay, we also display
a light overlay colored like starlight.
That starlight overlay gets masked to only be visible in bits that do
not contain any alpha.
We also mask the turf lighting to not go into bits that have no alpha,
to ensure we get the effect we want.
This is done with that lighting layer thing I mentioned earlier.
#### Makes appearance realization's list output ordered
I want it output in order of overlay, sub overlay suboverlay, next
overlay
Need to use insert for that
## Why It's Good For The Game
Pretty!
Also having space be emissive is a very very good way to test for fucked
emissive blockers (If it's broken why are we even drawing the overlay)
I know for a fact mob blockers on lizards and socks are kinda yorked, I
think there's more
<details>
<summary>
Old
</summary>
</details>
<details>
<summary>
New
</summary>
</details>
## 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: Space now makes things in it starlight faintly blue
fix: Glass floors that display space now properly let space shine
through them, rather then hiding it in the dark
add: Glass floors above space now glow faintly depending on their glass
type
/🆑
<!-- 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: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* update modular
* Update _decal.dm
* Update _decal.dm
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* FUCKIN WOOO
* much better
* yesssssss
* yeetus deletus the merge conflictus dies
* fug that was an oops
* better
* linters are weird
* woops I erased tesh tails
* better
* wingfix
Co-authored-by: Gandalf <jzo123@hotmail.com>
* Emissive system refactor (#58130)
The emissives system is the system that both lets computer screens and vendors glow in the dark and lets mobs and items block those glows. The current implementation relies on using filters to let mobs and items mask out the glow in the dark overlays on some structures. This is difficult to extend properly without massively increasing maptick. This PR changes the emissives system to use BYONDs native image layering to mask emissive overlays. This should prove to be a more extensible option.
tldr; There exists a system that lets computer screens glow on the dark and lets mobs and items block the glow. It isn't very extensible and this PR attempts to make it more extensible.
How emissive overlays used to work
Currently emissive overlays and the emissive blockers that mask those overlays are handled using a system of inter-masking planes. The emissive overlays and the emissive blockers are placed on separate, hidden plane masters. These are essentially rendering layers and groups. The emissive blocker plane is then used to mask the emissive overlay plane which effectively allows the emissive blockers to block the emissive overlays from being seen. After is has been masked the emissive overlay plane is used to mask the lighting plane, essentially creating holes in the shadows wherever an unblocked glowing thing exists.
Why this is a potential problem
This system works fine. In fact it works great! The computer screens glow, any person or item that winds up on a computer blocks the glow, and everything just works. However, this system runs into some issues when you try to extend it to work on things other than structures. Namely, the current system only supports emissive overlays on structures and emissive overlays that are completely unblockable by any means. As a result, several interesting uses to the system require extending the system.
As a result, if you want to apply emissive overlays to items (which exist between structures and mobs) or emissive overlays to turfs (which exist below structures) you must extend the emissives system to get the emissive overlays and emissive blockers to properly function. Doing this naively, by adding extra emissive overlay and emissive blocker planes and applying all of the relevant masking filters, is not exactly performant.
Maptick is a major contributor to lag and the higher the maptick the more free lag you, the player, get delivered fresh to your client. Trying the naive method resulted in #55782 (1f1b58bb26), an attempt to add glowing carpet to the game. Since the PR revolved around adding glowing carpet it had to extend the emissives system to allow for emissive turfs and emissive blocking structures. Extending the system was done naively as described above and you can see the results. 1.5 times the maptick across the board. Ouch.
So, we know that extending the system in it's current form is impractical. At least if done naively. Thus we are stuck.
tldr; The emissive system currently uses inter-plane masking to allow for emissive blockers to function. This is difficult to reasonably extend without murdering maptick. See #56496 (1f1b58bb26) for the results of naively extending this system.
How emissive overlays are going to work
Alright, so we know that the current system of using planes to let the emissive blockers mask the emissive overlays is difficult to extend in it's current form. The solution is to change how the system works so that it can be extended in a more efficient manner. What we want is a system that allows one set of images to be out masked by another set of images and for the first set of images to be capable of masking the light plane. Preferably, we would also like the ability to interleave the masking effect between emissives and emissive blockers with almost arbitrary layering.
Conveniently, this layering and masking is something BYOND already does to normal items and objects. If we put the emissive overlays and the emissive blockers on the same plane we can use their layers to interleave them almost arbitrarily like any normal structures and items! All we need is a way to mask away the emissive blockers from the resulting rendered plane and we can mask the lighting plane with the remaining emissive overlays.
Luckily, BYOND has provided a single filter that is capable of this task. The color matrix filter. This filter can be used to apply a color matrix to an image! Provided that the emissive overlays and the emissive blockers are different colors we can use a color matrix filter to effectively mask out the emissive blockers from the plane! The resulting emissive plane can be applied as an alpha mask to the lighting plane as it used to, to the same effect. The best part is, we get layering practically for free!
This is exactly what this PR does. It converts the emissives system from the old plane and masking based blocking to a new layer-based system which uses BYONDs native layer handling to mask the emissive overlays.
* Emissive system refactor
Co-authored-by: TemporalOroboros <TemporalOroboros@gmail.com>
