58 Commits

Author	SHA1	Message	Date
Leland Kemble	6b9e42d0ed	Blacklists TCG card decks from spawners (#94535) ... ## About The Pull Request Empty TCG card decks cannot appear in spawners anymore ## Why It's Good For The Game getting the concept of trading cards but no cards for christmas is a pretty unthoughtful gift ## Changelog 🆑 fix: Empty TCG game decks will no longer appear in presents /🆑	2025-12-19 10:11:49 -05:00
ArcaneMusic	d87637e6ab	Adjusts easing in places where EASE_IN/OUT was applied without a curve. (#92976) ... Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>	2025-09-27 17:54:45 +02:00
MrMelbert	5261efb67f	Re-refactors batons / Refactors attack chain force modifiers (#90809) ... ## About The Pull Request Melee attack chain now has a list passed along with it, `attack_modifiers`, which you can stick force modifiers to change the resulting attack This is basically a soft implementation of damage packets until a more definitive pr, but one that only applies to item attack chain, and not unarmed attacks. This change was done to facilitate a baton refactor - batons no longer hack together their own attack chain, and are now integrated straight into the real attack chain. This refactor itself was done because batons don't send any attack signals, which has been annoying in the past (for swing combat). ## Changelog 🆑 Melbert refactor: Batons have been refactored again. Baton stuns now properly count as an attack, when before it was a nothing. Report any oddities, particularly in regards to harmbatonning vs normal batonning. refactor: The method of adjusting item damage mid-attack has been refactored - some affected items include the Nullblade and knives. Report any strange happenings with damage numbers. refactor: A few objects have been moved to the new interaction chain - records consoles, mawed crucible, alien weeds and space vines, hedges, restaurant portals, and some mobs - to name a few. fix: Spears only deal bonus damage against secure lockers, not all closet types (including crates) /🆑	2025-05-19 13:32:12 +10:00
Ghom	339616ae78	You can now interact with held mobs beside wearing them (feat: "minor" melee attack chain cleanup) (#90080) ... ## About The Pull Request People can now pet held mothroaches and pugs if they want to, or use items on them, hopefully without causing many issues. After all, it only took about a couple dozen lines of code to make... ...Oh, did the 527 files changed or the 850~ lines added/removed perhaps catch your eye? Made you wonder if I accidentally pushed the wrong branch? or skewed something up big time? Well, nuh uh. I just happen to be fed up with the melee attack chain still using stringized params instead of an array/list. It was frankly revolting to see how I'd have had to otherwise call `list2params` for what I'm trying to accomplish here, and make this PR another tessera to the immense stupidity of our attack chain procs calling `params2list` over and over and over instead of just using that one call instance from `ClickOn` as an argument. It's 2025, honey, wake up! I also tried to replace some of those single letter vars/args but there are just way too many of them. ## Why It's Good For The Game Improving old code. And I want to be able to pet mobroaches while holding them too. ## Changelog 🆑 qol: You can now interact with held mobs in more ways beside wearing them. /🆑	2025-04-23 20:18:26 +00:00
SyncIt21	9bd45e2f3a	Part 3: Storage Improvements (#90476) ... Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>	2025-04-20 12:02:29 +00:00
SmArtKar	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. /🆑	2025-03-30 21:30:31 +00:00
SyncIt21	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 /🆑	2025-03-23 22:20:23 +01:00
grungussuss	58501dce77	Reorganizes the sound folder (#86726) ... ## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑	2024-09-23 22:24:50 -07:00
san7890	a4328ae1f9	Audits tgui_input_text() for length issues (#86741) ... Fixes #86784 ## About The Pull Request Although some of the issues found were a direct result from #86692 (c698196766), there was still 40% of length-related issues that wouldn't be covered anyways that are fixed in this PR. I.E.: * Name inputs without `MAX_NAME_LEN` * Desc inputs without `MAX_DESC_LEN` * Plaque inputs without `MAX_PLAQUE_LEN` * Some people just screwed up the arguments so it would prefill something like "40" in the `default` var because they didn't name their vars. To help me audit I added a lot of `max_length` named arguments to help people understand it better. I think it might be kinder to have a wrapper that handles adding `MAX_MESSAGE_LEN` in a lot of these cases but I think there is some reason for a coder to be cognitive about input texts? Let me know what you think. I didn't update anything admin-related from what I can recall, let me know if anything needs to be unlimited again. ## Why It's Good For The Game The change to `INFINITY` notwithstanding, there were still an abundance of issues that we needed to check up on. A lot of these are filtered on down the line but it is clear that there needs to be something to catch these issues. Maybe we could lint to make `max_length` a mandatory argument? I don't know if that's necessary at all but I think that the limit should be set by the invoker due to the wide arrangement of cases that this proc could be used in. This could all be a big nothingburger if the aforementioned PR is reverted but a big chunk of cases fixed in this PR need to be fixed regardless of that since people could put in 1024 character names for stuff like guardians (or more now with the change). Consider this "revert agnostic". ## Changelog 🆑 fix: A lot of instances where you could fill in 1024-character names (normal limit is 42) have been patched out, along with too-long plaque names, too-long descriptions, and more. /🆑	2024-09-20 22:46:41 +00:00
klorpa	69176298ed	Spelling Fixes (#86056) ... ## About The Pull Request Fixes several errors to spelling, grammar, and punctuation. ## Why It's Good For The Game Improves readability and user experience. ## Changelog 🆑 spellcheck: fixed a few typos /🆑	2024-09-10 17:04:59 +02:00
Ben10Omintrix	91baa94ac5	event based incapicated and able_to_run (#86031) ... ## About The Pull Request this is a revival of #82635 . i got permission from potato to reopen this, he did almost all the work. i only just solved the conflicts and fixed all the bugs that were preventing the original from being merged (but it should be TMed first) ## Why It's Good For The Game slightly improves the performance of basic mob AI ## Changelog 🆑 LemonInTheDark refactor: able_to_run and incapacitated have been refactored to be event based /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: ZephyrTFA <matthew@tfaluc.com>	2024-09-04 10:02:49 -04:00
nikothedude	ff0b0c6c74	Adds extra signals for storage add/remove, + minor signal doc (#83247) ... ## About The Pull Request Title. Converts TCG decks to use signals instead of a proc override, as is better practice. ## Why It's Good For The Game It's generally better practice to not snowflake behavior like this onto the storage itself, instead using signals/procs. Also, its good to have parity between add/remove in signals. ## Changelog 🆑 code: New signals for atom storage remove and insert /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>	2024-05-24 15:40:38 +01:00
MrMelbert	995d8e2ee1	Fixes a variety of input stalling exploits (#82577) ... ## About The Pull Request Fixes the following input stalling exploits (maybe missed some): - Changing GPS tag - Setting teleporter destination - Request Console Reply - Various AI law board interactions - Note, I used `is_holding` but technically this means these fail with telekinesis. I can swap them to `can_perform_action(...)`, which allows TK, but I noticed some places explicitly deny TK interactions with Ai law boards. Not sure which is preferred. - Borg Rename Board - Plumbing Machines and Ducts - APCs and SMES terminal placements - Stargazers Telepathy - Go Go Gadget Hat ## Changelog 🆑 Melbert fix: You can't change the GPS tag of something unless you can actually use the GPS fix: You can't set the teleporter to a location unless you can actually use the teleporter fix: You can't reply to request console requests unless you can actually use the console fix: You can't update AI lawboards unless you're actually holding them fix: You can't update a borg rename board unless you're actually holding it fix: You can't mess with plumbing machines unless you can actually use them fix: You can't recolor / relayer ducts unless you're actually holding them fix: You can't magically wire APCs and SMESs unless you're right by them fix: You can't use Stargazer Telepathy on people who you can't see fix: You can't configure the Inspector Hat unless you can actually use it /🆑	2024-04-12 03:03:27 +00:00
MrMelbert	12afcb911e	Comprehensive cleanup of storage datum, replaces the weakrefs with just refs (because they were managed already) (#81120) ... ## About The Pull Request - Large amount of storage datum cleanup. - Documentation. - Maybe more consistent use of parent vs real_location. - Removes the weakrefs, replaces it with just references. - These were already managed references anyways so why bother? - Removes a bunch of arguments no one used and would ever used so only the most useful args are left. - Some bugfixes. ## Why It's Good For The Game Aiming to make storage easier to work with. The whole intent of this was to bugfix the whole "weight class" thing that keeps popping up but I had to do this first. ## Changelog 🆑 Melbert fix: When placing an item into storage (such as backpacks), all nearby mobs now get a message, rather than just the first mob. fix: TGC decks of cards should act a bit less odd when looking inside. refactor: Refactored a bit of storage, cleaned up a fair bit of its code. Let me know if you notice anything funky about storage (like backpacks). /🆑	2024-02-05 11:42:03 -08:00
NamelessFairy	7e8f583332	Corrects tile offsetting for TGC Mana and Health bars. (#79002) ... ## About The Pull Request Fixes: #78466 Health and Mana bars are supposed to be offset a number of tiles based on mapper preference but #75189 changed the code to use pixel offsets rather than tile offsets without changing the map variables to account for this. I've changed it back to tile offsets since pixel offsets are going to look super weird if someone maps these in with super high offsets, it already looks rather weird even with a 1 tile offset. I've also changed them to effects rather than decals since they're holograms and can be stuck to walls and stuff if the mapper chooses to without triggering the unit test. ## Why It's Good For The Game Restores some intended functionality for mappers and fixes the incorrect offsets on the TGC holodeck map. ## Changelog 🆑 fix: TGC Mana and Health bars are correctly offset on the holodeck. /🆑	2023-10-16 21:46:38 +02:00
John Willard	b5975bd915	Unit tests now catch decals in walls/space (#75189) ... ## About The Pull Request Unit tests will now fail if there's a decal in a wall or open space turf. Open space turf could be limiting to mappers but I don't think it makes sense for decals (like dirt, glass shards, etc) to be floating around in space in the exact same spot. If there's a decal you want to put in space, decals have a ``turf_loc_check`` var that will bypass this. **Important note: This is not changing existing behavior. Decals already delete themselves when they spawn in these incorrect locations, we're just avoiding them from spawning in the first place.** ### Changes I made - Ash flora are now lava immune, rivers spawn after flora does, so I decided that it would be easiest (and more flavorful) to have them be lava-immune rather than to not have them spawn at all. - Decals can now be spawned in non-turf locations. This is currently done by mail, which can give you bones as part of the mail. Currently it will just delete itself instead. - Trading Card button is now on the same tile as their display, which now uses an offset. Before it would spawn it on the tile next to it, which could be a wall in some instances. - Mirrors now have floating movement type. They ARE floating since they're attached to the wall, and it prevents them from burning up due to lava in the Pride ruin. - I also added a broken mirror subtype because I thought the icon_state check was terrible. - Bubblegum called ``DestroySurroundings`` several times on the same thing, I hopefully fixed some of that. Their charge ability also registered ``COMSIG_MOB_STATCHANGE`` despite ``/datum/action`` doing it by default, so I fixed that too. ## Why It's Good For The Game Decals in walls is already a bad idea, but currently all it does is delete it on Initialize. It would be better if we ensured they wouldn't spawn in the first place. ## Changelog 🆑 fix: Lava will no longer burn 6 of the mirrors in pride ruin fix: Lava will no longer burn plants that spawn in them. /🆑	2023-06-15 16:39:22 -07:00
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.	2023-05-03 14:44:51 +00:00
NamelessFairy	2f2687f43f	Fixes TGC decks being capped to 31 cards rather than 30. (#74602) ... ## About The Pull Request Fixes #72701 (closed but the issue seems to have been misunderstood.) TGC decks are limited to 30 cards when inserting cards by using the deck on individual cards (the legal amount) but using individual cards on a deck has a limit of 31 cards instead, the 30 card limit is now correctly checked on card insertions. ## Why It's Good For The Game Bugfix. ## Changelog 🆑 fix: TGC decks will no longer allow you to insert an illegal 31st card. /🆑	2023-04-09 17:04:53 -06:00
san7890	ccef887efe	Lints Against Unmanaged Local Defines (#74333) ... # MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW RATHER THAN AFTER THE FACT. ## About The Pull Request Hey there, This took a while to do, but here's the gist: Python file now regexes every file in `/code` except for those that have some valid reason to be tacking on more global defines. Some of those reasons are simply just that I don't have the time right now (doing what you see in this PR took a few hours) to refactor and parse what should belong and what should be thrown out. For the time being though, this PR will at least _halt_ people making the mistake of not `#undef`ing any files they `#define` "locally", or within the scope of a file. Most people forget to do this and this leads to a lot of mess later on due to how many variables can be unmanaged on the global level. I've made this mistake, you've made this mistake, it's a common thing. Let's automatically check for it so it can be fixed no-stress. Scenarios this PR corrects: * Forgetting to undef a define but undeffing others. * Not undeffing any defines in your file. * Earmarking a define as a "file local" define, but not defining it. * Having a define be a "file local" define, but having it be used elsewhere. * Having a "local" define not even be in the file that it only shows up in. * Having a completely unused define* (* I kept some of these because they seemed important... Others were junked.) ## Why It's Good For The Game If you wanna use it across multiple files, no reason to not make it a global define (maybe there's a few reasons but let's assume that this is the 95% case). Let me know if you don't like how I re-arranged some of the defines and how you'd rather see it be implemented, and I'd be happy to do that. This was mostly just "eh does it need it or not" sorta stuff. I used a pretty cool way to detect if we should use the standardized GitHub "error" output, you can see the results of that here https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792 ## Changelog Nothing that really concerns players. (I fixed up all this stuff using vscode, no regexes beyond what you see in the python script. sorry downstreams)	2023-03-29 10:17:03 -07:00
LemonInTheDark	33d9a0338f	Reworks trashbags slightly (#73761) ... ## About The Pull Request I'm a bit sad about the state of trashbags. They're very clunky to use, so they almost never get touched. S depressing. Let's try and fix that. Let's make em fit in the belt slot (again), but as a tradeoff we'll make it harder to pull one thing from your bag. We'll give it a say, 1.5 second delay, so you can't quickdraw from em. If you try and dump them out into something else, we'll throw any spillover on the ground below you I'm also doing some general code cleanup here. Making procs more readable, vars more direct, removing some old legacy stuff. I've added a remove_single proc to hook into via subtype, which takes a mob as input. this has required placing extra requirement on some helper procs, but fortunately it's not something they're unable to meet. My hope is this will make garbage bags usable without being stupid. ## Why It's Good For The Game I don't see these get used at all, cause they're a pain to carry around. They got gimped because people were using them as infinite storage for shotgun shells and other small items. I've made using them for this sort of thing hard and slow, so I think we oughta be fine. If not I'll do some more touching, maybe give the autodrop a delay. ## Changelog 🆑 balance: The janitor's trashbag now fits on his belt. In exchange, taking something out of it sends a visible message, and has a delay. /🆑 --------- Co-authored-by: san7890 <the@san7890.com>	2023-03-14 16:39:24 -06:00
NamelessFairy	7740b791bc	Last TGC Holodeck PR before the freeze! Card marking and Blank cards! (#73013) ... ## About The Pull Request This should be the final PR required to finish my goal of the holodeck TGC arena having all the features of the tabletop version. Marking cards (e.g. for hivemind cards) and cards that summon other cards are both intended to use the flipper as a counter. This is not possible on the holodeck and as such this PR adds that functionality. When a card is in a holder a new option to mark the card has been added which will add a small indicator to the top right of the card summon when activated. For empty card holders you can now right click them to create a blank card, you will be prompted to input a name for the blank card, (e.g. Resin Wall) and then the card will act like a regular card. ## Why It's Good For The Game TGC can now be played in its entirety on the holodeck, at this point all tabletop features should have representations on the holodeck. ## Changelog 🆑 add: You can now mark TGC cards on the holodeck battle arena, useful for keeping track of effects such as hivemind. add: Right clicking a card holder on the TGC holodeck battle arena will allow you to generate a "blank card", useful for when using cards that summon other cards, such as the xenomorph hivelord. spellcheck: Capitalized some descriptions for TGC machines /🆑	2023-02-02 20:56:53 -07:00
NamelessFairy	d6f9e59273	[NO GBP] Trading card life and mana panels can be set to 0 life/mana (#72973) ... ## About The Pull Request Setting the life or mana values in either of the panels to 0 would trigger and if statement only meant to trigger if the value was set to null, meaning that setting life or mana to 0 would be ignored. ## Why It's Good For The Game Its possible to have 0 mana/life. ## Changelog 🆑 fix: You can now set life and mana panels to 0 life/mana. /🆑	2023-01-28 00:00:33 -08:00
NamelessFairy	1b9b020f4a	Inspecting a trading card or card hologram now shows the full card art in chat. (#72862) ... ## About The Pull Request Does what it says in the title, example below.  ## Why It's Good For The Game TGC cards get shrunk down whenever you place them, making their card art very difficult to make out in a lot of cases, by doing this you can now view the full card art by inspecting the card rather than needing to pick it up. Placed Ian card for reference  ## Changelog 🆑 qol: Inspecting a trading card or card hologram will now let you see the full enlarged card art. /🆑 Co-authored-by: Time-Green <timkoster1@hotmail.com>	2023-01-24 15:37:32 +00:00
NamelessFairy	573b955bdd	Life and Mana bars for the TGC battle arena. (#72838) ... ## About The Pull Request Adds a life and mana bar for each player in the TGC holodeck arena, practically removing the need for players to keep track of these stats using items outside of the holodeck. The mana bar features a next turn button which will automatically increase the number of slots by 1 and refill or slots. You can inspect the panels to see these values numerically rather than visually.  ## Why It's Good For The Game I've set out on a goal on making the TGC battle arena a complete visualizer for the TGC game, where all you need to bring is a deck of cards and a friend. Adding this eliminates the need for pen and paper or an external notepad program for tracking life and mana, and replaces it with a far more visually interesting option that is also significantly easier for both players to see and keep track of. ## Changelog 🆑 add: The TGC arena on the holodeck now features display panels to track each player's life shards and mana. qol: Slightly increased the amount of space on the TGC holodeck arena's tables by removing the windows on either side of the player. /🆑	2023-01-24 15:19:47 +00:00
NamelessFairy	b702ebd0e2	TGC rulebook added to the card battle arena and fixes a bug with holographic TGC coins (#72595) ... ## About The Pull Request The coins spawned by the TGC holodeck arena had monetary value and could be used as an infinite source of income, they've been replaced with a worthless subtype. Also a small QoL change since I've seen people looking for it ICly but I've added a rulebook to the holodeck so people can access the wiki page directly. ## Why It's Good For The Game Infinite money exploit bad and I've watched multiple people go hunting for a non-existent rulebook. ## Changelog 🆑 qol: Rulebook for TGC has been added to the TGC arena. fix: Holographic TGC coins are no longer legal tender and cannot be inserted into your ID. /🆑	2023-01-16 14:24:06 +00:00
ShizCalev	8b84a73818	fixes invisible trading card game decks (#72699) ... Fixes #72695 🆑 ShizCalev fix: Trading cards are no longer invisible when stacked. /🆑	2023-01-15 02:32:24 -08:00
NamelessFairy	f2942acfb3	Hologram Projectors for TGC! (#72226) ... ## About The Pull Request Adds a new holodeck layout that features a TGC card fighting arena, complete with holographic representations of your cards. Cards act the same as physical cards when displayed except you can see the stats of the cards without needing to inspect and the cards stats can be modified on the fly for keeping track of equipment. Example:  ## Why It's Good For The Game TGC is a significantly more complicated game then the other ones we have like UNO and CAS and is extremely messy to play on a table ingame, this provides a much clearer way of visualizing the game by having all active creature stats on full display at all times without having to rely on inspecting cards to check. ## Changelog 🆑 add: Introducing a new holodeck map, the TGC Arena, featuring hologram projectors for your trading cards. fix: Janitor and Intern TGC cards are now considered creatures rather than just humans. balance: The price of card packs has been reduced from double a paycheck to 3 quarters of one. balance: The number of cards available in the good clean fun vendor has been doubled. /🆑	2023-01-07 09:53:59 -08:00
ShizCalev	ae8ed395e1	Changes the missing food icon test to cover ALL /obj's (#71908) ... Might as well cover everyyyyyyyyything. :) Fixes https://github.com/tgstation/tgstation/issues/71953 Fixes https://github.com/tgstation/tgstation/issues/71983 🆑 ShizCalev code: We now unit test all /obj's for missing icons. :) /🆑 todo: Fix the fucked up icons. Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>	2022-12-13 17:51:40 -08:00
LemonInTheDark	bcb5e8403b	Adds a debug var to cardpacks that allows users to dump all cards in the series (#71659) ... <!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request Debug var to dump everything in a cardpack ## Why It's Good For The Game Someone's working on a tcg expansion and asked for this. so here ya go bestie	2022-12-06 09:04:06 -08:00
AnturK	4d6a8bc537	515 Compatibility (#71161) ... Makes the code compatible with 515.1594+ Few simple changes and one very painful one. Let's start with the easy: * puts call behind `LIBCALL` define, so call_ext is properly used in 515 * Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since src is now invalid there. * Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache directory is not appened to base path in browser controls so we don't check for it in base js and put the dev server dummy window file in actual directory not the byond root. * Renames the few things that had /final/ in typepath to ultimate since final is a new keyword And the very painful change: `.proc/whatever` format is no longer valid, so we're replacing it with new nameof() function. All this wrapped in three new macros. `PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is not actually necessary but if we get nameof that does not allow globals it would be nice validation. This is pretty unwieldy but there's no real alternative. If you notice anything weird in the commits let me know because majority was done with regex replace. @tgstation/commit-access Since the .proc/stuff is pretty big change. Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>	2022-11-15 03:50:11 +00:00
LemonInTheDark	23bfdec8f4	Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) (#69115) ... About The Pull Request I've reworked multiz. This was done because our current implementation of multiz flattens planes down into just the openspace plane. This breaks any effects we attach to plane masters (including lighting), but it also totally kills the SIDE_MAP map format, which we NEED for wallening (A major 3/4ths resprite of all wall and wall adjacent things, making them more then one tile high. Without sidemap we would be unable to display things both in from of and behind objects on map. Stupid.) This required MASSIVE changes. Both to all uses of the plane var for reasons I'll discuss later, and to a ton of different systems that interact with rendering. I'll do my best to keep this compact, but there's only so much I can do. Sorry brother. Core idea OK: first thing. vis_contents as it works now squishes the planes of everything inside it down into the plane of the vis_loc. This is bad. But how to do better? It's trivially easy to make copies of our existing plane masters but offset, and relay them to the bottom of the plane above. Not a problem. The issue is how to get the actual atoms on the map to "land" on them properly. We could use FLOAT_PLANE to offset planes based off how they're being seen, in theory this would allow us to create lens for how objects are viewed. But that's not a stable thing to do, because properly "landing" a plane on a desired plane master would require taking into account every bit of how it's being seen, would inherently break this effect. Ok so we need to manually edit planes based off "z layer" (IE: what layer of a z stack are you on). That's the key conceit of this pr. Implementing the plane cube, and ensuring planes are always offset properly. Everything else is just gravy. About the Plane Cube Each plane master (except ones that opt out) is copied down by some constant value equal to the max absolute change between the first and the last plane. We do this based off the max z stack size detected by SSmapping. This is also where updates come from, and where all our updating logic will live. As mentioned, plane masters can choose to opt out of being mirrored down. In this case, anything that interacts with them assuming that they'll be offset will instead just get back the valid plane value. This works for render targets too, since I had to work them into the system as well. Plane masters can also be temporarily hidden from the client's screen. This is done as an attempt at optimization, and applies to anything used in niche cases, or planes only used if there's a z layer below you. About Plane Master Groups BYOND supports having different "maps" on screen at once (IE: groups of items/turfs/etc) Plane masters cannot cover 2 maps at once, since their location is determined by their screen_loc. So we need to maintain a mirror of each plane for every map we have open. This was quite messy, so I've refactored it (and maps too) to be a bit more modular. Rather then storing a list of plane masters, we store a list of plane master group datums. Each datum is in charge of the plane masters for its particular map, both creating them, and managing them. Like I mentioned, I also refactored map views. Adding a new mapview is now as simple as newing a /atom/movable/screen/map_view, calling generate_view with the appropriate map id, setting things you want to display in its vis_contents, and then calling display_to on it, passing in the mob to show ourselves to. Much better then the hardcoded pattern we used to use. So much duplicated code man. Oh and plane master controllers, that system we have that allows for applying filters to sets of plane masters? I've made it use lookups on plane master groups now, rather then hanging references to all impacted planes. This makes logic easier, and prevents the need to manage references and update the controllers. image In addition, I've added a debug ui for plane masters. It allows you to view all of your own plane masters and short descriptions of what they do, alongside tools for editing them and their relays. It ALSO supports editing someone elses plane masters, AND it supports (in a very fragile and incomplete manner) viewing literally through someone else's eyes, including their plane masters. This is very useful, because it means you can debug "hey my X is yorked" issues yourself, on live. In order to accomplish this I have needed to add setters for an ungodly amount of visual impacting vars. Sight flags, eye, see_invis, see_in_dark, etc. It also comes with an info dump about the ui, and plane masters/relays in general. Sort of on that note. I've documented everything I know that's niche/useful about our visual effects and rendering system. My hope is this will serve to bring people up to speed on what can be done more quickly, alongside making my sin here less horrible. See https://github.com/LemonInTheDark/tgstation/blob/multiz-hell/.github/guides/VISUALS.md. "Landing" planes Ok so I've explained the backend, but how do we actually land planes properly? Most of the time this is really simple. When a plane var is set, we need to provide some spokesperson for the appearance's z level. We can use this to derive their z layer, and thus what offset to use. This is just a lot of gruntwork, but it's occasionally more complex. Sometimes we need to cache a list of z layer -> effect, and then use that. Also a LOT of updating on z move. So much z move shit. Oh. and in order to make byond darkness work properly, I needed to add SEE_BLACKNESS to all sight flags. This draws darkness to plane 0, which means I'm able to relay it around and draw it on different z layers as is possible. fun darkness ripple effects incoming someday I also need to update mob overlays on move. I do this by realiizing their appearances, mutating their plane, and then readding the overlay in the correct order. The cost of this is currently 3N. I'm convinced this could be improved, but I've not got to it yet. It can also occasionally cause overlays to corrupt. This is fixed by laying a protective ward of overlays.Copy in the sand, but that spell makes the compiler confused, so I'll have to bully lummy about fixing it at some point. Behavior changes We've had to give up on the already broken gateway "see through" effect. Won't work without managing gateway plane masters or something stupid. Not worth it. So instead we display the other side as a ui element. It's worse, but not that bad. Because vis_contents no longer flattens planes (most of the time), some uses of it now have interesting behavior. The main thing that comes to mind is alert popups that display mobs. They can impact the lighting plane. I don't really care, but it should be fixable, I think, given elbow grease. Ah and I've cleaned up layers and plane defines to make them a bit easier to read/reason about, at least I think. Why It's Good For The Game <visual candy> Fixes #65800 Fixes #68461 Changelog cl refactor: Refactored... well a lot really. Map views, anything to do with planes, multiz, a shit ton of rendering stuff. Basically if you see anything off visually report it admin: VV a mob, and hit View/Edit Planes in the dropdown to steal their view, and modify it as you like. You can do the same to yourself using the Edit/Debug Planes verb /cl	2022-09-27 20:11:04 +13:00
tattle	fd9f50c552	[IDB IGNORE] Renames the inhand/misc folder to inhand/items (#69573) ... Also adds balloons to inhand/items	2022-09-01 03:29:10 +02:00
tattle	d91390a447	[IDB IGNORE] The Great Sweep: Moving dmis into subfolders (part 1) (#69416) ... Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine Moves Halloween, Christmas, and misc holiday items to obj/holiday Moves lollipops to obj/food Moves crates, closets, and storage to obj/storage Moves assemblies to obj/assemblies Renames decals.dmi to signs.dmi ...because they're signs and not decals Moves statues, cutouts, instruments, art supplies, and crayons to obj/art Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys Moves guns, swords, shields to obj/weapons	2022-08-24 20:49:35 -03:00
magatsuchi	7d0f393f5d	Tsu's Brand Spanking New Storage: or, How I Learned To Pass Github Copilot As My Own Code (#67478) ... Currently, storage works as a subtype of /datum/component, utilizing GetComponent() and signals to operate. While this is a pretty good idea in theory, the execution was pretty trash, and we end up with alot of GetComponent() snowflake code (something that shouldn't even need to be used frankly), and a heaping load of scattered procs that lead into one another, and procs that don't get utilized properly. Instead, this PR adds atom_storage and proc/create_storage(. . .) to every atom, allowing for the possibility of storage on quite frankly anything. Not only does this entirely remove the need for signals, but it heavily squashes down the number of needed procs in total (removing snowflake signal procs that just lead to one another), reducing overall proc overhead and improving performance.	2022-07-08 18:13:18 -07:00
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.	2022-04-27 03:01:21 -07:00
LemonInTheDark	12a90800c5	Adds tooltips to /tg/c keywords. Adds support for chat embedded tgui components (#65383) ... * Refactors tcg code a bit. Adds support for "keywords" Idea is to allow card makers to embed tooltips in their card descriptions. These tooltips are defined in the keywords.json file They can be referenced using {$keyword_name} I've also done some refactoring to move more logic and state onto the subsystem, and implemented a few keywords from the wiki * New keywords, applies the old ones to the second card set * Adds support for embedding react components in tgui chat This is done by adding the data-component attribute to an html element The value of that attibute is the component you want to use. New components can be added by modifying the TGUI_CHAT_COMPONENTS list in tgui-panel/chat/renderer.js. Props can also be passed in in a limited capacity. Any props you wish to pass must be added to TGUI_CHAT_ATTRIBUTES_TO_PROPS. This is due to a style restriction of html attributes, they cannot contain an upper case char. Use this list to convert between attibute compatible text and the prop's name. Props support 3 datatypes. true and false can be passed by wrapping them in ""s. (Note to self add a special char here to prevent colison with people just passing the string true. Numbers are supported in a limited capacity. Whitespace is not allowed, but floats and ints are fair game. And of course, strings are fully supported. I've currently added support for Tooltip, since that's what I'm using this for. Also added some tooltip html styles to the chat css. * Implements the embedded component system to make tcg cards have nice pretty tooltips so people don't need to have the wiki open on one screen * Adds documentation for embedding tgui components in chat, adds some protection against accidentially sending true as a bool * Adds italitcs to the tooltips, moves the span stuff to a macro * tGUI -> tgui, thank fikou Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> * Style suggestions Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> * Removes unneeded key from the components list Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> * Removes needless span * Actually adds the tooltip, oops Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> Co-authored-by: Aleksej Komarov <stylemistake@gmail.com>	2022-03-15 11:36:31 +02:00
Jeremiah	415e9dd7c1	Fixes typos in span, other html elements (#63510) ... Atomizes a much larger PR for another time... There are typos in span and other html messages that causes them to not render correctly or at all. Bug fixes Converts those instances of span to use the macro	2021-12-23 17:06:01 +00:00
Seth Scherer	24169f0d80	Updates /code/game/objects/item/{melee,tcg}/* to follow the style guide (#63130) ... Co-authored-by: SuperNovaa41 <supernovaa41@protonmail.com>	2021-12-02 12:56:25 -08:00
Ghilker	95c8e00af7	cleanup _HELPERS/_lists.dm and all the necessary files (#61827) ... Bring _HELPERS/_lists.dm to latest standards by: -Adding proper documentation and fixing existing one -Giving vars proper names -Procs now use snake case as per standard (many files that use those procs will be affected)	2021-10-12 14:48:51 +01:00
tralezab	6c01cc2c01	every case of initialize that should have mapload, does (#61623) ... ## About The Pull Request stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload  ## Regex used: procs without args, not even regex `/Initialize()` procs with args `\/Initialize\((?!mapload)((.)*\w)?` cleanup of things i didn't want to mapload: `\/datum\/(.)*\/Initialize\(mapload`	2021-09-24 17:56:50 -04:00
Fikou	82b1ffb829	tcg flippers no longer have the scaling element (#60424)	2021-07-29 12:16:09 -07:00
Watermelon914	375a20e49b	Refactors most spans into span procs (#59645) ... Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs. Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines. Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing. Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc. (Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)	2021-06-14 13:03:53 -07:00
TemporalOroboros	e4079c87b8	update_appearance (#55468) ... Creates update_name and update_desc Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together Less non-icon handling code in update_icon and friends Signal hooks for things that want to change names and descriptions 99%+ of the changes in this are just from switching everything over to update_appearance from update_icon	2021-02-19 12:06:18 -03:00
LemonInTheDark	5c22a0cfc1	Converts many proc overrides to properly use list/modifiers, lots of other smaller things (#56847) ... Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too.	2021-02-16 09:18:46 -05:00
Koshenko	51819e5a52	Refactor card scaling into an element for general item scaling (#56102) ... The current TCG code had some code for scaling its cards down when they're on the ground and then scaling them back in hand/inventory. This element aims to preserve this functionality and to allow it work for other items. While the TCG makes the cards smaller on the ground, this element allows for items to be scaled up OR down when on the floor or in inventory. While this particular element has to do with scaling, I am looking at ways to expand this sort of icon change functionality to icon_state as well, but there are additional issues with blood decals needing to be redrawn and possibly vis_contents.	2021-01-21 09:49:33 -03:00
EOBGames	5a72442dc8	Third Rate Duelist With A Fourth Rate Deck: The TG TCG, Part 2 (#54659) ... Finally adds the ruleset to the TGC, allowing players to play the game (in a relatively provisional state). Cards now have rules and keywords attached, as well as a proper system for displaying information in the sidebar (all the credit for this has to go to @ArcaneMusic, who also contributed a huge amount of the ruleset for the cards). The full ruleset and keywords can be found here: https://tgstation13.org/wiki/Tactical_Game_Cards	2021-01-06 12:16:58 -03:00
TiviPlus	0eaab0bc54	Grep for space indentation (#54850) ... #54604 atomizing Since a lot of the space indents are in lists ill atomize those later	2020-11-30 12:48:40 -05:00
ArcaneMusic	5338ad1696	Re-assesses 99% of vending prices through Arconomics to match player resources and round-length. (#54715) ... * The Re-pricening * Rewritten and adjusted for paycheck defines. * I made the map changes finally. * And the refills too. * "OH YEAH REPLACING IT ALL WITH DEFINES AND SCALING IT THE EXCEL DOCUMENT WILL BE EASY, ARCANE!!!" * And the premium ones too. * Accidently spoiled a future pr due to dme bleedover	2020-11-13 16:17:22 -05:00
TiviPlus	9fb0c73f63	Grep for proc(var/bad) (#54848)	2020-11-09 08:44:35 -03:00
Timberpoes	2cf6e03dd6	Fixes two incorrectly named COMSIG defines (#54660)	2020-10-29 00:23:52 -03:00