mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-20 03:30:01 +01:00
docker-build
184
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
690bfc04b4 |
Rebalances wound determination values, wounding escalation and wound armor to hopefully be less explosive (#91099)
This is a big one so please bear with me, wounds are complicated We've decreased the max contributed damage to wound rolls from 35 to 25. This results, after the exponent, a max possible wound roll of 1 to 91 before any modifiers (assuming the attack, after armor, is 25 or above). The minimum value to wound is still 5. Most wounds were contributing significant numbers per wound type to the potential for a new wound to occur. Getting wounded once meant you were getting wound a lot, but actually getting past that first wounding may be the tricky part. We have significantly reigned in the wound penalty that having a wound contributes, and instead utilize the series wound penalty to allow same type wounds to escalate themselves faster as a priority. Having wounds still makes you more wound vulnerable, just not to such an extreme degree. The priority here for what wounds matter most for contributing to overall wounding vulnerability is ``Infected BURNS > BURNS > SLASH|PIERCE > BLUNT.`` Wound armor, unlike all other kinds of armor, was used as a additive value to the wound roll modifiers rather than a multiplicative value. We have reworked how wound armor is determined by changing how wound modifiers are calculated. Firstly, we're passing our entire injury roll into the ``check_woundings_mod()`` proc, as we're not treating this as a proc that just adds values anymore. Secondly, bare wound bonus only applies if there is no potential wound protection from any source, as expected. But it comes last in the calculations. Thirdly, wound protection is applied to the injury roll last, after wound bonuses from the attack, wound bonuses from other wounds and wound bonuses from a disabled limb are applied. This does not include serial wound bonuses, which are determined outside of this proc. Wound protection comes from two sources. Clothing and limb wound resistance. Your chest and head have an amount of wound resistance so long as they are not mangled in any fashion. Being mangled means having either a hairline fracture or a weeping avulsion wound. Wound protection reduces the final injury roll by a percentage. Say our roll is 50, and we have effectively 50% wound protection. The final roll would be 25. ~~Most clothing have had their wound armor values changed. As a loose rule, I used the highest of melee or bomb armor, except where that value was 100, in which case I used the lowest instead. I'm basing this decision on how embeds are calculated, which is attack type agnostic.~~ ~~Some armor have inconsistent values because they are alternative armors to an existing armor type or are hyperspecialized armor. Ablative, bulletproof and security vests all share a value of 35, despite the former two not having decent melee or bomb armor.~~ ~~Some clothing missing wound armor that should have had them now have wound armor.~~ ~~This may need a bit of scrutiny in case one or two seem weirdly high. Some have maybe become too low. Its a bit hard to say.~~ I changed it to ``exposed_wound_bonus`` to better represent when it applies. You can be naked and still not be affected by this bonus if the limb has wound resistance. I'm not promising anything with this PR, but this is an attempt to sanity check the values on wounds so that we're not seeing what the data that determined the removal of beheading presented. An extreme over-representation of tier 3 wounds. ~~And, from that, maybe I can argue for beheadings coming back. That's my goal. I think beheadings happened so much because the numbers were in need of work.~~ Well okay I just wanna make wounds a bit more workable actually more than I want beheadings. Why is it that tier 3 wounds were so over-represented? Because wounds will often force more severe wounds of other types by merit of any wounds existing at all on a limb. Having **_a_** wound makes you more wound prone for any kind of wound, and not just making you more likely to suffer a more severe type of the same wound. The threshold mechanic was intended to simulate making a wound worse, but oddly just made a limb broadly more prone to getting worse from any kind of attack to such a degree that future wound rolls of different types were often going to start at the threshold necessary to be a tier 3 wound. Dismemberment, mind you, requires you to suffer a flesh wound while you have a bone wound of tier 2 or higher (with tier 3 giving a bonus to this). You can do this readily via just a sharp weapon, because having a mangled limb causes the wound to turn into a bone wound. Technically, this is meant to be less likely as the effective damage for this wound is halved. But the wound bonus from having a flesh wound was almost always significant enough to kick your new bone wound up to a tier 3. In other words; its not surprising that you saw so many beheadings, because the system wanted to behead you as fast as it possibly can thanks to all these escalating values. Wound armor was only applied as a flat reduction on the roll. The average for wound armor was 10. After receiving a single wound, you can expect wound rolls to reach upwards of 100, even if the actual damage roll was not particularly high, due to wound stacking bonuses form being wounded. This meant that wounds, if they happened, came thick and fast after the first, regardless of what your protection might be to wounds. It was just a matter of getting past the initial bump. This is why effects that forced wounds were so powerful. They basically made a given limb more prone to taking a wound without having to deal with the protection problem first. Finally, this is just a broad flaw with the system that is not its fault. It is actually a problem that isn't a problem. Most people in the game are not wearing helmets that protect their head. So most people are going to suffer from a higher proclivity of being wounded if people are aiming for the head. There is this...kind of cargo cult belief that aiming for the head means you do more damage, or can stun someone if you're lucky or what have you. It's entirely nonsense, but it has a grain of truth in that people rarely wear, or even have access too, headwear that provides wound protection or any protection at all. People have jumpsuits, which are universally wound protected, but that isn't true of the head. Look, the point is, they're not aiming at the head because it is usually less armored, its for other reasons but it just so happens to become true due to wounds and how wounds roll their type. To soften this issue, I've decided to treat wound resistance as armor until the limb suffers a tier 3 wound. This way, hits to the head MAY not necessarily escalate to tier 3 instantly as they would on live even from relatively low power weapons. Some weapons have very low force, but have extreme bare wound bonuses. This should be less likely after this change. I doubt this will necessarily make high damage high wound weapons like energy swords any less prone to cutting you clean open, but it might thanks to the reduction to contributed damage to the injury roll. The system is now _a bit more random_. 🆑 balance: Wounds do not make you as vulnerable to suffering wounds of all types as before. Instead, wounds make you more vulnerable to suffering worse versions of themselves as a priority. balance: Wound armor is now more impactful when protecting you from wounds when you have already been wounded. balance: Your head and chest are more difficult to wound until they have been mangled; either from suffering from a weeping avulsion or a hairline fracture. code: Changed the variable for bare_wound_bonus to exposed_wound_bonus to better explain what that variable is doing. /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> |
||
|
|
3c1505ac06 |
Cyborgs now use storage datum (#90927)
This moves Cyborgs onto using storage datums, removing the remenants of the shitcode that was Cyborg inventory. It's now done mostly by equipping/unequipping/storage items, much like how other mobs do. This allows borgs to take advantage of more hand support stuff and things like ``dropped()``, so borgs no longer have to copy paste drop code to ``cyborg_unequip`` It also: - Removes ``CYBORG_ITEM_TRAIT`` - Removes all borg items being ``NODROP`` https://github.com/user-attachments/assets/11442a10-3443-41f2-8c72-b38fb0126cdb Currently borgs are able to have their entire inventory open and a bag below it, which I thought was a little weird. I always assumed they WERE storage items, so I guess I'm doing it myself. Cyborgs using storage code makes it easier for contributors to actually do stuff with, without risking breaking everything. It also hopefully will make borg items more resilient against breaking in the future, now that we're not relying on nodrop. Also just brings them more in line with other mobs, all of which make use of storages. 🆑 refactor: Cyborg's modules now use storage (so opening a bag will close modules instead of overlap one over the other). qol: Observers can now see Cyborg's inventories (like they can for humans). /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
d4d5885959 |
Real Fuel No Clickbait© (#91304)
## About The Pull Request Fixes #91299, by making plasma appear to be fuel for the purposes of checking how full the welder is. ## Why It's Good For The Game Bugg bad. Stealthy sabotage method being extremely obvious bad. ## Changelog 🆑 fix: Plasma now contributes to the fuel gauge of rigged welders, making them less extremely obvious. /🆑 --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> |
||
|
|
bc2215667f |
Re-refactors batons / Refactors attack chain force modifiers (#90809)
Melee attack chain now has a list passed along with it, `attack_modifiers`, which you can stick force modifiers to change the resulting attack This is basically a soft implementation of damage packets until a more definitive pr, but one that only applies to item attack chain, and not unarmed attacks. This change was done to facilitate a baton refactor - batons no longer hack together their own attack chain, and are now integrated straight into the real attack chain. This refactor itself was done because batons don't send any attack signals, which has been annoying in the past (for swing combat). 🆑 Melbert refactor: Batons have been refactored again. Baton stuns now properly count as an attack, when before it was a nothing. Report any oddities, particularly in regards to harmbatonning vs normal batonning. refactor: The method of adjusting item damage mid-attack has been refactored - some affected items include the Nullblade and knives. Report any strange happenings with damage numbers. refactor: A few objects have been moved to the new interaction chain - records consoles, mawed crucible, alien weeds and space vines, hedges, restaurant portals, and some mobs - to name a few. fix: Spears only deal bonus damage against secure lockers, not all closet types (including crates) /🆑 |
||
|
|
11d82b7995 |
You can now interact with held mobs beside wearing them (feat: "minor" melee attack chain cleanup) (#90080)
People can now pet held mothroaches and pugs if they want to, or use items on them, hopefully without causing many issues. After all, it only took about a couple dozen lines of code to make... ...Oh, did the 527 files changed or the 850~ lines added/removed perhaps catch your eye? Made you wonder if I accidentally pushed the wrong branch? or skewed something up big time? Well, nuh uh. I just happen to be fed up with the melee attack chain still using stringized params instead of an array/list. It was frankly revolting to see how I'd have had to otherwise call `list2params` for what I'm trying to accomplish here, and make this PR another tessera to the immense stupidity of our attack chain procs calling `params2list` over and over and over instead of just using that one call instance from `ClickOn` as an argument. It's 2025, honey, wake up! I also tried to replace some of those single letter vars/args but there are just way too many of them. Improving old code. And I want to be able to pet mobroaches while holding them too. 🆑 qol: You can now interact with held mobs in more ways beside wearing them. /🆑 |
||
|
|
4562325810 |
Fixes a rigged welding tool runtime (#89918)
## About The Pull Request Found while testing #89903, switched_on attempts to access deleted reagents datum as explode() qdels the welding tool, so it runtimes. ## Changelog Not player facing |
||
|
|
b6b8306fda | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-02a | ||
|
|
586710e0d4 |
You can light a match on the heel of your boot (#88690)
## About The Pull Request - Matches can be ignited with boots. - Matches have a rare chance of failing to ignite (prompting you to try again) or an even rarer chance of snapping (wasting it). - Also makes ignition span use mostly-consistent (using rose span for the "cooler" ignition effects). ## Why It's Good For The Game You may be thinking "hey, matches won't light on just friction unless they're from the 1800s", and you'd be right. But it's a cool movie trope, which means it should be possible, I don't make the rules. ## Changelog 🆑 Melbert add: You can light matches on the heel of your boots - Just don't do it too hard. /🆑 |
||
|
|
e32fa969df |
Fix welding sparks breaking on z level change (#88626)
## About The Pull Request Welding overlays were being put on the welding tool's update_overlays_on_z, rather than the target's. This fixes that. ## Why It's Good For The Game Fix bug ## Changelog 🆑 fix: welding sparks no longer break on transitioning to a different floor /🆑 |
||
|
|
6d0809f78b |
Toolbox Mastery: Finally gives toolboxes a real use (#88252)
## About The Pull Request Using a toolbox on an object will now bring up a radial menu containing all "tools" inside of it, and picking one will put it in your offhand and use it on the object you clicked. After use, the item will be stowed back in the toolbox. Welding tools will be turned on (and off when stowed), and spess knives will give you an option to pick which tool you want to use. Only certain items qualify as tools (most items that would fit into a toolbelt do), so you cannot use this to sneakily attack someone with an esword. https://github.com/user-attachments/assets/0cd5c859-490f-4643-b451-92ce15a34fba Using a toolbox in such a fashion passes click modifiers through, allowing you to use left/right, ctrl and alt click modes of items just fine. God bless our attack chain. ## Why It's Good For The Game Toolboxes are inferior to toolbelts and boxes in almost every single way, being only capable of storing 7 items and not fitting anywhere. This gives them an actual use and maybe they'll see use in actual construction projects. ## Changelog 🆑 add: Toolboxes can be used on any object to pull out and use a tool from it as long as your offhand is free. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
|
25289b8bc6 | fixes a fuck load of sounds | ||
|
|
e59d8ba64b | Merge commit '179a607a90ad7ec62bdaff4e6fe72af60ee56442' of https://github.com/tgstation/tgstation into upstream-24-10b | ||
|
|
bb70889f6e |
TG Upstream Part 1
3591 individual conflicts Update build.js Update install_node.sh Update byond.js oh my fucking god hat slow huh holy shit we all fall down 2 more I missed 2900 individual conflicts 2700 Individual conflicts replaces yarn file with tg version, bumping us down to 2200-ish Down to 2000 individual conflicts 140 down mmm aaaaaaaaaaaaaaaaaaa not yt 575 soon 900 individual conflicts 600 individual conflicts, 121 file conflicts im not okay 160 across 19 files 29 in 4 files 0 conflicts, compiletime fix time some minor incap stuff missed ticks weird dupe definition stuff missed ticks 2 incap fixes undefs and pie fix Radio update and some extra minor stuff returns a single override no more dupe definitions, 175 compiletime errors Unticked file fix sound and emote stuff honk and more radio stuff |
||
|
|
58501dce77 |
Reorganizes the sound folder (#86726)
## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑 |
||
|
|
a4e7929a3b |
Lighters use welding fuel and can be used as welders in some cases (#85941)
## About The Pull Request Lighters now have welding fuel which can be filled/extracted by hand, giving a small but consistent source of welding fuel for non-chemists. Welding fuel is now required for these lighters to work, they'll close automatically once they're out of fuel. They last for a minute, zippo lasts 2 minutes, before they need to be refuelled. It can have other reagents put into it but it only checks for welding fuel, so it won't work at all unless its got some. They can be used as welding tools in minor cases, mostly fixing things and welding doors shut, but can't do big things like deconstruction, except the xenobio one because it's a lot hotter than the normal lighter. Also added a baseline support to check for heat to perform certain welds, before heat is just this binary "has or doesnt have heat", which made its value useless. ## Why It's Good For The Game Adds a ghetto way of getting welding fuel, hiding reagents, and a ghetto welding tool without being something that prisoners could break out of prison with. They could weld the doors shut which is a little funny, security still has proper welding tools to counter it. It also currently is kinda lame that lighters could just be open 24/7, unlike matches which has a lifespan of 10 seconds each or something. ## Changelog 🆑 add: Lighters now use and require welding fuel to work, but can be used as a welding tool for tasks that don't require much heat. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
4c4930c71d | Merge branch 'master' of https://github.com/tgstation/tgstation into pulls-tg-to-fix-shit | ||
|
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
|
968e99bef2 |
[MIRROR] Fixes welding and coil logic on robotic limb fixing (#29396)
* Fixes welding and coil logic on robotic limb fixing (#85857) ## About The Pull Request Before, trying to fix an undamaged limb would have you whack the person with the wires, or burn them with a welder. This is quite counter productive when trying to repair someone. Now it cancels any further attacks when you click on an uninjured limb, and tells you about it.  ## Why It's Good For The Game I won't accidentally smack someone with a burning welder without combat mode on just because their chest happens to have no damage. ## Changelog 🆑 fix: Trying to repair someone's undamaged limb with a welder or wires no longer has you smacking them /🆑 Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com> * Fixes welding and coil logic on robotic limb fixing --------- Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@ users.noreply.github.com> |
||
|
|
2000b07e29 |
Fixes welding and coil logic on robotic limb fixing (#85857)
## About The Pull Request Before, trying to fix an undamaged limb would have you whack the person with the wires, or burn them with a welder. This is quite counter productive when trying to repair someone. Now it cancels any further attacks when you click on an uninjured limb, and tells you about it.  ## Why It's Good For The Game I won't accidentally smack someone with a burning welder without combat mode on just because their chest happens to have no damage. ## Changelog 🆑 fix: Trying to repair someone's undamaged limb with a welder or wires no longer has you smacking them /🆑 Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
fec946e9c0 |
/Icon/ Folder cleansing crusade part, I think 4; post-wallening clean-up. (#85823)
Hello everybuddy, your number three rated coder-failure here to clean up some mess. This PR accomplishes some of the more major structural clean up changes I wanted to do with /obj/ folder, but decided to wait on until wallening gets merged, and so, time has come. Several things to still be done, although I know these cleaning PR's are quite a load, so will wait for this one to get done with first. ## Why It's Good For The Game Saner spriters, better sprites, less annoyance. Also deleted a whole load of redundancy this time around, a lot of sprites which existed simultaniously in two places now got exit their quantum superposition. |
||
|
|
64d6a6e3ca |
[MIRROR] Cable coil and welding tool healing now loops. Fixed heal message not displaying when healing someone else (#29200)
* Cable coil and welding tool healing now loops. Fixed heal message not displaying when healing someone else * fix conflict * Fixes this --------- Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: SpaceLoveSs13 <68121607+SpaceLoveSs13@users.noreply.github.com> Co-authored-by: Waterpig <wtryoutube@seznam.cz> Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com> |
||
|
|
5639f9b6d3 |
Cable coil and welding tool healing now loops. Fixed heal message not displaying when healing someone else (#85377)
## About The Pull Request Using cable coil or welding tools to heal robotic bodypart will now restart the interaction once the part is successfully healed, similarly to how sutures/meshes work. To ensure that this doesn't instantly heal whoever it is applied to, they now take 1 seconds to apply to someone else after the first loop (same as click cooldown, basically). Self-application still takes 5 seconds. There also was an (I think?) unreported issue with them not actually displaying the heal messages when used on someone else because the messages were inside of self-healing check. ## Why It's Good For The Game Clicking on self every 5 seconds can get annoying, same reasoning as to why sutures/meshes loop. And bug is just a bug, not much to say here. ## Changelog 🆑 qol: Cable coil and welding tool healing now loops similarly to sutures/meshes fix: Fixed cable coil/welding tool heal message not displaying when healing someone else /🆑 |
||
|
|
acaa0c1e93 |
[MIRROR] Pegging Update (#28212)
* Pegging Update * e * Update declarations.dm --------- Co-authored-by: Lucy Grindler <110352801+LucyGrind@users.noreply.github.com> Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com> |
||
|
|
6351073f56 |
Pegging Update (#83991)
## About The Pull Request We be addin' peg legs an' peg arms, makin' 'em craftable fer all ye scurvy dogs. Ye can attach 'em yerselves, no need fer a surgeon's touch, usin' the mighty ligament hook code. There be tons o' balance tweaks an' special properties fer these limbs. Yarrrrr! ## Why It's Good For The Game Arrr, this be givin' ye a ghetto alternative to headin' to medbay when yer limbs be blown off. Plus, the potential fer pirate RP be fantastic! Who doesn’t want peg limbs? If ye think otherwise, ye be lyin’ ,and ye'll be walkin’ the plank! Yarrrrr! ## Changelog 🆑 Hacks-The-Doors (coding) & Septicchlorine (spriting) add: craftable peg limbs (2 planks) which are attachable without surgery bal: peg limbs take 1.5x burn and 1.3x brute, and do reduced damage bal: peg limbs have chunky fingers (like insuls, but per limb) /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: septic <105231896+septoBismol@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
|
b540aaf8ab |
[MIRROR] Afterattack is dead, long live Afterattack (#28128)
* Afterattack is dead, long live Afterattack * wew * fixes --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com> |
||
|
|
ff6b41aa07 |
Afterattack is dead, long live Afterattack (#83818)
## About The Pull Request - Afterattack is a very simple proc now: All it does is this, and all it's used for is for having a convenient place to put effects an item does after a successful attack (IE, the attack was not blocked)  - An overwhelming majority of afterattack implementations have been moved to `interact_with_atom` or the new `ranged_interact_with_atom` I have manually tested many of the refactored procs but there was 200+ so it's kinda hard ## Why It's Good For The Game Afterattack is one of the worst parts of the attack chain, as it simultaneously serves as a way of doing random interactions NOT AT ALL related to attacks (despite the name) while ALSO serving as the defacto way to do a ranged interaction with an item This means careless coders (most of them) may throw stuff in afterattack without realizing how wide reaching it is, which causes bugs. By making two well defined, separate procs for handing adjacent vs ranged interactions, it becomes WAY WAY WAY more easy to develop for. If you want to do something when you click on something else and you're adjacent, use `interact_with_atom` If you want to do something when you click on something else and you're not adjacent, use 'ranged_interact_with_atom` This does result in some instances of boilerplate as shown here:  But I think it's acceptable, feel free to oppose if you don't I'm sure we can think of another solution ~~Additionally it makes it easier to implement swing combat. That's a bonus I guess~~ ## Changelog 🆑 Melbert refactor: Over 200 item interactions have been refactored to use a newer, easier-to-use system. Report any oddities with using items on other objects you may see (such as surgery, reagent containers like cups and spray bottles, or construction devices), especially using something at range (such as guns or chisels) refactor: Item-On-Modsuit interactions have changed slightly. While on combat mode, you will attempt to "use" the item on the suit instead of inserting it into the suit's storage. This means being on combat mode while the suit's panel is open will block you from inserting items entirely via click (but other methods such as hotkey, clicking on the storage boxes, and mousedrop will still work). refactor: The detective's scanner will now be inserted into storage items if clicked normally, and will scan the storage item if on combat mode /🆑 |
||
|
+18 |
ba5c112a86 |
Huge Mirror fixes (#27488)
* Fixes incorrect operator usage in mecha code (#82570)
## About The Pull Request
I completely screwed up and told the original PR author of #82415
(
|
||
|
|
d280c9ccce | Makes it EVEN EASIER to work with atom item interactions ft. "Leaf and Branch" & "Death to Chains" (#82625) | ||
|
|
39d07e5880 |
Yeets ATTACK_QDELETED, fixes welding torches not using fuel on attacking non-mobs (2 year old bug) (#82694)
## About The Pull Request - Deletes `ATTACK_QDELETED` - May have been necessary in the past but it's pointless now. All it does is clutter the attack chain. Perish. - Fixes welders not using fuel on attacking non-mobs - #65762 "fixed" welders consuming fuel on clicking turfs by adding an `isliving` check and not an `ismovable` check? ## Changelog 🆑 Melbert fix: Blobs may rejoice, welding torches now consume fuel when attacking objects again after two years. /🆑 |
||
|
|
f8b87b994b |
[MIRROR] Overlay Lighting Color/Intensity Pass (#26825)
Overlay Lighting Color/Intensity Pass Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
|
ef714c1c34 |
Overlay Lighting Color/Intensity Pass (#81425)
## About The Pull Request I was looking at screenshots of the game and realized we had a lot of light sources that were really... flat. Medium intensity, not colored at all, cringe. So I went over all the uses of overlay styled lighting (since I've done matrix lighting already) and gave them more unique features. Colors that match the sprite they're used with, intensity to produce vibes, that sort of thing. It's kinda impossible to go one by one cause there's a LOT. I may have gone a bit overboard with a few, I'm messing around with some things like giving bots colors based off their department, etc. We'll see how this all turns out. Oh also I tweaked how the cone of overlay lighting is drawn. It seemed a bit too present to me so I dropped the alpha down from like 200 to 120 at max (so it's roughly half of the mask's alpha so it's less overwhelming ## Why It's Good For The Game Lighting should be impactful, subtle and colorful <details> <summary> Old Lights </summary>           </details> <details> <summary> New Lights </summary>           </details> ## Changelog 🆑 add: Tweaked the saturation, color and intensity of a bunch of lights /🆑 |
||
|
|
29dd8ff6b9 |
Removes unintended double delay from welding code (#26521)
Removes unintended double delay |
||
|
|
4f53ec2660 |
[MIRROR] Fixes complex lights not handling moving well, renames lighting defines (#26484)
* Fixes complex lights not handling moving well, renames lighting defines (#81423) ## About The Pull Request [Fixes static lights not moving](https://github.com/tgstation/tgstation/commit/ffef43c05a55dae414ef94558ecf9b9df709ded7) Worked fine when the owner moved, but if the owner was inside something else, it would try and trigger an update on the PARENT's lights, which are obviously not us. [Renames MOVABLE_LIGHT and STATIC_LIGHT to better describe what they do](https://github.com/tgstation/tgstation/commit/de73a63bd4d97783c69c95370726d1c253ffb8fe) People keep trying to change the lighting system of lamps and it makes me mad. I choose OVERLAY_LIGHT and COMPLEX_LIGHT here, I couldn't figure out a better name for turf matrix lighting. Suggestions welcome ## Why It's Good For The Game Closes #80005 Hopefully improves understanding of lighting at a glance ## Changelog 🆑 fix: Fixes fancy lights not updating their source location when picked up and moved /🆑 * Oh well --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> |
||
|
|
70651816c2 |
Fixes complex lights not handling moving well, renames lighting defines (#81423)
## About The Pull Request [Fixes static lights not moving](https://github.com/tgstation/tgstation/commit/ffef43c05a55dae414ef94558ecf9b9df709ded7) Worked fine when the owner moved, but if the owner was inside something else, it would try and trigger an update on the PARENT's lights, which are obviously not us. [Renames MOVABLE_LIGHT and STATIC_LIGHT to better describe what they do](https://github.com/tgstation/tgstation/commit/de73a63bd4d97783c69c95370726d1c253ffb8fe) People keep trying to change the lighting system of lamps and it makes me mad. I choose OVERLAY_LIGHT and COMPLEX_LIGHT here, I couldn't figure out a better name for turf matrix lighting. Suggestions welcome ## Why It's Good For The Game Closes #80005 Hopefully improves understanding of lighting at a glance ## Changelog 🆑 fix: Fixes fancy lights not updating their source location when picked up and moved /🆑 |
||
|
|
09c56f903f |
[MIRROR] Spamming the weld on a robotic part no longer drains the fuel with no benefit [MDB IGNORE] (#26033)
* Spamming the weld on a robotic part no longer drains the fuel with no benefit (#80801) See name, spamming the self repair will no longer empty your welding tool faster than a clown emptying the captain's office. * This... should work --------- Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com> Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> |
||
|
|
bf1be84bed |
Spamming the weld on a robotic part no longer drains the fuel with no benefit (#80801)
## About The Pull Request See name, spamming the self repair will no longer empty your welding tool faster than a clown emptying the captain's office. |
||
|
|
2cbbccf4e7 |
[MIRROR] Fix some shenanigans involving interaction order with wound tending [MDB IGNORE] (#25551)
* Fix some shenanigans involving interaction order with wound tending (#80225) ## About The Pull Request Fixes #80223 . See issue for information about the bug. This PR fixes it by placing wound tending before parent call but after surgery. It also fixes it by rewriting a little bit of medical stack item code to only block interaction chain when actually healing someone - This is not necessary with the above fix, but it futureproofs things. ## Changelog 🆑 Melbert fix: When using an item on a mob, you will always attempt to fix wounds AFTER surgery, BUT BEFORE the item's own interactions. As an example, this means using a mesh on a mob will attempt to progress surgery first, then attempt to fix any burn wounds, then heal burn damage. /🆑 * Fix some shenanigans involving interaction order with wound tending --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
|
787ae445d7 |
Fix some shenanigans involving interaction order with wound tending (#80225)
## About The Pull Request Fixes #80223 . See issue for information about the bug. This PR fixes it by placing wound tending before parent call but after surgery. It also fixes it by rewriting a little bit of medical stack item code to only block interaction chain when actually healing someone - This is not necessary with the above fix, but it futureproofs things. ## Changelog 🆑 Melbert fix: When using an item on a mob, you will always attempt to fix wounds AFTER surgery, BUT BEFORE the item's own interactions. As an example, this means using a mesh on a mob will attempt to progress surgery first, then attempt to fix any burn wounds, then heal burn damage. /🆑 |
||
|
|
b15b16976a |
[MIRROR] Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom [MDB IGNORE] (#25516)
* Attack chain refactoring: Broadening `tool_act` into `item_interact`, moving some item interactions to... `atom/item_interact` / `item/interact_with_atom`
* Patches up merge skew (#80197)
## About The Pull Request
Yeah #79968 (
|
||
|
|
1e76fd70b4 |
Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom (#79968)
## About The Pull Request Implements half of this (with some minor changes):  The ultimate goal of this is to split our attack chain in two: - One for non-combat item interactions - Health analyzer scanning - using tools on stuff - surgery - Niche other interactions - One for combat attacking - Item hit thing, item deal damage. - Special effects on attack would go here. This PR begins this by broadining tool act into item interact. Item interact is a catch-all proc ran at the beginning of attack chain, before `pre_attack` and such, that handles the first part of the chain. This allows us to easily catch item interaction and cancel the attack part of the chain by using deliberate bitflag return values, rather than `TRUE` / `FALSE`*. *Because right now, `TRUE` = `cancel attack`, no matter what, which is unclear to people. Instead of moving as much as possible to the new proc in this PR, I started by doing some easy, obvious things. More things can be moved in the future, or technically they don't even need to move in a lot of cases. ## Changelog 🆑 Melbert refactor: Refactored some methods of items interacting with other objects or mobs, such as surgery and health analzyers. Report if anything seems wrong /🆑 |
||
|
|
4c01e3f805 |
[MIRROR] Demotes the "electrical conductivity" flag from flags_1 to obj_flags [MDB IGNORE] (#25381)
* Demotes the "electrical conductivity" flag from `flags_1` to `obj_flags` (#80033) ## About The Pull Request Code to handle this flag only ever existed on the `/obj` sublevel, so there's no need for it to be on the `/atom` level `flags_1`. There was probably a point in time in which mobs or turfs conducted electricity but there's zero code for it anymore so we truly just live in a society now. ## Why It's Good For The Game Frees up a slot on `flags_1` (which is really nice actually), proper scoping of certain bitflag stuff, etc. ## Changelog Not relevant to players. I may have screwed something up, will be doing a few passes on this myself to ensure all the search and replaces went alright but we should be good™️ * Demotes the "electrical conductivity" flag from `flags_1` to `obj_flags` * Modular * Update misc.dm --------- Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
|
7f7688b60a |
Demotes the "electrical conductivity" flag from flags_1 to obj_flags (#80033)
## About The Pull Request
Code to handle this flag only ever existed on the `/obj` sublevel, so
there's no need for it to be on the `/atom` level `flags_1`. There was
probably a point in time in which mobs or turfs conducted electricity
but there's zero code for it anymore so we truly just live in a society
now.
## Why It's Good For The Game
Frees up a slot on `flags_1` (which is really nice actually), proper
scoping of certain bitflag stuff, etc.
## Changelog
Not relevant to players.
I may have screwed something up, will be doing a few passes on this
myself to ensure all the search and replaces went alright but we should
be good™️
|
||
|
|
87bfa7a61a |
[MIRROR] Fixes typo 'transfered', olive oil reaction repath [MDB IGNORE] (#23469)
* Fixes typo 'transfered', olive oil reaction repath * Modular * Update condiment.dm * Update recipes_guide.dm * Update _cup.dm --------- Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
|
69f51c6c65 |
Fixes typo 'transfered', olive oil reaction repath (#78064)
## About The Pull Request Transferred. ## Why It's Good For The Game How did this get to be in 71 files?! This bothers me. Also changes 'quality_oil' typepath in the reactions to 'olive_oil' to match its rename post-foodening. ## Changelog N/A |
||
|
|
2f552919c1 |
[MIRROR] Icons folder cleaning wave two [MDB IGNORE] (#22454)
* Icons folder cleaning wave two * Merge conflict resolution * Modular path hell * hmm * Update 2022-10.yml * Another modular thing --------- Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com> Co-authored-by: Giz <vinylspiders@gmail.com> |
||
|
|
bb3d041572 |
[Manual Mirror Fix] Removes shitty "status" variable on organs, makes them use organ_flag (#22480)
* Removes shitty "status" variable on organs, makes them use organ_flags instead (#76350) Title. Seriously this shit pisses me off, why are ORGAN_SYNTHETIC and ORGAN_ROBOTIC two different things? not applicable unless i fucked up --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> * Modulars * Some merge skew * More diffs --------- Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: Giz <vinylspiders@gmail.com> |
||
|
|
fb10121022 |
Icons folder cleaning wave two (#76788)
## About The Pull Request Further continous organizing and cleaning the Icons folder. There are still some minior nitpicks left to do, but I reached my daily sanity expenses limit again, and the faster these get in the less issues for both me and others later. Also cleans some mess I caused by my blindness last PR. ## Why It's Good For The Game Saner spriters = better sprites |
||
|
|
82cf9ea499 |
Removes shitty "status" variable on organs, makes them use organ_flags instead (#76350)
## About The Pull Request Title. ## Why It's Good For The Game Seriously this shit pisses me off, why are ORGAN_SYNTHETIC and ORGAN_ROBOTIC two different things? ## Changelog not applicable unless i fucked up --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> |
||
|
|
068089fb52 |
[MIRROR] Standardize Welder Fuel Usage [MDB IGNORE] (#21943)
* Standardize Welder Fuel Usage (#76021) Remove welder fuel usage from all actions except attacking and leaving it on most welder tasks require a minimum of 1u of fuel, some longer tasks require a minimum of 2 or 3u welders now drain 1u every 5 seconds they're active ## About The Pull Request Prior to this PR welder fuel usage was random, a lot of tasks didn't use any welder fuel and welders were basically near infinite so long as you didn't use them for combat, it took 26 seconds of activity to drain 1u of fuel, that means an emergency welder alone could run for 5 minutes straight before needing a refuel After this PR all welders will drain 1u every 5 seconds instead of every 26 seconds, but welding objects won't require extra fuel anymore, making the fuel usage much more consistent. resolves #55018 ## Why It's Good For The Game Actually makes fuel tanks useful and relevant without making it obnoxious to do repetitive quick tasks like turn rods into plates, there's actually a reason to upgrade off the emergency welder now since it lasts 50 seconds rather than 5 minutes ## Changelog 🆑 qol: Welders now have a more consistent fuel usage /🆑 * Standardize Welder Fuel Usage --------- Co-authored-by: Couls <coul422@gmail.com> |
||
|
|
c0e46fabf7 |
Standardize Welder Fuel Usage (#76021)
Remove welder fuel usage from all actions except attacking and leaving it on most welder tasks require a minimum of 1u of fuel, some longer tasks require a minimum of 2 or 3u welders now drain 1u every 5 seconds they're active ## About The Pull Request Prior to this PR welder fuel usage was random, a lot of tasks didn't use any welder fuel and welders were basically near infinite so long as you didn't use them for combat, it took 26 seconds of activity to drain 1u of fuel, that means an emergency welder alone could run for 5 minutes straight before needing a refuel After this PR all welders will drain 1u every 5 seconds instead of every 26 seconds, but welding objects won't require extra fuel anymore, making the fuel usage much more consistent. resolves #55018 ## Why It's Good For The Game Actually makes fuel tanks useful and relevant without making it obnoxious to do repetitive quick tasks like turn rods into plates, there's actually a reason to upgrade off the emergency welder now since it lasts 50 seconds rather than 5 minutes ## Changelog 🆑 qol: Welders now have a more consistent fuel usage /🆑 |