Bluespace anomalies detonating Move() things. When something is Move()d, none of the logic in forceMove() or doMove() is called, and thus stationloving things can't tell when they've left the z-level (since that's where the logic for it is).
There are a number of approaches I could have taken: Refactoring anomalies to use different movement code. Refactoring Movement code to send more signals in various scenarios. Refactoring the stationloving component.
I settled on two steps. First, refactoring the component to bring it up to modern code standards. Second, moving the logic for COMSIG_MOVABLE_Z_CHANGED to Moved() so the signal always fires regardless of if Move() or forceMove() or doMove() is used, with an optional var for whether the z-change is communicated to contents. This means the ore box was changed to actually send the signal instead of just returning with no parent call or signal sent. Stationloving ore boxes when?
stationloving procs no longer call SIGNAL_HANDLERs directly. Var names are now more descriptive. Things are renamed and documented. At least for the parts of the code I know.
Probably some other code cleanups.
Implements a helper proc for generating emissive blockers.
Makes everything that generates an emissive blocker overlay use the new helper.
Grants all emissive blockers and emissive overlays KEEP_APART, RESET_COLOR, and RESET_TRANSFORM.
Also fixes the jack-o-lantern worn overlays so that they actually glow while they are active.
credit to zewaka for the idea of using underlays
turns the lighting object movables that were unnecessary and increased maptick into a datum which then applies and removes an underlay in update(). also applies a lot of general lighting clean ups (mostly using as anything in loops and fixing single letter var names).
multiz is a little different by necessity, now only the bottom turf's lighting matters in the brightness of the top turf unlike master where the bottom turf's lighting object is hidden from the vis_contents of the top turf. there are still some kinks to iron out here though, since currently objects suspended in openspace (like tram platforms) look bad and glass floors look bad too
only thing i have left to do is make multiz work (well)
UPDATE: multiz now appears the same as far as i can tell, its possible there are other situations in which its different but datum mats work and it automatically updates if the turf below changes. now i just need to make the system less finnicky if at all possible (and possibly merge managed_turf_vis_content with managed_overlays maybe?)
new update: its basically equivalent to normal multiz as far as i can tell (visually at least, in the circumstances ive tested so far)
NEW NEW UPDATE: turfs no longer have the VIS_HIDE vis_flag and multiz works without stacking the lighting from the floor below! so this shouldnt have any overt drawbacks to master anymore
1 needless movable per tile is terrible for maptick. this is probably a larger improvement than my emissive blocker change in terms of maptick. im guessing we'd get around 0.6 average maptick per player after this where currently we get 0.85 or so
Edit: according to lemon, sybil reached 0.71 maptick per person when tm'd with this
if this is a big enough improvement i might finally be able to get rid of the Gone discord avatar
Sourced from #59118 and a cursed project I'll pr later, This pr contains a lot of harddel fixes for stuff that pops up after a player interacts with something. I'm not gonna list them all here because there's something like 60 130, check the commit log if you're curious
Oh and I moved ref tracking screaming to a separate define, and made some optimizations to the thing in general. I think that's it, this pr is a bit of a frankenstine
Removed a bunch of back reference lists that were either entirely unused, or contained references that could be found within the datums contained in other lists.
lighting corner datums now get deleted with unused.
light sources no longer track lighting corners where the appiled light rounds to 0.
Fix lighting on turfs that gained dynamic lighting mid round. lazy init corner datums.
these two are related. by decoupling corner datums from the turfs dynamic lighting state, we can use them to know what level of light a non-dynamic light turf should have once it gains dynamic light.
Also should free up some memory not storing these datums in maint. Corner datums only exist on a turf that has light cast upon it by the dynamic lighting system.
Lighting corners are now lazy inited and deleted. they should always (and only exist) if there is a light source shining on it within range (even if the turf has no dynamic lighting). This is needed to support turfs that become lighting enabled mid round. On the plus side, they will no longer be generated on full dark turfs.
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.
## About The Pull Request
Changes up some layer and plane defines for no particular reason lol
## Why It's Good For The Game
Planes actually override layers, and layers control ordering within planes. A lot of the usage of plane and layer was wholly unnecessary. This refactor helps future maintainability while also being needed staging for _future features._
Clears out two deprecated explosions systems (explosion ids and explosion levels)
Refactors a bunch of contents_explosions procs to be maybe slightly faster.
Cleans up a bunch of ex_act code.
Slightly cleaner code
A few less unused vars on /atom and /turf
Converts the effects of the nightmares light eater into a component and a couple elements
Adds some flavor text to the light eater
Makes the effects of the nightmare's light eater dispel if the armblade is destroyed
Probably a net increase in code quality
More flavortext
The nightmare's light eater effect can be dispelled if you are willing to sacrifice the armblade
Done using this command sed -Ei 's/(\s*\S+)\s*\t+/\1 /g' code/**/*.dm
We have countless examples in the codebase with this style gone wrong, and defines and such being on hideously different levels of indentation. Fixing this to keep the alignment involves tainting the blames of code your PR doesn't need to be touching at all. And ultimately, it's hideous.
There are some files that this sed makes uglier. I can fix these when they are pointed out, but I believe this is ultimately for the greater good of readability. I'm more concerned with if any strings relied on this.
Hi codeowners!
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
* Adds emissive carpet, adds plane support to decal element
- Adds a basic abstract/debugging emissive carpet
- Makes decals capable of supporting plane
- Adds auto-smoothing decals
* Adds simple neon carpet variations
* Adds neon carpet reagents and recipes
* Refactors emissive blockers to allow multiple layers of emissive / emissive blocking objects
- Splits the emissive and emissive blocker plane masters into several plane masters which handle different layers of emissiveness.
* Makes neon carpet tile stacks emissive
* Rearranges and docs some emissive plane masters
- Folds the overlay lighting plane master into the emissive planes since it is also used to mask the lighting plane
* Fixes null mats_per_unit stack recombining after splitting
- I think I broke this a while ago when I reworked how stacks handle materials. Whoops.
- This basically only effects carpet at the moment. Good thing I did this when I did!
* Adds neon carpets to cargo
- Adds a cargo supply crate containing a _lot_ of neon carpets for 3000 credits
* Fixes neon carpet highlights leaking through vending machines and such
- Turns out vending machines axed their own emissive blockers whenever they updated their icon because they cleared their managed_vis_overlays...
- Generic emissive blocking has been elementized and some update_overlays procs have been straightened out.
* Fixes id_arg_index for the emissive blocker element
* Commits @Rohsie's suggestions
Some tweaking and code smoothing of the spray-on gloves. The only
mechanical change is in also letting them be washed off (although it
takes a while under a shower or using a sink).
A visible message also provides better feedback.
* Make /wash a SHOULD_CALL_PARENT proc
A number of things depend on that signal being called.
* Makes suggested changes
- Adds SIGNAL_HANDLER to signal handler
- Changes name of turf variable for readability
- Reenables lighting object override of parent
Adds in a new type for the lighting system, the directional one. It piggybacks on the overlay lighting to create a directional effect + adds a nice visual cone mask to make the effect feel really directional.
Also: made the static light system respect the light_on variable.
It feels really nice to shine AT things you're looking at with flashlights and the such, it makes maintenance scouring much more immersive too.
Adds more paranoia as you dont see light behind yourself when you've got a flashlight. Plus makes ambushes more fun
VV-related code cleanup
Added code to trigger the proper setters for several variables that have them.
Added some admin logging for var-edit teleports.
Cleaned-up some code all around.
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
Sparks no longer lag, projectile beams move super smoothly, same with mobs and whatnot. This also allows for easy expansion into directional lights, field-of-view, wee-woo rotating lights or whatever.
It does have a downside: things right-clicked or checked through the alt+click tab will show the light overlay:
This is a BYOND limitation, very well worth it IMO.
🆑
add: Smooth movable lighting system implemented. Projectiles, sparks, thrown flashlights or moving mobs with lights should be much smoother and less laggy.
balance: Light sources no longer stack in range, though they still do in intensity.
/🆑
Moves all opacity var manipulation to a proc which sends a signal.
light_blocker element for movable opaque atoms made, which tracks its movement and updates the affected turfs for proper lighting updates.
has_opaque_atom boolean replaced by the opacity_sources lazylist to keep track of the sources, and a directional_opacity which serves a similar function but also allows for future expansion with on-border opaque objects (not yet implemented).
Some opacity-related sight procs optimized as a result of this.
Some variables moved to the object's definition.
A define or two added into the mix for clarity.
Some code cleaning, like turning booleans into their defines.
One file renamed for clarity.
Changelog
cl
balance: Mechs no longer block sight. It's a non-trivial cost for the lighting system with little to no gain.
/cl
Defined all the existing light_color values.
Moved their definitions to colors.dm
Made white the default color. It was so already, but that was very obscured.
Moved the atom light-related variables to the atom definition.
Wrapped changes to variables such as light_color into procs that report the event through signals.
Moved the light_on variable to the atom level, also adding a signal for its changing, to represent toggling lights.
Cleaned up a little bit of code in where new variables were defined before redefinitions.
This is all atomization to reduce changes in #52413
None of this affect gameplay at all, it's all code cleaning and refactoring.
There's more colors to standardize, a search for color = will find lots of targets, and I see little need to have both the LIGHT_COLOR and COLOR patterns, but I don't want to make this PR bigger than it already is.
* Don't initialize the atom_colours list on atoms until it's actually needed
* Moved bloody_hands var to mob/living/carbon/human instead
* Added COMSIG_COMPONENT_CLEAN_RADIATION signal to reduce moms spaghetti
The shower and suit storage unit now calls this signal instead of either doing it manually or doing it via the washed proc
* Cleaned up carbon washing, renamed washed to wash
* The wash proc now doesn't take the washer as first arg because that wasn't used anywhere
* The wash strength is no longer optional
* Carbons now overrides the wash proc instead of using the signal
* Properly check for obscuredness before washing any equipped items
* Properly wash all items and bloody hands etc
* Added clean_lips proc for humans for cleaning any lipstick
* Cleaned up washing. Washy stuff now calls wash instead of calling the clean signal directly
* Renamed is_cleanable to ismopable, gives this category a more fitting purpose. Many things beyond floor decals are cleanable. It is now also determined using the atom layer instead to make it more generic.
* Properly utilize the is_cleanable define
* Added wash override for turfs where they also wash any mopables on the same tile
* Space cleaner and cleaning element etc now simply washes the mob instead of doing its own manual cleaning on ~some~ equipped items
* Non-component washables now simply override wash instead of registering for the clean signal
* Fixed some left over clean signal registers not returning true
* Added clean_strength var to space cleaner
* Moved human wash proc next to the other washing procs
* Also wash glasses and mask if not obscured when washing face
* Fixed attempting to "scoop up" cleanable decals using a rag
* Fixed plasmaman spacehelm icon not updating when washed
Also removed a duplicated worn_overlays proc
* Fixed head icon not updating when washing lipstick
* Moved radioactive clean signal register to where it should be
* Added atom radiate VV verb for debugging
* Redesigned the CLEAN constants into a more sensible flags setup
This makes it more dynamic, cleaning apparatuses can clean more specific than just a cleaning strength.
* CLEAN_TYPE_* flags indicate a specific cleanable, such as blood, fingerprints or disease
* CLEAN_* consts consist of a combination of cleaning types to make cleaning apparatuses have a consistent behaviour on what they clean
* Fixed broken rad removal logic in showers
* Apply suggestions from code review
Co-authored-by: Rohesie <rohesie@gmail.com>
* Removed unneccesary bool from sink code
* Fixed wrongly named variable in turf wash
* Renamed bloody_hands to blood_in_hands
Co-authored-by: Rohesie <rohesie@gmail.com>
About The Pull Request
Just moving /turf/proc/get_corners() into its only caller, slightly shuffled.
Also #defining /proc/GetRedPart() etc, which should flatten down to a copytext+text2num operation with #51005. Also defining parse_light_color() since it has two callers and does something trivial (splits #ff0000 into three luminance vars).
cl Naksu
code: Lighting corner updates are ever so slightly faster.
/cl
This will save memory, and we're constantly manually modifying the
color of this atom all the time, so it makes no sense to bookkeep it in
the atom colour list (that's for restoring atom colors that are affected
by other effects)
I was going to use a flag on flags_1 to control the behaviour, but
they're all in use and I don't want to add flags_2
