mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-13 03:02:38 +00:00
8b965c912765bd42b51bc845d54673f578bcbbdd
211 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Waterpig
|
d3d3a12540 |
The big fix for pixel_x and pixel_y use cases. (#90124)
## About The Pull Request
516 requires float layered overlays to be using pixel_w and pixel_z
instead of pixel_x and pixel_y respectively, unless we want
visual/layering errors. This makes sense, as w,z are for visual effects
only. Sadly seems we were not entirely consistent in this, and many
things seem to have been using x,y incorrectly.
This hopefully fixes that, and thus also fixes layering issues. Complete
1:1 compatibility not guaranteed.
I did the lazy way suggested to me by SmArtKar to speed it up (Runtiming
inside apply_overlays), and this is still included in the PR to flash
out possible issues in a TM (Plus I will need someone to grep the
runtimes for me after the TM period to make sure nothing was missed).
After this is done I'll remove all these extra checks.
Lints will probably be failing for a bit, got to wait for [this
update](
|
||
LemonInTheDark
|
77823ad210 |
Pathfinding Visualization, JPS fixes, Misc Improvement (#90233)
## About The Pull Request [cleans up poor namespacing on light debugging tools]( |
||
Bloop
|
241514f520 |
Fixes improper static list declarations + adds grep for it (#87207)
## About The Pull Request I randomly came across a `var/list/static` in the code, which does not actually do what was intended, and thought it was silly. A ctrl+f revealed that this was a fairly common mistake, so I went and fixed all the instances of it I could find. ~~Including one in lighting code, which it looked like they were trying to create a global list to cache generated lighting sheet values for speed, but it was just a normal list that got created each time pointlessly. Now those values are actually being cached (using a global var, because a `static` list was not the right thing to use there in the first place).~~ Nevermind, it seems that this was in fact being cached even if it shouldn't have been, because byond. Just rearranged it there seeing as it works either way. ## Why It's Good For The Game Code that does what it's supposed to ## Changelog 🆑 fix: fixes a bunch of improper static list declarations /🆑 |
||
tonty
|
3f0b4abb8d |
Replaces world.icon_size (and some magic numbers) with defines (#86819)
## About The Pull Request All usages of world.icon_size in code have been replaced with new `ICONSIZE_X`, `ICONSIZE_Y` and `ICONSIZE_ALL` defines depending on context Replaces some "32" magic numbers with the defines A few bits of code have been modified to split up x/y math as well ## Why It's Good For The Game Magic number bad, code more readable, code more flexible and I'm told there's an access cost to doing world.icon_size so minor performance gains ## Changelog 🆑 tonty code: made some code relating to the world's icon size more readable /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@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
|
||
|
LemonInTheDark
|
4b4e9dff1d |
Wallening [IDB IGNORE] [MDB IGNORE] (#85491)
## What's going on here Kept you waitin huh! This pr resprites most all walls, windows and other "wall adjacent" things to a 3/4th perspective, technical term is "tall" walls (we are very smart). If you're trying to understand the technical details here, much of the "rendering tech" is built off the idea of split-vis. Basically, split a sprite up and render it on adjacent turfs, to prevent seeing "through" walls/doors, and to support seeing "edges" without actually seeing the atom itself. Most of the rest of it is pipelining done to accommodate how icons are cut. ## Path To Merge Almost* all sprites and code is done at this point. There are some things missing both on and off the bounty list, but that will be the case forever unless we force upstream (you guys) to stop adding new shit that doesn't fit the style. I plan on accepting and integrating prs to the current working repo <https://github.com/wall-nerds/wallening> up until a merge, to make contribution simpler and allow things like bounties to close out more easily This pr is quite bulky, even stripping away map changes it's maybe 7000 LOC (We have a few maps that were modified with UpdatePaths, I am also tentatively pring our test map, for future use.) This may inhibit proper review, although that is part of why I am willing to make it despite my perfectionism. Apologies in advance. Due to the perspective shift, a lot of mapping work is going to need to be done at some point. This comes in varying levels of priority. Many wallmounts are offset by hand, some are stuck in the wall/basically cannot be placed on the east/west/north edges of walls (posters), some just don't look great good in their current position. Tests are currently a minor bit yorked, I thought it was more important to get this up then to clean them fully. ## What does it look like?       ## Credits <details> <summary>Historical Mumbojumbo</summary> I am gonna do my best to document how this project came to be. I am operating off third party info and half remembered details, so if I'm wrong please yell at me. This project started sometime in late 2020, as a product of Rohesie trying to integrate and make easier work from Mojave Sun (A recently defunct fallout server) with /tg/. Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man is insane) was working with tall walls, IE walls that are 48px tall instead of the normal 32. This was I THINK done based off a technical prototype from aao7 proving A it was possible and B it didn't look like dogwater. This alongside oranges begging the art team for 3/4th walls (he meant TGMC style) lead to Rohesie bringing on contributors from general /tg/, including actionninja who would eventually take over as technical lead and Kryson, who would define /tg/'s version of the artstyle. Much of the formative aspects of this project are their work. The project was coming along pretty well for a few months, but ran into serious technical issues with `SIDE_MAP`, a byond map_format that allows for simpler 3/4th rendering. Due to BULLSHIT I will not detail here, the map format caused issues both at random with flickering and heavily with multiz. Concurrent with this, action stepped down after hacking out the rendering tech and starting work on an icon cutter that would allow for simpler icon generation, leaving ninjanomnom to manage the project. Some time passed, and the project stalled out due to the technical issues. Eventually I built a test case for the issues we had with `SIDE_MAP` and convinced lummox jr (byond's developer) to explain how the fuckin thing actually worked. This understanding made the project theoretically possible, but did not resolve the problems with multi-z. Resolving those required a full rework of how rendering like, worked. I (alongside tattle) took over project development from ninjanomnom at this time, and started work on Plane Cube (#69115), which when finished would finally make the project technically feasible. The time between then and now has been slow, progressive work. Many many artists and technical folks have dumped their time into this (as you can see from the credits). I will get into this more below but I would like to explicitly thank (in no particular order) tattle, draco, arcanemusic, actionninja, imaginos, viro and kylerace for keeping the project alive in this time period. I would have curled up into a ball and died if I had to do this all myself, your help has been indispensable. </details> <details> <summary>Detailed Credits</summary> Deep apologies if I have forgotten someone (I am sure I have, if someone is you please contact me). I've done my best to collate from the git log/my memory. Thanks to (In no particular order): Raccoff: Being funny to bully, creating threshold decals for airlocks aa07: (I think) inspiring the project ActionNinja: Laying the technical rock we build off, supporting me despite byond trying to kill him, building the icon cutter that makes this possible ArcaneMusic: Artistic and technical work spanning from the project's start to literally today, being a constant of motivation and positivity. I can't list all the stuff he's done Armhulen: Key rendering work (he's the reason thindows render right), an upbeat personality and a kick in the ass. Love you arm Azlan: Damn cool sprites, consistently Ben10Omintrix: You know ben showed up just to make basic mobs work, he's just fuckin like that man BigBimmer: A large amount of bounty work, alongside just like, throwing shit around. An absolute joy to work with Capsandi: Plaques, blastdoors, artistic work early on CapybaraExtravagante: Rendering work on wall frames Draco: SO MUCH STUFF. Much of the spritework done over the past two years is his, constantly engaged and will take on anything. I would have given up if not for you Floyd: Early rendering work, so early I don't even know the details. Enjoy freedom brother Imaginos16: A guiding hand through the middle years, handled much of the sprite review and contribution for a good bit there Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of effort dissecting feedback with a focus on making things as good as they can be at the jump Infrared: Part of the impetus for the project, made all the xenomorph stuff in the MS style Jacquerel: A bunch of little upkeep/technical things, has done so much sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES) Justice12354: Solved a bunch of error sprites (and worked out how to actually make prs to the project) Thanks bro! Kryson: Built the artstyle of the project, carrying on for years even when it was technically dying, only stopping to casually beat cancer. So much of our style and art is Kryson KylerAce: Handled annoying technical stuff for me, built window frame logic and fully got rid of grilles. LemonInTheDark: Rendering dirtywork, project management and just so much fucking time in dreammaker editing sprites Meyhazah: Table buttons, brass windows and alll the old style doors Mothblocks: Has provided constant support, gave me a deadline and motivation, erased worries about "it not being done", gave just SO much money to fill in the critical holes in sprites. Thanks moth MTandi: Contributed art despite his own blackjack and hookers club opening right down the road, I'm sorry I rolled over some of your sprites man I wish we had finished earlier Ninjanomnomnom: Consulted on gags issues, kept things alive through some truly shit times oranges: This is his fault Rohesie: Organized the effort, did much of the initial like, proof of concept stuff. I hope you're doin well whatever you're up to. san7890: Consulting on mapper UX/design problems, being my pet mapper Senefi: Offsetting items with a focus on detail/the more unused canidates SimplyLogan: Detailed map work and mapper feedback, personally very kind even if we end up talking past each other sometimes. Thank you! SpaceSmithers: Just like, random mapping support out of nowhere, and bein a straight up cool dude Tattle: A bunch of misc project management stuff, organizing the discord, managing the test server, dealing with all the mapping bullshit for me, being my backup in case of bus. I know you think you didn't do much but your presence and work have been a great help Thunder12345: Came out of nowhere and just so much of the random bounties, I'm kind of upset about how much we paid him Time-Green: I hooked him in by fucking with stuff he made and now he's just doin shit, thanks for helping out man! Twaticus: Provided artistic feedback and authority for my poor feeble coder brain, believed in the project for YEARS, was a constant source of ❤️ and affirmation unit0016: I have no god damn idea who she is, popped out of nowhere on the github one day and dealt with a bunch of annoying rendering/refactoring. Godspeed random furry thank you for all your effort and issue reports Viro: A bunch of detailed spriting moving towards 3/4ths, both on and off the wallening fork. If anyone believed this project would be done, it was viro Wallem: Artistic review and consultation, was my go-to guy for a long time when the other two spritetainers were inactive Waltermeldon: Cracked out a bunch of rendering work, he's the reason windows look like not dogwater. Alongside floyd and action spent a TON of time speaking to lummox/unearthing how byond rendering worked trying to make this thing happen ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin bugaboo that was living in my brain like it was nothing. Love you brother And finally: The Mojave Sun development team. They provided a testbed for the idea, committed hundreds and hundreds of hours to the artstyle, and were a large reason we caught issues early enough to meaningfully deal with them. Your work is a testament to what longterm effort and deep detailed care produce. I hope you're doing well whatever you're up to. Go out with a bang! </details> ## Changelog 🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan, Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd, Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson, KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom, oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner, SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016, Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team! add: Resprites or offsets almost all "tall" objects in the game to match a 3/4ths perspective add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: = <stewartareid@outlook.com> Co-authored-by: Capsandi <dansullycc@gmail.com> Co-authored-by: ArcaneMusic <hero12290@aol.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com> Co-authored-by: KylerAce <kylerlumpkin1@gmail.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com> Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com> Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com> Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com> Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> Co-authored-by: Rob Bailey <github@criticalaction.net> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
Jackriip
|
4d36dfc2ff |
localizes create_all_lighting_objects (#85135)
## About The Pull Request Moves create_all_lighting_objects to the only thing that uses it - the lighting subsystem I saw zero difference in lighting system init time ## Why It's Good For The Game Reduces global proc pollution and keeps everything in the same place, improving code readability ## Changelog 🆑 refactor: moves the create_all_lighting_objects proc to the lighting subsystem /🆑 |
||
Kocma-san
|
d1799dc6b5 |
Fixed lights stopping emitting light in some situations (#84299)
## About The Pull Request closes #77789 edt: also closes #82600 Light sources stop emitting light if the tile in which the light source itself is located and all 4 adjacent tile block the light. This usually happens when a smoke grenade is thrown, or something went wrong in the chemistry again <details> <summary>Videos</summary> As it was before https://github.com/tgstation/tgstation/assets/112967882/44ff556b-d09f-4024-945e-c2c105f511a9 Now https://github.com/tgstation/tgstation/assets/112967882/9f9f8f43-47a9-47be-8499-99bab39fc166 </details> ## Why It's Good For The Game You wont need to switch the lights twice to make them work after someone threw smoke grenades into the hallways anymore ## Changelog 🆑 fix: Fixed lights stopping emitting light in some situations /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
wixoa
|
1a10197544 |
Remove 2 instances of duplicate argument names (#81757)
## About The Pull Request I fixed 2 instances of procs having multiple arguments with the same name. BYOND does not error on these, instead ignoring all but the last. It's best to remove these for clarity. ## Why It's Good For The Game N/A --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
LemonInTheDark
|
70651816c2 |
Fixes complex lights not handling moving well, renames lighting defines (#81423)
## About The Pull Request [Fixes static lights not moving]( |
||
Kyle Spier-Swenson
|
8703eac50d |
split area.contained_turfs up by zlevel, make init 10 seconds faster (#80941)
## About The Pull Request Situation: areas have a list of all turfs in their area. Problem: `/area/space` is an area and has a 6 to 7 digit count of turfs that has to be traversed for every turf we need to remove from it. This can take multiple byond ticks just to preform this action for a single space rune Solution: split the list by zlevel, and only search the right zlevel list when removing turfs from areas. replaces `area.get_contained_turfs()` with a few new procs: * `get_highest_zlevel()` - returns the highest zlevel the area contains turfs in. useful for use with `get_turfs_by_zlevel` * `get_turfs_by_zlevel(zlevel)` - returns a list of turfs in the area in a given zlevel. Useful for code that only cares about a specific zlevel or changes behavior based on zlevel like lighting init. * `get_turfs_from_all_zlevels()` - the replacement for `get_contained_turfs()`, renamed as such so anybody copying/cargo culting code gets a hint that a zlevel specific version might exist. Still used in for loops that type checked so byond would do that all at once * `get_zlevel_turf_lists()` - returns the area's zlevel lists of lists but only for non-empty zlevels. very useful for for loops. The area contents unit test has been rewritten to ensure any improper data triggers failures or runtimes by not having it use the helpers above (some of which ensure a list is always returned) and access the lists directly. |
||
|
LemonInTheDark
|
a823708054 |
Adds lighting height control (space color consistency) (#79046)
## About The Pull Request Adds support for modifying a light's "height" You can think of this as the distance it is from the ground below it (Really it's the distance to the corners around it + 0.5 but yaknow) We use it to keep wall lights from looking weird, but well, not everything is a wall light Floors tend to not be, and space in particular does not want to be treated as such. In fact, it wants a NEGATIVE height, so it acts as if it in on top of all of its corners. This allows us to ensure that the starlight from space and the starlight from starlight overlays always have the same intensity and color, preventing weird lines from where the two intersect, or starlight feeling not very present in cases with only one turf I've also bumped starlight's intensity form 0.75 to 1, this should help with the lines thing discussed above. ## Why It's Good For The Game  ## Changelog 🆑 add: Starlight should be a bit more intense, and flow better onto non space tiles /🆑 --------- Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: san7890 <the@san7890.com> |
||
|
LemonInTheDark
|
b77fa8c2a2 |
Starlight Control (Aurora works now, space gas doesn't touch starlight, narsie ending effects) (#78877)
## About The Pull Request [Implements a setter for starlight variables]( |
||
Time-Green
|
42543ac141 |
NEW STATION TRAIT: Radioactive Nebula (#76825)
## About The Pull Request Adds a new station trait: Radioactive Nebula! The station is located inside a radioactive nebula. Space background and lighting is different shades of green. Objects in space will also glow green. (This is kinda lying, since the glowing stuff isn't radioactive, you just get an element that slowly irradiates you, though people and certain objects that get the 'IRRADIATED' status may still double-whammy you) Do not go into space without rad-protected gear, or you will get very sick very fast. RAD-protection MODsuit modules spawn in robotics and are also immediately researched. The nebula does protect against external threats, like pirates, ninja's and nukies. They can still get to the station pretty well, but they can't stay in space for extended periods of time To make it more livable, public rad protection gear will spawn in lockers around the station. Everyone will also spawn with potassium iodide pills in their emergency box. Dynamics threat is also reduced by 30, so there's a proclivity towards more lower threat rounds when the radioactive nebula is present. Radioactive resonance virus cannot be generated though, since it kinda obliterates any and all challenge and threat  **Shielding**  In order to protect the station from radiation, nebula shielding units need to be constructed. Five spawn ready-to-built in engineering, and more can be bought pretty cheap from cargo. (Normal radstorms are disabled) The gravity generator has 20 minutes of innate shielding, where every nebula shielding unit adds another 20 minutes. 5 are needed to completely block all radiation even when the gravity gen is down, but constructing more is recommended in-case of sabotage/destructions/power outtages. Active nebula shielding will passively generate tritium. You can either vent/ignore this, or use it for something. I'm not an atmos tech but I'm sure you can do something with it _What happens when no shielding units are constructed/they all fail?_ The station will suffer a 5 minute long radiation storm, with only shuttles being excempt. The storm is nerfed strongly, and you can tank the 5 minutes, but you'll be pretty sick. After the 5 minutes are over, central command will send an emergency shielding unit which will block the radiation for 10 minutes and warn the station to set up nebula shielding. ## Why It's Good For The Game The station being inside a radioactive nebula shakes up a pretty major aspect of the game (that being the 'space' in space station 13). Hallway decals are colored green, display screens will display radiation markings, carps blend with the nebula, etc. Putting the station inside a radioactive nebula shakes up the rules of the game and what people can expect. Suddenly, you can no longer just go outside without taking meds or getting proper radiation protection, encouraging people to stay cozy and inside.  Inside, the crew gets the goal to set-up radiation shielding to defend themselves against the nebula, rewarding a creative engineering department with passive resource income and protecting the station against massive radiation storms. I think it's nice to give engineering something to set up. Even if they don't care, they can just plop it down somewhere in a closed room and be done with it. The radiation storm is pretty aggressive, but very survivable if you use your potassium iodide pills, the extra radiation suits or whatever chemistry has whipped up. Most importantly, it gives the entire station a common enemy: the nebula. Everyone is encouraged to prepare against the mechanics. Chemistry can make meds, viro can make protective virusses, robotics gets encouraged to make radprotected MODsuits, engineering gets to set-up radiation shielding, assistants can look at space or whatever assistants do. <details> <summary>Cool images</summary>     </details> ## Changelog 🆑 add: Adds a new rare radioactive nebula station trait! Get ready and PREPARE, before it gets in... tweak: Nearstation space area lighting may look slightly different /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
LemonInTheDark
|
41f20bc3ce |
[MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request Hello friends, I've been on a bit of a lighting kick recently, and I decided I clearly do not have enough things to work on as it is. This pr adds angle support to static lights, and a concepting/debug tool for playing with lights on a map. Let's start from first principles yeah? ### Why Angled Lights? Mappers, since they can't actually see a light's effect in editor, tend to go off gut. That gut is based more off what "makes sense" then how things actually work This means they'll overplace light sources, and also they tend to treat lights, particularly light "bars" (the bigger ones) as directional. So you'll have two lights on either sides of a pillar, lights inside a room with lights outside pointing out, etc.  This has annoying side effects. A lot of our map is overlit, to the point that knocking out a light does.... pretty much nothing. I find this sad, and would like to work to prevent it. I think dark and dim, while it does not suit the normal game, is amazing for vibes, and I want it to be easier to see that. Angled lights bring how lights work more in line with how mappers expect lights work, and avoids bleedover into rooms that shouldn't be bled into, working towards that goal of mine. ### How Angled Lights? This is more complex then you'd first think so we'll go step by step  Oh before we start, some catchup from the last time I touched lighting code. Instead of doing a lighting falloff calculation for each lighting corner (a block that represents the resolution of our lights) in view we instead generate cached lightsheets. These precalculate and store all possible falloffs for x and y distances from a source. This is very useful for angle work, since it makes it almost totally free. Atoms get 2 new values. light_angle and light_dir Light angle is the angle the light uses, and light_dir is a cardinal direction it displays in We take these values, and inside sheetbuilding do some optional angle work. getting the center angle, the angle of a pair of coords, and then the delta between them. This is then multiplied against the standard falloff formula, and job done. We do need some extra fenangling to make this all work nicely tho. We currently use a pixel turf var stored on the light source to do distance calculations. This is the turf we pretend the light source is on for visuals, most often used to make wall lights work nice. The trouble is it's not very granular, and doesn't always have the effect you might want. So, instead of generating and storing a pixel turf to do our distance calculations against, we store x and y offset variables. We use them to expand our working range and sheet size to ensure things visually make sense, and then offset any positions by them. I've added a way for sources to have opinions on their offsets too, and am using them for wall lights. This ensures the angle calculations don't make the wall behind a light fulldark, which would be silly. ### Debug Tool? In the interest of helping with that core problem, lights being complex to display, I've added a prototyping tool to the game. It's locked behind mapping verbs, and works about like this. Once the verb is activated, it iterates over all the sources in the world (except turfs because those are kinda silly), outlining and "freezing" them, preventing any future changes. Then, it adds 3 buttons to the owners of a light source.  The first button toggles the light on and off, as desired. The third allows you to move the source around, with a little targeting icon replacing your mouse The second tho, that's more interesting. The second button opens a debug menu for that light  There's a lot here, let's go through it. Bit on the left is a list of templates, which allow you to sample existing light types (No I have no idea why the background is fullwhite, need to work on that pre merge) You can choose one by clicking it, and hitting the upload button. This replaces your existing lighting values with the template's, alongside replacing its icon and icon state so it looks right. There are three types as of now, mostly for categorization. Bar, which are the larger typically stronger lights, Bulb, which are well, bulbs, and Misc which could be expanded, but currently just contains floor lights. Alongside that you can manually edit the power, range, color and angle of the focused light. I also have support for changing the direction of the light source, since anything that uses directional lighting would also tie light dir to it. This isn't *always* done tho, so I should maybe find a way to edit light dir too. My hope is this tool will allow for better concepting of a room's lights, and easier changing of individual object's light values to suit the right visuals. ### Lemon No Why What Ok so I applied angle lights to bars and bulbs, which means I am changing the lighting of pretty much every map in the codebase. I'm gonna uh, go check my work. Alongside this I intend to give lighting some depth. So if there's room to make a space warmer, or highlight light colors from other sources, I will do that. (Images as examples)  I also want to work on that other goal of mine, making breaking lights matter. So I'll be doing what I can to ensure you only need to break one light to make a meaningful change in the scene. This is semi complicated by one light source not ever actually reaching fullbright on its own, but we do what we must because we can.  I'm as I hope you know biased towards darker spaces, I think contrast has vibes. In particular I do not think strong lights really suit maintenance. Most of what is used there are bulbs, so I'm planning on replacing most uses with low power bulbs, to keep light impacts to rooms, alongside reducing the amount of lights placed in the main tunnels  **If you take issue with this methodology please do so NOW**, I don't want to have to do another pass over things. Oh also I'm saving station maps for last since ruins are less likely to get touched in mapping march and all. ### Misc + Finishing Thoughts Light templates support mirroring vars off typepaths using a subtype, which means all the templates added here do not require updating if the source type changes somehow. I'd like to expand the template list at some point, perhaps in future. I've opened this as a draft to make my intentions to make my changes to lights known, and to serve as motivation for all the map changes I need to do. ### Farish Future I'm unhappy with how we currently configure lights. I would like a system that more directly matches the idea of drawing falloff curves, along with allowing for different falloffs for different colors, alongside extending the idea to angle falloff. This would make out of engine lighting easier, allow for nicer looking lights (red to pink, blue to purple, etc), and improve accessibility by artists. This is slightly far off, because I have other obligations and it's kinda complicated, but I'd like to mention it cause it's one of my many pipedreams. ## Changelog 🆑 add: Added angle lighting, applies it to most wall lights! add: Adds a lighting prototyping tool, mappers go try it out (it's locked behind the mapping verb) /🆑 --------- Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
LemonInTheDark
|
4d1e34322f |
Macros multi-z code, removes the false premise of manual offsets (#76248)
## About The Pull Request [Removes the pretense of relative multiz levels]( |
||
ChungusGamer666
|
b9b19bd6e1 |
Lighting object oddities (#76009)
## About The Pull Request Fire stacks status effect no longer uses a weakref for the mob light, I am pretty sure there was no real reason to use a weakref there. Deleted weird luminescent glow dummy, now it just uses the standard moblight obj. Put all /obj/effect/dummy/lighting_obj together in a single file and added a comment explaining why they exist. (I severely dislike the /obj/effect/dummy typepath, but I am very much unsure if just replacing all of them with /obj/effect/abstract would break shit) ## Why It's Good For The Game Code organization good |
||
SyncIt21
|
cd4ed228f2 |
Fix out of bounds in lighting subsystem (#75018)
## About The Pull Request Fixes #74697 Look at this for loop |
||
|
SyncIt21
|
42d8836d95 |
Flood lights update their color when spray painted (#74926)
## About The Pull Request Fixes #74921 All colourful & stuff https://user-images.githubusercontent.com/110812394/233796341-cbdd5be1-7483-4d8d-b4ef-2b5a02bed6fa.mp4 ## Changelog 🆑 fix: flood light now shines with their object color /🆑 --------- Co-authored-by: san7890 <the@san7890.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
|
8982828d05 |
Removes Starlight Config (#74289)
## About The Pull Request It was config'd off to save init time, but having it function in testing and mapping is more valuble then the time spend on it. On that topic, we spend roughly 1.7 seconds of init on this. ~1.3 is spent handling the light sources and their light object modifications (this is potentailly inflated since other sources could cause the same objects to need updates) ~0.3 is spent searching for space turfs around lighting_objects during init. This will impact change_turf slightly too, costing about ~0.07 in local testing. It does save time for live however, since we avoid these config checks. ## Why It's Good For The Game I believe this time is worth spending. I've had people try to "fix" artifacts of starlight not being enabled, things that aren't bugs. The test environment should as much as we can make it reflect the visual reality of the game. This helps ensure that ## Changelog 🆑 server: The starlight config has been removed, as it is enabled by default /🆑 |
||
|
LemonInTheDark
|
069bd12e26 |
Fixes the labor claim console not properly linking in shuttle loads (#73590)
## About The Pull Request
Caused by
|
||
|
LemonInTheDark
|
a2295b2b04 |
Lighting source refactor (Tiny) (#73284)
## About The Pull Request I'm doing two things here. Let's get the boring bit out of the way. Lighting source updates do three distinct things, and those things were all in one proc. I've split that one proc into three, with the first two feeding into the third. Second, more interesting thing. An annoying aspect of our lighting system is the math we use for calculating luminosity is hardcoded. This means that we can't have subtypes that are angled, or that have squared falloff, etc. All has to look the same. This sucks, and it shows. It has to be, goes the thinking, because we need very fast lookups that OOP cannot provide. We can't bog down the main equation with fluff, because the main equation needs to be really speedy. The thing about this equation is the only variants on a turf to turf basis is exactly how far turfs are from the center. So what if, instead of doing the math in our corner worker loop, we build lookup tables to match our current source's state. The tables, like a heatmap, could encode the lighting of any point along the line. This is actually faster then doing the math each time, because the list generation can be cached. It also means we've pulled the part we want to override out of hotcode. It's cheap to override now, and a complex subtype, with angles and such would have no impact on the typical usage. So the code's faster, easier to read, and more extensible. And we can do stuff like squared falloff for some lights in future without breaking others. Winning! ## Why It's Good For The Game Winning |
||
|
LemonInTheDark
|
f88edef0fb |
Space/Changeturf fixes and optimizations (#73261)
## About The Pull Request We've got a few space related things that are busted, and shuttle movement is slow. I'd like to try to improve these things, if just a bit. Long list of only tenuously related topics. Sorry for the shotgun blast #### [Fixes lazyloaded stuff having bad space]( |
||
|
LemonInTheDark
|
e9c87c0acb |
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> |
||
|
ChungusGamer666
|
a2479cb48e |
Static light sources will attempt to follow the top atom (#72148)
## About The Pull Request Fixes https://github.com/tgstation/tgstation/issues/71826 Probably fixes some other issue related to lighting but i didn't find any ## Why It's Good For The Game Look, i know it's called STATIC lighting for a reason, and movement on it should be kept to a minimum, but this at least ensure that static lighting being carried around, if that happens for some reason, updates properly. ## Changelog 🆑 fix: Static light sources update properly now when carried by a mob. /🆑 |
||
|
LemonInTheDark
|
9e69e5d6ac |
Minor plane cube cleanup (#72038)
## About The Pull Request [Fixes area lighting not working on turf change in multiz cases]( |
||
AnturK
|
84f69359a0 |
More horrible 515 proc compatibility. (#71333)
So i left over some basic `/whatever/proc/format` uses in the original PR this fixes it. Notable exceptions to the rule: - Paths in add_verb/remove_verb, we need full path instead of a name there to access verb metadata so we can't use proc ref macros there. - regex.Replace, found out that it does not accept call by name. Instead i added new REGEX_REPLACE_HANDLER so we can at least try to mark these. There's still leftover global procs that do not use GLOBAL_PROC_REF but they functionally equivalent so that's for later. I don't see any reasonable way to grep for this. But if you got any ideas please share. |
||
|
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>
|
||
|
LemonInTheDark
|
5b4ba051a0 |
Builds logic that manages turfs contained inside an area (#70966)
## About The Pull Request Area contents isn't a real list, instead it involves filtering everything in world This is slow, and something we should have better support for. So instead, lets manage a list of turfs inside our area. This is simple, since we already move turfs by area contents anyway This should speed up the uses I've found, and opens us up to using this pattern more often, which should make dev work easier. By nature this is a tad fragile, so I've added a unit test to double check my work Rather then instantly removing turfs from the contained_turfs list, we enter them into a list of turfs to pull out, later. Then we just use a getter for contained_turfs rather then a var read This means we don't need to generate a lot of usage off removing turf by turf from space, and can instead do it only when we need to I've added a subsystem to manage this process as well, to ensure we don't get any out of memory errors. It goes entry by entry, ensuring we get no overtime. This allows me to keep things like space clean, while keeping high amounts of usage on a sepearate subsystem when convienient As a part of this goal of keeping space's churn as low as possible, I've setup code to ensure we do not add turfs to areas during a z level increment adjacent mapload. this saves a LOT of time, but is a tad messy I've expanded where we use contained_turfs, including into some cases that filter for objects in areas. need to see if this is sane or not. Builds sortedAreas on demand, caching until we mark the cache as violated It's faster, and it also has the same behavior I'm not posting speed changes cause frankly they're gonna be a bit scattered and I'm scared to. @Mothblocks if you'd like I can look into it. I think it'll pay for itself just off `reg_in_areas_in_z` (I looked into it. it's really hard to tell, sometimes it's a bit slower (0.7), sometimes it's 2 seconds (0.5 if you use the old master figure) faster. life is pain.) ## Why It's Good For The Game Less stupid, more flexible, more speed Co-authored-by: san7890 <the@san7890.com> |
||
GoblinBackwards
|
2c544a1959 |
Fixes compile error in lighting code when testing mode is enabled (#70550)
* Fixes compile error in lighting code when compiling with testing mode enabled, because it was using a var that wasn't yet defined. |
||
|
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 |
||
|
LemonInTheDark
|
e5a2b0f16e |
Micros the lighting subsystem (Saves a second of init) (#69838)
About The Pull Request Micros lighting objects, and their creation We save a good bit of time by not walking space turfs adjacent to new objects. We also save some time with micros in the actual underlay update logic. I swear dude we spend like 0.8 seconds of init applying the underlay. I want threaded maptick already Micros lighting sources, and corner creation A: Corners were being passed just A turf, and then expected to generatecorners based on that. This is pointless. It is better to instead pass in the coords of the bottom left turf, and then build in a circle. This saves like 0.3 seconds B: We use so many damn datum vars in corner application that we just do not need to. This resolves that, since it pissed me off. It's pointless. Lets cache em instead There's some misc datum var caching going on here too. Lemme see... Oh and a bit of shortcutting for a for loop, since it was a tad expensive on its own. Also I removed the turfs list, because it does fucking nothing. Why is this still here. All my little optimizations save about 1 second of init I think Not great, but not bad, and plus actual lighting work is faster now too Why It's Good For The Game Speed |
||
|
LemonInTheDark
|
b01356b80d |
Removes 1.4 seconds from game init on LOWMEMORYMODE (#69455)
We were spending 1.4 seconds on doing an add_overlay on EVERY turf in /area/space There's no fukin reason to do this, you CAN JUST ADD OVERLAYS TO AREAS IT WAS POINTLESS. I HATE IT HERE |
||
Kylerace
|
fe7513d282 | addresses reviews on the tram pr made after merge, fixes diagonal movement bugs (#68033) | ||
|
Kylerace
|
8f0df7816b |
(code bounty) The tram is now unstoppably powerful. it cannot be stopped, it cannot be slowed, it cannot be reasoned with. YOU HAVE NO IDEA HOW READY YOU ARE (#66657)
ever see the tram take 10 milliseconds per movement to move 2100 objects? now you have https://user-images.githubusercontent.com/15794172/166198184-8bab93bd-f584-4269-9ed1-6aee746f8f3c.mp4 About The Pull Request fixes #66887 done for the code bounty posted by @MMMiracles to optimize the tram so that it can be sped up. the tram is now twice as fast, firing every tick instead of every 2 ticks. and is now around 10x cheaper to move. also adds support for multiz trams, as in trams that span multiple z levels. the tram on master takes around 10-15 milliseconds per movement with nothing on it other than its starting contents. why is this? because the tram is the canary in the coal mines when it comes to movement code, which is normally expensive as fuck. the tram does way more work than it needs to, and even finds new ways to slow the game down. I'll walk you through a few of the dumber things the tram currently does and how i fixed them. the tram, at absolute minimum, has to move 55 separate industrial_lift platforms once per movement. this means that the tram has to unregister its entered/exited signals 55 times when "the tram" as a singular object is only entering 5 new turfs and exiting 5 old turfs every movement, this means that each of the 55 platforms calculates their own destination turfs and checks their contents every movement. The biggest single optimization in this pr was that I made the tram into a single 5x11 multitile object and made it only do entering/exiting checks on the 5 new and 5 old turfs in each movement. way too many of the default tram contents are expensive to move for something that has to move a lot. fun fact, did you know that the walls on the tram have opacity? do you know what opacity does for movables? it makes them recalculate static lighting every time they move. did you know that the tram, this entire time, was taking JUST as much time spamming SSlighting updates as it was spending time in SStramprocess? well it is! now it doesnt do that, the walls are transparent. also, every window and every grille on the tram had the atmos_sensitive element applied to them which then added connect_loc to them, causing them to update signals every movement. that is also dumb and i got rid of that with snowflake overrides. Now we must take care to not add things that sneakily register to Moved() or the moved signal to the roundstart tram, because that is dumb, and the relative utility of simulating objects that should normally shatter due to heat and conduct heat from the atmosphere is far less than the cost of moving them, for this one object. all tram contents physically Entered() and Exited() their destination and old turfs every movement, even though because they are on a tram they literally do not interact with the turf, the tram does. also, any objects that use connect_loc or connect_loc behalf that are on the same point on the tram also interact with each other because of this. now all contents of the tram act as if theyre being abstract_move()'d to their destination so that (almost) nothing thats in the destination turf or the exit turf can react to the event of "something laying on the tram is moving over you". the rare things that DO need to know what is physically entering or exiting their turf regardless of whether theyre interacting with the ground can register to the abstract entered and exited signals which are now always sent. many of the things hooked into Moved(), whether it be overrides of Moved() itself, or handlers for the moved signal, add up to a LOT of processing time. especially for humans. now ive gotten rid of a lot of it, mostly for the tram but also for normal movement. i made footsteps (a significant portion of human movement cost) not do any work if the human themselves didnt do the movement. i optimized has_gravity() a fair amount, and then realized that since everything on the tram isnt changing momentum, i didnt actually need to check gravity for the purposes of drifting (newtonian_move() was taking a significant portion of the cost of movement at some points along the development process). so now it simply doesnt call newtonian_move() for movements that dont represent a change in momentum (by default all movements do). also i put effort into 1. better organizing tram/lift code so that most of it is inside of a dedicated modules folder instead of scattered around 5 generic folders and 2. moved a lot of behavior from lift platforms themselves into their lift_master_datum since ideally the platforms would just handle moving themselves, while any behavior involving the entire lift such as "move to destination" and "blow up" would be handled by the lift_master_datum. also https://user-images.githubusercontent.com/15794172/166220129-ff2ea344-442f-4e3e-94f0-ec58ab438563.mp4 multiz tram (this just adds the capability to map it like this, no tram does this) Actual Performance Differences to benchmark this, i added a world.Profile(PROFILER_START) and world.Profile(PROFILER_START) to the tram moving, so that it generates a profiler output of all tram movement without any unrelated procs being recorded (except for world.Profile() overhead). this made it a lot easier to quantify what was slowing down both the tram and movement in general. and i did 3 types of tests on both master and my branch. also i should note that i sped up the "master" tram test to move once per tick as well, simply because the normal movement speed seems unbearably slow now. so all recorded videos are done at twice the speed of the real tram on master. this doesnt affect the main thing i was trying to measure: cost for each movement. the first test was the base tram, containing only my player mob and the movables starting on the tram roundstart. on master, this takes around 13 milliseconds or so on my computer (which is pretty close to what it takes on the servers), on this branch, it takes between 0.9-1.3 milliseconds. ALSO in these benchmarks youll see that tram/proc/travel() will vary significantly between the master and optimized branches. this is 100% because there are 55 times more platforms moving on master compared to the master branch, and thus 55x more calls to this proc. every test was recorded with the exact same amount of distance moved here are the master and optimized benchmark text files: master master base tram.txt https://user-images.githubusercontent.com/15794172/166210149-f118683d-6f6d-4dfb-b9e4-14f17b26aad8.mp4 also this shows the increased SSlighting usage resulting from the tram on master spamming updates, which doesnt happen on the optimized branch optimized optimization base tram.txt https://user-images.githubusercontent.com/15794172/166206280-cd849aaa-ed3b-4e2f-b741-b8a5726091a9.mp4 the second test is meant to benchmark the best case scaling cost of moving objects, where nothing extra is registered to movement besides the bare minimum stuff on the /atom/movable level. Each of the open tiles of the tram had 1 bluespace rped filled with parts dumped onto it, to the point that the tram in total was moving 2100 objects. the vast majority of these objects did nothing special in movement so they serve as a good base case. only slightly off due to the rped's registering to movement. on master, this test takes over 100 milliseconds per movement master 2000 obj's.txt https://user-images.githubusercontent.com/15794172/166210560-f4de620d-7dc6-4dbd-8b61-4a48149af707.mp4 when optimized, about 10 milliseconds per movement https://user-images.githubusercontent.com/15794172/166208654-bc10086b-bbfc-49fa-9987-d7558109cc1d.mp4 optimization 2000 obj's.txt the third test is 300 humans spawned onto the tram, meant to test all the shit added on to movement cost for humans/carbons. in retrospect this test is actually way too biased in favor of my optimizations since the humans are all in only 3 tiles, so all 100 humans on a tile are reacting to the other 99 humans movements, which wouldnt be as bad if they were distributed across 20 tiles like in the second test. so dont read into this one too hard. on master, this test takes 200 milliseconds master 300 catgirls.txt when optimized, this takes about 13-14 milliseconds. optimization 300 catgirls on ram ranch.txt Why It's Good For The Game the tram is literally 10x cheaper to move. and the code is better organized. currently on master the tram is as fast as running speed, meaning it has no real relative utility compared to just running the tracks (except for the added safety of not having to risk being ran over by the tram). now the tram of which we have an entire map based around can be used to its full potential. also, has some fixes to things on the tram reacting to movement. for example on master if you are standing on a tram tile that contains a banana and the TRAM moves, you will slip if the banana was in that spot before you (not if you were there first however). this is because the banana has no concept of relative movement, you and it are in the same reference frame but the banana, which failed highschool physics, believes you to have moved onto it and thus subjected you to the humiliation of an unjust slipping. now since tram contents that dont register to abstract entered/exited cannot know about other tram contents on the same tile during a movement, this cannot happen. also, you no longer make footstep sounds when the tram moves you over a floor TODO mainly opened it now so i can create a stopping point and attend to my other now staling prs, we're at a state of functionality far enough to start testmerging it anyways. add a better way for admins to be notified of the tram overloading the server if someone purposefully stuffs it with as much shit as they can, and for admins to clear said shit. automatically slow down the tram if SStramprocess takes over like, 10 milliseconds complete. the tram still cant really check tick and yield without introducing logic holes, so making sure it doesnt take half of the tick every tick is important go over my code to catch dumb shit i forgot about, there always is for these kinds of refactors because im very messy remove the area based forced_gravity optimization its not worth figuring out why it doesnt work fix the inevitable merge conflict with master lol create an icon for the tram_tunnel area type i made so that objects on the tram dont have to enter and exit areas twice in a cross-station traversal add an easy way to vv tram lethality for mobs/things being hit by it. its an easy target in another thing i already wanted to do: a reinforced concept of shared variables from any particular tram platform and the entire tram itself. admins should be able to slow down the tram by vv'ing one platform and have it apply to the entire tram for example. Changelog cl balance: the tram is now twice as fast, pray it doesnt get any faster (it cant without raising world fps) performance: the tram is now about 10 times cheaper to move for the server add: mappers can now create trams with multiple z levels code: industrial_lift's now have more of their behavior pertaining to "the entire lift" being handled by their lift_master_datum as opposed to belonging to a random platform on the lift. /cl |
||
|
LemonInTheDark
|
a6d4e180ad |
Adds a visualizer for lighting object updating. Optimizes the same (#67678)
It occured to me, we didn't have a good way to "see" what turfs were actually being updated Figured I'd fix that I've also added some debug vars on SSlighting to make testing with/without some checks easier Speaking of which, I've added a second check to lighting corner updating Basically, if our past and current cached rgb values are the same, there's no point updating This is possible because static lighting is relative. If you've got a TON of blue, it'll outweight the red and green you have in smaller amounts We also do some rounding to ensure values look right Similarly, if you've got roughly the same lighting, and a bit of something you already have a lot of is added, you're not likely to actually enter a new "bracket" of color Anyway uh, it's hard to profile this, but I've seen it help quite a bit, mostly with things like emergency lighting that updates lighting in small amounts often, and in constricted spaces. To some extent just comes down to map design |
||
ShizCalev
|
a85d7c6974 |
Cleans up some varedit procs not using strings instead of the proper helper (#65769)
Although these vars are unlikely to ever change, if the vars were ever renamed it would result in these strings not erroring properly if they weren't updated as well. |
||
Seth Scherer
|
868b4cb316 |
Renames the change_area proc to be more accurate (#65758)
|
||
AffectedArc07
|
0d9a49503a | Fixes bugged lighting overlays on dark tiles (#63171) | ||
John Willard
|
88d7dbfc10 |
removes double spaces before symbols (#62397)
This can apparently cause some bugs on occasions, so I thought I might as well try to kill them all. |
||
Wayland-Smithy
|
56529dea50 | Fix base lighting appearance inheritance (#62042) | ||
TiviPlus
|
e060c7eedc | fix lighting (#61530) | ||
|
TiviPlus
|
519a15032e | Default Baselighting to white (#61544) | ||
Timberpoes
|
cbc6f35f54 |
Things that love the station may no longer leave the station, even when Dr. Anomaly says they should. (#61335)
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. |
||
|
TiviPlus
|
7dff58205c |
var/static_lighting proper varedit support (#61164)
per title it creates/destroys the lighting objects now |
||
TemporalOroboros
|
a71327e028 |
Reduces copypasta in emissive code (#61249)
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. |
||
|
TiviPlus
|
e629c36feb | Refactor area and turf lighting (#60954) | ||
|
TiviPlus
|
efb04ce04e |
Only blend areas when it's actually needed (#60237)
* Only blend areas when it's actually needed * Respect varedits |
||
|
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 |
