mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-26 14:39:58 +01:00
docker-container
26
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
+37 AlexisGitHubtgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com>ArcaneMusicMrMelbertRhialsrageguy505LemonInTheDarkJohn WillardAliceee2chTime-GreenTsar-SalatSmArtKarMaxipatSyncIt21deltanedasSimplyLoganloganukLeland KembleFalloutFalconRoxyLucysiliconOpossumIsratoshTheRyeGuyWhoWillNowDieNeocloudyAlexander V.ElGitificadorTwaticusdependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>BloopCameron LennoxTimIamgoofballLayzu666Arturlang_0StevenmrmanlikesbtBen10OmintrixJohn F. KennedyCursorJoshJosh PowellYobrocharlieHardly3DshayokiLT3 |
21b4095dfd |
[MDB IGNORE] [IDB IGNORE] Upstream Sync - 04/17/2026 (#5453)
Upstream 04/17/2026 fixes https://github.com/Bubberstation/Bubberstation/issues/5549 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: tgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Rhials <28870487+Rhials@users.noreply.github.com> Co-authored-by: rageguy505 <54517726+rageguy505@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: Aliceee2ch <160794176+Aliceee2ch@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: Tsar-Salat <62388554+Tsar-Salat@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Maxipat <108554989+Maxipat112@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: deltanedas <39013340+deltanedas@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: loganuk <fakeemail123@aol.com> Co-authored-by: Leland Kemble <70413276+lelandkemble@users.noreply.github.com> Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com> Co-authored-by: Roxy <75404941+TealSeer@users.noreply.github.com> Co-authored-by: Lucy <lucy@absolucy.moe> Co-authored-by: siliconOpossum <138069572+siliconOpossum@users.noreply.github.com> Co-authored-by: Isratosh <Isratosh@hotmail.com> Co-authored-by: TheRyeGuyWhoWillNowDie <70169560+TheRyeGuyWhoWillNowDie@users.noreply.github.com> Co-authored-by: Neocloudy <88008002+Neocloudy@users.noreply.github.com> Co-authored-by: Alexander V. <volas@ya.ru> Co-authored-by: ElGitificador <168473461+ElGitificador@users.noreply.github.com> Co-authored-by: Twaticus <46540570+Twaticus@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> Co-authored-by: Cameron Lennox <killer65311@gmail.com> Co-authored-by: Tim <timothymtorres@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Layzu666 <121319428+Layzu666@users.noreply.github.com> Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com> Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> Co-authored-by: mrmanlikesbt <99309552+mrmanlikesbt@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: John F. Kennedy <54908920+MacaroniCritter@users.noreply.github.com> Co-authored-by: Cursor <102828457+theselfish@users.noreply.github.com> Co-authored-by: Josh <josh.adam.powell@gmail.com> Co-authored-by: Josh Powell <josh.powell@softwire.com> Co-authored-by: Yobrocharlie <Charliemiller5617@gmail.com> Co-authored-by: Hardly3D <66234359+Hardly3D@users.noreply.github.com> Co-authored-by: shayoki <96078776+shayoki@users.noreply.github.com> Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com> |
||
|
dieandGitHub
|
bb91185a3a |
Kitchen soundpack (#93495)
## About The Pull Request https://github.com/user-attachments/assets/f35be993-66b2-448f-953b-4b2ec9a7b8f6 ## Changelog 🆑 sound: added more sounds for knives sound: added more sounds for pots sound: added more sounds for trays sound: added more sounds for cutlery sound: added more sounds for rolling pins /🆑 |
||
|
GhomandGitHub
|
4f6727024d |
Crafting refactor, implementing materials (#89465)
## About The Pull Request My original plan was to just implement materials into crafting so that items would inherit the materials of their components, allowing for some interesting stuff if the material flags of the item allow it. However to my dismay crafting is a pile of old tech debt, starting from the old `del_reqs` and `CheckParts` which still contain lines about old janky bandaids that are no longer in use nor reachable, up to the `customizable_reagent_holder` component which has some harddel issues when your custom food is sliced, and items used in food recipes not being deleted and instead stored inside the result with no purpose as well as other inconsistencies like stack recipes that transfer materials having counterparts in the UI that don't do that. EDIT: Several things have come up while working on this, so I apologise that it ended up changing over 100+ files. I managed to atomize some of the changes, but it's a bit tedious. EDIT: TLDR because I was told this section is too vague and there's too much going on. This PR: - Improves the dated crafting code (not the UI). - replaced `atom/CheckParts` and `crafting_recipe/on_craft_completion` with `atom/on_craft_completion`. - Reqs used in food recipes are now deleted by default and not stored inside the result (they did nothing). - Renames the customizable_reagent_holder comp and improves it (No harddels/ref issues). - Adds a unit test that tries to craft all recipes to see what's wrong (it skips some of the much more specific reqs for now). - In the unit test is also the code to make sure materials of the crafted item and a non-crafted item of the same type are roughly the same, so far only applied to food. - Some mild material/food refactoring around the fact that food item code has been changed to support materials. ## Why It's Good For The Game Improving the backbone of the crafting system. Also materials and food code. ## Changelog 🆑 refactor: Refactored crafting backend. Report possible pesky bugs. balance: the MEAT backpack (from the MEAT cargo pack) may be a smidge different because of code standardization. /🆑 |
||
|
|
455fe545e0 |
Part 4: Storage Improvements (#90783)
## About The Pull Request - Address https://github.com/tgstation/tgstation/pull/90476#discussion_r2051701283. Makes pill bottle code cleaner - Datumized some more storage values(monkey guncase toolbox & crafter toolbox) making their init slightly faster - Moved all standard storage subtypes(bags, boxes, lockboxes etc) that is scattered across various files & folders in the codebase into their respective files under `code/game/objects/item/storage` folder. This means for e.g. if you want to see all boxes in the game you can find them in `code/game/objects/item/storage/boxes` folder & don't have to go looking for hidden subtypes in various module files or folders where they were hidden away. Makes looking for stuff & modifying these storages much saner & easier ## Changelog 🆑 code: organized storage subtypes under the same files & folders /🆑 --------- Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> |
||
|
SmArtKarandGitHub
|
6b83a91956 |
Revert "Refactor for storage initialization & organization (#89543)" (#90332)
## About The Pull Request Reverts the storage initialization refactor and all subsequent related PRs. The original PR is below our standards both for code quality and testing, and is majorly flawed at its core. This has been discussed with other maintainers and headcoder(s?) over on discord. A lot of changes from the PR could be brought over later, but in its current state it should not have been merged. - Closes #90322 - Closes #90313 - Closes #90315 - Closes #90320 - Closes #90312 - Closes #90344 ## Why It's Good For The Game This PR causes a series of major issues which cannot be resolved without either completely rewriting a lot of the original PR, or bad code. Not matching our standards is grounds for not merging a PR, and the fact that a PR should not have been merged is a reason for a revert. ## Changelog 🆑 fix: Fixed a series of storage-related bugs caused by a refactor PR. /🆑 |
||
|
SyncIt21andGitHub
|
0f57a23830 |
Refactor for storage initialization & organization (#89543)
## About The Pull Request A Huge chunk of changes just comes from moving existing storage code into new files & seperating `atom_storage` code into its own subtype under the already existing `storage/subtypes` folder. With that the changes in this PR can be organized into 3 categories. **1. Refactors how `/obj/item/storage/PopulateContents()` initializes storages** - Fixes #88747 and every other storage item that has a similar variant of this problem The problem with `PopulateContents()` is that it allows you to create atoms directly inside the storage via `new(src)` thus bypassing all the access restrictions enforced by `/datum/storage/can_insert()` resulting in storages holding stuff they shouldn't be able to hold. Now how this proc works has been changed. It must now only return a list of items(each item in the list can either be a typepath or a solid atom or a mix of them in any order) that should be inserted into the storage. Each item is then passed into `can_insert()` to check if it can fit in the storage. If your list contains solid atoms they must be first moved to/Initialized in nullspace so `can_insert()` won't count it as already inserted. `can_insert()` has now also been refactored to throw stack traces but explaining exactly why the item could not fit in the storage thus giving you more debugging details to fix your stuff. A large majority of changes is refactoring `PopulateContents()` to return a list instead of simply creating the item in place so simple 1 line changes & with that we have fixed all broken storages(medical toolbox. electrical toolbox, cruisader armor boxes & many more) that hold more items they can handle **2. Organizes initialization of `atom_storage` for storage subtypes.** All subtypes of `/obj/item/storage` should(not enforced) create their own `/datum/storage/` subtype under the folder `storage/subtypes` if the default values are not sufficient. This is the 2nd change done across all existing storages Not only does this bring code cleanliness & organization (separating storage code from item code like how `/datum/wire` code is separated into its own sub folder) but it also makes storage initialization slightly faster (because you are not modifying default values after `atom_storage` is initialized but you are directly setting the default value in place). You now cannot & should not modify `atom_storage` values inside `PopulateContents()`. This will make that proc as pure as possible so less side effects. Of course this principle is not enforced and you can still modify the storage value after `Initialize()` but this should not be encouraged in the future **3. Adds support for automatic storage computations** Most people don't understand how `atom_storage` values work. The comment here clearly states that https://github.com/tgstation/tgstation/blob/55bbfef0da70d87455ca8d6fd5c95107eb8dbefb/code/game/objects/items/storage/toolbox.dm#L327-L329 Because of that the linked issue occurs not just for medical toolbox but for a lot of other items as well. Which is why if you do not know what you doing, `PopulateContents()` now comes with a new storage parameter i.e. `/datum/storage_config` This datum allows you to compute storage values that will perfectly fit with the initial contents of your storage. It allows you to do stuff like computing `max_slots`, `max_item_weight`, `max_total_weight` etc based on your storage initial contents so that all the contents can fit perfectly leaving no space for excess. ## Changelog 🆑 fix: storages are no longer initialized with items that can't be put back in after taking them out refactor: storage initialization has been refactored. Please report bugs on github /🆑 |
||
|
GhomandGitHub
|
7c703fc712 |
Food types are now passed down when cooking from recipes. (#89706)
## About The Pull Request ~~I have some beef with the cooking system.~~ Cooking recipes are coded in a way that disregard the possibility for their components to have different foodtype flags than the ones you would find normally find. For example, if I wanted to make corned beef, but instead of a standard steak, I used a killer tomato "steak", the result would still have the meat food type, even if none of the components has it. I've had to resort to a few hacky lines of code to manipulate the food types from the edible component, but that can be easily fixed if #89687 is merged. ## Why It's Good For The Game This also makes cooking recipes less strict about their food types and can help us spot inconsistencies with recipes. ## Changelog 🆑 qol: Food types are now passed down when cooking from recipes. For example, a plate of corned "beef" made from giant killer tomato slabs no longer counts as meat but only vegetables now. fix: Fixed a metric ton of inconsistencies with food types and recipes. fix: Dank-pockets (the weed variant) can now be microwaved. /🆑 |
||
|
r3dj4ck0424andGitHub
|
809dad7478 |
Adds bowls to a lot of recipes (#85573)
## About The Pull Request <details> <summary> Causes the following foods to drop a bowl when eaten </summary> Fried Eggplant Polenta <br> Hua Mulan Congee <br> Herby Cheese <br> Pineapple Salsa <br> Chips and Salsa <br> Beef Stroganoff <br> Sambal <br> Desert snail cocleas </details> <details> <summary> Adds a bowl to the following recipes </summary> Desert snail cocleas <br> Sambal <br> Hurricane Fried Rice <br> Ikareis <br> Hawaiian Fried Rice <br> Ketchup Fried Rice <br> Mediterranean Fried Rice <br> Egg Fried Rice <br> Bibimbap <br> Bulgogi Noodles <br> Yakisoba Katsu <br> Martian Fried Noodles <br> Simple Fried Noodles <br> Setagaya Curry <br> Po Kok Gai <br> Galinha De Cabidela <br> Katsu Curry <br> Beef Bowl <br> Salt Chilli Octopus Bowl <br> Kansai Bowl <br> Eigamudo Curry <br> Pineapple Foster <br> Sprout Bowl <br> Beef Stroganoff <br> Chips and Salsa <br> Pineapple Salsa <br> Herby Cheese <br> Hua Mulan Congee <br> Fried Eggplant Polenta </details> Causes Loaded poms-franzisks to drop a plate when eaten, and adds a plate to the recipe ## Why It's Good For The Game Closes #85509 There's a whole bunch of recipes that have bowls in their sprites, and many of them drop bowls when eaten. (Quite a few of them have the "salad" recipe type, which drops a bowl by default.) But this was very inconsistent. Some bowl-sprited foodstuffs neither dropped or needed bowls, and some of them dropped bowls without requiring them in the crafting. This PR should help make things a lot more consistent, and until and unless someone redoes the sprites this should be a good enough solution. (I also added a plate to the loaded poms-frazinsks for roughly the same reason.) Since this also stops the crewmates from conjuring bowls out of thin air, this should make bowls a bigger seller in the dinnerware vendor. ## Changelog 🆑 fix: In light of recent allegations of wizardry among the kitchen staff, our cooks will now need bowls when crafting food that comes in bowls. This should also stop said bowls from vanishing once the food is gone. /🆑 |
||
|
JacquerelandGitHub
|
d019239e51 |
Mothic Fleet Rations now leave trash (#81280)
## About The Pull Request During the feature freeze someone pointed out that it was weird that mothic rations can get dirty if dropped on the floor, as they're supposed to be inside wrappers. I added a trash type to them, which has the added side-effect of the game assuming that if it leaves trash it probably doesn't get dirty when dropped on the ground. I also changed the colour of the text on the wrapper from black to very very dark brown because I didn't like drawing it in black on the wrapper. ## Why It's Good For The Game More immersive. More Janitor content. ## Changelog 🆑 add: Mothic Fleet Rations now no longer get dirty or decompose if left on the floor, due to their wrappers. /🆑 |
||
|
KrypandenejandGitHub
|
90d0bd9ed3 |
A few food fixes (#81128)
## About The Pull Request Some bug smashing, as well as adding decent values to martian drinks. This is also my first few ever PRs, so if something goes wrong, yell at me ## Why It's Good For The Game This should hopefully make it so that martian drinks appear more at bars. Also, you can now eat a pesto pizza whole. Yey. ## Changelog 🆑 fix martian drinks give various moodboosts that aren't just "nice" now fix: pesto pizza (cooked) is no longer raw, and cilbir is meat instead of fruit /🆑 |
||
|
xXPawnStarrXxandGitHub
|
d9cdd4917a |
Big baked rice complexity fix. (#80193)
## About The Pull Request Someone pointed out to me that big baked rice actually gets WORSE when cooked, which doesn't make any sense to me, I assume it's just an oversight that was never patched.  ## Why It's Good For The Game I don't want food getting worse when you put more effort into it. ## Changelog 🆑 fix: fixed big rice pans getting worse with cooking. /🆑 |
||
|
|
70bd061bd6 |
General code maintenance for Reagents (#78637)
## About The Pull Request 1. Moved global procs inside of `code/modules/reagents/chemistry/holder.dm` that are not tied to `datum/reagent` to it's own dedicated global list file `code/_globalvars/lists/reagents.dm` these procs initialized global lists so it makes sense to move them here and also reduces the size of this file a.k.a code organization 2. Moved global lists inside `code/_globalvars/lists/objects.dm` that are related to reagents also to `code/_globalvars/lists/reagents.dm`. Now all global reagent lists are located in this 1 file a.k.a code organization 3. Other code improvements for reagent code & its holder include - removed a ton of unused procs - removed unused vars and local defines - replaces `!` with `QDELETED()` in place of some target objects - throws stack trace if you pass an invalid reagent path to some procs - Heavy auto doc for a lot of procs 4. Adds a lot of sanity checks on numbers related to reagents i.e. whenever a reagent is added/removed/transferred etc 3 sanity checks are done on those numbers - We first check is the number valid via the `ISFINITE()` macro. This macro wasn't used as much as it needs to be so it is added in some missing places. If not a stack trace is thrown - The number if it relates to reagents volumes must be greater than `CHEMICAL_QUANTISATION_LEVEL` define so we don't deal with 0 or very small/negative numbers - The number is then quantized i.e. we do `round(amount, CHEMICAL_QUANTISATION_LEVEL)` so we don't deal with numbers having 10 decimal places or something like that - Replaced `CHEMICAL_VOLUME_MINIMUM` with `CHEMICAL_QUANTISATION_LEVEL` so we can use the same constant everywhere 5. Addresses one of the issues presented in #31206. One way this occurred was when multiple reagents was put in a beaker and then a dropper was used to transfer them. Because multiple reagents were to be equally divided by their volumes when sucked up by the dropper some rounding was done causing fractional errors. That has been improved although not completely fixed cause there is a chance for it to occur when for example an odd number of reagents are transferred between the beaker and dropper. Another instance where it can occur is when very small volumes are being transferred. When this happens `update_total()` removes these reagents before they can be transferred causing missing amounts. 6. Numbers were being rounded in inconsistent ways for e.g. in some places it was rounded with the correct quantization constant https://github.com/tgstation/tgstation/blob/30782f817db5aef2d388af335f4c70b88c74b93b/code/modules/reagents/chemistry/holder.dm#L264 But in other places it gets rounded with a different constant https://github.com/tgstation/tgstation/blob/30782f817db5aef2d388af335f4c70b88c74b93b/code/modules/reagents/chemistry/holder.dm#L653 We should be using the 1 constant `CHEMICAL_QUANTISATION_LEVEL` for all these places so we don't get different values. so the rounding was added in multiple places but we use `FLOOR()` instead so we don't get values greater than the volume of reagent available. ## Changelog 🆑 code: moved some global procs and vars related to reagents to its own dedicated file. removed some unused procs and macros code: heavy auto docs for a lot of procs refactor: adds reagent sanity and bound check code refactor: multiple reagents are more uniformly distributed when transferring them between beakers or dropper & in every other reagent dependent operation /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
A miscellaneous FernandGitHub
|
a92843744b |
Simplifies the way burning food is handled, kills burns_in_oven and burns_on_grill (#77570)
## About The Pull Request Currently, burning food is handled in the following way (for the sake of brevity I'll explain it with baking but it's essentially the exact same with grilling): - If a recipe has a baking recipe added in it's `make_bakeable`, then it will produce that when baked. - If it does not have a recipe added, but `burns_in_oven` is TRUE, then it will have a negative baking recipe for "burned mess" added by the parent of `make_bakeable`, and be turned to that after 20 to 25 seconds. - If it has neither, it will instantly be set on fire. What this PR does is, basically, remove the check for `burns_in_oven/burns_on_grill` and make food always have a negative burned mess recipe unless overriden by an actual recipe. Also modified the examines a bit to better fit food that hasn't necessarily been baked/grilled before but would still turn to a burnt mess if put in either. ## Why It's Good For The Game My issues with the way it currently works are: 1. The "default" case is one that largely doesn't make sense for food. Most things would logically just get turned to a burnt mess after being overcooked for some time rather than combusting the very moment you close the range. 2. If you make any cooking item the result of a baking recipe, then you must also remember to make its `burns_in_oven` var true, because otherwise it will be set on fire as soon as it finishes baking, making it impossible to cook. (See issue #77377) This is pretty bad because it's easy not to notice or add these vars, given that they're a bit out of the way mechanically and... 3. ...the var names are very unintuitive. In practical terms all `burns_in_oven` and `burns_in_grill` do is add a timer before the item is ruined, not actually cause or prevent the ruining. By removing these vars and their function we deal with all three, as turning into a burnt mess is now the default outcome for food that shouldn't be baked/grilled and coders adding food/recipes don't need to worry about the confusingly-named vars. Also, as mentioned before, fixes #77377. ## Changelog 🆑 fix: boiled rice doesn't burn instantly after being baked code: simplifies the way burning food is handled, grilled/baked food now turns to a burnt mess rather than being set on fire, unless they have a baking/grilling recipe /🆑 |
||
|
AndrewandGitHub
|
b1c5e5e0f6 | Foodening (#77887) | ||
|
Rex9001andGitHub
|
a20edc0518 |
Fixes moffic grilled hard cheese burning on the grill instantly (#75788)
Fixes the bug that makes grilled cheese burn instantly upon creation ## About The Pull Request Does what it says on the tin, adds Adds burns_on_grill = TRUE on hard grilled cheese ## Why It's Good For The Game You can now make moffic grilled cheese without burning it on the grill ## Changelog 🆑 fix: fixes moffic grilled hard cheese burning on the grill instantly /🆑 |
||
|
MrMelbertandGitHub
|
6085e3b5ee |
Reagent soup / Soup rework / Stoves - A kitchen expansion (#74205)
## About The Pull Request  **This PR:** - Reworks most* existing soup into reagents. - Adds Stoves and Ranges. Ranges replace most* existing ovens. - Adds soup pots, to cook soup **How does it work?** In the kitchen you will find a stove now. Stoves act as a "reagent container heater", essentially a chem heater. You can set a pot onto the stove. To make soup, visit the cooking recipe book for a guide. Most recipes are the same as before, just tweaked slightly - Add water to the pot (50 units for 1 batch generally), then add all the corresponding ingredients to the pot. Set the pot out on the stove and right click it to turn it on. If the recipe's correct, shortly it will start to mix and give you soup! One soup recipe will give you roughly 3 servings of soup. You can pour our the soup into a bowl using a ladle or just by pouring it manually. Of note: **All of the reagent contents of the ingredient are transferred into the soup.** Better, more nutrient rich ingredients produces more soup, and poisoned produce will pass it on. If you place the soup into a chem master, you will notice it's roughly half "soup reagent" and half a variety of reagents, including nutriments / proteins. This is your soup! It is recommended you serve your soup with the reagents included, as they make up more nutrition for the customer, however you can separate it out if you're picky. **Todo:** - [x] Fill out the PR body a bit more - [x] Mapping (wait for big merge conflict pr to go past) - [x] Soup colors - [x] Balance pass over for soup recipes - [x] TODOs - [ ] Unit tests - [x] Cullen Skink's recipe is invalid - [x] Try to see if there's an easy way to prevent soup from fattening you up too easy. ## Why it's good for the game Adds some more depth to the kitchen and moves chef away from the click-button-get-food style that exists. Allows for inherently custom soups by the way of making it reagents, so no need to support custom soup food items. ## Changelog 🆑 Melbert, stove and pot sprites by Kryson, ladle sprite by Kinneb add: Kitchens are now stocked with Ranges. add: You can now print (and create) Stoves. add: The dinnerware vendor now dispenses ladles. add: Spoons can now actually spoon... things. add: Soup has been reworked entirely. Soups are now reagents, cooked via a soup pot on a Stove or Range. Simply add water and your required items, then apply heat. Be careful not to boil over! add: Stoves, Ranges, and Griddles will now heat up their surroundings - don't turn them on around plasma! fix: Fixes being able to cook in an Oven while the room is depowered qol: Hitting a customer bot with an incorrect recipe no longer counts as a hostile attack leading to your demise shortly after refactor: Customer bots that request a reagent now use custom orders code: Cut down a lot of code in the crafting menu code, and removes some ugly ispaths del: Soup is no longer food items, so can't appear in random food pools (at least not yet). balance: Virus Food recipe now requires you cool it to 200k. /🆑 |
||
|
tattleandGitHub
|
5c97b13e18 |
Food code sweepups + heart boxes have more chocolate variety (#72127)
- Chocolate boxes now contain bonbons (formerly tiny chocolates), truffles, and peanut butter cups - Slices of bread now taste like their respective breads instead of tasting "indescribable" - Fiesta skewers have food categories now - Misc food file has had more split out of it into sweets.dm, vegetables.dm, and packaged.dm - Removed a bunch of redundant food_reagent code - Changed the sugar in clown cakes' food_reagents to banana juice - Increased the amount of vitamin in pound cakes (it's four whole cakes and the amount of vitamin doesn't go up?) |
||
|
|
0818d6ae4c |
Crafting/Cooking menu update (#71779)
## About The Pull Request Updated crafting menu, adding a lot of new functions and recipes that were not in the crafting menu before. <img alt="cult" src="https://user-images.githubusercontent.com/3625094/206009533-aec3a1dd-cbe5-45eb-8515-1b75fabb65c5.PNG"> <img alt="nH77dLyyGx" src="https://user-images.githubusercontent.com/3625094/206009786-b6706f70-0599-40bf-b051-8f499de43abd.png">  https://user-images.githubusercontent.com/3625094/206009841-738e4a03-0660-45b7-8d83-15eeb6501967.mp4 ## Why It's Good For The Game It is easier to use, and it has a lot of recipes that were spread throughout the game, some of which weren't even on the wiki. Crafting and cooking now count about 1200 recipes in total, including conditionally available ones. ## Changelog 🆑 qol: Rewrote the crafting/cooking menu UI qol: Split crafting and cooking menus in two different menus qol: Crafting is no longer blocking the entire UI, only the "Make" buttons are disabled qol: Added stack crafting recipes to the crafting menu qol: Added cooking recipes that were absent in the crafting menu before (tool recipes, machine recipes, reactions) qol: Added option to search recipes by title qol: Added option to filter recipes by required materials/ingredients qol: Added food types to the cooking menu, highlighting diet of your species (liked, disliked foods) qol: Added total nutrition value of the result to the cooking menu qol: Added option to filter cooking recipes by the food type of the resulting food qol: Added "Can make" category that lists all currently craftable recipes throughout all categories refactor: changed categories and reshuffled some items in them code: Reagents now have default container to get an icon from the reagent datum code: Objects now have `desc_controls` var for OOC information about mouse controls that are visible on examine, but not in the description fix: Fixed alignment on many food icons fix: Fixed missing icon for beef stroganoff /🆑 Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> |
||
|
Sol NandGitHub
|
c9415b99de |
Gives bread and cake slice_types and adds screentip verbs to proccessed foods (#71449)
## About The Pull Request A side effect of my pizza PR #71202 I added contextual screentips as part of processable.dm. In doing this, I noticed that with a few exceptions, almost every single bread and cake type copies the proc exactly the same for every single child of cake or bread, so I put the proc on the parent of bread and cake and gave them slice_types, making them more similar to pizza.dm For everything else I've changed the default that I put in processable.dm into "slice" or "cut" for things that use the knife and "flatten" for things that use the rolling pin. Finally, you can slice bread with saws now, because I think its silly that only pizza gets this luxury. ## Why It's Good For The Game Because it wasnt the focus of #71202 I didn't mess with screentips outside of the pizza file a lot, but now that it's merged I figure I should go and do that. As Bread and Cake's processables are almost fully standardized it seems silly for them to call on the proc 12 times in the same document so I did this, which also allows for more versatility in editing how they work as well allow people to, if they want to, add more tool behaviours in the future without adding in 12 lines of code. Also means that people who want to add new cake or bread have one less thing to do. ## Changelog 🆑 add: you can saw bread with a saw into bread slices qol: added screentip verbs to a bunch of food files code: bread and cake now have slice types and all only have one call on the processable.dm proc /🆑 |
||
|
PaxilmaniacandGitHub
|
b4eab1c357 |
Converts all* of the times in the food files into SECONDS (#67984)
drink your processable component copy-paste |
||
|
SomethingFishandGitHub
|
97fc8b0428 |
Fixes mothic garlic pizza not producing the correct slice on slicing (#67773)
produces correct slice on slicing |
||
|
EOBGamesandGitHub
|
ad07e02316 |
The Great Species Food Rebalance, Part One: Nutriment, Chemical Recipes, Cargo Orders, Baking Times, Oh My! (#67227)
the great rebalance, part one A comprehensive rebalance of food, including cooking times, nutriment values, crafting recipes, and cargo orders |
||
|
ArcaneMusicandGitHub
|
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.
|
||
|
ArcaneDefenceandGitHub
|
fc20b6e1ea | Allows processable to require a table (#66257) | ||
|
Kapu1178andGitHub
|
1d0eadcb12 |
Kapulimbs (#65523)
* i wanna go to bed so im pushing this * It compiles but doesn't work yet * It works! * I WANT TO DIE * Appease linters * some CI fixes * Address reviews + oversight * Limb grower fix * more icon fixes * forgot to hit save * I'm a dumbass * Removes bodypart parent from unit test * Fixes monkeys and CI * Grammar pass * I hate zombie code so much * General code cleanup * THE SHITCODERS ARE COMING FOR MY VARS * THE UNIT TESTS ARE COMING FOR MY SHITCODE * Reviews + skirts * Removes an unused DMI * Why didn't I do this in the first place? * HAIR REFACTOR * Haha whoops * How did I miss this * Admin spawned creatures now have their features * Optimize me harder * minor fix i need to push to merge master * Fixes hair (maybe) and a runtime * Maybe fixes mirrors * Attempts to fix women * Fixes hair on dismembered heads and a grammar change * Caps lock did me dirty * address reviews * icon failures fix + missed reviews * Fixes: Facehuggers and Regenerate_limb * Fixes ethereal color pref appearance * How the fuck did this not break everything else horribly? * JESUS FUCKING CHRIST IM A MORON * Fixes compile * I'm not high I swear * Im a dipshiiiit * grumble grumble * Fixes a visual bug with digitigrade legs. Adds \improper to roundstart species names. Added two new clothing-related helper procs. Renamed a couple procs to be more accurate. Adds SHOULD_CALL_PARENT(TRUE) to examine_more. Addresses reviews. * Forgot this little readability thing. * Updates CODEOWNERS * Me when I forget how github works * mapload me harder * Last second fixes |
||
|
EOBGamesandGitHub
|
cf899a1821 | Moth Food Returns: A Taste of the Fleet (#63174) |
