Upstream 04.04.26#99
Merged
Merged
Conversation
…ey are active/moving) (#95311) ## About The Pull Request When brand intelligence triggers, infected vending machines have a 50% chance to deny you from using them unless you are moderately wealthy (>=1000 cr) When the vending machines activate/start moving, they outright deny usage from everyone ## Why It's Good For The Game We have some very good vendor deny icons but they are almost completely impossible to trigger in game (with the exception of booze vendors and some very edge cases) Someone gave me the idea to use them in the brand intelligence event and it feels pretty appropriate. Also helps you identify infected vendors (whereas right now you can only tell by the occasional message). Maybe it'll even incentivize people to actually hunt down the origin rather than just wait it out. ## Changelog :cl: Melbert add: Intelligence vendors (from the event) have a 50% chance to deny users who are not wealthy. When the vendors awake and start moving, they instead get a 100% chance to deny anyone. /:cl:
## About The Pull Request This adds screentips for scanning raptors - both with the PDA RaptorDex app, and the standalone handheld version. Also fixed a bug where the "scanned" balloon alert didn't properly appear for the, bc it'd try to display the balloon alert to the raptor... <img width="329" height="419" alt="2026-03-15 (1773602977)" src="https://github.com/user-attachments/assets/8a16f5c4-f65b-4931-ac0b-7c165f4781de" /> <img width="285" height="349" alt="2026-03-15 (1773603014)" src="https://github.com/user-attachments/assets/827e2e1a-5243-4763-8532-b4fe2246c745" /> ## Why It's Good For The Game I initially didn't realize that you had to _right click_ to scan raptors with the PDA app, so like, I decided to add screentips to make that clearer. also bugfix good. ## Changelog :cl: qol: Added screentips for scanning raptors with the RaptorDex PDA app and standalone handheld RaptorDex. fix: Fixed the handheld RaptorDex not showing the "scanned" balloon alert when scanning a raptor. /:cl:
## About The Pull Request No other sprite available, and no reason not to use the basic claymore one. They use the basic claymore inhand sprite too. ## Why It's Good For The Game closes #95451 ## Changelog :cl: image: gave the worn ceremonial claymore the basic claymore's worn icon. /:cl:
## About The Pull Request #95197 made gene-produced webs drain the stamina of their makers, this is a fix for that ## Why It's Good For The Game ## Changelog :cl: fix: webbing production webs no longer harm their maker /:cl: --------- Co-authored-by: l0 <-->
## About The Pull Request ### Main changes Lavaland relics from boulders have a (mostly) unique suite of random effects, differentiating them from normal station relics <Details> <Summary>Spoiler Effect list</Summary> - Dimensional shift (same as normal) - Summon monsters (Summon animals, but Lavaland/Cult creatures, has a high chance of deleting itself.) - Explode (same as normal) - Low potency shield (When holding the relic, you get a shield that blocks three normal attacks.) - High potency shield (When holding the relic, you get a shield that blocks one normal or overpowering attack.) - Random teleport (same as normal) - Random AOE teleport (Cult themed version of normal teleport that affects all nearby objects/mobs. Blocked by antimagic, has a low chance of deleting itself) - Recharge (same as normal) - Rockfall (Places rock turfs over nearby open turfs. These are weak, ie they can be hand-mined. Stuns anyone caught in it, has a chance of deleting itself) - Blood spray (Consumes a chunk of the user's blood and sprays blood around. Has a chance of swapping to Blood suck) - Blood suck (Consumes a chuck of all nearby mob's blood and transfers it to the user. Blocked by antimagic. Has a chance of swapping to Blood spray) - Cleaning foam (same as normal) - Acid cleaning foam (spawn an ez-clean grenade, has a high chance of deleting itself.) </Details> ### Other changes Relics spawned from gifts (ie Christmas) auto-reveal themselves Blood sprays won't merge with each other Better documentation, and relics now uses `deconstruct` when terminating itself ## Why It's Good For The Game - The flavor behind these cursed and cultish relics doing the same thing as the cobbled together electronics found in maint is kinda weak. 90% of the time I see them abandoned in a pile in mining. More flavorful and potent effects may make people decide to investigate them more. - The gift thing was just a fun random idea I had. Allows people to play with their new toy immediately. ## Changelog :cl: Melbert add: Relics found from cracking boulders now have a (mostly) unique set of mining and cultish related effects. add: Relics found in gift boxes no longer need to be discovered first in science. /:cl:
…her than targeting chest. (Adds stumps) (#95252) ## About The Pull Request - The `prosthetic replacement` surgical operation has been reverted to be closer to how it used to work: The operation is done targeting the limb that's missing The change was made out of necessity, as surgical state was tied to limbs - you had to operate on the chest to re-attach limbs because there was no limb to operate on. To circumvent that, I have done the unthinkable of adding stumps when you are dismembered. - Missing limbs are now represented as an invisible, un-removable, un-interactable limb. Making this change was not as difficult as originally anticipated, and (at least surface level) seems to have broken very little. Surprisingly little had to change to make this work. Direct accesses to `mob.bodyparts` was changed to `mob.get_bodyparts()` with an optional `include_stumps` argument. Similarly, `get_bodypart()` had an optional `include_stumps` added. This means we ultimately barely needed to change anything, and in fact, some loops/checks were able to be streamlined. ## Why It's Good For The Game - As mentioned, this change was out of necessity and was easily the least intuitive part of the broader changes. Reverting it back to how it used to work should make it far easier for people to pick up on, and means we can cut out a bunch of bespoke instruction sets that I had to include. - The addition of stumps also adds a ton of future potential - code wise it allows for stuff like better damage tracking (we can transfer damage between limb <-> stump rather than limb <-> chest), and feature we can do "fun" stuff like have stumps bleed on dismemberment that you can bandage. ## Changelog :cl: Melbert del: "Add prosthetic limb" surgical operation has been reverted to be a bit closer to how it used to work - you operate on the missing limb / limb stump, rather than on the chest. refactor: Missing limbs are now represented as limb stumps. In practice this should change nothing (for now), as no features were rewritten to make use of these besides surgery. Please report any oddities with missing limbs, however. /:cl:
## About The Pull Request I want to do stuff with parallax (like placing stuff in the backdrop and moving it around), but I'm in my not doing 100 things in one pr arc so we're doing this piecemeal. To start, I wanted to try adding oldspace back as a parallax layer. This is something I was considering when it was first removed but never got around to, so here we are. I started by [writing a rust program](https://github.com/LemonInTheDark/old_space_gen) to fabricate the required icon state, then realized that all the different parts of space have their own animation delays. There's no way I could make one icon state with all them looping, so instead I split them up into multiple components and then overlayed them together. This works, but is infeasible (my gpu died) at the scale required for parallax (17 480x480 sets, 15 unique delays per 1 set) so I used render targets to render one copy, then mirror it to the rest of the overlays. This works wonderfully, and gets us down to (on my machine) a gpu cost comprable with about medium parallax intensity. I'm open to making these tile bound but I thought making them look "far away" feels better. In the process of all this I got very mad at the existing parallax code, soooooooo Parallax layers are no longer stored on the client, they are stored on and managed by the parallax home atom that holds them for display. Said atom also tracks all the information about how they are selected. Parallax layers no longer take a hud as input, instead expecting a client. (we were just swapping them back and forth and I thought it was dumb). Parallax no longer tries to support passing in a mob that does not actually own the hud it is displayed on. This feature wasn't even being used anymore because it was fully broken, so all it was doing was making the code worse. Parallax no longer has to do a full refresh anytime something about WHAT layers are displayed might have changed. We cache based off the variables we care about, and use the change in state to determine what should happen (this is improved by moving "rendering the layers" fully to the control of the home datum). Parallax no longer directly modifies the hud's plane masters, instead relying on trait based signals to manipulate them (this avoids wasted time in the common event of a needless parallax prefs check). Parallax no longer has 2 procs that are only called together to "remove/readd/update" the layers, instead doing both in a new check() proc. Cleans up some plane master cruft to do with tracking/managing huds (might break, tested, think it's fine). ## Why It's Good For The Game https://github.com/user-attachments/assets/79138a0f-9f6d-447d-843e-0d237db13276 ## Changelog :cl: add: Added an option for rendering space parallax with old space sprites (the ones from before we invented parallax), they're animated and I feel quite pretty. fix: Space parallax should hopefully behave a little more consistently now refactor: Rewrote a lot of how space parallax handled itself, please yell at me if any bugs make themselves known /:cl:
…ys (#95362) ## About The Pull Request [Adds a visual tick helper, integrates it into SSmove and such](tgstation/tgstation@e97035f) Basically, if we do "stuff" during verb time then the next chance clients have to actually see it is on the next visual tick (rather then the normal "this tick"). This is cause clients get their next frame during maptick, and maptick runs before verbs. We want to be able to handle this properly because if you say, create an object and then move it on the same VISUAL tick (NOT game tick), it will just teleport instead of playing out the move. I don't want this for stuff like sparks, so we need a way to work around it. [Moves most users of the _FAST flag to _INSTANT](tgstation/tgstation@6f96daa) These are the kids that don't immediately spawn something and the move it, and we want to allow them to move actually as soon as possible (important for stuff like space) [Improves basic effect systems, makes their products delete when they stop moving](tgstation/tgstation@172cb25) Moves some stuff out to getters or vars so children can better decide how long effects should last/how fast they should move. Uses this to clean up weird dupe code used by explosions. Makes all these effects delete on contact with something that stops them. I'm doing this because an effect just hanging in the air looks really really odd. Does have consequences for sparks that are already moving at a wall though, might need a better way to handle that. Makes all these effects use _FAST loops so they don't just hang in the air for a second on spawn Adds a setter proc on sparks for their duration, gonna use this to improve their effects some [Refactors overlay lights, adds support for animating their images](tgstation/tgstation@3ad0083) Implements light_render_source and relevant setters, this allows us to replace the components of an overlay light with basically whatever we want Refactors overlay lighting to handle its images more consistently, allowing us to hook into an image being modified Combining the two of these will allow us to consistently copy a light's image, modify it in some way, and then relay that modification back down. Allowing us to animate it or do more advanced effects painlessly Also, fixes ranges of 1 or less not rendering at all on initial set (thank you kapu) [In which I get fed up and add a macro helper for UID generation](tgstation/tgstation@aab48b0) [adds vv hooking for all existing lighting vars](tgstation/tgstation@b81c620) [Upgrade effect system's dir picking to avoid duplicates when possible](tgstation/tgstation@18b6225) [Uses the technique described above to animate spark's lights out as they move](tgstation/tgstation@67ba177) This is a decently nice effect imo, it allows us to bump their power (read, alpha) since it'll get animated away. I try to sync the animation to the actual icon state's flow (it's 0.7s long). I also sped them up somewhat to hopefully have a nicer looking effect? we'll see. [Abstracts away intercepting overlay lights into a holder datum](tgstation/tgstation@b3f1fe7) This should make it far easier to reuse this pattern! [Fixes overlay lights flashing to double intensity when picked up off the ground](tgstation/tgstation@1d83f20) We needed to clear out their underlays BEFORE the animation [Adds a flickering effect to flares and their children](tgstation/tgstation@b7a858e) I'm still not 100% happy with this, I was trying to avoid it feeling like a heartbeat with random noise and I.. THINK it worked? it's honestly quite hard to tell [Adds the same flickering to lighters, welding tools and life candles](tgstation/tgstation@3ec4402) Also, updated light candles to mirror the appearance of normal candles and use overlay lighting EDIT: I realized while working on flares that I accidentally double applied color, so if you saw the sparks animations before now it was different (less vibrant). IDK if I like this better or worse but it is RIGHT and that's what matters. ## Why It's Good For The Game I got mad about how bad these looked, and this is a start at improving them. Also, adds a framework for more dynamic effects applied to overlay lights (you could use this to apply a sort of "emergency rotating" effect, or flicker/buzz for example). <details> <summary>Before</summary> https://github.com/user-attachments/assets/66437f27-ee3c-4f14-a7ee-4a1c3e68533a https://github.com/user-attachments/assets/ed14fff8-a7eb-47fe-bab5-9a490ac96629 </details> <details> <summary>After</summary> https://github.com/user-attachments/assets/fb24ff2e-c745-42a5-8e11-c8a1eeef35a5 https://github.com/user-attachments/assets/fd8c2116-cb92-4fe6-ad3e-786a6538e52a </details> ## Changelog :cl: add: Reworks how sparks render. They're now a bit brighter, will fade out as they move/if they hit something, will stack with each other less and also won't start hang in the air on spawn. add: Added a flickering effect to lighters, welding tools, flares, torches and candles (since they're flames). fix: Overlay based lights (think flashlights) will no longer flash to double intensity while being picked up. refactor: Reworked how some effects (explosion particles, sparks, some reagent stuff) function, report any bugs! /:cl:
## About The Pull Request - Fixes tgstation/tgstation#94993 (comment) - Partially addresses #95310. That is deconstructing the floor tile of the sink won't destroy it. This behaviour was caused by #95062 which made sinks mount to floors & not walls ## Changelog :cl: fix: you can pry out/deconstruct floor tiles/reinforced tiles etc without destroying any floor lights/sinks mounted on as long as there is plating underneath that turf /:cl: --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
## About The Pull Request Ok so on the parallax pr I moved a bunch of dumb plane group signal registration to the set home proc. Unfortunately because set_home is run BEFORE update_offset, any created relays will then be offset down X from where they should be. For the master plate, this means #1's relay to transparent plate #0 will instead draw to transparent plate #1 (which of course renders into master plate #1) To fix this I've moved update_offset to BEFORE set_home, so children can hook into it and do things in a sane and normal way. Near as I can tell there's no reason they're ordered as they currently are. I've also added a failsafe check to prevent relay creation before update_offset is called, and attached a CRASH() to such. Interestingly enough this caused crashes on shift right click. That's fun I think
## About The Pull Request Exactly what it says on the tin - the Staff of Storms is now normal sized instead of bulky, and will fit in a backpack. ## Why It's Good For The Game The Staff of Lava fits in a backpack, and it arguably has far more destructive/abuse capability than the Staff of Storms. The main use of the Staff of Storms is dealing with ash storms, and like, I don't want to take up my back slot for that. ## Changelog :cl: balance: The Staff of Storms is now normal-sized, and fits in a backpack. /:cl:
## About The Pull Request So, the DNA vault is a 3x3 building, which spawns itself around the machine frame in kind of a awkward pattern. X represents the machine frame, and O represents the built vault's solid tiles: ``` ~X~ ~~~ ~~~ ``` and upon built ``` OOO O~O O~O ``` Right now, building the vault doesn't required specific space, meaning you can spawn it right into walls, hallways, whatever without consideration. So, at the very least, this PR tweak it so that <img width="285" height="349" alt="image" src="https://github.com/user-attachments/assets/557a1ee1-d9a6-4d7e-8edd-d4381b8b2b3b" /> -> <img width="318" height="411" alt="image" src="https://github.com/user-attachments/assets/dc7eaf4a-7c47-4e79-892c-8135f653183e" /> In doing so, this adds a new proc to machine construction onto circuit boards called `completion_requirements` that can be used to check this before completion. This also adds a small QOL tweak to the debug BRPD by adding cables to the parts list, as well as adding the same pointer arrows to the BSA construction prompt for consistency with this change. ## Why It's Good For The Game Seems like an oversight for the BSA to factor in space requirements where the DNA vault, a similar multi-tile machine to not care in the same way.
## About The Pull Request This adds experimental read-only support for `/alist`s in VV. I'm not quite sure how to add support for properly changing alists, but this is better than nothing at least. ### Before <img width="474" height="262" alt="image" src="https://github.com/user-attachments/assets/8701fc64-855b-429e-88d1-f6607000b2c8" /> ### After <img width="943" height="539" alt="2026-03-23 (1774313721) ~ dreamseeker" src="https://github.com/user-attachments/assets/cb6caf2a-19fd-49a9-b228-1bccb2c315f3" /> ## Why It's Good For The Game Should be able to at least view alists with VV. ## Changelog :cl: admin: View Variables can now properly view alists, altho it cannot edit them. /:cl:
## About The Pull Request <img width="444" height="318" alt="image" src="https://github.com/user-attachments/assets/d2b21460-0b11-499a-b05e-33d3a9768e71" /> Walking through snow or sand leaves behind a trail of prints similar to that of bloody footprints (they use the old sprites, in fact). Like bloody footprints, you can examine them to get a hint at what left the prints (shoe type or leg type if barefoot). When weather comes through (snow storm or sand storm), all prints will be cleared off. During a raging snow or sand storm, you won't leave prints at all. Snowprints can be filled with snow to remove them as well. Some equipment or effects will stop you from leaving snowprints (ski shoes, ice shoes*, heretic's cloak of shadows). Also you obviously don't leave prints if you're flying or crawling or riding something. **We don't have snow shoes* ## Why It's Good For The Game Initially I made this as a cute little detail, but I realized it has far reaching implications for play on Icebox (and many, many sandbox applications) On Icebox, any average joe can run into the wastes and become untraceable, which makes it almost impossible to track down antagonists. Snowprints... are a method for tracking people who run off into the snow. But you can play around it - You can make fake trails and retrace your steps. You can wait for a snowstorm to clear your tracks. You can even fill in your tracks with snow if you're patient. Alternatively, acquiring snow shoes means you leave no trail... or you could learn to fly, crawl through the snow, use a vehicle, so on. If you're assigned to assassinate a miner, you can follow their snowprint trail as they head into the wastes. However, this may only works early in the round, as the caverns have no snowstorm to clear prints - as miners come and go, it will become harder to follow trails. Speaking of miners, they can follow their co-workers trail if they get injured, or look for prints to see if a ruin has been looted. Similarly if a crew member falls down to the mining layers, they could find a miner's trail to follow it back to the station. And If you're a paramedic and someone was wounded out in the wastes, you might be able to find their trail to track them down. But you can't dilly-dally, as the storm will wipe away any chance of that. Ultimately I think a small detail like this has some big potential for emergent gameplay which could be cool. My intent is not to affect antagonists too negatively, so more tools to avoid leaving prints (snow shoes) could be added. ## Changelog :cl: Melbert add: Walking in snow or sand leaves behind prints. You can examine the turf to see what left the prints, like with bloodprints. add: Snowstorms or sandstorms clear away any footprints left behind in the snow or sand. add: Some equipment or effects, like skis or snowshoes, prevent you from leaving prints in the snow. add: You can fill in snowprints with snow. /:cl:
…#95571) ## About The Pull Request The Pneumatic Cannon: ~~god's greatest mistake~~ On live there's current a bug, almost certainly attack chain-based causing the cannon to be unable to be placed on tables. This most often occurs with the clown's pie cannon, as it will always try and fire at the table instead of putting it down. This PR corrects this by adding a small intermediary proc similar to the ones guns use in order to verify some of the conditions that could prevent you from firing the pneumatic cannon, while still letting you fire point blank at another mob. Additionally, Autodocs some variables, as well as axing a variable that was doing quite literally nothing that another variable was already doing. Finally, cleans up some of the logic on `examine()` for the cannon, such as not looping through 50 pies that an automatic pie cannon can hold, and cleaning up some magic numbers a bit with some self explanatory logic regarding combined weight on self-charging pneumatic cannons. ## Why It's Good For The Game Cleans up some attack chain code, and allows for everyone favorite non-gun gun to behave in a similar way to a gun that we'd all expect. Also, makes the examine text a bit more useful, such as displaying the contents of the cannon in a way that doesn't require a CHECK_TICK for something that can only hold pies. Lastly, cleans up most of the var documentation because it's my pet peeve ## Changelog :cl: qol: The pneumatic cannon's examine will now show the contents of the cannon loaded. fix: You may now place a pneumatic cannon (and the clown's pie cannon!) onto tables. /:cl:
## About The Pull Request The cult barrier rune runtimes when destroyed because both the barrier and the rune try to qdel each other in `Destroy()` Spells runtime when using their last charge because they attempt to log their action's name, which is deleted in `cast_spell()` The cult master spell that moves your underlings around runtimes because they pass no volume into `play_sound()` ## Why It's Good For The Game Fixes runtimes ## Changelog :cl: fix: Three cult abilities no longer runtime /:cl:
## About The Pull Request They kept their dir from last time you kicked em out ## Why It's Good For The Game You should turn when you turn ## Changelog :cl: fix: Wheelys dont turn you when you kick them out /:cl:
…bited in a morgue tray (+makes it shake) (#95602) ## About The Pull Request If you orbit a recovered crewmember or thanatorenasia body situated in a morgue, the indicated will change from red to green, indicating the body is revivable Additionally, orbiting a recovered crewmember or thanatorenasia body will cause morgues or bodybags to shake. This is an extension of the existing behavior where orbiting the body causes it to twitch. ## Why It's Good For The Game Allows doctors to store bodies in a safe place while they wait for a ghost to occupy it, also means you don't have to repeatedly defib them. ## Changelog :cl: Melbert qol: Recovered crew/Thanatorenasia bodies in morgue trays change the indicator to green when a ghost is orbiting them (to allow ghosts to signal they want it to be revived) qol: Recovered crew/Thanatorenasia bodies now cause morgue trays / bodybags to shake when orbited, much like how the body itself shakes when orbited (to allow ghosts to signal they want it to be revived) /:cl:
## About The Pull Request - Adds an `EGG` foodtype - All food recipes are `CAT_FOOD` Foods now have three sub categories to sort from Cuisines - correspond to Lizard, Martian, Mexican, etc. Dishes - correspond to pizza, bread, pastry, etc. Meals - correspond to breakfast, main, dessert, etc. In the crafting menu, you can select any number or combination of cuisine, dish, and meal. <img width="557" height="559" alt="image" src="https://github.com/user-attachments/assets/e4265c51-992c-415a-bfc6-cbf44255b3cc" /> You can even click two dishes or two cuisines to see results from those two dish categories or cuisine categories specifically. - De-capitalized (or \improper'd) several foods for proper formatting ## Why It's Good For The Game - `EGG` foodtype was added solely to replace the old `CAT_EGG`. Now you can filter by egg foodtype in the `types` subtab. - I was playing chef recently and I was a little frustrated at the food grouping. If you want to find all available pizzas, it's split between moth and pizza. If you want to find all available soups, that's split between soup, lizard, moth, and martian. Adding more granularity allows for chefs to find exactly what they're looking a lot faster. - Formatting ## Changelog :cl: Melbert qol: "Egg" foodtype now exists for better food sorting, though no species in particular likes or dislikes it at the moment. qol: Food crafting recipes now have three sub categories - Cuisine type, Dish type, and Meal type. You can now filter between "Moth Pizzas" or "Lizard Soups" rather than needing to guess if the recipe is in "Pizza" or "Mothic". spellcheck: de-capitalized several foods /:cl:
github-actions
Bot
added
GitHub
Модулярная фишка
Изменения карт
Спрайты
Документация
UI
Звуки
labels
Contributor
|
good to go? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Эти рефакторы...
🆑 MassMeta
add: Upstream 04.04.2026
/:cl: