mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-05 06:05:58 +01:00
ed94de4ddf7edad8694badefc577392e0f762bf5
172 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Iamgoofball
|
a159b52e85 |
TTS Improvements: Improved Audio Quality, Pitch Adjustment, Preference Silicon Voices, Per-Character Voice Disable Toggle, Tongue Voice Filters, Reworked Silicon and Vending Machine Filters (#76129)
## About The Pull Request https://github.com/tgstation/tgstation/assets/4081722/5ca8e015-21f9-4159-9953-bc370152d01f Improves the audio quality and speaker fidelity by implementing Retrieval Voice Conversion as an intermediary layer, utilizing the repository at https://github.com/ddPn08/rvc-webui. Leverages RVC to allow players to set a pitch for their voice. https://github.com/tgstation/tgstation/assets/4081722/0eb76ed7-ad67-4da2-9ceb-02605eea2c83 Makes silicons utilize a player's chosen voice preference on their character slot, and adds a preview button to hear the voice as a silicon on character creation. Adds a toggle on character creation to disable having a voice on a specific character slot. Adds support for per-tongue voice filters. Reworks the silicon voice effect to be a special effect done on the TTS server level instead of via normal filters. Reworks the vending machine effect to use the new robotic voicebox effect. ## Why It's Good For The Game Vastly improves the audio quality and speaker fidelity of our TTS system. Allows players to further customize their voice per character, naturally pitching the voice up or down with cutting edge machine learning based pitch adjustment. Allows silicon players to have a consistent voice that's also audible and understandable regardless of the voice or pitch of the speaker. Improves vending machine audio quality. Enhances the immersion of snail tongues and robotic voiceboxes. Adjusts how Poly's pitch adjustment works based on if RVC is available or not. Allows players who feel that a voice doesn't fit their character to disable having TTS on their specific character. Provides server operators a way to disable specific voices in situations with a shared voice server. ## Changelog 🆑 Iamgoofball, Nadare, ddPn08, Mangio621, the rest of the RVC dev team add: Improves the audio quality and speaker fidelity by implementing Retrieval Voice Conversion as an intermediary layer, utilizing the repository at https://github.com/ddPn08/rvc-webui. add: Leverages RVC to allow players to set a pitch for their voice. add: Makes silicons utilize a player's chosen voice preference on their character slot, and adds a preview button to hear the voice as a silicon on character creation. add: Adds a toggle on character creation to disable having a voice on a specific character slot. add: Adds support for per-tongue voice filters. add: Reworks the silicon voice effect to be a special effect done on the TTS server level instead of via normal filters. add: Reworks the vending machine effect to use the new robotic voicebox effect. /🆑 --------- Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com> |
||
|
Tom
|
09ad8fc2d3 |
Changes brand intelligence to check onstation var instead of station z level. Well, kind of both. (#76266)
## About The Pull Request Checks the `.onstation` var on `/obj/machinery/vending` instead of checking the z-level directly. The z-level check is already run in init to set this var in the first place, but this way it allows the var to be set manually to secure vendors that are on the station z-level but are not wanted as candidates for brand intelligence. This scenario doesn't currently exist here, but it affects things like https://github.com/Skyrat-SS13/Skyrat-tg/issues/21918 and future-proofing is always nice. I did consider doing this as another var, but that felt a bit excessive. Can change if wanted. (also removes some duplicate comments because I was there) ## Why It's Good For The Game Wasted events uhh bad ## Changelog 🆑 fix: Brand intelligence can no longer affect off-station vendors in some specific circumstances. /🆑 |
||
|
LemonInTheDark
|
830d2e50b4 |
Fixes some stupid airlock sleeps (#75961)
## About The Pull Request [A common problem with explosions is an overabundance of sleeping](https://github.com/tgstation/tgstation/commit/6499077a09469ff401c224c0510bc184c663b118) In an attempt to solve this issue, let's not continue to sleep and do work in door closing if the door is already deleted (This is caused by firelocks activating due to other adjacent objects deleting, triggering an atmos update, and closing the firelocks before they get bombed. I don't have a elegant way of resolving that core problem, so let's just minimize the impact) [Nukes a stupid sleep loop in airlock code](https://github.com/tgstation/tgstation/commit/5b16360520526d6f5aa3b511049456b74f33f430) When an airlock was depowered, it would enter a sleep loop, decrementing its delay by 1 second every well, one second, so long as it had the right wires flipped This is very stupid Instead, let's use signals off wire changes and a combo of timer and remaining time var to do this with JUST a timer Most of the changes here are just swapping over wires to a setter to make signal registration work\ ## Why It's Good For The Game Less sleeping around explosions means less dropped ticks after a bomb goes off. Good just in general Also this excises dumb boomer code and adds some hooks for other devs to use (we should use wires more man) |
||
|
Watermelon914
|
a98706ff8b |
Adds TTS to the game. Players can select their own voices in preferences. (#74775)
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
John Willard
|
1674f25725 |
New Medical job: The Coroner (#75065)
## About The Pull Request HackMD: https://hackmd.io/RE9uRwSYSjCch17-OQ4pjQ?view Feedback link: https://tgstation13.org/phpBB/viewtopic.php?f=10&t=33972 Adds a Coroner job to the game, they work in the Medical department and have their office in the Morgue. I was inspired to make this after I had played my first round on Paradise and messed around in there. The analyzer is copied from there (https://github.com/ParadiseSS13/Paradise/pull/20957), and their jumpsuit is also mostly stolen from it (i just copied the color scheme onto our own suits). Coroners can perform autopsies on people to see their stats, like this  They have access to Medbay, and on lowpop will get Pharmacy (to make their own formaldehyde). They also have their own Secure Morgue access for their office (doubles as a surgery room because they are edgelords or whatever) and the secure morgue trays. Secure Morgue trays spawn with their beepers off and is only accessible by them, the CMO, and HoS. It's used to morgue Antagonists. Security's own morgue trays have been removed. The job in action https://cdn.discordapp.com/attachments/950489581151735849/1102297675669442570/2023-04-30_14-16-06.mp4 ### Surgery changes Autopsies are a Surgery, and I tried to intertwine this with the Dissection surgery. Dissections and Autopsies both require the Autopsy scanner to perform them, however you can only perform one on any given body. Dissections are for experiments, Autopsies is for the paper of information. Dissected bodies now also give a ~20% surgery speed boost, this was added at the request of Fikou as a way to encourage Doctors to let the Coroner do their job before reviving a body. I also remember the Medical skill, which allowed Doctors to do surgery faster on people, and I hope that this can do something like that WITHOUT adding the potential for exploiting, which led to the skill's downfall. ### Morgue Improvements Morgue trays are no longer named with pens, they instead will steal the name of the last bodybag to be put in them. Morgue trays are also removed from Brig Medical areas and Robotics, now they have to bring their corpses to the Morgue where the Coroner can keep track and ensure records are properly updated. ### Sprite credits I can't fit it all in the Changelog, so this is who made what McRamon - Autopsy scanner Tattax - Table clock sprites and in-hands CoiledLamb - Coroner jumpsuits & labcoats (inhand, on sprite, and their respective alternatives) - Coroner gloves - CoronerDrobe (the vending machine) ## Why It's Good For The Game This is mostly explained in the hackmd, but the goal of this is: 1. Increase the use of the Medical Records console. 2. Add a new and interesting way for Detectives to uncover mysteries. 3. Add a more RP-flavored role in Medical that still has mechanics tied behind it. ## Changelog 🆑 JohnFulpWillard, sprites by McRamon, tattax, and Lamb add: The Coroner, a new Medical role revolving around dead corpses and autopsies. add: The Coroner's Autopsy Scanner, used for discovering the cause for someone's death, listing their wounds, the causes of them, their reagents, and diseases (including stealth ones!) qol: Morgue Trays are now named after the bodybags inside of them. balance: The morgue now has 'Secure' morgue trays which by default don't beep. balance: Security Medical area and Robotics no longer have their own morgue trays. balance: Dissected bodies now have faster surgery speed. Autopsies also count as dissections, however they're mutually exclusive. /🆑 --------- Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
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. |
||
|
oranges
|
4c48966ff8 |
Renames delta time to be a more obvious name (#74654)
This tracks the seconds per tick of a subsystem, however note that it is not completely accurate, as subsystems can be delayed, however it's useful to have this number as a multiplier or ratio, so that if in future someone changes the subsystem wait time code correctly adjusts how fast it applies effects regexes used git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i 's/DT_PROB/SPT_PROB/g' git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i 's/delta_time/seconds_per_tick/g' |
||
|
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) |
||
|
LemonInTheDark
|
60e85fa947 |
Polishes some side sources of light and color (#73936)
## About The Pull Request [Circuit Floor Polish](https://github.com/tgstation/tgstation/commit/6b0ee9813271f693ceb44ad42277c36ef2e71268) Circuit floors glow! but it looks like crap cause it's dim and the colors are washed out. I'd like to make them look nicer. Let's make them more intense and longer range, and change the colors over to more vivid replacements. While I'm here, these should really use power and turn on and off based off that. Simple enough to do, just need to hook into a signal (and add a setter for turf area, which cleans up other code too). [Desklamp Upgrade](https://github.com/tgstation/tgstation/commit/8506b13b9c97bf740c3e97db04450555387dd126) Desklamps look bad. They're fullwhite, have a way too large range.Crummy. Let's lower their lightrange from 5 to 3.5, and make the ornate ones warmer, and the more utilitarian ones cooler. The clown one can be yellow because it's funny I'm renaming a color define here so I'm touching more files then you'd expect [Brightens Niknacks](https://github.com/tgstation/tgstation/pull/73936/commits/835bae28e9eb9946be53c9f5dac0a0a39f15ef21) Increases the light range of request consoles, status displays, newscasters, and air alarms (keycard machines too, when they're awaiting input at least) Increases the brightness of air alarms, I think they should be on par with apcs, should be able to tell when they're good/bad. Increases the brightness of vending machines (I want them to light up the tiles around them very lightly, I think it's a vibe) Fixes a bug with ai status displays where they'd display an emissive even if they didn't have anything on their screen, looking stupid. This was decently easy but required a define. Looked really bad tho ## Why It's Good For The Game Pretty <details> <summary> Circuit Floors </summary> Old   New   </details> <details> <summary> Desk Lights </summary> Old   New   </details> The niknack changes are more minor so I'm not gonna grab photos for them. I can if you'd like but I don't think it's necessary. Mostly a vibes in dark spaces sorta thing ## Changelog 🆑 add: I made circuit floors brighter and more vivid. add: Made air alarms, vending machines, newscasters, request consoles, status displays and keycard machines slightly "brighter" (larger light range, tho I did make air alarms a bit brighter too) add: Tweaked desklamps. Lower range, and each type gets its own coloring instead of just fullwhite. fix: AI displays are no longer always emissive, they'll stop doing it if they aren't displaying anything. Hopefully this'll look nicer /🆑 |
||
|
ShizCalev
|
d7ae9c580c |
Fixes the cops not being called when minors try to purchase cigarettes from vending machines. (#73008)
radios in nullspace are bad.
```
[2023-01-08 15:10:45.804] runtime error: Cannot read null.z
- proc name: New (/datum/signal/subspace/vocal/New)
- source file: broadcasting.dm,122
- usr: Ilya Volyova (/mob/living/carbon/human)
- src: /datum/signal/subspace/vocal (/datum/signal/subspace/vocal)
- usr.loc: the floor (131,87,2) (/turf/open/floor/iron)
- call stack:
- /datum/signal/subspace/vocal (/datum/signal/subspace/vocal): New(the station bounced radio (/obj/item/radio), 1359, The ShadyCigs Deluxe (/atom/movable/virtualspeaker), /datum/language/common (/datum/language/common), "SECURITY ALERT: Underaged crew...", /list (/list), null)
- the station bounced radio (/obj/item/radio): talk into impl(the ShadyCigs Deluxe (/obj/machinery/vending/cigarette), "SECURITY ALERT: Underaged crew...", null, /list (/list), /datum/language/common (/datum/language/common), null)
- world: ImmediateInvokeAsync(the station bounced radio (/obj/item/radio), /obj/item/radio/proc/talk_into... (/obj/item/radio/proc/talk_into_impl), the ShadyCigs Deluxe (/obj/machinery/vending/cigarette), "SECURITY ALERT: Underaged crew...", 1359, /list (/list), /datum/language/common (/datum/language/common), null)
- the station bounced radio (/obj/item/radio): talk into(the ShadyCigs Deluxe (/obj/machinery/vending/cigarette), "SECURITY ALERT: Underaged crew...", 1359, /list (/list), /datum/language/common (/datum/language/common), null)
- the ShadyCigs Deluxe (/obj/machinery/vending/cigarette): vend(/list (/list), null)
- the ShadyCigs Deluxe (/obj/machinery/vending/cigarette): ui act("vend", /list (/list), /datum/tgui (/datum/tgui), /datum/ui_state/default (/datum/ui_state/default))
- /datum/tgui (/datum/tgui): on act message("vend", /list (/list), /datum/ui_state/default (/datum/ui_state/default))
- /datum/callback/verb_callback (/datum/callback/verb_callback): InvokeAsync()
- /datum/tgui (/datum/tgui): on message("act/vend", /list (/list), /list (/list))
- /datum/tgui_window (/datum/tgui_window): on message("act/vend", /list (/list), /list (/list))
- tgui Topic(/list (/list))
- Ilya Volyova (/client): Topic("type=act%2Fvend&payload=%7B%22...", /list (/list), null)
```
🆑 ShizCalev
fix: Fixed the cops not being called when minors try to purchase
cigarettes from vending machines.
/🆑
|
||
|
Rhials
|
b7bf3db955 |
Vendors now tip in the opposite direction when struck from inside of a wall (#72898)
When someone standing on a closed turf strikes a vendor, the vendor will now instantly tip over, in the _opposite_ direction. This will provide no chance for goodies, meaning you cannot build walls on top of yourself and abuse this for free stuff. |
||
|
MrMelbert
|
acb96fee1d |
Refactors memories to be less painful to add and apply, moves memory detail / text to memory subtypes. Adds some new memories to demonstrate. (#72110)
## About The Pull Request So, a huge issue with memories and - what I personally believe is the reason why not many have been added since their inception is - they're very annoying to add! Normally, adding subtypes of stuff like traumas or hallucinations are as easy as doing just that, adding a subtype. But memories used this factory argument passing method combined with holding all their strings in a JSON file which made it just frustrating to add, debug, or just mess with. It also made it much harder to organize new memories keep it clean for stuff like downstreams. So I refactored it. Memories are now handled on a subtype by subtype basis, instead of all memories being a `/datum/memory`. Any variety of arguments can be passed into memories like addcomponent (KWARGS) so each subtype can have their own `new` parameters. This makes it much much easier to add a new memory. All you need to do is make your subtype and add it somewhere. Don't need to mess with jsons or defines or anything. To demonstrate this, I added a few memories. Some existing memories had their story values tweak to compensate. ## Why It's Good For The Game Makes it way simpler to add new memories. Maybe we'll get some more fun ones now? ## Changelog 🆑 Melbert add: Roundstart captains will now memorize the code to the spare ID safe. add: Traitors will now memorize the location and code to their uplink. add: Heads of staff winning a revolution will now get a memory of their success. add: Heads of staff and head revolutionaries who lose their respective sides of the revolution also get a memory of their failure. add: Completing a ritual of knowledge as a heretic grants you a quality memory. add: Successfully defusing a bomb now grants you a cool memory. Failing it will also grant you a memory, though you will likely not be alive to see it. add: Planting bombs now increase their memory quality depending on how cool the bomb is. refactor: Memories have been refactored to be much easier to add. /🆑 |
||
|
san7890
|
4efacff9fa |
Completely Culls req_access_txt/req_one_access_txt (#72281)
Hey there, Now that every instance of `req_access` and `req_one_access` is a list of strings, there is absolutely no reason for req_access_txt/req_access_one_txt to exist. In fact, any instance where they were still used in the codebase was very convoluted and was very broken! Don't worry, I fixed it all out, and life is good. I also dmdoc the surviving access variables, because those were missing. I went on the side of caution and made a more verbose documentation with an example just to have people really grasp this (it took me a while to actually get it) I believe that we changed _everything_ over to the req_access/req_one_access system earlier this year in VV, but the problem is that _new mappers don't understand the difference between the two systems_. In fact, the "txt" system is completely redundant since all it does is transition stuff to the "base" system. So, let's just completely cull the one that's all but deprecated and ensure this confusion no longer arises. The whole purpose of "txt" seemed to be to convert the access, but it's all pointless now that we can just read the list directly. I'm also 99% certain that the "access check" on vending machines broke (and didn't seem to have correct logic in the first place? I legitimately couldn't find a case where it could fail in testing, so I changed that up), and that's fixed up now. Let me know if I was clueless there. I know it's short-circuiting now as opposed to "all must be true", but it just didn't work. |
||
|
Zephyr
|
6a0c884410 |
[no gbp] removes all duplicate armor datums (#72354)
## About The Pull Request closes #72348 Title ## Why It's Good For The Game My bad ## Changelog Heres the script I used this time if you want to ```cs var baseDir = Environment.CurrentDirectory; var allFiles = Directory.EnumerateFiles($@"{baseDir}\code", "*.dm", SearchOption.AllDirectories).ToList(); var known = new Dictionary<string, List<KeyValuePair<string, int>>>(); foreach (var file in allFiles) { var fileLines = File.ReadAllLines(file); for (var i = 0; i < fileLines.Length; i++) { var line = fileLines[i]; if (line.StartsWith("/datum/armor/")) { var armorName = line.Replace("/datum/armor/", "").Trim(); if (!known.ContainsKey(armorName)) known[armorName] = new List<KeyValuePair<string, int>>(); var knownList = known[armorName]; knownList.Add(new KeyValuePair<string, int>(file, i)); } } } Console.WriteLine($"There are {known.Sum(d => d.Value.Count)} duplicate armor datums."); var duplicates = new Dictionary<string, List<int>>(); foreach (var (_, entries) in known) { var actuals = entries.Skip(1).ToList(); foreach (var actual in actuals) { if (!duplicates.ContainsKey(actual.Key)) duplicates[actual.Key] = new List<int>(); duplicates[actual.Key].Add(actual.Value); } } Console.WriteLine($"There are {duplicates.Count} files to update."); foreach (var (file, idxes) in duplicates) { var fileContents = File.ReadAllLines(file).ToList(); foreach (var idx in idxes.OrderByDescending(i => i)) { string line; do { line = fileContents[idx]; fileContents.RemoveAt(idx); } while (!String.IsNullOrWhiteSpace(line)); } File.WriteAllLines(file, fileContents); } ``` |
||
|
Zephyr
|
72add64520 |
Refactors armor into dedicated subtypes (#71986)
## About The Pull Request See title. ## Why It's Good For The Game Code is cleaner, and more readable/intuitive Technically closes https://github.com/tgstation/dev-cycles-initiative/issues/8 ## Changelog 🆑 refactor: armor, from the ground up basically /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
Tim
|
f6caf9a008 |
Add language variety to machines that speak (#71643)
## About The Pull Request This builds on #70278 by giving other machines (vendors, newscasters, computers, etc.) the ability to speak different languages. If the station "Bot language malfunction" trait is rolled, then these machines will select a random race starting language. If a machine is EMP'd then it has a chance to change the language. There is also a language wire that can be pulsed to change the language for vending machines. Default language for machines is galactic common, but there are rare exceptions: - Beach vendors will now speak beachbum - Syndicate vendors will now speak codespeak - Changeling vendors will now speak a random language after each slogan ## Why It's Good For The Game More depth to the language feature. ## Changelog 🆑 add: Add language variety to machines that speak. You can also pulse the vendor language wire to make it switch languages or EMP a machine to get the same effect. add: Shambling cola vendors will now speak a different language each time they talk. Syndicate vendors will now speak codespeak. Beach vendors will now speak beachbum. /🆑 |
||
|
EvilDragonfiend
|
392204b697 |
Fixes vendor showing weird glass icons (#71929)
## About The Pull Request Fixes vendor showing weird glass icons ## Why It's Good For The Game bug fix good ## Changelog 🆑 fix: vendor no longer shows glass icons in a specific condition /🆑 |
||
|
LemonInTheDark
|
cf02f62298 |
useless update_appearance reduction, emissive_blocker micro optimization (saves a second of init) (#71658)
## About The Pull Request [Saves 0.2 seconds of init time. 50% of emissive blockers](https://github.com/tgstation/tgstation/commit/8318b648f6d32844aacbfb4c309152cd45801f5c) Emissive blockers are a decent expense during init, even these, which are the ones that update outside of initialize. I've inlined them, removed some redundant vars and checks, reduced the arg count, and shifted some things around. This ends up saving 200ms, or 50% of its total cost. I also shifted mutable_appearance about a bit. it's not a massive saving, but it is technically faster [Prevents a few redundant appearance_updates, saves 0.8 seconds of init](https://github.com/tgstation/tgstation/commit/5475cd778b66b22b1e2c8d86b2c6d59fb84f219a) Prequisit info: update_appearance is decently expensive It's good then to only do it if we have a reason to, right? Me and moth were shooting the shit about just general init time, and we came up with the idea of tracking which update_appearances actually "worked" and which didn't. That bit comes later, let's enjoy the fruits of that work first First, holograms were calling update_appearance on process, for almost no reason. I patched the one event they don't already "react" to, and then locked it behind a change decection if. good for live, doesn't impact init. Next, decals. If you add a decal to something before it inits, it'll react to the after successful init signal. The trouble is the same atom could have its appearance updated from this MORE then once, since decals can be stacked on tiles, and signal unregisters don't work once the signal is sent. So we add a flag to track if we've had this happen to us or not, so it only happens once. saves 80 ms Power! lots of things call power_change on init, often more then once. We'll update appearance for each of those calls, even if only one is an actual change. That's silly, better to track what sort of power we're using for our appearance and go off that changing This was taking about 300ms. Really stupid Icon smoothing. After emissive blockers were added, any change to something's icon smoothing would lead to an update_appearance call. Nasty shit, specially cause of walls, which don't even use emissive blockers. Ok then, so we'll always update appearance for movables, and will allow turfs that are interested to hook it manually. Not many of those anyhow This is slightly a dev ux thing, but it saves 600ms so I think it's worth it. Rare case anyway Telecomms: telecomm machines were updating appearance on process. This is to cover for them turning on/off on process. Better then to just check if on actually changed. This cost adds up midgame, doesn't impact init tho Materials: There's this update_appearance call in material on_apply. it doesn't do anything. The logs will lie to you and say it does, but it's just like reapplying emissives. It doesn't need to exist Saves like 50ms Canisters: Live thing, lots of time wasted updating appearance for no reason, lets see if we change anything first yes? [Uses defines to wrap update_appearance for tracking](https://github.com/tgstation/tgstation/commit/4fa82e1c9d93577aadb3c743f17196331f62e67c) [Undoes _update_appearance changes, instead reccomends 2 regexes to use](https://github.com/tgstation/tgstation/commit/a8c8fec57a4e43d1fa636b5ac68459903faa9fc5) I need file and line number for my tracking, so I need to override update_appearance calls, and also preferably not require every override of update_appearance to handle dummy file + line args. So instead, I created a wrapper proc that checks to see if appearanaces match (they're unique remember, the two of the same visual appearance will be equivalent) The trouble is I can't intercept JUST proc calls, or JUST function definitions with defines. it needs to be both. So I renamed the /update_appearance proc to /_update_appearance this way I can capture old uses, and don't need to worry about merge/dev brain skew ~~It does mean that all update_appearance proc definitions now look weird tho. My profiling is leaking into dev ux. I wish I had better templating.~~ **The above is no longer being pr'd**, it's instead just recommended via a few regexes adjacent to the define. Smelled wrong anyhow [Adds a setter for panel_open, so I can update_appearance on it](https://github.com/tgstation/tgstation/pull/71658/commits/cf1df8a69fc1a816391d085ee7419b14f9fe9167) ## Why It's Good For The Game Speed |
||
|
Rimi Nosha
|
c60b5575b4 |
TGUI Latejoin Menu! (#71531)
## About The Pull Request Converts the latejoin menu to TGUI, and makes it give reasons for why a job is unavailable instead of hiding it! <details> <summary>Cool Images!</summary> <image src=https://user-images.githubusercontent.com/106692773/205135570-c8b788f1-1ff0-4e6d-b53d-e2119317c37b.png> <image src=https://user-images.githubusercontent.com/106692773/205135598-2ac9e138-37dc-4baf-ae33-deb0990616cd.png> <image src=https://user-images.githubusercontent.com/106692773/205135609-ae6b840b-40b5-4248-bd30-5fdadd6582f2.png> <image src=https://user-images.githubusercontent.com/106692773/205135615-d8997834-f433-48ee-8763-274e306b521b.png> </details> ## Why It's Good For The Game TGUI menu good, yes? ## Changelog 🆑 RimiNosha qol: The latejoin menu is now TGUI! qol: You'll also be able to see why you can't join a job, instead of it being invisible! code: Department UI colors have changed slightly. This will only affect the latejoin and nations UIs. /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: Aleksej Komarov <stylemistake@gmail.com> |
||
|
Mothblocks
|
6a2c7965b2 |
Don't update radio icon unless necessary, don't create radios in vending machines until needed -- Saves 0.091s of init time (#71682)
#71006 introduced a large regression in init times by forcing them to update their icons for every single proc being called. This is very slow. Defers the icon creation until initialize is finished, and only if necessary. Also learned that basically everything has a radio by making a station bounced radio and putting it inside them. Yay...Removes the one in vending machines until it's actually necessary. Was thinking of making it a PDA message instead but nah |
||
|
Zephyr
|
bbefd1c1bd |
prevent crushing mobs you cannot reach (#71363)
See title Resolves https://github.com/tgstation/tgstation/issues/69110 🆑 fix: Vending machines will no longer crush you through windows! /🆑 vscode web editor sucks ass and didnt let me set pr body |
||
|
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>
|
||
|
itseasytosee
|
8e4bc80d92 |
Easy's Super Omega "unarmed strike based species var moved to limbs" refractor, unarmed strike striking with specific body parts rather than it just being flavor, and brain based attacking limb selection extra chunky edition. And also bodypart traits. (#70422)
<!-- 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 Ok first if you don't want to read any further explanation you can watch these two videos and you will understand all of the mechanical depth of this change. https://user-images.githubusercontent.com/55666666/194788103-8019dad8-7e44-4cc8-bc8f-0a4f8f00a357.mp4 https://user-images.githubusercontent.com/55666666/194788109-345a3146-fb4b-4a2e-9c2a-e2ee786ba97d.mp4 ### **Disclaimer: Effect on gameplay extremely limited and niche read at your own risk** Starting at the top, regarding the species datum, the vars attack_type, punchdamagelow, punchdamagehigh, punchstunthreshold, attack_verb, attack_effect, attack_sound, and miss_sound have been removed. All bodyparts (not just arms) now have corresponding variables for how they should act if utilized in an unarmed attack. The bodyparts vars are correlated to their corresponding species. All arm type bodyparts have been repathed through a common parent for the purposes of keeping variables consistent. The same is true for the legs. When a carbon begins an unarmed attack, it will check the carbon's brain to see what limb should be used for the attack. If the brain has no answers it will default to the arm that corresponds to the active hand of the attacker. Currently in all brains except monkeys, it check to see if the attackers target target is laying down, and if so, call for a kick with the leg that corresponds with the attackers active hand. If the attacker has no useable legs, or the attacker does not have a corresponding leg to the active hand, or the target is not laying down, the brain will simply default for an attack with the active hand. Monkeys brains (take note the difference between having a monkey brain and being controlled by monkey AI) are the exception, they will simply always choose their heads, and by default an attack with the head is a bite attack. As an example: Previously ethereal would make attacks that used the verb "burn" and did burn damage despite what limbs they possessed. Now anybody with an ethereal limb will make an unarmed attack that does burn damage and has all the same verbs as an ethereal would. And finally, the chunky finger species trait has been moved over to the species arms. Effect on other sources like insuls remains unchanged. <!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! --> ## Why It's Good For The Game The main motivation is moving direct mechanical elements off of species to, quoting tralezab here, "Make species like a blueprint." Opens more opportunities for coders to add specific elements to limbs, perhaps we could see a buff to unarmed strikes from robot arms, or a species that headbutts people to death. Also undeniably cool, and fixes some weirdness like fully auged ethereals still doing their normal ethereal attack. <!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. --> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 itseasytosee refactor: Elements of unarmed strikes are now limb dependent instead of species dependent. Go rip off an ethereal arm, sew it onto yourself, and burn some people. /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> Co-authored-by: itseasytosee <noodlenymphftw@gmail.com@gmail.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com> Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
ArcaneMusic
|
f3ca3424c9 |
Merges the Export Scanner, Sales Tagger, and Price Tagger into one item. (#70314)
About The Pull Request The Export Scanner, Sales Tagger, and Price Tagger are all niche, cargo adjacent items that each perform a different minor task and if using one, requires usually one of the three extremely rarely. Each one requires printing a new item at the lathe, all for maybe one or two uses before it needs to be replaced. This PR merges the three into a singular, modular item. Existing export scanners have been reflavored the "universal scanner". When used in-hand, it produces a radial to swap between the three modes, Each mode has identical function to their previous scanner, with the only functional difference being that the sales tagger now prints new tags on secondary attack as opposed to primary. The other two items lathe recipes have been removed, as their functionality has been fully moved to the universal scanner. Also flips the export scanner icon state to match the other 2 scanner items that have been lumped together. Why It's Good For The Game Cargo now only needs to swap between 1 of three nearly identical barcode scanner looking items at a time, as opposed to having to print an item that sees functional use once every thousand rounds. By increasing the ease of use, it will also make it easier to use custom vendors, as well as print sales tags on regular rounds, as the universal scanner can still be found in shipping boxes located around the station and in tool storages. Arguably not a balance change, as the three tools are extremely cheap to print, and don't have a formal impact on cargo balance except for tedium. |
||
|
ArcaneMusic
|
9b0713e790 |
Moves Custom Vendor side-effects from delete to deconstruct. (#70336)
* Fixes Custom Vendor Side-Effects by moving the effects to deconstruct, which blows the contents inside up as theft-deterrent. |
||
|
san7890
|
9dfee357f8 |
Fixes Weird Vending Machine Untipping Behavior (Cyborg Edition) (#70448)
* Adds an Adjacency Check for untipping Vending Machines Hey there, Basically, if you were a cyborg, you could untip a vending machine from halfway across the world. There was no adjacency check for pretty much anyone to untip a vending machine, and since a cyborg will always pass through on anything that interacts with an `/obj/machinery`, it would always untip no matter how far away the person was. In fact, we even have an `isAI` check down the line because I think AI's could remotely untip any vending machine (lol). Let's just pass in an adjacency check for this. Phew. * an even earlier return * alright let's actually not override base behavior * updates the check later on in the chain |
||
|
Yaroslav Nurkov
|
04ca99d7e9 |
NT Pay app. Money send on distance, transaction log! (#70108)
* base * reasons * GetToken proc, with a many remarks * Add a way to change reason in transfer_money proc. Add a reasons. * Reason to use the app. Commission. Standard application. * Apply suggestions from code review - Tralezab Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com> * Tralezab & jlsnow301 advices. New format(everywhere) * Nanotrasen * Refactor TGUI(not me:( ). Fix useless capitalize * Update code/modules/economy/account.dm * Trans transforms in transaction * coMmission. little autodoc mistalke. Translation != Transaction * oops * Merge Conflict * ... * back feats * mistakes bye! * ну да Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com> |
||
|
John Willard
|
91f02f2a6b |
canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE (#69790)
* canUseTopic now uses TRUE/FALSE instead of defines that just say TRUE The most idiotic thing I've seen is canUseTopic's defines, they literally just define TRUE, you can use it however you want, it doesn't matter, it just means TRUE. You can mix and match the args and it will set that arg to true, despite the name. It's so idiotic I decided to remove it, so now I can reclaim a little bit of my sanity. |
||
|
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 |
||
|
Rhials
|
e213772e9e |
Minor adjustments to the brand intelligence event (and also a tiny change to stray meteor admin setup) (#69984)
* Brand Intelligence false alarm will no longer only report that a cola vendor has been hit, and will instead use an on-station vendor to lie to players more accurately. * Modified the brand intelligence announcement slightly to give a bit more direction to the crew. * Changed some vendor vars to use TRUE/FALSE instead of 1/0 * Murders the last remaining single character varname in the brand intelligence file. * Brand Intelligence event now supports admin setup. Choose your brand of brand intelligence! * Stray meteor event admin setup message no longer lies to you. |
||
|
Seth Scherer
|
f1a363c825 |
Converts a shitload of istypes to their more concise macros (#69260)
* Converts a lot of istypes() to use their istype macro helpers. |
||
|
Mothblocks
|
9323d90a7d |
Vending machines now support categories (and premium/contraband is moved there), adds it to the Clothesmate (#69076)
* Initial setup and data * Work on UI * Final UI * Remove TODO * Section for categories |
||
|
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. |
||
|
bob-b-b
|
17692b8522 |
Buffs the greedy god vending machine (#67836)
The greedy god vending machine was pretty underwhelming compared to normal custom vending machines, it only had fancy light beams, this makes it harder to break and lets it store/sell more items |
||
|
SmArtKar
|
207b36fb67 |
Fixes vendors qdeling brains of GODMODEd admemes upon rolling a crit squash (#67100)
* Fixes vendor qdeling brains of GODMODEd admemes |
||
|
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.
|
||
|
ArcaneMusic
|
6ad8000bd3 |
Adds the Accounting Console to the game (HOP Job Content) (#66304)
This PR adds the accounting console to the game, as a console that exists round start within the HOP's office. The accounting console allows for players to get 2 separate lists of information: - A list of all the bank accounts associated with each crewmember on the station, listing their account balance, their job, and their paygrade modifier (Which is either 1 or 0.7, depending on their species) - The audit log, a basic list of transactions of player purchases, listed listed in the following formal universally: [person] spent [cost]CR on [Purchase Source]. It's intentionally left without all the information so that players will need to investigate if they notice strange purchases coming from an account, as a kind of ghetto money forensics. |
||
|
Arkatos1
|
b98d91c095 |
updateDialog and updateUsrDialog cleanup (#66494)
This PR focuses on cleaning up two procs - updateDialog and updateUsrDialog. Both of which are/were used updating for old HTML UIs. As these UIs got converted to TGUI over time, these old code fragments started to pile up, often due to coders simply overlooking them. This resulted in them being dead code doing nothing when called, or randomly opening up windows when they shouldnt, for example when a vending machine is screwdrivered and UI cannot even be interacted with.
However, there were also some desirable uses - like opening a window when an ID is inserted into civilian bounty console, which you are then gonna obviously use to pick a bounty. I kept these uses and replaced them with proper ui_interact, so they now always work, instead of them working only when you had them set as a currently used machine on mob. The list of these changes is:
Civilian Bounty Console will now always bring up its UI when you insert the ID.
Air Alarm and APC will now always bring up its UI when you unlock their controls.
Portable Chem Mixer, Chem Dispenser, Chem Heater, Improvised Chem Heater, Chem Spectometer and Chem Master will now always bring up their UI when you add or replace beaker to them.
Two old /Topic calls were cleaned up as well, as they were no longer relevant.
Removes dead or outdated code, adds sensible UX when working with certain UIs.
|
||
|
Ghilker
|
ffd1ae5fc0 |
Rebalanced Power consumption, increase for machines (#66059)
Machinery power consumption rebalance. |
||
|
John Willard
|
2db00c7dc5 |
standardizes default unfasten wrench (#65425)
I'll do more in the future but I'll limit myself to this because I'm tired, bored, and don't want to make so many PRs touching the same things that I have to deal with conflicts each time one is merged. Just as an example, screwdriver's gotta be done as well, does the exact same thing wrenches do, I believe. Standardizes (and touches) each time default_unfasten_wrench is used. Fixes tool logs, since it relies on tool acts to exist, I'm trying to move as many tool acts to its proper proc. Like a spiritual successor to the tool superpack PRs. Co-authored-by: Luc <89928798+lewcc@users.noreply.github.com> |
||
|
Kapu1178
|
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 |
||
|
AnturK
|
41e02e5e39 |
Fixes issues found by new switch lints (#64766)
Very nice addition to sdmm. |
||
|
Ghom
|
c5d2b2e51e |
Fixes layering issues brought by the FoV PR. (#63903)
* Fixed most (not all) incorrect planes and layers detected by the unit test. |
||
|
Jeremiah
|
30253cf6a8 | Tgui input refresh (#64331) | ||
|
Jeremiah
|
cdfd5df7be |
Refactors pay stands + custom vendors (#63889)
I am disgruntled by the way pay stations work. They're not intuitive, they're a pain to build and have no interface. Basically: They don't get made, and the potential is lost.
Pay stands => Holopay
Summoned by right clicking your ID
Disappears if the card is out of range.
New TGUI window that offers more customization
Other bundled fixes:
Custom vendors become more user friendly
Code improvement
Lots of documentation + refactoring
New bundled number input will likely take place of animated number in tgui input number
Why It's Good For The Game
More RP opportunity for players, plus bug fixes. It's now much easier for players to start their own in game business selling substances clown shoes.
Changelog
cl
code: Created a new input component that accepts only integers. More usage to come.
refactor: Pay stands are now holographic. It's 2562! Create one by right-clicking your ID.
del: Circuit boards for pay stands.
refactor: Pay stands now have their own TGUI.
fix: Custom vendors now alert you when someone makes a purchase.
fix: Custom vendors now place items in your hand when you make a purchase.
/cl
|
||
|
SMOSMOSMOSMOSMO
|
4748bb0769 |
Vending Machine no gravity fix (#64379)
Vending machines will no longer tilt onto people if there is currently no gravity experienced by it. |
||
|
cacogen
|
0ebcce8de2 |
Fixes + expands vending machine returned purchases (#64314)
Fixes vending machine returns, also makes it so you can return anything to (nearly) any vending machine. New stuff vends first. Secondhand stuff last. |
||
|
Seth Scherer
|
ad55a08493 |
Stops vending machines from runtiming when broken (#63888)
* fix * review |
||
|
Seth Scherer
|
9436ed25c8 | Fixes cyborgs being able to right a vending machine from any distance #63887 | ||
|
Jeremiah
|
9c6fdb567d |
TGUI list conversions + bug fixes (#63354)
About The Pull Request
Converts more inputs to TGUI. Possibly all user-facing input lists in the game.
Did any surrounding text/number inputs as well
Added null choice support so users can press cancel.
Added some misc TGUI input fixes
Fixed custom vendors while I was there
I refactored a lot of code while just poking around.
Primarily, usage of .len in files where I was already working on lists.
Some code was just awful - look at guardian.dm and its non use of early returns
If there are any disputes, I can revert it just fine, those changes are not integral to the PR.
Why It's Good For The Game
Fixes #63629
Fixes #63307
Fixes custom vendors /again/
Text input is more performant.
Part of a long series of TGUI conversion to make the game more visually appealing
Changelog
cl
refactor: The majority of user facing input lists have been converted to TGUI.
refactor: Tgui text inputs now scale with entered input.
fix: Many inputs now properly accept cancelling out of the menu.
fix: Fixes an edge case where users could not press enter on number inputs.
fix: Custom vendor bluescreen.
fix: You can now press ENTER on text inputs without an entry to cancel.
/cl
|
