mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-05 14:17:12 +01:00
ed94de4ddf7edad8694badefc577392e0f762bf5
200 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 MrMelbert
|
43f1a52223 |
Removes some boilerplate from transforming component (#75998)
## About The Pull Request Removes some boilerplate from transforming component, uses traits in a similar way to the two-handed component Also fixes #74955 (If it's still broken?) ## Why It's Good For The Game Makes it a bit cleaner to work with. Cause I wanna do something with this in the future maybe. ## Changelog 🆑 Melbert fix: Fixed e-cutlasses and bananium swords having invisible inhands code: Removed boilerplate from transforming component /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
MrMelbert
|
22799fcb89 |
Refactors the worst list ever, Stun Absorptions, into status effects + makes status flags more accurate (making certain mobs more vulnerable to incapacitations?) (#76000)
## About The Pull Request - Refactors the stun absorption list into a status effect - Does a fair bit of cleanup around stun code Weird thing involved in this. Check out this define. `IS_STUN_IMMUNE(source, ignore_canstun) ((source.status_flags & GODMODE) || (!ignore_canstun && (!(source.status_flags & CANKNOCKDOWN) || HAS_TRAIT(source, TRAIT_STUNIMMUNE))))` Notice anything odd about it? It only checks for `CANKNOCKDOWN`. What does this mean? Well, *every single* one of the stun procs used this macro for checking stun immunity. Which means every method of stun checked the `CANKNOCKDOWN`. This means that, say you have a mob which has `CANSTUN` but not `CANKNOCKDOWN`. Intuitively this means that the mob cannot be knocked down, but can be stunned. But instead, this means the mob can't be stunned either. This doesn't affect humans, they have all the status flags, but it does affect some other mobs. Alien adults (not queens) have `CANUNCONSCIOUS|CANPUSH`. Before, they didn't have `CANKNOCKDOWN`, so they were fully immune to stuns and sleeps. But now, they can be knocked unconscious. However, overall it doesn't change much, as most mobs that flipped off `CANKNOCKDOWN` flipped off the others too. For consistency though it makes sense for these flags to work as they imply. - `incapacitate` didn't have a signal, now it does ## Why It's Good For The Game More consistent, better code? I may use this in the future. ## Changelog 🆑 Melbert refactor: Refactored Stun Absorptions (Bastard Sword, His Grace) refactor: Refactored Stun Immunity. Note this means that some mobs which, prior, were immune to all forms of incapacitation are now vulnerable to some. Notably, adult non-queen xenomorphs are now vulnerable to falling unconscious. /🆑 |
||
|
san7890
|
874ada4278 |
Refactors Ant into Basic Mob (#75662)
## About The Pull Request On the tin. No new fancy AI wheels or anything, just a simple port. ## Why It's Good For The Game Knocks another one off the list, just really light stuff. They're a bit smarter now too, I think the intention was them for them to be pet-like as well (according to the code). Should be really rather easy to give them the pet-like behaviors and elements if someone really wants to in the future, just sorta paving the way for more work to be done to make mobs more intricate/interesting. ## Changelog 🆑 refactor: Giant ants are now more capable of distinguishing friend and foe. /🆑 |
||
|
Ghom
|
88b898dffd |
Stops shields getting broken by pillows and disablers. (#75759)
## About The Pull Request See the title. Doing so by adding a new arg for damage type to `check_shields()` and `hit_reaction()`. The other way would had involved a couple istype checks for item or projectile damage type, but this is a longer term solution and can tackle more than just that. ## Why It's Good For The Game Fixes #74876. ## Changelog 🆑 fix: Stops shields getting broken by pillows and disablers. /🆑 |
||
|
Tom
|
e5ce1c09a7 |
Converts butterflies to basic mobs and adds them to cytology (#75582)
## About The Pull Request Converts butterflies into basic mobs. Also a little list organisation. <details> <summary>Yep, those are some butterflies alright</summary>  </details> ## Changelog 🆑 refactor: Converted butterflies to the basic mob system add: Butterflies can now be grown in cytology /🆑 |
||
|
DrTuxedo
|
a4822c165b |
Now blocking is more noticeable! New blocking and parrying sounds (#74998)
## About The Pull Request Now whenever an attack is blocked, the sound will play and deflection with the item now plays sound too: https://github.com/tgstation/tgstation/assets/42353186/1a0cc5b7-f2af-4d72-88d7-57cc11f5baa3 The parry.ogg was updated to a better-sounding one https://github.com/tgstation/tgstation/assets/42353186/5ffc53d8-0b3c-4e6b-9256-b7b9735918bc Every item now has a "block_sound" that can be set, it determines what sound is played when you block an attack with it. Cult items no longer have their own way of fuckery to play parry sounds, now they use this system as well. Now shield bash sound is 80% smaller after cutting out all of its noise and silence. ## Why It's Good For The Game Adds feedback on whether the attack was blocked or not, signalling both to the attacker and defender that it didn't go through even if the animation played, which is a great QoL. Same with the deflection sound (although deflection is still pretty visible, the sound would not hurt) New sounds add more flavour to the weapons, especially the energy sword, giving it even more badassery. Cutting down the noise from the shield bash sound has made it better to listen and saved some kilobytes of information. And making every item use the universal system for blocking sounds, removing cultist items' own code for playing parrying sounds. ## Changelog 🆑 DrDiasyl aka DrTuxedo#0931 qol: Now blocking an attack will play a sound and display a spark effect, giving back feedback sound: parry.ogg was updated to a better-sounding version sound: shieldbash.ogg no longer has noise and unnecessary silence sound: New block_shield.ogg and block_blade.ogg for shields and energy swords code: Cultists items no longer have their own code for playing parrying sounds /🆑 --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
ShizCalev
|
d927f28951 |
Makes update_icon_updates_onmob more robust (#75324)
Safeguards against #74965 happening in the future. Noticed a bunch of these were using ITEM_SLOT_HANDS. This is incorrect, as the element already automatically updates held items. grep'd it to catch future instances. Likewise, a number of objects weren't passing slot_flags to the element, meaning it wasn't actually updating those things properly when they were being worn. I've simplified this so now the element will automatically update all slot_flags, and passing an additional slot to the element when being added is only needed for additional slots that might need to be updated. This also means if slot_flags change, the element will now update correctly as well. 🆑 ShizCalev code: The update_icon_updates_onmob element will now automatically update all slots in an item's slot_flags var. This does fix multiple things that weren't updating properly. Passing a slot to the element is now only necessary if you want to add additional slots to be updated. /🆑 |
||
|
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. |
||
|
san7890
|
fa0225b05c |
Converts Spiderlings from Structures to Basic Mobs (#75001)
If I could've made this more atomic, I would have in a heartbeat, trust me. ## About The Pull Request Hey there. People were mocking us for having spiderlings still be a subtype of `/obj/structure`. I decided to take a lot of time to fix that. A lot of behavior it was implementing was just pseudo-mob stuff, so it was actually easier than it looked for the raw conversion. A lot of the footwork on spider stuff in the basic framework was already done previously by Jacquerel, so that was pretty nice. However, there are two new things that weren't introduced in the code that had to be put in. A) A component to handle growth and differentiation into a mob. This may have already existed, no clue. If it does (and it's NOT evolutionary_leap), let me know. B) AI Behavior to handle seeking out a vent, entering a vent, and then exiting out of a different vent. I may have gone a bit wacky on the code, but it certainly works as expected (spiderling goes in one vent, exits the other). Let me know if you can think of a way it can be better optimized, but it was deliberately written to be very failsafey in case shit goes yonkers. One fundamental difference between structure spiderlings and basic mob spiderlings (beyond the AI and not just a random prob() check for movement) is the fact that they had vent movement coded in... but we _really_ don't need stuff like that for our intents and purposes. If the range turns out to be too OP in the current framework, we can always change it up a bit, but also there's a _lot_ of vents we can end up in the station (my testing had one spiderling end up in the AI sat to get obliterated). ## Why It's Good For The Game Spiderlings aren't structures! They behave like a mob should! Players can possess spiderlings! They work seamlessly with differentiating into a giant spider! Better AI! More room for people to add into this very under-utilized buggers! ## Changelog 🆑 refactor: Spiderlings are now basic mobs, report any complete weirdness/deviation from known behavior. They should be a lot more intelligent now though. add: AI Spiderlings are super fragile, but they're also super fast, especially when they get into a vent. Once they're in circulation, they could end up everywhere! Maybe in the armory, maybe in a locked closet in maintenance. Be sure to be vigilant and splat them whenever you can to save the station from a whole lotta heartache! /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
ChungusGamer666
|
821123b598 |
Makes a whole bunch of wooden objects flammable (#74827)
## About The Pull Request This whole PR started because I realized that baseball bats are not actually flammable which I found weird, then I looked at a whole bunch of other stuff that really should be flammable but also isn't. ## Why It's Good For The Game Makes wooden objects behave slightly more consistently? Honestly, most of these seem like oversights to me. ## Changelog 🆑 balance: The following structures are now flammable: Picture frame, fermenting barrel, drying rack, sandals, painting frames, paintings, spirit board, notice board, dresser, displaycase chassis, wooden barricade balance: The following items are now flammable: Baseball bat, rolling pin, mortar, coffee condiments display, sandals, wooden hatchet, gohei, popsicle stick, rifle stock /🆑 |
||
|
Tim
|
4397d63a55 |
Split weapons_and_items.dmi icons into their own categories (#74363)
## About The Pull Request This sprite file had been a dumping ground for miscellaneous sprites for the past decade. It's bloated and full of random kinds of icons and even has a few unused ones. It's time to reorganize them into their own separate dmi's based on theme. ## Why It's Good For The Game Better organization and easier access when looking for stuff. ## Changelog 🆑 imageadd: Split all icons in weapons_and_items.dmi to their own categories imagedel: Removed some unused icons /🆑 |
||
|
Rhials
|
9bdb194539 |
Gives the chainsaw start/stop/loop SFX, makes the arm-mounted chainsaw a subtype of a regular chainsaw (#73996)
## About The Pull Request The chainsaw now has an audio loop, as well as SFX for starting and stopping. I'm pretty confident that I did the attribution stuff correctly. https://user-images.githubusercontent.com/28870487/225054900-4bf87ee7-9245-4004-b414-77d0e6e83a7c.mp4 I think this came out well. It may be a bit loud, but I wanted the volume to be about the same as how the chainsaw slash sound comes out. Audio stuff isn't really my forte, so let me know if anything sounds off, or if any adjustments should be made. To make this work for the mounted chainsaw (more specifically, the abstract object that enters your hand), it has been made into a chainsaw subtype. An updatepaths script has been included in the event that someone has a map where the former path was included (why??). ## Why It's Good For The Game Makes the chainsaw more menacing. It's one of the most powerful and beloved pieces of crew weaponry, in addition to being a fucking chainsaw. If you aren't keen on walking around the hallways with the chainsaw loop playing like the badass you are, you can always just keep it off until you get into a fight. Gives an extra bit of immersion for those special moments where you get to chainsaw someone to death. ## Changelog 🆑 soundadd: The chainsaw now has SFX for starting, stopping, and idling. /🆑 |
||
|
MrMelbert
|
8284a7faab |
Fixes some invisible inhands from the transforming component (#73807)
## About The Pull Request The original issue caused by #70037 Esword issue caused by #73716 Originally the transforming component did not override the inhand icon state of the the item on its own (instead putting the onus on the item itself if they wanted unique behavior). It was changed to always update inhand icon state, most of which don't have one I don't really like this fix, it should be explicit "I want inhand to change" and not default, but this will work for now Also the PR that fixed the Jaws issue didn't actually set the var they created Fixes #73805 Fixes #73711 (Actually) ## Why It's Good For The Game Invisible sword bad ## Changelog 🆑 Melbert fix: Fixed a eswords, some tools, and some other misc. items from being invisible while extended / active fix: Teleshields and other misc items not extending in hand when active fix: Switchblades click on extend again fix: Pendrivers click on extend /🆑 |
||
|
Thedragmeme
|
88d6fae7c5 |
Tape Wizard, the distant cousin of the Paper Wizard (#73739)
## About The Pull Request Adds a new wizard costume and non magical variant, made exclusively from tape.  ## Why It's Good For The Game New unique nice looking thing = good Opens the door for more uses of an already niche mechanic  Roleplay. ## Changelog 🆑 add: Adds the tape wizard costume, both a real and fake variant add: Adds the costume behind the autodrobe contraband wire, and the real variant in the wiz den 🆑 |
||
|
tralezab
|
ad1f3ff8a2 |
Fixes valentines breaking highlander (#73519)
## About The Pull Request fixes #73450 Highlander checked special roles instead of antag datum for its abilities, special role is set to the last antag you were so becoming valentines (or anything else for that matter) broke it ## Why It's Good For The Game Bugfix ## Changelog 🆑 fix: Valentines and other antags no longer break highlander /🆑 |
||
|
Jacquerel
|
cbbf7b3613 |
Basic Mob Spiders III: Sgt. Araneus is no longer a bat (#73350)
## About The Pull Request This PR converts giant spiders into basic mobs and resultingly fixes #37793 They _should_ have the same behaviour as their simple mob versions although I can't verify that their movement speeds are _exactly_ the same. It should at least be pretty close. A quirk of spiders is that they had a pretty large `move_to_delay` which made them slow in the hands of AI (because it would just pause for ages between taking steps) and faster in the hands of players, and they often appear in both forms so I had to implement this as a speed modifier based on player control. Additionally this is the first basic mob which can be set on fire. This is currently implemented as a var on `mob/living/basic` but I know there was some annoyance at adding the environment tolerances as vars on there so if desired I can try and extract it out, I'm just not sure how easy it will be. Something else I noticed is that spiders seem to take stamina damage from bug spray... but stamina damage does nothing to either simple _or_ basic mobs. I have left it in for now in case I am missing something, and rebalancing it to do something else would be more like a balance change. Oh also I killed the `mob/basic/retaliate` folder because that isn't a classification that needs to exist or makes sense. ## Why It's Good For The Game We don't want to use simple mobs any more. Sergeant Araneus can finally actually be a spider, instead of being a bat. ## Changelog 🆑 refactor: Spider code has been refactored and AI-controlled spiders may have slightly different movement or reaction times. fix: Basic mobs can now be slowed when they take stamina damage, however currently only spiders actually _can_ take stamina damage. fix: Spiders should now more reliably disable their AI when controlled by a player. fix: Araneus is no longer considered to be a bat and so cannot fly. fix: Araneus is no longer considered to be a bat and so is no longer frightening to people who are scared of the supernatural. /🆑 |
||
|
itseasytosee
|
e977974750 |
Implements functionality for variable weapon attack and secondary weapon attack speeds. (#72959)
## About The Pull Request The click cooldown after attacking with a weapon can now be controlled with a var. A var can also be set for secondary attack cooldown, if unset it is the same as the weapon's normal attack speed. The two weapons who already had hardcoded mechanics to achieve this effect (see: The Stinger, Hyper Frequency Blade) have been converted to this system. ## Why It's Good For The Game Future varying of weapon qualities and admin shenanigans. ## Changelog 🆑 code: Greater support for variability in weapon attack speed admin: Admins are now able to grief you by hitting you with a toolbox 10 times in one second. /🆑 |
||
|
SuperSlayer
|
961029548e |
Fixes high frequency blade ignoring pacifism trait (#72754)
## About The Pull Request Fixes being able to slash mobs with wielded high frequency blades while having pacifism trait. ## Why It's Good For The Game Bugs are bad ## Changelog 🆑 fix: Wielded high frequency blades no longer ignore pacifism /🆑 |
||
|
MrMelbert
|
c3a1f21c1a |
Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind (#72267)
## About The Pull Request - Nearsighted is now a grouped status effect. - Blindness is now a grouped status effect. - Eye handling of blindness has improved. - When eyes are removed, they now cause you to become blind, rather than handling it in `update_tint`. - Being ahealed no longer blinds you for one tick, meaning that black overlay on aheal is gone. - Temporary Blindness is now a status effect. - Both Nearsightedness and Blindness have been exorcised from mob vars and life chains. This means that we've finally cut 2 procs from life, `handle_status_effect` and `handle_traits`, and moved both to event based processing. Wooo optimizations. - Swapped pacifism status effect to use apply and set helpers. - Removed an unused admin toggle that disabled welding helmet tint but also tint from every clothing item and also blindness from losing your eyes. - Clothes now generally all blind their mob more consistently. - Oculine, eye surgery, and sensory restoration are now no longer the only way to fix blindness from eye damage. If your eyes are healed through any other means, it will also heal your blindness. - Some things that made you blind, such as ling blind sting, no longer just flat made you blind from eye damage forever. They now cause eye damage directly, which in turn makes you blind from eye damage, as expected. - Pacifists can't eyestab anymore. Eyestabs now have a limit on the amount of blur applied. - Refactored some `is_x_covered` procs to accept flags rather than have a lot of arguments for some silly reason. - Unit tests for blindness. ## Why It's Good For The Game Blindness was exceptionally poorly handled prior, primarily due to the fact that it was tied to the mob instead of separated out On top of that the system put a LOT of faith in proper handling of blindness on the coder's end which was misplaced evidently. Many places didn't update or handle blindness correctly, or just let people perma-blind. Deferring it to a status effect improves this a lot ## Changelog 🆑 Melbert refactor: Refactored blindness and nearsightedness. Important to note is that all mobs are naturally blind until their eyes are actually created. refactor: Refactored "is covered" procs fix: Less sources of blindness now cause permanent blindness. Includes the "Blind" Spell and "Blind Sting" from changelings. admin: Ahealing someone no longer flashes the blind overlay for 1 tick. admin: I removed an unused (sort of) inaccessible admin verb that allowed you to toggle the tint from all welding helmets (and clothing) (and lack of eyes) in existence, let me know if you want similar back balance: Changeling "Blind Sting" now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Visionloss virus symptom now causes eye damage (enough to blind) rather than arbitrarily forcing blindness. balance: Oculine has been reworked slightly. Prior, Oculine arbitrarily healed blindness and nearsightedness from eye damage reagrdless of how damaged the eyes were, and applied blur on success. Now, Oculine just heals eye damage, and blindness / nearsightedness is restored in the process. There is now a probability every tick that eye blur is applied based on how pure the oculine is while healing very damaged eyes. balance: Pacifists can no longer eyestab. balance: Any clothing item that covers your eyes contributes to getting the bonus while sleeping, and to removing temporary blindness faster /🆑 |
||
|
ShizCalev
|
69337dffba |
Fixes dual wielding bypassing wizard checks (#72431)
Fixes #72428 🆑 ShizCalev fix: Non-magic inclined mobs will no longer fire staffs while duel wielding. /🆑 |
||
|
Mothblocks
|
f54dcda1c0 |
afterattack now returns a flag if it's reasonable to suspect the user intends to act on an item (#72320)
Necessary for #72292 to work effectively, and probably not very useful out of that context. Split out of its own PR because this is long and boring. I want to make sure that we're catching actual mistakes there, and not just experiencing side effects of how shitty the attack chain is. |
||
|
tralezab
|
27f09dd015 |
Cutting the Burdened Cheese Part 1: Removes free burden points from removing unnecessary or cosmetic organs. (#71938)
## About The Pull Request Burdened organs now only count for the main organs only. Cyberimplants don't count, alien organs don't count, etc. This is because someone could get a bunch of extra organs, and then take the burdened sect and remove them for free burden points. Useless organs for species also do not count (stomachs given to species that do not hunger, for instance) Removes the error on burden points clamping on negative values. This can happen when someone previously disabled takes burden sect. ## Why It's Good For The Game Cheese is being used to bypass the unique gameplay goals burdened sect provides. Will throw another pr when fikou finishes bat mutants ;) ## Changelog 🆑 fix: Removed some cheese strategies from burdened sect. /🆑 Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
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> |
||
|
ShizCalev
|
ae8ed395e1 |
Changes the missing food icon test to cover ALL /obj's (#71908)
Might as well cover everyyyyyyyyything. :) Fixes https://github.com/tgstation/tgstation/issues/71953 Fixes https://github.com/tgstation/tgstation/issues/71983 🆑 ShizCalev code: We now unit test all /obj's for missing icons. :) /🆑 todo: Fix the fucked up icons. Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
MrMelbert
|
79ffefa06d |
Allows Fully Heal to be passed a series of flags, fixes Adminordrazine being horrible (#71123)
## About The Pull Request - Fully heal can be passed a series of flags detailing what all is healed by the proc. This allows for things to provide almost-but-not-quite fully heals. - Uses this in Adminordrazine, so that it stops being a pain to update every time fully heal is updated. This includes some small balance changes which i'll go over, nothing extremely noticable. ## Why It's Good For The Game Allows for more precise control over full heals. ## Changelog 🆑 Melbert refactor: Fully heal can be passed a series of flags. As a result, some things which previously did a full heal might heal slightly less, or some things which did partial full heals might do slightly more. fix: Adminordrazine will no longer completely break every facet of a person admin: Ahealing a changeling will refill all of their chems. /🆑 |
||
|
Sol N
|
05dc0007f7 |
Boxcutters and Switchblades are now both knives when they should be knives (#71245)
## About The Pull Request The humble boxcutter always had knife tool behaviour turned to true instead of only being a knife when the blade is out, and its rulebreaking older brother the switch blade, despite having a description that calls it a knife, never had any knife tool behaviour. I have fixed both of these things. ## Why It's Good For The Game This is more consistent behaviour. ## Changelog 🆑 fix: Boxcutter is only the knife tool when it is active fix: Switchblade is now a knife tool when it is active /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
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>
|
||
|
tattle
|
ad5debaaa1 |
Add investigate_deaths (#71112)
## About The Pull Request Adds INVESTIGATE_DEATHS, an investigate category intended to better show causes of death.   Also makes suicide_act take a `mob/living` as an argument instead of a `mob`, and some minor style improvements since apparently I hate atomicity. ## Why It's Good For The Game Inspired by a mysterious death and dusting. More logging and leads for admins investigating deaths. Also fixes #59028 ## Changelog 🆑 Tattle admin: added investigate deaths to shed some more light on unusual demises, dustings, and gibbings /🆑 Co-authored-by: tattle <article.disaster@gmail.com> |
||
|
ShizCalev
|
39810b265c |
Fixes baseball bat throwing qdeleted things runtime (#70333)
Attacking stuff can destroy it (ie beepsky) if they have low enough health. The following runtime has occurred 1 time(s). runtime error: Qdeleted thing being thrown around. proc name: throw at (/atom/movable/proc/throw_at) source file: atoms_movable.dm,1132 usr: Harold McKormack (as Adam Karl... (/mob/living/carbon/human) src: Sergeant-At-Armsky (/mob/living/simple_animal/bot/secbot/beepsky/armsky) |
||
|
ShizCalev
|
d6ce53a288 |
fixes boxcutter n a couple other inhads (#70425)
fix: Boxcutters now have inhands again. |
||
|
ShizCalev
|
7048110298 | Inhands var hardsetting (#70364) | ||
|
ShizCalev
|
1a32f60cf4 |
[ready] adds unit test for missing inhand icons. fixes a bunch of missing inhand icons (#70037)
fix: Fixed a bunch of missing inhand icons. fix: Fixed cables in electrical toolboxes not randomizing their colors. fix: Fixed the wrong colored icon showing when trying to make cable cuffs out of cables. fix: The collectable SWAT helmet is now using the proper icon again! refactor: Pipecleaners and power cables now share a unified color system, so they're once again available in ALL the same colors. imageadd: Updated the screwdriver belt overlay to represent the newer sprite. imageadd: Added a bunch of new inhand icons. Special thanks to Twaticus for doing the helmets! <3 fix: Wirecutters now have an icon when inside a belt again! admin: Added a new omnitool subtype that allows you to spawn all items in a typepath! fix: Explorer gaskmasks now properly reflect their adjusted state when held. fix: Fixed balaclavas having the wrong icon when pulled up. fix: Fixed the base energy sword (admin spawn only) being invisible. fix: The rainbow energy sword is now a little bit more rainbowy! fix: Fixed an tk exploit with orange handcuffed shoes. fix: The traitor outfit in the select equipment panel is now actually functional! |
||
|
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 |
||
|
IndieanaJones
|
a2e0ab3ff0 |
Spider Rebalance PR: Burn Baby Burn Edition (#68971)
This is a remake of #66106, with more thought put into the underlying balance. The main goal of this PR is to make fighting spiders more accessible and interesting for the majority of the crew while nerfing the extremely strong and boring option of simply using freezing temps to kill spiders. Also fixes #67765. The changes are as follows: NEW SPIDER COUNTERS Fly swatters now deal 25 damage to spiders on hit, increased from 1 Pesticide now deals massive stamina damage to spiders and a little bit of physical damage as well (the damage portion not added by this PR) Spiders can now be caught on fire through any traditional mean of catching something on fire. Spiders will automatically put themselves out after a time. This was done instead of an active action because AI spiders are also subject to this change as well, and I don't feel like bloating the simple mob AI with putting themselves out SPIDER CHANGES NERFS Toxin injection has been removed from all spiders except for the hunter, flesh spiders and the viper Hunter toxin (used by hunters and flesh spiders) now only brings the afflicted down to 40 health, and will stop taking effect once the afflicted reaches that threshold. Should the afflicted still have the toxin in their system and get healed, the toxin will begin dealing damage again until the afflicted is at 40 health or below again Viper toxin now only brings the afflicted down to 10 health, but also has the hallucination effects of Mindbreaker toxin. This hallucination effect is applied regardless of target health. It also no longer generates other harmful chemicals into the afflicted's system, but is much more potent at base Flesh spiders cannot regenerate while on fire BUFFS Time it takes for spiders to normalize their temperature cut by half. While they will react faster when in cold or hot environments, when they leave said environments it will take less time to return to normal temperature Unsuitable temperature damage reduced to 4 from 8 You can no longer push spiders by running into them Webbing heat damage threshold increased from 300 to 350 (same temp where spiders also take damage) Broodmother egg laying time reduced to 12 seconds from 15 Broodmother web laying time multiplier reduced to 0.5 from 1 Broodmother health increased to 60 from 40 Broodmother damage increased to 10 - 15 from 5 -10 BEHIND THE SCENES CHANGES You can now make any simple mob able to be caught on fire by setting flammable to true How fast a simplemob stops burning is controlled by fire_stack_removal_speed Can now now control how fast simplemobs regulate their temperature using temperature_normalization_speed. Before this PR, this value was hard-coded at 10, I have set the default to 5 as 10 was too long in almost any case. This will notably affect slimes, who could easily die to being cold long after being removed from the cold area. I see this as purely beneficial Toxins now have a health_required value. The afflicted has to be above this health value in order to take damage from the toxin. Only used in the spider toxins currently When I was setting up simplemobs to be flammable, I noticed basic mobs can be glitchily set on fire, so I fixed it to where they can't be set on fire. Why It's Good For The Game Spacing something is very easy, but not very fun or interesting compared to starting and controlling a fire. Swapping spiders' temperature weakness from spacing to fire is beneficial to the fun of fighting them and playing as them, allowing more creativity and resourcefulness on both sides. Ideally, this should allow for atmosians and chemists to use their skills in a fun way. Currently, ignoring spacing them, the only people who can reasonably take on spiders is security, since they have lasers which do burn and stuns to slow the spiders down. However, this small subset of players cannot normally destroy a spider infestation without spacing them, so letting fly swatters and pesticide be used to combat spiders allows other crewmembers to fight back, letting them actually enjoy facing spiders as a threat and allowing the crew to defend themselves. Being killed by spider toxin after fighting off a horde isn't fun. The changes still make it a threat you have to be aware of, but not one which detracts as much from the combat loop. This also forces spiders to secure the kill themselves, which is more fun than having the toxin do it for you. Broodmothers in their current state are incredibly weak by themselves, which is intentional by design. However, the new changes hope to make playing as a broodmother easier and hopefully allow more broodmothers to get the spider infestation started properly. After all, Dynamic is their common source now, and they should be consistently worth the threat cost to spawn them. Previously, spider structures would seemingly vanish for no reason if the room was heated to be greater than 300 but less than 350, as the spiders would not be able to tell that it was too hot. Now, if the structures are taking damage, spiders will also be taking damage, so understanding what's going on should be easier now. Pushing spiders into a corner by running into them was not a fun tactic to deal with as a spider and didn't make much sense seeing how big the spiders are. Changelog cl add: Spiders can now be caught on fire add: Spiders take significant damage from fly swatters and stamina damage from pesticide balance: Spiders have been re-balanced. Their toxins can no longer kill but they are not as susceptible to freezing balance: General stats of spider broodmothers have been buffed with more health, damage, and faster web and egg placement balance: Flesh spiders cannot regenerate whilst on fire balance: Simplemobs change their internal temperature twice as fast fix: Basic mobs no longer glitchily catch on fire. /cl |
||
|
tattle
|
d91390a447 |
[IDB IGNORE] The Great Sweep: Moving dmis into subfolders (part 1) (#69416)
Moves singulo and supermatter dmis into obj/engine, renamed from obj/tesla_engine Moves Halloween, Christmas, and misc holiday items to obj/holiday Moves lollipops to obj/food Moves crates, closets, and storage to obj/storage Moves assemblies to obj/assemblies Renames decals.dmi to signs.dmi ...because they're signs and not decals Moves statues, cutouts, instruments, art supplies, and crayons to obj/art Moves balloons, plushes, toys, cards, dice, the hourglass, and TCG to obj/toys Moves guns, swords, shields to obj/weapons |
||
|
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. |
||
|
Kapu1178
|
2eccf3cea0 |
Cleans up update_icons, makes the update_icon_updates_onmob element bespoke, updates CODEOWNERS (#69179)
* I just realised this is all one commit. * hail marry * fix. * FIXES IT FOR REAL * Update code/datums/elements/update_icon_updates_onmob.dm |
||
|
John Willard
|
952c3ee0d3 |
Removes ComponentInitialize() (#69118)
* Removes ComponentInitialize() Completely removes ComponentInitialize() as a proc, which was called on every single atom in the game, twice in some instances (like new players), over something that can already be done with Initialize(). This is the second attempt at doing this, after the first attempt fell apart for some reason. This time it was way easier though, since storages are no longer a Component. * update icon blocker added before calling parent * Update code/game/machinery/porta_turret/portable_turret.dm Co-authored-by: san7890 <the@san7890.com> * adds a mapload while I'm here * moves human mood * Does some UNRELATED thing to the PR Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |
||
|
Wallem
|
8e3b5e170e |
Changes sprites for the two bat sub-variants (#68882)
Updates the sprite for the metal & homerun bat |
||
|
Salex08
|
8a8fa9c99c |
Replaces GetComponent in Mining items with Signalers (#68575)
* Replaces many instances of GetComponents in mining items with signals and better uses overall of Components, in drills and the GPS handcuffs. * To do this, also added 3 new signals to mechs when you are adding/removing mech equipment onto one. |
||
|
Fikou
|
739812d4e1 |
Adds Baseballs (#68249)
Adds baseballs to the game (There is a baseball field in the holodeck). You can now bat thrown objects with the baseball bat to launch them away at high speed. https://streamable.com/471jvv (baseball is a boomerang here because otherwise this would have been impossible to test singleplayer) Why It's Good For The Game it could be fun to have a game of baseball, and people trying to bat an item thrown at them sounds funny image Changelog cl Fikou, sprite by Mooster add: Baseballs are now available in the Baseball Field on the Holodeck. add: Baseball Bats can now hit thrown objects mid-air to send them back. /cl |
||
|
ArcaneMusic
|
9d826a5e7f | Fixes the white cane sounds, and blind mob's examine. (#67941) | ||
|
ArcaneMusic
|
1eaca674f0 |
Adds the white cane. (Bounty Code) (#67801)
This PR adds the white cane. It can be crafted using 3 iron rods. Additionally, white canes can be purchased from the medical vendor, differentiating them from the costume canes. White canes are transforming items that can be folded down from a small size to their fully extended versions, which are too large to store in a bag. |
||
|
itseasytosee
|
878e3b8d37 |
Implements a Demolition Modifier variable to items, affects damage vs structures and robots. (#66967)
Adds a modifier variable which can be used to increase or decrease a given items damage to structures, machinery, vehicles, and robots (including cyborgs, simple-bots, and anything else with the MOB_ROBOTIC biotype) |
||
|
Ryll Ryll
|
e8f2441630 |
Minor twohanded component refactor (#66791)
The two handed component, while useful, has quite a bit of bloat that gets replicated whenever a new class of 2h items is added. This PR cuts that bloat by replacing the use ofCOMSIG_TWOHANDED_WIELD and COMSIG_TWOHANDED_UNWIELD as ersatz callbacks with actual callbacks, the replacement of various var/wielded defs on items with a check for HAS_TRAIT(src, TRAIT_WIELDED), and the removal of any now-unnecessary on_wield()/on_unwield() procs that simply toggled those wielded vars |
||
|
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.
|
||
|
Fikou
|
cfa5289a31 | high frequency blade now works on vehicles + can customize slash color (#65363) | ||
|
Gandalf
|
684eab3d31 |
Converts SFX keys into DEFINES (#65146)
About The Pull Request Simply converts all instances of soundkeys that use get_sfx from strings into defines. E.g. "sparks" is now SFX_SPARKS Why It's Good For The Game It makes life a lot easier when you're looking for a sound effect. You just type SFX_ and you get suggestions in VSC. Plus, it looks better. image Changelog Not player facing. |
||
|
Wallem
|
3bd5a2d8df |
Makes Ants glow, puts a minimum on ant screaming and shoe permeability, and other ant-related things. (#64786)
I found out how emissives work and my first thought was "damn ants should glow that would look sick" So now they do. Also, having less than 5u ants in your body will make you not scream, so 0.0001u ants will no longer have that tiny chance of making someone scream for their life. If an ant pile has a max damage value less than 1, then they won't be able to bite through your shoes. This is the same threshold as the second tier ant icon. Makes the giant ant a hostile mob with the neutral faction, meaning they will attack anything not in the neutral faction. |
