mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-14 17:45:02 +01:00
docker-container
20 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 MrMelbert
|
1276076519 |
Allows you to look down ladders, both via verb/hotkey and, yknow, visually (#88876)
## About The Pull Request   ## Why It's Good For The Game Even though you (logically) should be able to peer down a ladder before you step down, to know if you're going to climb directly into a meat grinder, you cannot. Now you can. Gas still does not travel between ladders. Maybe later ## Changelog 🆑 Melbert qol: You can now look down ladders, both via the look down verb/hotkey and by just looking with your eyes /🆑 --------- Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
YesterdaysPromise
|
fec946e9c0 |
/Icon/ Folder cleansing crusade part, I think 4; post-wallening clean-up. (#85823)
Hello everybuddy, your number three rated coder-failure here to clean up some mess. This PR accomplishes some of the more major structural clean up changes I wanted to do with /obj/ folder, but decided to wait on until wallening gets merged, and so, time has come. Several things to still be done, although I know these cleaning PR's are quite a load, so will wait for this one to get done with first. ## Why It's Good For The Game Saner spriters, better sprites, less annoyance. Also deleted a whole load of redundancy this time around, a lot of sprites which existed simultaniously in two places now got exit their quantum superposition. |
||
|
LemonInTheDark
|
e90a9b4b68 |
Flattens The Floor Plane (Camera Update Too) (#84350)
## About The Pull Request Ok so like, side map right? It makes things higher up in the world render above things lower down in the world. Most of the time this is what we want, but it is NOT what we want for floors. Floors are allowed to be larger then 32x32, and if they are we want them to render based off JUST their layer. If we don't allow this grass turfs and others get cut off on their bottom edge, which looks WEIRD. In order to make this happen, we can add TOPDOWN_LAYER to every layer on the floor plane and disable sidemap. I've added documentation for this to VISUALS.md, and have also implemented unit test errors to prevent mixing TOPDOWN layers with non topdown planes (or vis versa). This new test adds ~1 second to tests, which is I think a perfectly scrumpulent number. EDIT: I nerd sniped myself and implemented sidemap layering and lighting for cameras (also larger then 32x32 icon support for getflat) The lighting isn't perfect, we don't handle things displaying in the void all that well (I am convinced getflat blending is broken but I have no debugger so I can't fix it properly), but it'll do. This came up cause I had to fix another layering issue in cameras and thought I might as well go all in.  ## Why It's Good For The Game Old:  New:  ## Changelog 🆑 fix: Grass turfs will render properly now. Reworked how floors render, please report any bugs! fix: Cameras now properly capture lighting fix: The layering seen in photos should better match the actual game /🆑 |
||
|
Zephyr
|
1b96345e44 |
Multi-Z Support for Lazy Templates | Cleans up some turf flag misuse (#77786)
## About The Pull Request Adds multi-z support for lazy templates Also fixes some improper use and placement for turf flags ## Why It's Good For The Game Shadow needs/wants this for bit runner maps. Turf flags are also why lava has been generating in places it shouldnt. (inside of ruins) ## Changelog 🆑 fix: Lava can no longer occasionally generate inside of previously loaded templates and breach and/or destroy shit /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
san7890
|
ccef887efe |
Lints Against Unmanaged Local Defines (#74333)
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW RATHER THAN AFTER THE FACT. ## About The Pull Request Hey there, This took a while to do, but here's the gist: Python file now regexes every file in `/code` except for those that have some valid reason to be tacking on more global defines. Some of those reasons are simply just that I don't have the time right now (doing what you see in this PR took a few hours) to refactor and parse what should belong and what should be thrown out. For the time being though, this PR will at least _halt_ people making the mistake of not `#undef`ing any files they `#define` "locally", or within the scope of a file. Most people forget to do this and this leads to a lot of mess later on due to how many variables can be unmanaged on the global level. I've made this mistake, you've made this mistake, it's a common thing. Let's automatically check for it so it can be fixed no-stress. Scenarios this PR corrects: * Forgetting to undef a define but undeffing others. * Not undeffing any defines in your file. * Earmarking a define as a "file local" define, but not defining it. * Having a define be a "file local" define, but having it be used elsewhere. * Having a "local" define not even be in the file that it only shows up in. * Having a completely unused define* (* I kept some of these because they seemed important... Others were junked.) ## Why It's Good For The Game If you wanna use it across multiple files, no reason to not make it a global define (maybe there's a few reasons but let's assume that this is the 95% case). Let me know if you don't like how I re-arranged some of the defines and how you'd rather see it be implemented, and I'd be happy to do that. This was mostly just "eh does it need it or not" sorta stuff. I used a pretty cool way to detect if we should use the standardized GitHub "error" output, you can see the results of that here https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792 ## Changelog Nothing that really concerns players. (I fixed up all this stuff using vscode, no regexes beyond what you see in the python script. sorry downstreams) |
||
|
LemonInTheDark
|
2e240d0e9d |
Fixes an issue with multiz visholders duplicating (#73835)
## About The Pull Request I think the inherent issue here has to do with turf refs or something, but the big problem was I assumed if there was only once source, then the turf must be new. This was an invalid assumption, since we can add sources more then once, and | is used Because of this, each time a shuttle moved, we'd add an extra source for no reason, and stack extra vis holders. This lead to really bad clientside lag on some out of repo maps, which is how this issue came to my attention. Instead checking if the sources list exists or not solves the problem pretty handily, so let's do that. ## Why It's Good For The Game Closes #73834, prevents a potential future OOM |
||
|
lessthanthree
|
07c03375ce |
Fixes layering of tram rails (#71382)
## About The Pull Request -Fixes the layering of the tram rail so that it doesn't end up below the reinforced glass. -Replaces the last remaining vault platform turfs with proper tram turfs. -Removes an un-needed layer define for turf transparency.  ## Why It's Good For The Game The tram rail becoming disconnected when it travels over glass, in reality that'd probably derail it. So let's fix it! ## Changelog 🆑 LT3 fix: Tram platform is now entirely built with tram tiles. fix: All the parts of the tram are now on a correct layer/plane. remove: Removed the openspace layer on the transparency plane. /🆑 |
||
|
AnturK
|
4d6a8bc537 |
515 Compatibility (#71161)
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>
|
||
|
Mothblocks
|
60ee087b16 |
Remove ELEMENT_DETACH on everything that doesn't need it, rename to ELEMENT_DETACH_ON_HOST_DESTROY + a PSA (about 0.2s init time savings) (#70972)
ELEMENT_DETACH is **not** a requirement to having `Detach` called. Detach is always called when the element itself is destroyed. ELEMENT_DETACH is a flag that when set, makes sure Detach is called when the atom destroys. Sometimes you want this, for instance: ```dm /datum/element/point_of_interest/Detach(datum/target) SSpoints_of_interest.on_poi_element_removed(target) return ..() ``` This Detach cleans up a reference that would have hung if target was destroyed without this being called. However, most uses of Detach are cleaning up signals. Signals are automatically cleaned up when something is destroyed. You do not need ELEMENT_DETACH in this case, and it slows down init. This also includes somewhat more complex stuff, like removing overlays on the source object. It's getting deleted anyway, you don't care! I have removed all uses of ELEMENT_DETACH that seemed superfluous. I have also renamed it to `ELEMENT_DETACH_ON_HOST_DESTROY` to make its purpose more clear, as me and a lot of other maintainers misunderstood what it did, --- An update to this, ELEMENT_DETACH *is* needed for anything that can register to a turf, as turfs do not clear their signals on destroy. |
||
|
LemonInTheDark
|
23bfdec8f4 |
Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115)
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 #65800 Fixes #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 |
||
|
vincentiusvin
|
7c61bf65f2 |
Makes glass floors override platings. Fixes glass floor openspace bug. (#66301)
About The Pull Request Fixes #63868. Actual one liner fix for this one here. If this pr dies feel free to atomize this one. AND it turns out to not be tim's fault. Fixes #63548. But i really shouldnt say fixed. The original implementation was causing the invincible plating bug. When tim's refactor got in it instead relies on the element state, which was broken from the get go, removing the invincible plating bug which was in a sense "intended" its all messy man I hate this code. Thats why im removing the plating thing. Let the turf handle the turf change themselves this complicates things. Mapped in glass floors have openspace (now baseturf bottom) as their baseturfs, while built ones have plating under them. Which doesnt make sense to be honest. Why would things be visible if a plating is under the glass. They are also crowbarrable on top of this, which to be fair is my main reasoning behind the PR. To solve this, I am instead making glass floors replace the plating instead of building over it. This is made to be generalizable for every tile in game, as long as their initial baseturf is the same and the tile wants it to happen. do after of three seconds is completely arbitrary. If any maint want it changed let me know. Why It's Good For The Game First one solves a bug Second one makes more sense And er, icebox is currently using the glass floors in sec, they can be crowbarred very easily. This might be a good idea from a gameplay perspective. Changelog cl del: Removed adding glass floors to plating balance: Allows you to replace plating with glass floors instead. 3 second timer. del: Removed deconstructing the glass floors. No replacement for this one, use a rcd. fix: Fixed metastation glassfloor spawning a weird turf when crowbarred. /cl |
||
|
Tim
|
b7922744b7 |
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 (
|
||
|
Tim
|
566b9ee1d8 |
Fix Turf Transparency for MultiZ (#62875)
Fixes #62794 (Catwalk Tiles placed on the lower level of tram appear to be on the upper level) Fixes #57654 (Open Space shading not always applied) Fixes #53666 (When standing on a glass floor above a light on the Z level below you the light effect is rendered above the character. This makes light have ugly glows on the floors above. This also happens with grills and lattice.) Transparent turfs, catwalks, and lighting overlays were badly broken with MultiZ issues. This fixes any transparent turf to appear and be on the same z-level if it has the turf_transparent element. Catwalks will appear and be on the same z-level as well. They were initially glitching to top z-levels causing people to walk over an illusion that caused them to fall to their deaths. After I fixed these issues I noticed that lighting overlays were also glitching to top z-levels, which looked rather strange as there were lights in the middle of rooms and hallways with no supporting walls. Lights now appear under the transparent turfs properly. The mapping icons for catwalks displayed the wrong icon_state so I fixed that too. I made a big refactor for transparency and catwalks code that had to be done to get all of this to work properly. You no longer have to be afraid of falling off of glass floors, catwalks, or transparent tiles. Also lighting overlays don't glitch through upper z-levels anymore for transparent tiles. |
||
|
John Willard
|
96a3d410a2 |
Traits given by Elements now have element trait as their source. (#62134)
Hopefully the code is more organized and consistent this way. |
||
|
LemonInTheDark
|
6cb6d10185 |
Fixes a turf signal unregistration I missed, makes the transparent turf element detach (#60064)
* Forgot to patch this up, the transparency element both does not detach on parent destroy, and with the new signal changes leads to signals persisting, which is bad and ick. This fixes that |
||
|
Kylerace
|
d3a1bea859 |
Turns lighting objects into a datum, makes all lighting be performed with an underlay. big maptick fix very good! (#58991)
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 |
||
|
Emmett Gaines
|
1c81adac8d | Allows the connect_loc element to have a listener different from the tracked object (#58276) | ||
|
TemporalOroboros
|
e9f9ad1e34 | Makes Metalgen Unrecycleable (#55417) | ||
|
Qustinnus
|
6424b6136e | Turns transparency for turfs into an element, and gives it to datum materials. (#54250) |
