mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-14 01:24:21 +01:00
masterfixes
36 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Cabbage
|
8d1a6ef646 |
Quality of life for the Hearth (#5421)
## About The Pull Request Changes a bit of code. - Alters the code for wallframes, fixing and allowing the bubber edit to actually allow placement without proper flooring. - Alters the code for the large mortar, allowing it to accept anything that can be ground up into reagents (similar to the small one). - Allows crafted wall torches to be mounted on any wall, regardless of whether the area is powered or if there's a valid floor. Adds in a few quality of life improvements to the Hearthkin Hearth. - Eggplant seeds to the seed barrels. - Small pottery corner with some sand and bricks. - Glassblowing crate for ease of access. - Serving tray for ease of mass-cooking. ## Why It's Good For The Game Small code fixes to give functionality to previously broken implements. Small quality of life things to show more things to do to the ghost roles as well as allowing them easier access to said things, while not overly reducing the amount of time neccessary to spend on said things. ## Proof Of Testing Code changes work properly and as intended. Map changes load properly and are functional. No errors when building. ## Changelog 🆑 add: Added the ability for crafted wall torches to be mounted on walls regardless of floor or area power. fix: The large mortar can now properly grind and juice things, including items like injectors and sheets of material. fix: Fixed an error in wallmounting code preventing a bubber bypass from working. map: Added a small clay-working corner, glassblowing kit, serving tray and eggplant seeds to the hearth. /🆑 --------- Co-authored-by: Cabbage <supredoode@gmail.com> |
||
|
nevimer
|
00ccf0c6b5 |
Merge remote-tracking branch 'tgstation/master' into upstream-feb12-2026
# Conflicts: # .github/CODEOWNERS # .github/workflows/compile_changelogs.yml # .github/workflows/stale.yml # SQL/database_changelog.md # _maps/map_files/CatwalkStation/CatwalkStation_2023.dmm # code/__DEFINES/atom_hud.dm # code/__DEFINES/inventory.dm # code/__DEFINES/mobs.dm # code/__DEFINES/species_clothing_paths.dm # code/__DEFINES/subsystems.dm # code/__DEFINES/surgery.dm # code/__HELPERS/global_lists.dm # code/_globalvars/lists/maintenance_loot.dm # code/_globalvars/traits/_traits.dm # code/controllers/subsystem/minor_mapping.dm # code/controllers/subsystem/processing/quirks.dm # code/controllers/subsystem/shuttle.dm # code/datums/components/palette.dm # code/datums/components/surgery_initiator.dm # code/datums/diseases/advance/advance.dm # code/datums/hud.dm # code/datums/mood.dm # code/datums/mutations/chameleon.dm # code/datums/quirks/negative_quirks/nyctophobia.dm # code/datums/status_effects/debuffs/debuffs.dm # code/datums/status_effects/debuffs/drunk.dm # code/datums/status_effects/debuffs/slime/slime_leech.dm # code/datums/weather/weather.dm # code/game/data_huds.dm # code/game/objects/items.dm # code/game/objects/items/devices/scanners/health_analyzer.dm # code/game/objects/items/frog_statue.dm # code/game/objects/items/rcd/RLD.dm # code/game/objects/items/robot/items/hypo.dm # code/game/objects/items/stacks/medical.dm # code/game/objects/items/stacks/wrap.dm # code/game/objects/items/storage/garment.dm # code/game/objects/items/tools/medical/defib.dm # code/game/objects/items/weaponry.dm # code/game/objects/items/weaponry/melee/misc.dm # code/game/objects/structures/crates_lockers/closets/secure/security.dm # code/game/objects/structures/curtains.dm # code/game/objects/structures/dresser.dm # code/game/objects/structures/girders.dm # code/game/objects/structures/maintenance.dm # code/game/objects/structures/mirror.dm # code/modules/admin/greyscale_modify_menu.dm # code/modules/admin/verbs/light_debug.dm # code/modules/antagonists/ashwalker/ashwalker.dm # code/modules/antagonists/heretic/knowledge/starting_lore.dm # code/modules/antagonists/ninja/ninjaDrainAct.dm # code/modules/art/paintings.dm # code/modules/client/preferences.dm # code/modules/client/verbs/ooc.dm # code/modules/clothing/head/wig.dm # code/modules/events/disease_outbreak.dm # code/modules/holodeck/holo_effect.dm # code/modules/jobs/job_types/head_of_security.dm # code/modules/jobs/job_types/security_officer.dm # code/modules/library/skill_learning/generic_skillchips/point.dm # code/modules/mining/lavaland/ash_flora.dm # code/modules/mining/lavaland/mining_loot/megafauna/ash_drake.dm # code/modules/mob/dead/new_player/new_player.dm # code/modules/mob/living/basic/guardian/guardian.dm # code/modules/mob/living/basic/space_fauna/space_dragon/space_dragon.dm # code/modules/mob/living/carbon/carbon.dm # code/modules/mob/living/carbon/human/human.dm # code/modules/mob/living/carbon/human/human_defines.dm # code/modules/mob/living/carbon/life.dm # code/modules/mob/living/living.dm # code/modules/mob/living/living_defines.dm # code/modules/mob/mob.dm # code/modules/mob_spawn/ghost_roles/mining_roles.dm # code/modules/mod/mod_control.dm # code/modules/mod/modules/modules_general.dm # code/modules/modular_computers/computers/item/computer_ui.dm # code/modules/paperwork/paper.dm # code/modules/paperwork/paperbin.dm # code/modules/power/lighting/light.dm # code/modules/projectiles/guns/energy/kinetic_accelerator.dm # code/modules/projectiles/projectile.dm # code/modules/reagents/chemistry/reagents/drinks/alcohol_reagents.dm # code/modules/reagents/chemistry/reagents/food_reagents.dm # code/modules/reagents/chemistry/reagents/other_reagents.dm # code/modules/reagents/chemistry/reagents/pyrotechnic_reagents.dm # code/modules/research/xenobiology/crossbreeding/_clothing.dm # code/modules/research/xenobiology/crossbreeding/prismatic.dm # code/modules/surgery/advanced/brainwashing.dm # code/modules/surgery/advanced/lobotomy.dm # code/modules/surgery/amputation.dm # code/modules/surgery/blood_filter.dm # code/modules/surgery/bodyparts/_bodyparts.dm # code/modules/surgery/brain_surgery.dm # code/modules/surgery/cavity_implant.dm # code/modules/surgery/coronary_bypass.dm # code/modules/surgery/gastrectomy.dm # code/modules/surgery/healing.dm # code/modules/surgery/limb_augmentation.dm # code/modules/surgery/organ_manipulation.dm # code/modules/surgery/revival.dm # code/modules/surgery/sleeper_protocol.dm # code/modules/surgery/surgery_helpers.dm # code/modules/surgery/surgery_step.dm # code/modules/unit_tests/_unit_tests.dm # code/modules/unit_tests/designs.dm # code/modules/unit_tests/icon_state_worn.dm # code/modules/unit_tests/screenshots/screenshot_antag_icons_cultist.png # code/modules/unit_tests/screenshots/screenshot_antag_icons_headrevolutionary.png # code/modules/unit_tests/screenshots/screenshot_antag_icons_provocateur.png # code/modules/unit_tests/screenshots/screenshot_husk_body.png # code/modules/unit_tests/screenshots/screenshot_husk_body_missing_limbs.png # icons/map_icons/clothing/head/_head.dmi # icons/map_icons/clothing/shoes.dmi # icons/map_icons/items/_item.dmi # icons/mob/huds/hud.dmi # icons/mob/inhands/64x64_lefthand.dmi # icons/mob/inhands/64x64_righthand.dmi # icons/obj/machines/computer.dmi # tgui/packages/tgui/interfaces/OperatingComputer.jsx # tgui/packages/tgui/interfaces/PreferencesMenu/CharacterPreferences/MainPage.tsx # tgui/packages/tgui/interfaces/PreferencesMenu/types.ts # tgui/packages/tgui/interfaces/SurgeryInitiator.tsx # tools/icon_cutter/check.py |
||
|
SyncIt21
|
7fc6e1402a |
Additional maintenance for plumbing related stuff (#94753)
## About The Pull Request **Qol** - Adds examines & screen tips for washing items in sinks - Adds examines & screen tips for wall frame items i.e deconstructing with wrench & what structures you can mount them on **Fixes** - Plumbing components inside shuttles now properly reconnect - Plumbing iv drip has their connectors (red & blue pipes) visible again - Sinks consume reagents when washing and won't wash when it becomes dry - Fixes #94942 placing ducts by hand on turf won't run time. Also Plumbing machinery properly reconnects when un wrenching ducts in circular connections - All plumbing machinery now operates in the plumbing subsystem & map loaded machines begin processing **Refactor** - Refactored sink frame into a wall frame item meaning it can now be carried in hand and mounted on walls - Refactored the sink attack chain to use `item_interaction()` instead of `attackby()` - All sinks are now wall mounted components meaning destroying the wall they are attached to will cause it to deconstruct ## Changelog 🆑 qol: added examines & screen tips for wall frame items qol: added examines & screen tips for washing items in sinks fix: plumbing components inside shuttles reconnect to their machine counterparts correctly fix: plumbing iv drip has its red & blue connectors visible again fix: sinks consume reagents when washing and won't wash when it becomes dry fix: map loaded plumbing machines begin processing fix: placing stack of ducts by hand of ducts works again fix; plumbing machinery properly reconnects when un wrenching ducts in circular connections refactor: sinks are now proper wall mounted components meaning destroying their attached walls will cause it to get destroyed & sink frames are wall frame items that can be carried in hand /🆑 |
||
|
SyncIt21
|
c27e434dcc |
Objects mounted in shuttle areas drop again & relocates some shuttle objects (#94611)
## About The Pull Request - Fixes #94119 > This will require a different solution which someone smarter than me has to figure out in the foreseeable future Today me is now smarter than yesterday me. We basically just unmount when the object is about to shuttle moved and remount after it has been shuttle moved This also map edits some objects that could not be mounted in shuttles previously ## Changelog 🆑 fix: objects mounted in shuttle areas deconstruct when their support structure is destroyed fix: fixes runtime in arrivals shuttle when its request console is destroyed map: moved around some objects in shuttles so they can be mounted on its walls again /🆑 |
||
|
SyncIt21
|
468b351b86 |
Axes grind & juice vars into procs (#94592)
## About The Pull Request Inspired by #94233. `grind_results`(list) & `juice_typepath`(typepath) are only used when grinding & juicing after which the atom is deleted. This means if that object is not processed these vars occupy memory & don't do anything. Now these values are only generated on demand by calling their respective procs. Considering how these vars are on the obj level the memory savings are quite significant ## Changelog 🆑 refactor: grinding & juicing have been refactored to occupy low memory. Report bugs on github code: improved grinding & juicing code /🆑 |
||
|
SyncIt21
|
226ca2f9f3 |
Some wall mount improvements (#94499)
## About The Pull Request - Fixes #94497. Adds atom mount component directly but only for non shuttle areas - Hand placed posters are pixel shifted onto the wall and not directly force moved allowing for stuff like acid/fire to interact with them - Hand placing posters & signs apply the atom mounted component directly without calling `find_and_mount_on_atom()` ## Changelog 🆑 code: improves code for placing posters and signs on walls fix: hand placed posters now interact with fire/acid on their mounted turf fix: wallframes in player hands gets consumed when mounted in shuttle areas /🆑 |
||
|
shayoki
|
28e23abe01 | modular walltoys | ||
|
SyncIt21
|
f640a0e972 |
Enhances algorithm for finding an atom mount (#94076)
## About The Pull Request Depends on #94064 for the unit test but offers a better method for finding an atom to mount on - Finding a mount now takes into consideration the objects pixel x & y offsets meaning diagonal mounting is now supported. Gives great flexibility for mappers - If you don't want to use pixel offsets but default back to using the objects direction that behaviour is still preserved. Useful if your object uses directional icon states(lights & cameras for now) AND don't use offsets - If no direction could be specified then as the last resort it defaults back to the objects local turf for mounting ## Changelog 🆑 fix: all mounted objects on tables, fences, windows & walls should fall of correctly when the atom it is placed on is destroyed fix: security telescreen now falls off when their mounted wall is destroyed fix: defib wall mount falls off when their mounted wall is destroyed fix: floor lights are mounted to the ground/catwalk/tram floor they are sitting on meaning destroying it will destroy the light fix: wall mounted plaques now fall off when their mounted wall is destroyed /🆑 |
||
|
SyncIt21
|
39a196824a |
Enhances algorithm for finding an atom mount (#94076)
## About The Pull Request Depends on #94064 for the unit test but offers a better method for finding an atom to mount on - Finding a mount now takes into consideration the objects pixel x & y offsets meaning diagonal mounting is now supported. Gives great flexibility for mappers - If you don't want to use pixel offsets but default back to using the objects direction that behaviour is still preserved. Useful if your object uses directional icon states(lights & cameras for now) AND don't use offsets - If no direction could be specified then as the last resort it defaults back to the objects local turf for mounting ## Changelog 🆑 fix: all mounted objects on tables, fences, windows & walls should fall of correctly when the atom it is placed on is destroyed fix: security telescreen now falls off when their mounted wall is destroyed fix: defib wall mount falls off when their mounted wall is destroyed fix: floor lights are mounted to the ground/catwalk/tram floor they are sitting on meaning destroying it will destroy the light fix: wall mounted plaques now fall off when their mounted wall is destroyed /🆑 |
||
|
nevimer
|
baf3837ae8 |
Merge remote-tracking branch 'tgstation/master' into upstream-2025-11-29
# Conflicts: # _maps/RandomRuins/SpaceRuins/derelict_sulaco.dmm # _maps/RandomRuins/SpaceRuins/garbagetruck2.dmm # _maps/map_files/CatwalkStation/CatwalkStation_2023.dmm # _maps/map_files/tramstation/tramstation.dmm # code/_onclick/hud/new_player.dm # code/datums/components/squashable.dm # code/datums/diseases/advance/symptoms/heal.dm # code/datums/diseases/chronic_illness.dm # code/datums/status_effects/buffs.dm # code/datums/status_effects/debuffs/drunk.dm # code/datums/status_effects/debuffs/stamcrit.dm # code/game/machinery/computer/crew.dm # code/game/objects/items/devices/scanners/health_analyzer.dm # code/game/objects/items/wall_mounted.dm # code/game/turfs/closed/indestructible.dm # code/modules/admin/view_variables/filterrific.dm # code/modules/antagonists/heretic/influences.dm # code/modules/cargo/orderconsole.dm # code/modules/client/preferences.dm # code/modules/events/space_vines/vine_mutations.dm # code/modules/mob/dead/new_player/new_player.dm # code/modules/mob/living/carbon/human/death.dm # code/modules/mob/living/carbon/human/species_types/jellypeople.dm # code/modules/mob/living/damage_procs.dm # code/modules/mob/living/living.dm # code/modules/mob_spawn/ghost_roles/mining_roles.dm # code/modules/mob_spawn/mob_spawn.dm # code/modules/projectiles/ammunition/energy/laser.dm # code/modules/projectiles/guns/ballistic/launchers.dm # code/modules/projectiles/guns/energy/laser.dm # code/modules/reagents/chemistry/machinery/chem_dispenser.dm # code/modules/reagents/chemistry/reagents/cat2_medicine_reagents.dm # code/modules/reagents/chemistry/reagents/drinks/alcohol_reagents.dm # code/modules/reagents/chemistry/reagents/medicine_reagents.dm # code/modules/surgery/healing.dm # code/modules/unit_tests/designs.dm # icons/mob/inhands/items_lefthand.dmi # icons/mob/inhands/items_righthand.dmi # tgui/packages/tgui/interfaces/ChemDispenser.tsx |
||
|
SyncIt21
|
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 /🆑 |
||
|
Roxy
|
ce509e0ad5 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-23-10-2025 | ||
|
die
|
54198986b7 | generic device handling sounds (#93536) | ||
|
Roxy
|
e28e9fbdba | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-23-10-2025 | ||
|
SyncIt21
|
9740c687de |
General maintenance for wall mounts (#93534)
## About The Pull Request - Fixes #93392 - Replaces all custom callbacks with call to `deconstruct()`. The callbacks weren't necessary as it did the same thing as `deconstruct()` but in an round about way - Removed duplicate `Initialize()` procs and the params `building` & `ndir` from all wall mounts. Makes everything cleaner ## Changelog 🆑 fix: wall mounts placed by player now falls off when the wall they are mounted on is destroyed code: cleaned up wall mount code /🆑 |
||
|
SpaceCatSS13
|
7b6960af81 |
Adds gloryhole portals and stuck in wall content. (#3713)
## About The Pull Request Adds the LustWish portal bore to the vendor, an item that allows you to connect two locations via a portal that can act either as a gloryhole or a route for stuck in wall content. These portals allow for remote scenes using subtler or interact menu verbs.   ## Why It's Good For The Game I've heard requests for both portal play and gloryhole content, this scratches both itches sufficiently in my opinion ## Proof Of Testing <details> <summary> Screenshots/Videos</summary> Both modes pictured  </details> ## Changelog 🆑 add: The Lustwish Portal Bore has been added, equipped with both a gloryhole and stuck in wall mode, your lower half can now be in dorms while your head performs your job /🆑 --------- Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Roxy <75404941+TealSeer@users.noreply.github.com> Co-authored-by: The Sharkening <95130227+StrangeWeirdKitten@users.noreply.github.com> Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com> |
||
|
SmArtKar
|
77a67fa4c5 |
[NO GBP] Fixes wallmounts not being mountable by using a screwdriver on them (#86768)
## About The Pull Request Consequence of #86661, god damnit Closes #86767 ## Changelog 🆑 fix: Fixed wallmounts not being mountable by using a screwdriver on them /🆑 |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
LemonInTheDark
|
4b4e9dff1d |
Wallening [IDB IGNORE] [MDB IGNORE] (#85491)
## What's going on here Kept you waitin huh! This pr resprites most all walls, windows and other "wall adjacent" things to a 3/4th perspective, technical term is "tall" walls (we are very smart). If you're trying to understand the technical details here, much of the "rendering tech" is built off the idea of split-vis. Basically, split a sprite up and render it on adjacent turfs, to prevent seeing "through" walls/doors, and to support seeing "edges" without actually seeing the atom itself. Most of the rest of it is pipelining done to accommodate how icons are cut. ## Path To Merge Almost* all sprites and code is done at this point. There are some things missing both on and off the bounty list, but that will be the case forever unless we force upstream (you guys) to stop adding new shit that doesn't fit the style. I plan on accepting and integrating prs to the current working repo <https://github.com/wall-nerds/wallening> up until a merge, to make contribution simpler and allow things like bounties to close out more easily This pr is quite bulky, even stripping away map changes it's maybe 7000 LOC (We have a few maps that were modified with UpdatePaths, I am also tentatively pring our test map, for future use.) This may inhibit proper review, although that is part of why I am willing to make it despite my perfectionism. Apologies in advance. Due to the perspective shift, a lot of mapping work is going to need to be done at some point. This comes in varying levels of priority. Many wallmounts are offset by hand, some are stuck in the wall/basically cannot be placed on the east/west/north edges of walls (posters), some just don't look great good in their current position. Tests are currently a minor bit yorked, I thought it was more important to get this up then to clean them fully. ## What does it look like?       ## Credits <details> <summary>Historical Mumbojumbo</summary> I am gonna do my best to document how this project came to be. I am operating off third party info and half remembered details, so if I'm wrong please yell at me. This project started sometime in late 2020, as a product of Rohesie trying to integrate and make easier work from Mojave Sun (A recently defunct fallout server) with /tg/. Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man is insane) was working with tall walls, IE walls that are 48px tall instead of the normal 32. This was I THINK done based off a technical prototype from aao7 proving A it was possible and B it didn't look like dogwater. This alongside oranges begging the art team for 3/4th walls (he meant TGMC style) lead to Rohesie bringing on contributors from general /tg/, including actionninja who would eventually take over as technical lead and Kryson, who would define /tg/'s version of the artstyle. Much of the formative aspects of this project are their work. The project was coming along pretty well for a few months, but ran into serious technical issues with `SIDE_MAP`, a byond map_format that allows for simpler 3/4th rendering. Due to BULLSHIT I will not detail here, the map format caused issues both at random with flickering and heavily with multiz. Concurrent with this, action stepped down after hacking out the rendering tech and starting work on an icon cutter that would allow for simpler icon generation, leaving ninjanomnom to manage the project. Some time passed, and the project stalled out due to the technical issues. Eventually I built a test case for the issues we had with `SIDE_MAP` and convinced lummox jr (byond's developer) to explain how the fuckin thing actually worked. This understanding made the project theoretically possible, but did not resolve the problems with multi-z. Resolving those required a full rework of how rendering like, worked. I (alongside tattle) took over project development from ninjanomnom at this time, and started work on Plane Cube (#69115), which when finished would finally make the project technically feasible. The time between then and now has been slow, progressive work. Many many artists and technical folks have dumped their time into this (as you can see from the credits). I will get into this more below but I would like to explicitly thank (in no particular order) tattle, draco, arcanemusic, actionninja, imaginos, viro and kylerace for keeping the project alive in this time period. I would have curled up into a ball and died if I had to do this all myself, your help has been indispensable. </details> <details> <summary>Detailed Credits</summary> Deep apologies if I have forgotten someone (I am sure I have, if someone is you please contact me). I've done my best to collate from the git log/my memory. Thanks to (In no particular order): Raccoff: Being funny to bully, creating threshold decals for airlocks aa07: (I think) inspiring the project ActionNinja: Laying the technical rock we build off, supporting me despite byond trying to kill him, building the icon cutter that makes this possible ArcaneMusic: Artistic and technical work spanning from the project's start to literally today, being a constant of motivation and positivity. I can't list all the stuff he's done Armhulen: Key rendering work (he's the reason thindows render right), an upbeat personality and a kick in the ass. Love you arm Azlan: Damn cool sprites, consistently Ben10Omintrix: You know ben showed up just to make basic mobs work, he's just fuckin like that man BigBimmer: A large amount of bounty work, alongside just like, throwing shit around. An absolute joy to work with Capsandi: Plaques, blastdoors, artistic work early on CapybaraExtravagante: Rendering work on wall frames Draco: SO MUCH STUFF. Much of the spritework done over the past two years is his, constantly engaged and will take on anything. I would have given up if not for you Floyd: Early rendering work, so early I don't even know the details. Enjoy freedom brother Imaginos16: A guiding hand through the middle years, handled much of the sprite review and contribution for a good bit there Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of effort dissecting feedback with a focus on making things as good as they can be at the jump Infrared: Part of the impetus for the project, made all the xenomorph stuff in the MS style Jacquerel: A bunch of little upkeep/technical things, has done so much sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES) Justice12354: Solved a bunch of error sprites (and worked out how to actually make prs to the project) Thanks bro! Kryson: Built the artstyle of the project, carrying on for years even when it was technically dying, only stopping to casually beat cancer. So much of our style and art is Kryson KylerAce: Handled annoying technical stuff for me, built window frame logic and fully got rid of grilles. LemonInTheDark: Rendering dirtywork, project management and just so much fucking time in dreammaker editing sprites Meyhazah: Table buttons, brass windows and alll the old style doors Mothblocks: Has provided constant support, gave me a deadline and motivation, erased worries about "it not being done", gave just SO much money to fill in the critical holes in sprites. Thanks moth MTandi: Contributed art despite his own blackjack and hookers club opening right down the road, I'm sorry I rolled over some of your sprites man I wish we had finished earlier Ninjanomnomnom: Consulted on gags issues, kept things alive through some truly shit times oranges: This is his fault Rohesie: Organized the effort, did much of the initial like, proof of concept stuff. I hope you're doin well whatever you're up to. san7890: Consulting on mapper UX/design problems, being my pet mapper Senefi: Offsetting items with a focus on detail/the more unused canidates SimplyLogan: Detailed map work and mapper feedback, personally very kind even if we end up talking past each other sometimes. Thank you! SpaceSmithers: Just like, random mapping support out of nowhere, and bein a straight up cool dude Tattle: A bunch of misc project management stuff, organizing the discord, managing the test server, dealing with all the mapping bullshit for me, being my backup in case of bus. I know you think you didn't do much but your presence and work have been a great help Thunder12345: Came out of nowhere and just so much of the random bounties, I'm kind of upset about how much we paid him Time-Green: I hooked him in by fucking with stuff he made and now he's just doin shit, thanks for helping out man! Twaticus: Provided artistic feedback and authority for my poor feeble coder brain, believed in the project for YEARS, was a constant source of ❤️ and affirmation unit0016: I have no god damn idea who she is, popped out of nowhere on the github one day and dealt with a bunch of annoying rendering/refactoring. Godspeed random furry thank you for all your effort and issue reports Viro: A bunch of detailed spriting moving towards 3/4ths, both on and off the wallening fork. If anyone believed this project would be done, it was viro Wallem: Artistic review and consultation, was my go-to guy for a long time when the other two spritetainers were inactive Waltermeldon: Cracked out a bunch of rendering work, he's the reason windows look like not dogwater. Alongside floyd and action spent a TON of time speaking to lummox/unearthing how byond rendering worked trying to make this thing happen ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin bugaboo that was living in my brain like it was nothing. Love you brother And finally: The Mojave Sun development team. They provided a testbed for the idea, committed hundreds and hundreds of hours to the artstyle, and were a large reason we caught issues early enough to meaningfully deal with them. Your work is a testament to what longterm effort and deep detailed care produce. I hope you're doing well whatever you're up to. Go out with a bang! </details> ## Changelog 🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan, Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd, Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson, KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom, oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner, SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016, Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team! add: Resprites or offsets almost all "tall" objects in the game to match a 3/4ths perspective add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: = <stewartareid@outlook.com> Co-authored-by: Capsandi <dansullycc@gmail.com> Co-authored-by: ArcaneMusic <hero12290@aol.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com> Co-authored-by: KylerAce <kylerlumpkin1@gmail.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com> Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com> Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com> Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com> Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> Co-authored-by: Rob Bailey <github@criticalaction.net> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
YesterdaysPromise
|
71a1fee2f1 |
Explodes device.dmi (#80025)
## About The Pull Request I woke up today and thought 'what would be easy thing to do today so I can say I've done something?'. Then I remembered I saw several gangtool usages the time I split radio up, and I could remedy those. 7 hours later, device.dmi is split in a folder of its own, and I've also given unique sprites to door remotes and landing desginators. ## Why It's Good For The Game The device.dmi was kind of a mess. ## Changelog 🆑 /🆑 |
||
|
MrMelbert
|
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 /🆑 |
||
|
san7890
|
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™️
|
||
|
YesterdaysPromise
|
f4535255c0 |
Nukes radio.dmi, adds inhands for somewhat relevant items. (#79792)
## About The Pull Request Third /icon/ cleansing splinter 1. Comments on commits say all it does pretty much.  ## Why It's Good For The Game Inhand for walkietalkie was requested in the project, gets rid of some usecases of old 'gangtool', headset splitoff requested by Fazzie. Inhands reflecting the items they are supposed to represent is nice. ## Changelog 🆑 image: Following now have unique item sprites: syndicate war declaration radio, curator and chief beacon's, chaplain beacon. image: Following now have unique inhand sprites: radio, export scanner, walkie-talkie, syndicate war declaration radio, curator and chief beacon's, chaplain beacon. /🆑 |
||
|
SyncIt21
|
aa44be14e8 |
Makes /datum/component/wall_mounted actually do it's job (#78439)
## About The Pull Request This component added in #77417 never actually worked. It has 2 problems **1. Nothing even gets dismounted** https://github.com/tgstation/tgstation/assets/110812394/8859794c-e2da-4bf2-bf2e-cd44fb240872 This is because a ton of objects in game don't actually pass a callback when the object is getting dismounted i.e. they pass no params to the `find_and_hang_on_wall()` proc for e.g. https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/game/objects/items/wall_mounted.dm#L58 and because the callback is null the action https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/datums/components/wall_mounted.dm#L54 never gets executed. Now to combat this in the `Initialize()` proc a null check is done to ensure the callback is not null https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/datums/components/wall_mounted.dm#L15-L18 But this code itself is broken for 2 reasons 1. We create a callback using the `CALLBACK` macro they are not the same as `TYPE_PROC_REF` also we never specify which object this proc ref should even be called on 2. `on_drop` ends up null anyway because we first check if the param is null and set its value here https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/datums/components/wall_mounted.dm#L15-L16 But then we again overwrite `on_drop` with the param passed(which is null) so it ends up becoming null again https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/datums/components/wall_mounted.dm#L18 So this never did it's job. Also we simply can't create a callback on `obj/deconstruct` because this proc accepts a boolean as it's param https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/game/objects/obj_defense.dm#L150 But we pass the `hanging_param` as its param when invoking the callback https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/datums/components/wall_mounted.dm#L54 Which would cause undefined behaviour so we have to manually do a null check for this param and call the `deconstruct` proc explicitly to ensure correct behaviour **2. Wall mounts created in round would runtime** **Reproduction** 1. Use some iron sheets to construct an air alarm wall frame(or any wallmount of your choice) 4. Put on wall 5. Get stack trace  This occurred because the component received an invalid parent when mounting was attempted.  Which was caused by https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/game/objects/items/wall_mounted.dm#L45 We should be doing this the other way around i.e. `hanging_object.AddComponent(/datum/component/wall_mounted, on_wall)` But the truth is even this is not required nor is this https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/game/objects/items/wall_mounted.dm#L58 These 2 lines of code are not necessary because a lot of objects call `find_and_hang_on_wall()` proc by themselves in their `Initialization()` proc for e.g. https://github.com/tgstation/tgstation/blob/11ec431834d384b9a813d8e2a9a28758d942ad7c/code/modules/atmospherics/machinery/air_alarm/_air_alarm.dm#L127 So the work is already done for us. we were just adding the component 2 more times for no reason and causing problems. ## Changelog 🆑 fix: wall mounted objects air alarms, fire alarms etc now actually falls off/gets destroyed when their attached wall is deconstructed fix: wall mounts crafted in game also properly falls off/gets destroyed when their attached wall is deconstructed /🆑 |
||
|
ArcaneMusic
|
a77ac3e4f1 |
Adds a new component so that items that are "attached" to walls will now drop/deconstruct on turf destruction. (#77417)
## About The Pull Request Adds a new component, called wall_mounted, which applies on the wallframe objects on construction, as well as a number of wall frame objects and structures to cover mapped in, roundstart objects of the like. I might have forgotten a few, but this covers the vast majority that players will run into in a given round. This will cover wall destruction, turf explosion, the whole nine yards, and call that object/structure/machine's deconstruct proc. We have some special handling for intercoms as well since they're apparently items. So most basic case is this: You have a wall. that wall holds a sign. If you examine the wall, it tells you that the wall is currently supporting the **Example Sign**. It tells you that if the wall is damaged or destroyed, the sign will **fall off the wall.** So, if you were to welder, bomb, or hulk your way through that wall, it would call the deconstruct() proc on that sign, and fall off the wall, leaving an item sign at the foot of the wall. ## To-Do - [x] Stop breaking all wallmounts when operating shuttles (Signal conflict with COMSIG_TURF_CHANGED 😔) - [x] Confirm that the ~~deconstruct~~ designated proc of each wallmount falling is sane for the intended object - [x] Clean up the contents of the wall_mounted component to reduce copy-paste on object init. - [x] Add it to more stuff that may just not have a directional helper? - [x] ~~Change how APC construction is handled to make it easier!~~ - [x] ~~Don't accidently nerf malf AI into the ground I guess~~ ## Why It's Good For The Game Closes #22283. Helps close more of #47526. Closes #54983. Closes https://github.com/wall-nerds/wallening/issues/90. All of these objects are "wall mounts". It stands to reason that they're mounted to the walls they appear to be attached to. This attempts to rectify them by giving them a turf link to the turf they're mounted to, and then upon changes to that turf, dropping or breaking that object. It'll need a little more polish to get to 100%, since I can see a few more issues to iron out first, but I'm dropping this here for now to get some feedback and put some fire under me to get this completed. ## Changelog 🆑 add: Wall mounted objects (Things like APCs, Air Alarms, Light switches, Signs, Posters, Newscasters, you name it) will now fall to the ground and break or deconstruct when their attaching wall is changed or broken. /🆑 |
||
|
YesterdaysPromise
|
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 |
||
|
ArcaneMusic
|
f2fd69a49a |
Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. (#75052)
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you all here (through the automatic reviewer request system). So, mineral balance! Mineral balance is less a balance and more of a nervous white dude juggling spinning plates on a high-wire on his first day. The fact it hasn't failed after going on this long is a miracle in and of itself. This PR does not change mineral balance. What this does is moves over every individual cost, both in crafting recipes attached to an object over to a define based system. We have 3 defines: `sheet_material_amount=2000` . Stock standard mineral sheet. This being our central mineral unit, this is used for all costs 2000+. `half_sheet_material_amount=1000` . Same as above, but using iron rods as our inbetween for costs of 1000-1999. `small_material_amount=100` . This hits 1-999. This covers... a startlingly large amount of the codebase. It's feast or famine out here in terms of mineral costs as a result, items are either sheets upon sheets, or some fraction of small mats. Shout out to riot darts for being the worst material cost in the game. I will not elaborate. Regardless, this has no functional change, but it sets the groundwork for making future changes to material costs much, MUCH easier, and moves over to a single, standardized set of units to help enforce coding standards on new items, and will bring up lots of uncomfortable balance questions down the line. For now though, this serves as some rough boundaries on how items costs are related, and will make adjusting these values easier going forward. Except for foam darts. I did round up foam darts. Adjusting mineral balance on the macro scale will be as simple as changing the aforementioned mineral defines, where the alternative is a rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~ Items individual numbers have not been adjusted yet, but we can standardize how the conversation can be held and actually GET SOMEWHERE on material balance as opposed to throwing our hands up or ignoring it for another 10 years. |
||
|
SyncIt21
|
d48dc255d8 |
Final Patches for RCD related devices. (#74592)
## About The Pull Request Final closing act for #74527, some more bugs to squash. 1. Fixes broken sprite for rack in RCD UI  2. Fixes #41114 mounted RCD can lay plating on chasm/ any open turf again 3. Removes unused turf argument inside `try_clean()`, `try_wallmount()`, & `try_decon()` procs because well it was unused ## Changelog 🆑 refactor: remove unused turf var inside wallmount procs fix: broken rack sprite inside RCD UI fix: mounted RCD now lays plating over chasms and open turfs /🆑 |
||
|
SyncIt21
|
add6d49951 |
Code clean-up & refactor for all RCD related & like devices. (#74527)
## About The Pull Request
1. Debloats the RCD.dm file i.e. renames it to RHD[Rapid handheld device
the base for all rcd like devices] and moves its subtypes into their
respective files
`/obj/item/construction/rcd` moved to RCD.dm
`/obj/item/construction/rld` moved to RLD.dm
`/obj/item/construction/plumbing` moved to RPLD.dm
`/obj/item/construction/rtd` stays in RTD.dm
Other rcd like device i.e. RPD, RFC, RWD, along with the above mentioned
files are now all moved into 1 folder called "rcd"
majority of the `to_chat()` are now replaced with `balloon_alert()` to
reduce spam
2. Adds early returns, optimizes & adds extra resource sanity checks
before and after the `do_after()` proc for the RLD. RLD silo links now
works again.
- RLD now uses an ammo bar just like the RCD for updating only its
overlays & not its entire icon state, it also has a blinking yellow icon
state when low on ammo
- Remove unused empty blinking yellow icon state for plumbing RCD.
nobody designed the ammo bars for them so having`has_ammobar = TRUE`
caused the unit tests to fail
4. Adds extra structure placement & resource sanity checks for RCD, RTD
& Plumbing RCD before & after the `do_after()` proc
RCD Patches
- removes unused vars window_type & window_glass, these can be infered
from window_type directly
- removes furnish type & cost and let the rcd_vals() proc decide those
for consistency
- copies the rcd stuff from turf/floor to turf/open/misc with some
exceptions, It wasen't updated in a long time
- rcd vals i.e. cost & delay for window types are set for each
directional, full-tile, reinforced types. These all used constant values
& now they are adjusted accordingly
RTD patches
- Fixes #74526 RTD can lay floor tiles on all types of plating's
- The cost of deconstructing tiles was not calculated correctly i.e. it
always used the cost of the selected design & not the cost of the actual
floor type we are trying to deconstruct
- The construction & deconstruction time was constant & very fast for
all tile types, now the delay is adjusted based on the cost of the type
of tile in question
- RTD now has a blinking yellow empty icon state just like the RCD when
low on ammo
6. Fixes #73479 RCL now updates its pipe cleaning coil appearance when
changing colours & selecting white colour no longer yields a random coil
colour
7. makes sure `useResource() ` actually succeeds before doing any
action. The return value of this proc was not previously checked for
some devices
## Why It's Good For The Game
1. rcd like devices all moved into 1 folder for better organization
2. splits the original RCD.dm file into more logical & manageable files
for better maintainability
3. removes unused code & adds some extra sanity checks for everything
4. adds missing sprites for RLD & RTD
## Changelog
🆑
code: RCD & all its subtypes and other devices like it[RTD, RLD,
Plumbing RCD, RWD, RFC, RPD] now moved into 1 folder, removes unused
vars
refactor: RCD window type cost & delay are set based on the window type
selected.
refactor: RLD, RCD & plumbing RCD now has extra resource & target
placement sanity checks, optimizes RLD and code readability.
refactor: RTD now sets the correct delay with the cost of the tile type
currently being constructed/deconstructed taken into account
refactor: large majority of to_chat() replaced with balloon alerts
fix: RLD silo link now works again
fix: RTD can place tiles on any subtype of plating
fix: RCL now lays the correct colour of pipe cleaner when its colour is
changed
imageadd: empty blinking yellow icon states for RTD & RLD & an ammo bar
for RLD
/🆑
|
||
|
kawoppi
|
22e55067e8 |
[no gbp] dismantling an unplaced wallframe will now make a wrench sound (#73589)
## About The Pull Request Dismantling an unplaced wallframe will now make a wrench sound. ## Why It's Good For The Game Using a wrench almost always makes the wrench noise. Having that noise not play when you wrench something feels very weird. ## Changelog 🆑 soundadd: dismantling an unplaced wallframe will now make a wrench sound /🆑 |
||
|
ShizCalev
|
3362f2c88a |
Makes flashers actually flash again! (#70438)
* Makes flashers actually flash again! * Typo * Update code/game/machinery/flasher.dm * review * Update wall_mounted.dm |
||
|
tattle
|
fd9f50c552 |
[IDB IGNORE] Renames the inhand/misc folder to inhand/items (#69573)
Also adds balloons to inhand/items |
||
|
ArcaneMusic
|
5f4d5a42d4 |
Arconomy: The bigger balance PR (REVISED EDITION) (#65795)
This PR covers 4 Key features:
Price Rebalancing
Passive Income
Gas Exports
Lathe Tax
Relevant Design Doc (Slightly out of date as a result of the discourse on the subject).
https://hackmd.io/WlWgyRafTaiAqz6ouOqC-Q
-- START DOCUMENT --
# Arconomy Version Two
This is mostly me organizing a long list of thoughts that I'm not sure if I can properly describe and get across, but lets just work with what we got and go from there.
## There should probably be a relationship to time and profit
So, part one of a series called "Arcane was completely wrong about game design", I made a rather large misstep in regards to designing arconomy, and nobody told me this until far, FAR after I had gone way too in on my own ideas:
"There needs to be a relationship between time and money". Because Space Station 13 is a game that is built around rounds, either long, LONG rounds on MRP or 30 min - 1 hour long rounds in LRP, your whole orientation of the game is built around time. The longer you spend in a single round, the more you can do and mold the station and the game in a specific direction, whether it's from an admin event, doing your job, or going off on a wierd character based tangent.
The issue here lies in a question I tried to answer in my previous design doc:
> "Command players start with lots of money, and make mountains of money, and as a result, have so much money by the end of the shift that they're practically immune to the effects of the economy.
> Assistant players start out with practically no money, find that the station is covered in costs that they'll never be able to practically afford, and decide that the economy is stupid and not worth utilizing altogether."
Two fundimentally different outlooks on the same problem, caused by the pay discrepency as it existed originally. Since we have so many different jobs all at different paygrades, the option that made the most sense at the time was to completely remove paychecks alltogether because they would multiplicitively exacerbate the previous issue.
While it would flood the in-game economy over time at high levels, it did add a sense of timescale to the existing in-game relationships. You **KNEW** that after x many minutes you would get that fancy hat, or that you would need to find cash in other ways to get it. Having that time-scale is helpful as we've moved to our 90 minute round average/goal. It also, similarly, means that we know exactly how many credits each job SHOULD have had access to before a major disaster calls for a shuttle call. But, in hindsight, that is a value that should be consistant for all players. If a single, unaided player looks at a 200 credit bill, that should have the same impact player to player, and not limit their access to jobs.
## Bounties just ain't that fun, but they stand to see improvement from where they are now
So, guilty as charged, bounty running doesn't quite have the same charm as it used to have. For our friends just joining us, cargo used to have a single, per round laundry list of items that would payout to the cargo budget each shift. Each list would start with 10 items, one of which would randomly be assigned higher priority with a higher payout, and it would be cargo's job to ~~Break into each department and steal that thing~~ cooperate with jobs around the station to aquire funds for station crisis or when you just want to dick around and make stacks of cash. This had a distinct charm to it, but one element of it that majorly reduced the replayability of bounties was that they were severely limited in scope. Once you did your ONE drink bounty or your ONE chemical bounty, you no longer needed to interact with that department.
My original goal was this: Make an unlimited bounty system, where crewmates were able to get a cut of their work as profit. To a degree, it's fairly successful! Crew do have a way to actively work with cargo to get paid for their labor, and they help cargo as a result by giving them free valuables. The issue lies in the fact that this has kinda flipped the relationship on it's head: Bounties stopped being cargo's job to outsource to the crew, and instead the crew's job that becomes dependent on cargo.
In general, many bounties simply weren't meant to be repeatable content in the first place. And certainly not meant to be used for every job. Offloading it as a kind of fetchquest minigame so that all jobs can offset the loss of passive income? It's not the best choice. For jobs like botanists or scientists it's tolerable at best, frustrating at worst. Just look at the state of things like experisci-slime experiments or scanning furniture.
It gets far worse when it's from the perspective of jobs that have *explicitly* limited supplies like security. No, a security player is not going to be allowed to haul away all the good metal handcuffs from the brig for a bounty, and no, you cannot take all the riot shotguns from the brig.
Now, a few of these things were fixed over time, with mixed successes. Bounties started to be cleaned up in order to prevent limited quantity items from being an option for repeat bounties. Jobs that lack exports started to get some content for still allowing them to have repeatable exports (Like the Scanners for Security Officers to go on patrols).
The BIG EXCEPTION to this is Restaurant Bots, but we'll hit that in a second.
## Getting everything on the same price scale has been a major improvement.
Unironically one of the best changes made has been the idea that even if we lack that good time-credit scale from before, we didn't really have a "standard" to work off of when something new is added to the game and the dev needs to determine how much to make that thing cost. That's why the current costs of objects and values on-station are scaled off of a single define, the value of a crate sold on the cargo shuttle.
> Yes, I'd like an APPLE. It's worth 3124151 CREDITS. NO, I don't know why the apple juice in the vendor is worth 415 CREDITS, nor do I CARE, GOOD MAN.
From the back end, everything is scaled off the same define now. Paygrades are defined off of a different scale still, but that's fine. You know, from the cargo end of things, that a cargo player needs to ship off X number of empty metal crates to purchase a laser crate, or a pizza crate. Definate relationships help in solidifying the singular value of a product.
If we decide that we want to rescale the in-game economy and provide space credits with more granularity, at least we know we can do it with a single line of code, and not looking at every single instance of something that charges the player money.
### Arconomy Tangent: We gotta nuke gas selling.
This has been a long time coming and I know people are going to be upset at me, but look man.
I have no idea how selling moles of gas works these days. It seems like with minimal resources, true atmos wizards are able to make singular cans of gasses with infinite moles of some kind of gas, and if it's exotic enough, they can make upwards of a million credits a can. I've seen multiple occasions where selling gas cans to cargo has allowed for players to buy a bike.
For our Gen-Z zoomers reading this, players were never meant to BUY the bike. The bike is just a reskinned scooter meant as a cute little pokemon joke. If a player can actually buy a bike in a round, that's a sign that someone, somewhere, fucked up.
We fucked up the whole system with atmos gas selling.
We've now gone through metas of extracting miasma from lavaland for credits, we've gone through a meta where cargo starts building their own hydrogen burn chambers for simply produced gasses, we've seen time and time again that processed gasses in the funny space simulator just tends to be abused to death and back. I've had talks with TheFinalPotato on this in the past, and it just feels like a system that would need to be rewritten from the ground up, or looked at in terms of the whole cargo department. If I don't get to it first, the next cargo design doc someone writes **SHOULD**.
## Giving jobs content that integrates into the economy can be really fun.
Tourism bots and the baked in ingredient shopping is fun! It's enabled for a fluff job that doesn't have too terribly much by way of serious responsibilites to integrate active income minigames into the gameplay of chefs and bartenders. It's fully optional, it's quick, and it's not even a full shift investment.
These secondary tasks, which utilize jobs core gameplay loops in a new way, while rewarding them within the in-game economy are a decent way to keep players engaged with their jobs, and allow for them to use credits as a player resource as well as a primary job resource.
**I AM NOT SAYING** that all jobs need to find tasks to arbitrarily reward players with credits for. The reason it works so well for jobs like the chef or bartender is because their job is already to make food and drinks, but they have so many options that they're not encouraged to make too wide of a variety of food, especially when botanists won't always make everything you need. The food market gives them an outlet to buy outlier ingredients and the tourists pay handsomely enough that you can offset your costs most or the time.
I'll break this down as well into the three different methods of money-making in game as well, to guide someone on how to make good, secondary income content.
| Primary | Secondary | Tertiary |
| -------- | -------- | -------- |
| This is something like passive paycheck income. You get this just purely for playing the game, and staying alive. | This is an active trade off between your job's specific content, where you are trading your time for something it is directly your responsibility to do. Eg. Tourist Bots. | An active task you are performing for income, but lacks the specialization of a job. EG. Bounties. |
Jobs that excell at more service based tasks and less production based tasks should aim to aquire more seconary style economy integration, like medical, science, or security.
## The options for moving money around the station are actually pretty decent, but could be streamlined
Bounty boards are pretty decent at being a way to pay crew members for single service jobs. However, bounty boards are pretty much dead content, in a sense. There's not much incentive to hunt down your department's bounty board.
Similarly, most crew would just prefer to hand credits out by hand to prevent most kinds of abuse of their own credit supply.
Long term and certainly a major personal outcome I'd like to see: Bounty boards and Newscasters should be merged together. Newscasters have some truely awful spaghetti and their being held together by shoe-strings and duct tape (This is slang for HTML). Bounty boards are... well they're functional, but they have the benefit of being built in TGUI. Merging the two's functions should cut down on wall-space, as well as improve the quality of a vast deal of code, and make money transfer on station slightly easier.
Honestly, pretty happy with vend-a-trays. They're pretty decent store-machines on station and do their job pretty well when they get used. All in all I'm happy with how they work.
Custom Vendors are clunky to a fairly major degree and I don't think most players get how to make them work on account of need a price tagger (not a sales tagger, that's the cargo item) to mark an object for it's sale value, then load it into a custom vendor sales unit, then load it into a custom vending machine, and that's only IF custom vending machines decide to work this year. Streamlining the tools, or perhaps just vending machines would certainly improve this as a service.
## Just ain't enough cool stuff to buy with credits.
An ever-present problem, that we're just kinda stuck with. There's a decent number of issues involved with making content that can safely be gated with just credits.
* If it's usable as a weapon, is it too dangerous to hand out to the crew at large?
* Does security get potential oversight?
* If it's illegal, does it go through cargo?
* Does it HAVE to go through cargo?
* If it's beneficial, is it going to invalidate the existance of a job? (Think old medkits!)
* Is there anything that players WANT that's not a weapon, benefical to the station but not too strong, or quite literally traitor equipment?
It's a tough question.
Some items make complete sense to implement on a per job basis as either uncommon or premium equipment, while other items could potentially be moved to station-wide unique purchasables.
# Takeaways:
Look, these are just some possible solutions that I'm considering. I think that working alongside a maintainer who could actually give a damn on getting this system orderly and possibly alligned with our current design philosophy (Who also understands that a not-insignificant amount of current economy was abitrarly written by goofball an actual decade ago) could help iron this out into a clear and consise set of goals and milestones to make the in-game economy workable. Not balanced, but workable.
* **Design a simple simulation for per round intake and outtake, to determine benchmark values for a 90 minute round.**
It would need to look something like this, as a kind of fucked up, Multi-Input Multi-Output Control Problem. Possibly could be done in simulink, but I'm not quite sure how to do that at this moment, so a less complex version might be fine.
* **Look back at implementing crewmember incomes, but at a flat, more consistant rate over all jobs**
My leading idea: 50 credit, uniform paygrade. No wild, unscaled pay rates based on what job is "important" or not.
That line of thinking means that certain jobs should have more expensive equipment over other jobs, but then we're right back to the captain thinking that a cup of coffee is practically free where an assistant thinks that a screwdriver from the vendor is going to put them out of house and home.
Improves time-relationship values with credits.
This could lead way to heads of staff having some degree of control to giving raises or paycuts to crew-members, but perhaps at a very, VERY gradual rate.
* **Perform another big-picture look at bounty cubes.**
Potentially try to put bounties back in the hands of cargo, while still providing payouts to crewmates who assist in completing jobs. This may require some minor refactoring of the pricetag component, perhaps to even allow for multiple crewmembers to recieve profit from a payout.
This means once again, look at making bounties workable for all jobs on the station, not making the objects requested literal lathe-fodder, and finding ways to benefit the station in some way with the task of bounty cubes, even if it's just for credits.
Deceptively hard task.
* **Add secondary tasks that integrate the economy into non-bounty-able jobs/departments**
Like it says on the tin, look into ways to add content that improves economy integration into existing jobs, without necessarily changing what those jobs DO. The bounties for those jobs can still exist as a tertiary thing, but should be made clear that they're... tertiary.
Chefs still make food and bartenders still serve drinks, but they have a way to hand them out for fun and profit.
Some thoughts and ways to handle this potentially:
*Science:* Perform intricate testing on anomalous materials using science equipment. Should NOT REWARD RESEARCH POINTS. Mr. OJ Headcoder will CHEMICALLY CASTRATE me, or you, if you do.
*Medical:* Complete tricky or non-standard surgeries on dummies for medical data. Think like that meme from the TV show, House.
"He needs Mouse bites to live. MORE MOUSE BITES."
*Engineering:* Repair wacky machines that use both station-standard parts as well as solving quick puzzles.
* **Look into more effective money sinks that are dynamic sensitive**
Think, for example, about the station ransom event that spawns space pirates.
What if instead of the captain just dumping credits from the cargo budget into the aether to prevent pirate spawns (They're bugged anyway to my knowledge to spawn anyway), crewmates had to cough up that dough before a time-limit, or risk a pirate spawn. For those of you who were scratching their heads at (Operational Costs!?) in the above controls diagram, this is the sort of thing I mean.
Little, smaller things that might need to be purchased, invested in, or otherwise drain credits from the station over the course of the round.
# Arconomy 2.0: Smarter, Better, Flashier.
## Roundstart
Players begin each shift with a set amount of money, with the value being mostly uniform over the course of a shift assuming no interaction with economy. Jobs are split up into only 3 paygrades, Minimal, Crew, and Command. Minimal is reserved for jobs that are meant to fill population counts but lack a specialization, like prisoner and assistant. When starting the shift, a player will start with 5 paychecks worth of savings. This system is not designed for persistance, so you will always be able to tell how much money a player starts out with. Every 5 minutes, aka every economy tick, the player will recieve one paycheck, which is capped out at the standard crew member paycheck. This means that even if you start the shift as the captain, and begin the shift with 500 credits, you will recieve the same 50 credits as regular crew members.
| Minimal Paycheck | Crew Paycheck | Command Paycheck | Frequency |
| -------- | -------- | -------- |--------|
| 125 Cr | 250 Cr | 500 Cr | Roundstart |
| 25 Cr | 50 Cr | 50 Cr | Passive Income |
## Product Prices
Products found in vending machines are defined by the amount of a player's paycheck they're meant to cost. Regular items use the PAYCHECK_CREW value, while more expensive or otherwise prohibitive items are defined by PAYCHECK_COMMAND. Items are defined in this uniform, horizontal fashion in order to maintain the equal value of credits over all jobs. A 100 credit medkit in medical should have the same value to a doctor as it does to a botanist.
Jobs apply a discount to vending within their own department, so an engineering would have a discount on tools, and a doctor would have a discount on sutures. Items that are important to gameplay progression in a role are less expensive to their intended users.
> **AUTHORS NOTE:** I am considering removing in-department discounts. In the benefit of making the value of purchasables more universal, deciding that credits shouldn't be spent within their own department just seems... rather fucking stupid.
> Possibly move the discount to only the first few minutes of the shift, or perhaps as some kind of gameplay benefit to slowly increase in-department discount through gameplay milestones? Who knows 👻
>
Some jobs have premium, high value items stocked in their vending machines that are not meant to be purchased at roundstart. These are meant to encourage players to save or combine resources to gain access. An example of this is insulated gloves. Other high value items can also be found in contraband through hacking vending machines. This remains unchanged.
## Markets
The cargo department has been changed in order to improve player involvement with the economy, as well as to give cargo more variety in their merchandise while preventing a singular stale meta of products to purchase from.
Yes, I'm looking at you, russian surplus crate.
Lets start with what's remaining the same:
* Cargo is a department that manages imports and exports of products, fulfilling departmental orders, and aquiring supplies dependent on the station's state.
* Cargo encompasses the station's mail, mining, and flow of orders, as well as drone exploration.
* A skilled cargo member is able to find high value items to sell back to centcom in exchange for more funds, to purchase those supplies.
* Centcom may request bounties which crew can fulfill in exchange for credits, if they wish for additional work.
**Now for the new design flow:**
Cargo starts out with a new mechanic called a market. Markets hold existing export datums as well as purchasable products. The values of items will fluxuate up and down based on the market status, with in-game events or player actions raising or lowering the values of specific markets.
At roundstart, cargo has a single market to sell to, which is Nanotransen. This will not incapsulate all the existing export datums in the game, just the *primary* exports that are used by players. Items that are exclusive to nanotrasen and required to play certain game modes, like mindshield implants or being able to sell crates, are included and will always be available to purchase.
Additional markets can be unlocked through gameplay sources, such as:
| Market Name | Source | Imports/Exports |
| -------- | -------- |- |
| The Syndicate | Emagging/Hacking the Console | Illegal Goods/Contraband |
| The Clown Planet Commerse | Discovering the clown planet ruin | Pies, Horns, Pranking Equipment |
|Terragov Sector Security Surplus | Killing any megafauna. | Weapons, Ammunition, Advanced Riot Gear. |
| Mekki Materials Co. | Recovered loot from Exodrones | Materials and industrial equipment. |
|Donk Co.| As a tip from tourist robots. | Foods and Drinks, Toys and Games.|
|Waffle Co.| As above. | Bootleg products and wacky merchandise. |
|The Research Consortium| Reward for completing any experiment tree. | Slime Cores, RnD Artifacts, Robotics Equipment |
...And more, if I can think of more.
The purpose being, of course, to split up cargo's purchasable goods to be more instanced and unique, while also create unique situations where due to profitable markets, very specific exports are needed to help the department make money.
End of document for now :@ArcaneMusic
-- END DOCUMENT
Price Shifting
So, in-game items that have prices have a major issue on their hands, being that they were decided by how much money that job should make. This means that many of the jobs in-game have been given prices scaled to their job's income. That income I adjusted by removing passive income in #54161. While this was helpful to moving towards an active in-game economy, it resulted in items falling into distinct price brackets. A high paying job like security's items could never be purchased by someone like a botanist, but a job like a security officer had more capital and buying power than most other jobs in-game combined when moving down those brackets. We've done a simple normalization of scale to help in bring things closer to a semblance of equality.
There are now 3 price brackets, PAYCHECK_LOW, PAYCHECK_CREW, and PAYCHECK_COMMAND. Command staff will still have a higher base level of money on-hand than other crew, and low paying wages that we on-station don't respect as being real jobs (assistant, prisoner) will have their items be intentionally cheaper to encourage active participation in the economy, but the difference in scale is now noticeably far closer to each other. This means that assistants can still interact with the economy as spenders, but if they want to be doing a lot of work with money, they'll need to put in work. Additionally, this means we arbitrarily enforce a system that allows for items to have uniformity in what they cost to other players. 50 credits for a wrench feels better when you know that other job critical items in-game are also around the same price, and it's equivalent to one paycheck.
Paychecks are reintroduced
Economy lost it's relationship to time. In a game where a single round takes 90+ minutes (Backed up not only by the head-coder's design direction as well as plenty of aggregate round data), having a relationship to time and how long it takes to afford something is a major consideration when you look at buying something. Also, we get to say that I was certifiably wrong in regards to the active economy thing, since we have very, VERY few active sources of content in-game that are very... fun? Bounties are literal fetch quests but something like tourists is at least more engaging and interactive with the round, and should be the direction we want economy-job integration to head in.
Between having inflation as a price manipulation mechanic already in the code, as well as prices being roughly equalized in terms of their costs between jobs and their impact on the round, this allows for the reintroduction of paychecks to an extent.
As an additional note, doing this meant tweaking down the syndicate briefcase of cash, so that instead of giving you 5000 credits for 1 TC, it now costs 5 TC to accompany the fact that this is now a rather significant amount of money, even on decently high population. Fun fact: the Syndicate Briefcase of Cash actually PREDATES the economy, and was NEVER ADJUSTED beyond the original implementation of the economy as a result!
Gas Exports.
ALRIGHT ARE YOU READY FOR SOME GRAPHS? I THOUGHT SO, YOU LOVE GRAPHS.
So, gas exports are fucked, have always been fucked, and consistently have proven to be capable of breaking the in-game economy for a long time. This is no secret, I've been pinged with players getting billions, actual billions of credits using it multiple times in as many years. See, any round where a player manages to buy the bicycle is a round where I've fucked up, or someone fucked and I let it get past me.
So here's how gas exports work right now.
So, all of this hinges on the value of a single mole of gas, and some gasses enable you to make extremely, EXTREMELY profitable gasses through atmospheric gas wizardry However, even those less profitable gasses are still in an extremely high magnitude of value.
Most gasses if you have a full can of it will net you OVER 10k credits. For scale, one crate being sold in cargo is 200 credits.
That's a minimum of crates for pumping gas into a hollow metal box and praying it doesn't explode.
So we adjusted the values accordingly.
The baseline value of a single gas has been tweaked downward significantly. Even these values are still arguably very high, but I can play with it at the discretion of LemonintheDark. The green line at the top represents gasses that previously sold for 100 credits per mole, antinobilium I believe, and working downwards. I am going to try and enforce 10 credits per mole as the absolute maximum hard cap on gas exports, regardless of how many gasses we try to add in the future. Because the alternative is getting a gunjillion credits by huffing miasma into a tank of steel. And we ain't having that shit.
Lathe Tax
Part of the testing for this PR involved me modeling the SS13 economy in a given round as a kind of controls problem, with each source of income introduced in the round as a kind of input (Passive Income, Bounties, Tourists) in order to get a handle on roughly how much income a single round of SS13 will see per player on the given designed round-length, in order to estimate how much things are going to cost. Modeling how much players spend on a given round is variable enough that it'd be too difficult to accurately test without just throwing this up on a server and getting live data.
However, from the appearance of my dataset, players would be making a LOT more money nowadays with all of the above changes implemented. In an attempt to curve that intake, I attempted to implement a small, low scale tax of printing items that would take a small amount of players income every time they print, as a way to add a basic economic side-effect to this mechanic.
This has made a lot of people very angry and been widely regarded as a mixed decision. So, maintainers came up with an intended direction they want to see it, as they wanted to make sure that economy would remain a secondary system, that could still have an impact on round direction and the changes they want to see in the game.
So, here's the intent:
Lathe tax should exist in the form of printing things from protolathes outside of your department, not on autolathes or your own protolathe.
We want to promote people talking and collaborating to access things if it's outside the scope of their department and they still want it, with theft still being a viable avenue of gameplay.
Players will be charged 10 credits for printing a set of items not from their own protolathe, each. Printing an item can be paid for from your own ID card's bank account automatically, but the payment component has been buffed to handle physical money alternatives, as well as pulled money, similar to the luxury shuttle scanner gate's behavior.
Borgs are still enabled to print from lathes, however instead of it costing them credits, they now take a self-significant power cost in order to do so, preventing them from being used as a roving bank account for printing. I'll look into this further as we don't want to invalidate mechanics like borgs being able to do organ based surgery or building machinery, but we don't want them to become credit cards, so place that under advisement.
Tweaks and Updates:
(Suggested by Ziiro) If the revolutionaries win, centcom will no longer enforce the Lathe Tax.
(Suggested by about ~1000 people independently between my DMs, Reddit threads, the Feedback Thread, and elsewhere)
Printing items only taxes you once per print. EG: If you print 10 Kitchen Knifes as an assistant from the service lathe, you will only be charged once instead of 10 times.
For many of the reasons that I outlined above, this is a good change in a positive direction.
Players get more ability to interact with the economy without having to do content that's becoming increasingly depreciated in my absence.
Players also have a baseline consensus on what values of credits are high and low because jobs have been given an equalized standard in regards to the cost of certain items.
Price fluctuations through inflation will now be more meaningful in situations where the economy becomes more relevant.
The system will still encourage you to play a job that's productive to the status of the station through lower paycheck jobs existing as well.
Gas exports are now reduced to the point that their value is appropriate for the first time... actually ever. Nice.
The values of nearly every item purchasable by players has been rebalanced.
Players will now start with less starting money, but will receive a paycheck once every 5 minutes.
The value of gasses exported through the cargo department have been skewed way, WAY down in terms of price.
The Syndicate briefcase of cash now contains now costs 5 TC, up from 1 TC, for 5000 credits.
Printing items from lathes on station now costs a fee of 10 credits per item printed if it's from a lathe not under your department.
The payment component has received additional handling for physical credits, as well as pulled credits/ID cards for those without hands.
|
||
|
小月猫
|
884c1eeb62 |
fixes wallmounts (#65408)
closes #65393 (Engineering Cyborgs can't place APC or Air alarm frames on walls anymore)
fixes the code error in #64428 (
|
||
|
Luc
|
afc1e44ee2 |
Tool act superpack 2 (#64428)
About The Pull Request Continuation of #64375, extracting tool behavior from attackby() and moving it into discrete _act procs. This is about as many files as I had in the last version, as I still want this to be reviewable. As before, I've tested everything in game and it works as it previously did. Why It's Good For The Game The more code moved out of attackby, the more modular things become. Changelog cl refactor: Moves more tool behavior out of attackby(). /cl |
||
|
esainane
|
b6f761468e |
[MDB IGNORE] dir sanity, primarily on WALLITEMs (#62601)
About The Pull Request
Wall items mostly use the direction from the floor to the wall in the named mapping helper. Wall items mostly use the direction from the wall to the floor for the internal dir variable.
This leads to a headache when it comes to working out what conflicts with what, and what needs placing where.
Wall frames provided a member, inverse, which specified whether or not to invert the direction of the item when looking for conflicts. It was also used to specify whether to look for conflicts outside of the wall (cameras and lights appear external to the wall) or inside the wall (most wall items). This flag was set for Intercoms, APCs, and Lights. Since APCs and Lights expect a floor-to-wall direction, and Intercoms expect a wall-to-floor direction, this means that APCs and Lights were getting the correct direction, and Intercoms were getting the wrong direction.
Some implications of this setup were:
You could build an APC on top of another wall item, provided there was nothing external attached to the wall and the area didn't have an APC.
You could stack Intercoms indefinitely on top of the same wall, provided you weren't in a one-tile wide corridor with something on the opposite wall.
Or both! Here's twenty Intercoms placed on the wall, and a freshly placed APC frame after placing all Intercoms and deconstructing the old APC:
endless-stack-of-intercoms
Not everything used this inverse variable to adjust to the correct direction. For example, /obj/machinery/defibrillator_mount just used a negative pixel_offset to be visually placed in the correct direction, even though the internal direction was wrong, and never set! This also let you stack an indefinite number of defib mounts on the same wall, provided it wasn't a northern wall... except you could do this to northern walls too, since defibs weren't considered a wall item for the purposes of checking collisions at all!
Ultimately, every constructable interior wall item either used this inverse variable to adjust to the correct placement, set a negative pixel_offset variable to have its offset adjusted to the correct placement, or overrode New or Initialize to run its own checks and assignment to pixel_x and pixel_y!
Inventory: Table of various paths, related paths, and the adjustments they used
Unfortunately, untangling /obj/structure/sign is going to be another major headache, and this has already exploded in scope enough already, so we can't get rid of the get_turf_pixel call just yet. This also doesn't fix problems with the special 2x1 /obj/structure/sign/barsign.
Some non-wall items have been made to use the new MAPPING_DIRECTIONAL_HELPERS as part of the directional cleanup.
tl;dr: All wall mounted items and some directional objects now use the same direction that they were labelled as. More consistent directional types everywhere.
Why It's Good For The Game
fml
Changelog
cl
refactor: Wall mounted and directional objects have undergone major internal simplification. Please report anything unusual!
fix: You can no longer stack an indefinite amount of Intercoms on the same wall.
fix: Defibrillator Mounts, Bluespace Gas Vendors, Turret Controlers, and Ticket Machines are now considered wall items.
fix: Wall mounted items on top of the wall now consistently check against other items on top of the wall, and items coming out of the wall now consistently check against other items coming out of the wall.
fix: The various directional pixel offsets within an APC, Fire Extinguisher Cabinet, Intercom, or Newscaster have been made consistent with each other.
fix: The pixel offsets of Intercoms, Fire Alarms, Fire Extinguisher Cabinets, Flashers, and Newscasters have been made consistent between roundstart and constructed instances.
fix: Constructed Turret Controls will no longer oddly overhang the wall they were placed on.
qol: Defibrillator mounts now better indicate which side of the wall they are on.
fix: Some instances where there were multiple identical lights on the same tile have been fixed to only have one.
/cl
|
