mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-13 09:05:11 +01:00
observer_fix_tm
20 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
81427cd5cf |
Unit tests, refactor & realignment for map loaded wall mounts (#93662)
## About The Pull Request This 1st has to be PR'd so the integration tests can point out all wallmounts that could not find a support structure to mount on. I then will do many map edits to align them onto the closest atom Yes we no longer use wall mount but atom mounted component. All objects that are mounted on windows/tables & fences now also fall off when destroyed It'll probably be a WHILE before I can fix all wall mounts. Long day. Expect me to misalign many stuff to fix failing CI so make sure to provide suggestions when possible Improved wallmount code overall - Fixes #93793 ## Changelog 🆑 fix: fixes all incorrectly maploded wall mounts that aren't actually hanging on any support structure fix: objects mounted on tables, windows & fences also fall off now when destoryed qol: lights can be mounted on windows qol: cameras can be mounted on windows qol: buttons can be mounted on tables refactor: improved how wall mounts interact with objects as a whole report bugs on github /🆑 |
||
|
|
999bde8f84 |
Most screen alerts now fit the player's hud style. (#93493)
## About The Pull Request Most screen alerts that use the midnight hud style no longer have the button baked in their icon. Other screen alerts with their own background or shape (robot and mech alerts, atmos, heretic buffs or debuffs etc.) are not affected. Also updated a couple sprites but didn't spend too much time on them. Mostly reusing existing assets. Montage of how the alerts look on threee different hud styles (Operative, Trasen-Knox, Detective, ALSO I FIXED THE BUCKLED ALERT ALREADY): <img width="293" height="323" alt="image" src="https://github.com/user-attachments/assets/3a2b972b-aa5a-4c27-a454-c8c39acf6e20" /> It looks only a smidge iffy on the syndicate since the top and bottom borders aren't layered over all the overlays, but it isn't something to worry about in this PR. ## Why It's Good For The Game Screen alerts always had the midnight hud button baked in their icon states (now overlays), which completely disregard the player's hud setting, much unlike action alerts buttons. Melbert has also said that it'd be nice if the code for action buttons could also be used in screen alerts and viceversa, to slim things down. That's obviously not what I'm doing today, but having most of the screen alerts already without the baked background will surely help if we ever pursue that objective. ## Changelog 🆑 refactor: Refactored screen alerts a little. Most should now fit the player's hud style. Report any issue. imageadd: A few screen alerts have been polished/updated a little. /🆑 |
||
|
|
b48b717730 |
Fish analyzer UI is a bit more reactive, also fixing a couple things with fish reproduction (#93461)
## About The Pull Request The fish analyzer now uses ui_data to fetch hunger, health, size, weight and breeding cooldown rather than ui_static_data, meaning these values are updated in real time on the UI. It also calls update_static_data_for_all_viewers() whenever the user scans a new fish or aquarium or if fishes are added/removed to/from the aquarium, and closes the UI if the scanned object is out of normal view or further than 7 tiles away. I've also reduced the breeding cooldown for newly spawned fish from two times the standard cooldown (usually 2 minutes, hence 4 minutes) to 60% of it. Offsprings still retain the usual 200% cooldown however. This should make it a bit easier for people who want to use the aquarium with fish acquired through means other than fish farming itself. Lastly, this PR introduces a small unit test to make sure that the stable population of most fish is higher than 1. This was the problem with #93043, where you couldn't breed a slimefish with a lavaloop because the stable population of the latter wasn't set. I'm sure that's a problem with other fishes as well, and that explains some of the confusion with the feature (that and its opacity as a whole I guess). ## Why It's Good For The Game This will close #93043, improve the fish analyzer UI updates, make fish farming etc. less problematic. ## Changelog 🆑 qol: The fish analyzer UI should update more reliably. fix: Fixed some of the fishes being unable to reproduce. balance: Fish acquired through means other than fish farming itself takes less time to be able to reproduce. /🆑 |
||
|
|
aa4cf2b136 | The nullrod refactor (the carp-sie plushie is now actually a plushie) (#93311) | ||
|
|
4975174928 | [NO GBP] Adds unit test checks for materials and processable comp & co. (#92194) | ||
|
|
7c703fc712 |
Food types are now passed down when cooking from recipes. (#89706)
## About The Pull Request ~~I have some beef with the cooking system.~~ Cooking recipes are coded in a way that disregard the possibility for their components to have different foodtype flags than the ones you would find normally find. For example, if I wanted to make corned beef, but instead of a standard steak, I used a killer tomato "steak", the result would still have the meat food type, even if none of the components has it. I've had to resort to a few hacky lines of code to manipulate the food types from the edible component, but that can be easily fixed if #89687 is merged. ## Why It's Good For The Game This also makes cooking recipes less strict about their food types and can help us spot inconsistencies with recipes. ## Changelog 🆑 qol: Food types are now passed down when cooking from recipes. For example, a plate of corned "beef" made from giant killer tomato slabs no longer counts as meat but only vegetables now. fix: Fixed a metric ton of inconsistencies with food types and recipes. fix: Dank-pockets (the weed variant) can now be microwaved. /🆑 |
||
|
|
9b40e13f8b |
Makes dust animation look less 2006 (#87435)
## About The Pull Request This was inspired by an effect I saw on Paradise but I sprited my own https://github.com/user-attachments/assets/2130053c-a6ea-48e6-8b62-4c08563fd154 (Todo, make the skeleton appearing less jank) ## Why It's Good For The Game 1. Looks less 2006. 2. The dust sprite will reflect the mob being dusted, since it's literally just Your Sprite. Your clothes, species, etc. 3. All species and all mob types now animate being dusted - from corgi to xenos, from borgs to lizards -, and we can even reuse this effect for items being dusted if we so desire ## Changelog 🆑 Melbert image: The animation for being dusted now takes into account your sprite, rather than being a normal nude spaceman /🆑 |
||
|
|
cef009e7c6 |
Refactor special_step_sounds out of existence, Human steps now depend on leg type, Digitigrade legs use claw footstep sfx (#87006)
## About The Pull Request 1. Deletes `special_step_sounds`. Unused anyways. 2. Human footstep type is now determined by its legs. - This means a human with two different legs, with two different footstep types, now alternate between footstep type every other step. 3. Digitigrade legs now use claw footstep sfx ## Why It's Good For The Game Less random species vars, more dynamic human code, and a little bit more immersion ## Changelog 🆑 Melbert refactor: Refactored footsteps for humans. Human footstep sound effects are now determined by your leg type. Report any oddities. qol: Digitigrade legs now play claw footstep SFX. "plat plat" is dead, long live "tap tap". /🆑 |
||
|
|
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 /🆑 |
||
|
|
95b7fa1fb7 |
Add a unit test to check that maploaded simple/basic mobs are in an environment they can survive in. (#82180)
## About The Pull Request I've recently noticed that the maploaded penguins from the snowdin away mission were dying from unsafe atmos/temperature. This sparked the idea of making a (focus only) unit test that would prevent this sort of issues from happening. This PR also implements the usage of the `atmos_requirements` and `body_temp_sensitive` elements for simple animals too, cutting down the copypaste. ## Why It's Good For The Game More unit tests to make sure things are done correctly. ## Changelog 🆑 fix: Made sure that mapped critters (i.e. penguins on the snow cabin away mission) can survive in the environment they're spawned in. /🆑 |
||
|
|
5b793ee714 |
Actually fixing fishable contents for some sources. (#78030)
## About The Pull Request During my first fishing related PR, I hadn't yet know that for the `fish_counts` var to work, its contents also had to be within the `fish_table` list, thus I ended up adding stuff that's not actually fishable. Also there was no unit test to enforce that design, which is lame. ## Why It's Good For The Game Fixing the issues explained above. Basically #78019 but done right. ## Changelog 🆑 fix: You can now actually fish soggy wallets from toilets, rare ores on ice moon, some boney stuff in oil puddles (good luck finding them) and lube-fishes by the seawater. /🆑 |
||
|
|
cfc4e960bc |
Properly unreg's turf changed when space openspace is deleted (#76501)
## About The Pull Request Openspace tracks the turf below for starlight purposes The trouble is if a turf is replaced by another, all its signal registers still persist I forgot about this, so we'd get runtimes when a /turf/open/space/openspace was replaced, and the turf below it changed ## Why It's Good For The Game Less random runtimes |
||
|
|
d8058f1245 |
Datumizes out jobconfig.toml (extensibility edition) (#76102)
## About The Pull Request
Hey there,
#75992 (
|
||
|
|
6085e3b5ee |
Reagent soup / Soup rework / Stoves - A kitchen expansion (#74205)
## About The Pull Request  **This PR:** - Reworks most* existing soup into reagents. - Adds Stoves and Ranges. Ranges replace most* existing ovens. - Adds soup pots, to cook soup **How does it work?** In the kitchen you will find a stove now. Stoves act as a "reagent container heater", essentially a chem heater. You can set a pot onto the stove. To make soup, visit the cooking recipe book for a guide. Most recipes are the same as before, just tweaked slightly - Add water to the pot (50 units for 1 batch generally), then add all the corresponding ingredients to the pot. Set the pot out on the stove and right click it to turn it on. If the recipe's correct, shortly it will start to mix and give you soup! One soup recipe will give you roughly 3 servings of soup. You can pour our the soup into a bowl using a ladle or just by pouring it manually. Of note: **All of the reagent contents of the ingredient are transferred into the soup.** Better, more nutrient rich ingredients produces more soup, and poisoned produce will pass it on. If you place the soup into a chem master, you will notice it's roughly half "soup reagent" and half a variety of reagents, including nutriments / proteins. This is your soup! It is recommended you serve your soup with the reagents included, as they make up more nutrition for the customer, however you can separate it out if you're picky. **Todo:** - [x] Fill out the PR body a bit more - [x] Mapping (wait for big merge conflict pr to go past) - [x] Soup colors - [x] Balance pass over for soup recipes - [x] TODOs - [ ] Unit tests - [x] Cullen Skink's recipe is invalid - [x] Try to see if there's an easy way to prevent soup from fattening you up too easy. ## Why it's good for the game Adds some more depth to the kitchen and moves chef away from the click-button-get-food style that exists. Allows for inherently custom soups by the way of making it reagents, so no need to support custom soup food items. ## Changelog 🆑 Melbert, stove and pot sprites by Kryson, ladle sprite by Kinneb add: Kitchens are now stocked with Ranges. add: You can now print (and create) Stoves. add: The dinnerware vendor now dispenses ladles. add: Spoons can now actually spoon... things. add: Soup has been reworked entirely. Soups are now reagents, cooked via a soup pot on a Stove or Range. Simply add water and your required items, then apply heat. Be careful not to boil over! add: Stoves, Ranges, and Griddles will now heat up their surroundings - don't turn them on around plasma! fix: Fixes being able to cook in an Oven while the room is depowered qol: Hitting a customer bot with an incorrect recipe no longer counts as a hostile attack leading to your demise shortly after refactor: Customer bots that request a reagent now use custom orders code: Cut down a lot of code in the crafting menu code, and removes some ugly ispaths del: Soup is no longer food items, so can't appear in random food pools (at least not yet). balance: Virus Food recipe now requires you cool it to 200k. /🆑 |
||
|
|
b2e53feee2 |
Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart (#73678)
## About The Pull Request So, this spiraled from one missing icon being fixed to an entire check for said icons. Several icon files no longer use error icons because its assumed that the checks will handle any missing ones, but the checks don't apply to emissives nor overlays at all. This led to the radsuit having an emissive but no icon_state for it - a relic of the old radsuit. This was only noticed because of a downstream with an error icon appearing for it... I was curious how many were actually having the same issue, so I made a small little stack_trace in the mutable_appearance proc. There were like, 2k. Lots of them were icons named, like, "transparent" or "blank" too... I moved that check to the emissives proc because I semi-understand that system so could actually fix it, and it moved to around fourty roundstart. Much more achievable. (The error usually has more info if you click on it, including the item that caused it. I dunno how to add that to the check itself because of where it's located, though.)  This fixes all the ones I could find, including... Nonexistant icons that shouldn't be adding emissives on: - Empty Barsign - Radsuit - Mass Driver Controllers - Telescreens - Aux Base Consoles - PanDEMIC - Kobayashi computer (holodeck) - Abductor camera console - Syndie drop pod - BSA controller Entirely missing icons on: - Pwr Game Vendor (this was just misnamed) - Generic Soda Vendor - Engivend - Security Laptop (proud of this one.,.,)  There are no doubt more of them hidden about, but I don't really know what I'm doing... If there's a check that'd be better than this, please review telling me what to change <3 ## Why It's Good For The Game Fixes missing icons, fixes attempts to add icons where we don't need them, and adds a check to help fix more of the two issues as they occur. ## Changelog 🆑 fix: fixed missing emissives on the Engivend, Pwr-Game Soda, and generic Soda vendors. Also fixed the seclaptop having no valid screen icon! fix: fixed a few items trying to apply emissives when they shouldn't. code: added a stack_trace for emissives with missing icon states. /🆑 |
||
|
|
63eaec9a58 |
Adds a unit test to detect double stacked lights (#73650)
## About The Pull Request They make me sad and we should test for them I use dir here to prevent like, bulb + bar stuff, idk if that's wanted or not tho |
||
|
|
ab307032ed |
Nightvision Rework (In the name of color) (#73094)
## About The Pull Request Relies on #72886 for some render relay expansion I use for light_mask stuff. Hello bestie! Night vision pissed me off, so I've come to burn this place to the ground. Two sections to discuss here. First we'll talk about see_in_dark and why I hate it, second we'll discuss the lighting plane and how we brighten it, plus introducing color to the party. ### `see_in_dark` and why it kinda sucks https://www.byond.com/docs/ref/#/mob/var/see_in_dark See in dark lets us control how far away from us a turf can be before we hide it/its contents if it's dark (not got luminosity set) We currently set it semi inconsistently to provide nightvision to mobs. The trouble is stuff that produces light != stuff that sets luminosity. The worst case of this can be seen by walking out of escape on icebox, where you'll see this  Snow draws above the lighting plane, so the snow will intermittently draw, depending on see_in_dark and the luminosity from tracking lights. This would in theory be solvable by modifying the area, but the same problem applies across many things in the codebase. As things currently stand, to be emissive you NEED to have a light on your tile. People are bad at this, and honestly it's a bit much to expect of them. An emissive overlay on a canister shouldn't need an element or something and a list on turfs to manage it. This gets worse when you factor in the patterns I'm using to avoid drawing lights above nothing, which leads to lights that should show, but are misoffset because their parent pixel offsets. It's silly. We do it so we can have things like mesons without just handing out night vision, but even there the effect of just hiding objects and mobs looks baddddddd when moving. It's always bothered me. I'll complain about mesons more later, but really just like, they're too bright as it is. I'm proposing here that rather then manually hiding stuff based off distance from the player, we can instead show/hide using just the lighting plane. This means things like mesons are gonna get dimmer, but that's fine because they suck. It does have some side effects, things like view() on mobs won't hide stuff in darkness, but that's fine because none actually thinks about view like that, I think. Oh and I added a case to prevent examining stuff that's in darkness, and not right next to you when you don't have enough nightvision, to match the old behavior `see_in_dark` gave us. Now I'd like to go on a mild tangent about color, please bare with me ### Color and why `lighting_alpha` REALLY sucks You ever walk around with mesons on when there's a fire going, or an ethereal or firelocks down. You notice how there isn't really much color to our lights? Doesn't that suck? It's because the way we go about brighting lighting is by making everything on the lighting plane transparent. This is fine for brightening things, but it ends up looking kinda crummy in the end and leads to really washed out colors that should be bright. Playing engineer or miner gets fucking depressing. The central idea of this pr, that everything else falls out of, is instead of making the plane more transparent, we can use color matrixes to make things AT LEAST x bright. https://www.byond.com/docs/ref/#/{notes}/color-matrix Brief recap for color matrixes, fully expanded they're a set of 20 different values in a list Units generally scale 0-1 as multipliers, though since it's multiplication in order to make an rgb(1,1,1) pixel fullbright you would need to use 255s. A "unit matrix" for color looks like this: ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 ) ``` The first four rows are how much each r, g, b and a impact r, g, b and well a. So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of r. and 0 units of green, blue and alpha, and so on. A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green component, and leave red, blue and alpha alone, shifting any red of whatever it's applied to a green. Using these we can essentially color transform our world. It's a fun tool. But there's more. That last row there doesn't take a variable input like the others. Instead, it ADDS some fraction of 255 to red, green, blue and alpha. So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it could possibly be. This is what we're going to exploit here. You see all these values accept negative multipliers, so we can lower colors down instead of raising them up! The key idea is using color matrix filters https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these operations together. Pulling alllll the way back, we want to brighten darkness without affecting brighter colors. Lower rgb values are darker, higher ones are brighter. This relationship isn't really linear because of suffering reasons, but it's good enough for this. Let's try chaining some matrixes on the lighting plane, which is bright where fullbright, and dark where dark. Take a list like this ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, -0.2, -0.2, -0.2, 0 ) ``` That would darken the lighting a bit, but negative values will get rounded to 0 A subsequent raising by the same amount ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.2, 0.2, 0.2, 0 ) ``` Will essentially threshold our brightness at that value. This ensures we aren't washing out colors when we make things brighter, while leaving higher values unaffected since they basically just had a constant subtracted and then readded. ### But wait, there's more You may have noticed, we gain access to individual color components here. This means not only can we darken and lighten by thresholds, we can COLOR those thresholds. ``` list(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0.1, 0.2, 0.1, 0 ) ``` Something like the above, if applied with its inverse, would tint the darkness green. The delta between the different scalars will determine how vivid the color is, and the actual value will impact the brightness. Something that's always bothered me about nightvision is it's just greyscale for the most part, there isn't any color to it. There was an old idea of coloring the game plane to match their lenses, but if you've ever played with the colorblind quirk you know that gets headachey really fast. So instead of that, lets color just the darkness that these glasses produce. It provides some reminder that you're wearing them, instead of just being something you forget about while playing, and provides a reason to use flashlights and such since they can give you a clearer, less tinted view of things while retaining the ability to look around things. I've so far applied this pattern to JUST headwear for humans (also those mining wisps) I'm planning on furthering it to mobs that use nightvision, but I wanted to get this up cause I don't wanna pr it the day before the freeze. Mesons are green, sec night vision is red, thermals orange, etc. I think the effect this gives is really really nice. I've tuned most things to work for the station, though mesons works for lavaland for obvious reasons. I've tuned things significantly darker then we have them set currently, since I really hate flat lighting and this system suffers when interacting with it. My goal with these is to give you a rough idea of what's around you, without a good eye for detail. That's the difference between say, mesons, and night vision. One helps you see outlines, the other gives you detail and prevents missing someone in the darkness. It's hard to balance this precisely because of different colored backgrounds (looking at you icebox) More can be done on this front in future but I'm quite happy with things as of now ### **EDIT** I have since expanded to all uses of nightvision, coloring most all of them. Along the way I turned some toggleable nightvision into just one level. Fullbright sucks, and I'd rather just have one "good" value. I've kept it for a few cases, mostly eyes you rip out of mobs. Impacted mobs are nightmares, aliens, zombies, revenants, states and sort of stands. I've done a pass on all mobs and items that impact nightvision and added what I thought was the right level of color to them. This includes stuff like blobs and shuttle control consoles As with glasses much of this was around reducing vision, though I kept it stronger here, since many of these mobs rely on it for engaging with the game <details> <summary> Technical Changes </summary> #### Adds filter proc (the ones that act like templates) support to filter transitions. Found this when testing this pr, seemed silly. #### Makes our emissive mask mask all light instead This avoids dumbass overlay lighting lighting up wallmounts. We switch modes if some turfflags are set, to accomplish the same thing with more overhead, and support showing things through the darkness. Also fixes a bug where you'd only get one fullscreen object per mob, so opening and closing a submap would take it away Also also fixes the lighting backdrop not actually spanning the screen. It doesn't actually do anything anymore because of the fullscreen light we have, but just in case that's unsued. Needs cleanup in future. #### Moves openspace to its own plane that doesn't draw, maxing its color with a sprite This is to support the above We relay this plane to lighting mask so openspace can like, have lighting #### Changes our definition of nightvision to the light cutoff of night vision goggles and such Side affect of removing see_in_dark. This logic is a bit weak atm, needs some work. #### Removes the nightvision spell It's a dupe of the nightvision action button, and newly redundant since I've removed all uses of it #### Cleans up existing plane master critical defines, ensures trasnparent won't render These sucked Also transparent stuff should never render, if it does you'll get white blobs which suck </details> ## Why It's Good For The Game Videos! (Github doesn't like using a summary here I'm sorry) <details> Demonstration of ghost lighting, and color https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4 Engi-glass mesons and walking in maint (Potentially overtuned, yellow is hard) https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4 Diagnostic nightvision goggles and see_in_dark not hiding emissives https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4 Sec nightvision (I just think it looks neat) https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4 Medical nightvision goggles and other colors https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4 Miner mesons and mobs hiding in lavaland (This is basically the darkest possible environment) https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4 Thermal goggles and coloring displayed mobs https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4 </details> I think it's pretty, and see_in_dark sucks butt. ## 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: The darkness that glasses and hud goggles that impact your nightvision (think mesons, nightvision goggles, etc) lighten is now tinted to match the glasses. S pretty IMO, and hopefully it helps with forgetting you're wearing X. balance: Nightvision is darker. I think bright looks bad, and things like mesons do way too much balance: Mesons (and mobs in general) no longer have a static distance you can see stuff in the dark. If a tile is lit, you can now see it. fix: Nightvision no longer dims colored lights, instead simply thresholding off bits of darkness that are dimmer then some level. /🆑 |
||
|
|
f960967cea |
Avoid creating string list of turf platings, rename some of the APIs, and improve focused test support - 160ms+ (more on prod) of init savings (#72056)
Looking at some stuff that uses `Join` right now as targets, this one's pretty straight forward. `/turf/open/floor/Initialize`, called 20,000 times without ruins, creates a string list of the broken and burnt states. This carries the fixed cost of `Join`, which is very expensive, as well as some (not crazy, but not negligible) proc overhead. These vars were used for effectively nothing, and have been replaced with just using the list when necessary, which only adds an extra millisecond of cost to update_overlays. This was also used to automatically set `broken` and `burnt` at runtime. However, this looks like it has gone completely unused. Adds a unit test which adds it as a static field to the only type that cared about it, which was abductor tiles, which is wrong anyway, but Whatever. I want to support people making a subtype of floor tiles that are pre-broken without it messing up stuff silently, so the test is there. While I'm at it, renames `setup_broken_states` and `setup_burnt_states` to remove `setup_`, since they don't really do that anymore (and never did). Also also, adds support for `PERFORM_ALL_TESTS` to work with multiple focuses. For reviewing, basically all of the changes are in floor.dm, aside from test stuff, which is unit_test.dm. |
||
|
|
453080d3fc |
Moves space initialization check to unit test - Saves 0.065s of init time (#71796)
This hasn't been hit in a long time and this is an extremely hot proc, doing these checks in unit tests should catch any cases, though unlikely. This has zero cost at runtime because `if (FALSE)` statically compiles out. |
||
|
|
8ace31bde4 |
Allows for offloaded tests to be focused (#71719)
Focusing a test through TEST_FOCUS allows you to only run that one test. It's very useful for developing. However, we have a bunch of offloaded tests in `#ifdef UNIT_TESTS` that would not be focused. This changes it so that those tests will now only run if either no test is focused, or if their specific "focus only" test is focused. This is done through a `PERFORM_ALL_TESTS` macro that replaces the `#ifdef UNIT_TESTS`. This is completely free because `if (FALSE)` constant folds. Hide whitespace mode recommended. |