48 Commits

Author	SHA1	Message	Date
SyncIt21	922645b5b3	Light replacer & item patches (#75960) ... ## About The Pull Request Somehow this code break's every week, hopefully this should be the last 1. Fixes #75951 It wasn't just a problem with Jani Borg light replacer but the normal one's too. Now they all accept glass sheet's & light tubes (including broken one's) when you attack them with a light replacer and not just when you pick them up with hand (which Borg's can't do obviously) and then clicking them on the light replacer. 2. Glass sheet's & shard can be put inside backpack's or other storage item's and now they will all be consumed from the storage and not just light tubes & bulbs 3. Make's feedback message's more informative and display them for all insert event. they weren't displayed when a broken light tube was put in the light replacer 4. Only glass shards are accepted by the light replacer and not plasma, titanium shards etc. we should not use `istype()` for this purpose 5. Removed redundant` Initialize()` proc from `obj/item/light` 6. VV editing var's works properly 7. Blue beam for bluespace light replacer last's just 0.5 seconds so it doesn't look awkward ## Changelog 🆑 fix: light replacer accepts glass sheets & light tubes when you attack them with a light replacer fix: only glass shards can fill the light replacer not other shard types qol: glass sheet's & shards inside storage items like backpacks are also consumed when you attack the light replacer with it qol: feedback messages when inserting lights, glass sheet's, shards into the light replacer are more descriptive and displayed for all insert event's qol: blue beam for bluespace light replacer last's just 0.5 seconds so it doesn't look awkward refactor: renamed `add_shards()` to just `add_shard()` for adding 1 shard at a time refactor: removed redundant` Initialize()` proc from `obj/item/light` refactor: VV editing var's works properly /🆑 --------- Co-authored-by: Time-Green <timkoster1@hotmail.com>	2023-06-11 17:36:50 +00:00
SyncIt21	abbb2d32e4	Light Replacer Patches (#75690) ... ## About The Pull Request Fixes #75686. 1. `/obj/machinery/light/attackby()` checks if it is attacked by a light replacer and `/obj/item/lightreplacer/attackby()` checks if it is attacking a light tube causing the same replace light action to be performed twice and the error message to appear, so i removed the attackby code from the light tube 2. `/obj/structure/floodlight_frame/attackby()` has the same problem as well so i removed it's light replacer attackby code as well. 3. Now only the light replacer checks what target it's attacking in it's `preattack()` & `after_attack()` code. also made sure to return `TRUE` in it's `attackby()` code so it doesn't call `afterattack()`. It also calls it's parent proc 4. did some other code clean such as replacing `can_use()` proc with just `Use()` so it can perform both actions at once ## Changelog 🆑 fix: light replacer displaying error message after it finished replacing the light refactor: merged the `can_use()` proc with the `Use()` proc to perform both actions at once refactor: `/obj/item/lightreplacer/attackby()` returns TRUE to prevent calling it's `after_attack()` code and calls it's parent proc /🆑	2023-06-07 11:06:15 +12:00
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. /🆑	2023-05-10 18:36:01 -06:00
Jacquerel	1a918a2e14	Golem Rework (#74197) ... This PR implements this design document: https://hackmd.io/@Y6uzGFDGSXKRaWDNicSiEg/BkRr176st Put briefly, this will remove every existing golem subtype and consolidate golems into a single species with cool new sprites. NOT implemented from that PR is the ability to eat Telecrystals, I couldn't come up with an appropriate visual that can stack with the existing ones, but that should be a reasonably trivial add for a future artist & developer. New Golems have a food-based mechanic where their hunger decays pretty quickly and can only be replenished by eating minerals. They start moving slower as they get hungrier, until eventually they become completely immobilised and need to be rescued. Eating different kinds of minerals will visually change your sprite and give you a special effect in a similar way to old golems, but temporary. While transformed, you can't eat any other kind of mineral which would transform you (but can still consume glass). To see the full list of effects, look at the hackmd above. In service of these sprites working I have refactored the `species/offset_features` feature by killing it and delegating that responsibility to limbs instead. Rather than applying an offset to items due to your species, it is due to your weird head or arms. This makes overall more sense to me, but it inflates the code changes in this PR somewhat. It doesn't make a lot of sense to atomise unfortunately because that code also seemed to be entirely unused until I tried to use it in this PR, so you wouldn't be able to tell if my changes broke anything. I might make a downstream sad by doing this. All of the actual numbers in this PR are made up and only loosely tested, it will need some testmerges to gather feedback about whether it sucks or not. Other relevant changes: I reworked how bioscrambling works based off bodypart bodytypes, to automatically exclude golem limbs in either direction. There's really no way to have those work on humans or vice versa. Organs still fly though.	2023-05-07 22:45:20 +00:00
ArcaneMusic	f2fd69a49a	Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. (#75052) ... Ladies, Gentlemen, Gamers. You're probably wondering why I've called you all here (through the automatic reviewer request system). So, mineral balance! Mineral balance is less a balance and more of a nervous white dude juggling spinning plates on a high-wire on his first day. The fact it hasn't failed after going on this long is a miracle in and of itself. This PR does not change mineral balance. What this does is moves over every individual cost, both in crafting recipes attached to an object over to a define based system. We have 3 defines: `sheet_material_amount=2000` . Stock standard mineral sheet. This being our central mineral unit, this is used for all costs 2000+. `half_sheet_material_amount=1000` . Same as above, but using iron rods as our inbetween for costs of 1000-1999. `small_material_amount=100` . This hits 1-999. This covers... a startlingly large amount of the codebase. It's feast or famine out here in terms of mineral costs as a result, items are either sheets upon sheets, or some fraction of small mats. Shout out to riot darts for being the worst material cost in the game. I will not elaborate. Regardless, this has no functional change, but it sets the groundwork for making future changes to material costs much, MUCH easier, and moves over to a single, standardized set of units to help enforce coding standards on new items, and will bring up lots of uncomfortable balance questions down the line. For now though, this serves as some rough boundaries on how items costs are related, and will make adjusting these values easier going forward. Except for foam darts. I did round up foam darts. Adjusting mineral balance on the macro scale will be as simple as changing the aforementioned mineral defines, where the alternative is a rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~ Items individual numbers have not been adjusted yet, but we can standardize how the conversation can be held and actually GET SOMEWHERE on material balance as opposed to throwing our hands up or ignoring it for another 10 years.	2023-05-03 14:44:51 +00:00
tattle	77aebb4c29	Audio File Cleanup (#74863) ... ## About The Pull Request Removes a bunch of sound files that we don't use and moves some sound files into better locations. I'm hoping to get an archive repo for sounds going, much like the [map_depot](https://github.com/tgstation/map_depot) and [SS13-sprites](https://github.com/tgstation/SS13-sprites). EDIT: The old sound files are being moved here: https://github.com/tgstation/SS13-sounds Also increased the volume of the clownana rustle sound and clipped off some dead air from shockwave_explosion ## Why It's Good For The Game Removes a total of 1.95MB worth of unused sound files from the codebase. ## Changelog 🆑 Tattle soundadd: increased the volume of the clownana rustle /🆑 --------- Co-authored-by: tattle <article.disaster@gmail.com>	2023-04-20 17:22:08 -06:00
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'	2023-04-11 21:31:07 -07:00
Bloop	bd4392ab74	New inhand icons for light tubes, makes latex balloons craftable, and various other fixes/improvements (#74576) ... ## About The Pull Request This ended up turning into a bit of a junk drawer of a PR I'll admit, but there's really not a whole lot to it. There are three parts: ### Part I - Inhand sprites for light tubes. Adds inhand sprites for light tubes. No more cardboard tube placeholder. This is self explanatory-they have unique sprites for all 3 states (normal, broken, and burnt out). The broken version has sharpness now. Also refactored light_items.dm a bit, it was using a bespoke proc called `update` to do icon updates. Now it has been _updated_ to use `update_appearance` instead.  ### Part II - Latex Balloons Latex balloons, a very old piece of code that was full of typos, has had some life breathed back into it. It is a fun little item, and I saw no reason to let it rot. It can now be crafted using a latex glove and some cable. Also, you can pop them using anything sharp... such as a broken light tube! Aha! We've come full circle.  ### Part III - update_inhand_icon proc A new atom helper function, `/atom/proc/update_inhand_icon(mob/target = loc)` I was struggling to find an existing proc that could update inhand icons of a mob that was holding any given atom, without necessarily having a ref to the mob yet. So I ended up writing one that did that, and finding the spots in the code which were using a similar way of doing it (that is in fact how I stumbled upon the latex balloon item). ...........But then Iearned of the `/datum/element/update_icon_updates_onmob` component and ended up using that instead. There are still some very niche cases where you might not be able to use the component where the proc would come in handy however e.g. in transforming.dm--and if anything, I think it could serve as a good spot to leave a comment informing would be users of `update_icon_updates_on_mob` as an alternative. For that reason especially I thought it worth keeping. ## Why It's Good For The Game New inhand sprites, and a fun little craftable balloon. What's not to like? ## Changelog 🆑 add: latex balloons can now be crafted using a latex glove and some cable. You can fill them with air using a tank. They also have a new sound effect. imageadd: light tubes have a new inhand sprite fix: broken light tubes now actually have sharpness to them as they are basically spikes of glass. refactor: refactored latex balloon code /🆑	2023-04-09 19:51:35 -04:00
Zephyr	ecbcef778d	Refactors Regenerate Organs, and a few organ helpers (#74219) ... ## About The Pull Request Refactors regenerate organs to be slightly more intelligent in handling organ changes and replacements. Noteably: - We don't remove organs that were modified by the owner; such as changing out your heart for a cybernetic - We early break out of the for loop if they aren't supposed to have an organ there and remove it - We check for the organ already being correct, and just healing it and continuing if it is Also changes the names of some of the organ helpers into snake_case ### Mapping March Ckey to receive rewards: N/A ## Why It's Good For The Game ## Changelog --------- Co-authored-by: Jacquerel <hnevard@gmail.com>	2023-03-26 17:54:36 +01:00
Rhials	35f915fdee	Lightbulb removal code adjustments and message change (#74166) ... ## About The Pull Request This makes two changes to the lightbulb removal process code that I found while looking at a different issue: 'user' is passed as a carbon, which is then typecasted to 'electrician' as a carbon (again). electrician/user were used interchangeably, and were functionally identical, meaning the electrician var was unnecessary. Now, 'electrician' has been removed and replaced with user. The 'protection_amount' var is now 'protected' and uses TRUE/FALSE, since it was only ever a value of 0 or 1 anyways. The order in which it is determined has been shifted slightly. This also changes the message you get partway through ripping out a lightbulb with the lightbulb remover skillchip: `to_chat(user, span_notice("You feel like you're burning, but you can push through."))` `to_chat(user, span_notice("You feel your [the limb being burned] burning, and the light beginning to budge."))` ## Why It's Good For The Game Makes the code a bit easier to read. The "you feel like you're burning" message has ever so slightly bothered me for too long. I feel like I'm burning? It's a fucking light tube dude, I'm fine. ## Changelog 🆑 code: Lightbulb removal code is a little bit easier to read spellcheck: The lightbulb remover skillchip implant (which I know you guys LOVE to use) has a slightly different message now. /🆑	2023-03-23 19:28:36 -06:00
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 /🆑	2023-03-14 16:34:52 -06:00
LemonInTheDark	63eaec9a58	Adds a unit test to detect double stacked lights (#73650) ... ## About The Pull Request They make me sad and we should test for them I use dir here to prevent like, bulb + bar stuff, idk if that's wanted or not tho	2023-02-26 19:37:51 -05:00
Rhials	abb2f04080	Light Replacer cleanup and afterattack improvement (#72566) ... ## About The Pull Request Makes a few code improvements to the light replacer. * increment, decrement, and bulb shards were three values unnecessarily stored as vars on the light replacer. They are now defines, as they were static values either way. * Autodocs variables on the light replacer. * Everything uses snake case, and the single-character vars have all been smote from existence. * Changes some 0/1 use to FALSE/TRUE In addition to this cleanup, the afterattack chain has been cleaned up a lot. It now allows you to click on either the light, OR the turf under it to replace a light. As a bonus, you now get some balloon alerts when trying to replace lights while empty. ## Why It's Good For The Game Closes #72557. Cleans up the code I had to shuffle through to do so. ## Changelog 🆑 Rhials qol: the light replacer now allows you to click on either the light, or the floor beneath it, to refill lights. code: light replacer code is now a bit prettier. /🆑	2023-01-13 13:54:02 -08:00
LemonInTheDark	6e4c4c51e3	Adds depth to firealarm lighting, makes starlight more pretty (#72327) ... ## About The Pull Request [Messes with fire alarm/fire light lighting](https://github.com/tgstation/tgstation/commit/f3b2e574f1e98606c206a34aa40614268fec9b63) Makes fire alarms brighter, but shorter range. Fire lights get a darker color, less power and less range This leads to some nice lighting differences, and a pleasant depth of brightness that suits the situation. Darkness for emergencies vibes. Hopefully this reduces the eye poison that is fire alarms Before  After  [Modifies starlight to make it IMO prettier](https://github.com/tgstation/tgstation/commit/b9bdc80bed7e2502731cd3a0219545d60a057990) Gives it a slight blue tinge so it doesn't just look like fullbright, and makes it more powerful so it's visible more of time, and not a lot of cpu just for solars. This bit may require more tuning, not fully sure of it Before  After  Starlight changes require #72326 to look properly nice, images taken with that merged ## Why It's Good For The Game Better vibes, pretter lights, all good ## Changelog 🆑 add: Starlight is more potent now, and slightly blue add: The lights from fire alarms will be dimmer and lower range, with alarms themselves being brighter. Hopefully it vibes /🆑	2022-12-29 02:14:43 -08:00
texan-down-under	2e39b33eca	Adds missing descriptions again (#72013) ... Adds descriptions to some base types (such as walls, floors, machines frames and computer frames) to make the world feel more alive. Authored-by: etherware-novice <candy@notarealaddr.com> Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>	2022-12-24 16:53:26 +00:00
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>	2022-12-23 16:21:22 -08:00
Rhials	35776e7144	Grey Tide event light behavior changes and code tidiness (#71230) ... ## About The Pull Request Makes a number of changes to the Grey Tide event, some of which are and some of which aren't player facing. Player facing bits: - The lights will once again turn off when the event ends and the doors begin opening. Originally, the lights would all shatter when the event hit, providing a cover of darkness for opportunists to sneak around under. Unfortunately this would prevent the AI from fixing the doors until the lights were replaced, leading to headaches and the removal of this functionality in #43159. Now, the lights are simply turned off at the APC instead of shattered. - The lights now flicker at certain intervals as the event is running, rather than just right at the start. - Announcement has been slightly modified to indicate that the event hits more than just airlocks. - Event runs way faster. Doors open all at once, rather than one-at-a-time. And now for the non player-facing bits: - The filename is now grey_tide.dm instead of prison_break.dm. The event was effectively re-branded to the Grey Tide event six years ago, but the filename was unchaged. - potential_areas is now a part of setup instead of a var on the round_event. - Cleans up instances of single-character varnames and stuff not in snake case. - The event now checks if it has any valid areas (will it work or not) at the start, rather than at the end. - The event now sends a global signal when run, rather than checking everything in the entire world. It should run faster now. - Everything that can be affected by the grey tide event now stores its functionality on a signal handler, including the light flickers ## Why It's Good For The Game Makes the grey tide event a bit more interesting and easier to take advantage of. Cleans up the backend code a bit. ## Changelog 🆑 Rhials balance: The lights will now flicker more frequently before a Grey Tide event balance: The lights will now be shut off via the APC when the Grey Tide event opens up a department. code: Makes some miscellaneous code improvements to the Grey Tide event code: Grey tide event runs much faster code: Renames prison_break.dm to grey_tide.dm /🆑 Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>	2022-12-09 01:13:58 +00:00
Mothblocks	aac6d5a8d6	Defer creation of emergency power lights until needed -- Saves ~0.2s of init time (#71729) ... Every light was creating a power cell. Creating a power cell creates reagents, creates appearances, updates the appearances to reflect its charge, etc etc. It's very expensive. Of the 293ms, 1,652 calls of cell/Initialize, 196ms of it was emergency_light/Initialize. Defers it until necessary, `get_cell()` will produce the cell if it doesn't exist. Closes https://github.com/tgstation/dev-cycles-initiative/issues/21	2022-12-06 00:16:54 -08:00
AnturK	4d6a8bc537	515 Compatibility (#71161) ... Makes the code compatible with 515.1594+ Few simple changes and one very painful one. Let's start with the easy: * puts call behind `LIBCALL` define, so call_ext is properly used in 515 * Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since src is now invalid there. * Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache directory is not appened to base path in browser controls so we don't check for it in base js and put the dev server dummy window file in actual directory not the byond root. * Renames the few things that had /final/ in typepath to ultimate since final is a new keyword And the very painful change: `.proc/whatever` format is no longer valid, so we're replacing it with new nameof() function. All this wrapped in three new macros. `PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is not actually necessary but if we get nameof that does not allow globals it would be nice validation. This is pretty unwieldy but there's no real alternative. If you notice anything weird in the commits let me know because majority was done with regex replace. @tgstation/commit-access Since the .proc/stuff is pretty big change. Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>	2022-11-15 03:50:11 +00:00
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>	2022-11-07 16:22:37 -08:00
Mothblocks	d9aab85f3c	Save 0.28s of init time by removing an unnecessary timer in light/LateInitialize (#71059) ... Replaces a timer with just calling the proc directly. This saves 0.28s of making timer events. This timer exists as an artifact of being a `spawn (1)` since r4407. Local testing suggests it is completely unnecessary (lights work, lights break, new lights show)	2022-11-06 05:53:36 -05:00
Rhials	7561331499	flicker() no longer overrides lights being turned off (#70736) ... If a light has flicker() running and the light is turned off/disabled, it would ignore the light being turned off and continue flickering. This could lead to lights remaining on despite the area not having power, or having the lighting disabled in the APC.	2022-10-31 11:33:26 +01:00
MMMiracles	3388d5bae0	Cameras and lights now take power from adjacent walls if placed in external areas without power (#69975) ... * cameras and lights can now be powered by adjacent walls if placed in areas where power normally isn't available.	2022-10-08 16:56:38 -04:00
Rhials	13ca10b0bf	Rigged to Blow: Lightbulb Rigging/Reagent Handling Overhaul (#69833) ... About The Pull Request First and foremost, guts out the previous, arguably cursed "rigged" functionality from light tubes. Light tubes now have a capacity of 20 reagents. Light tubes will now splash their contents upon shattering, instead of just releasing plasma gas into the air (if rigged). Lightbulbs with reagents inside of them will now transfer with them to the light fixture they're inserted into, which will slowly heat the contents to a maximum of 1000 degrees. Heating the plasma reagent manually leads to it harmlessly boiling out of the container and dissipating, effectively ruining the original functionality. To account for plasma boiling over (when it should be bursting into flames) a SEALED_CONTAINER reagent container flag has been added. This is mostly just to prevent the plasma from leaving the container until it is ignition-ready. As a result, light tubes rigged the old way no longer harmlessly explode, and instead produce a small, (mostly) self-contained fire in the area surrounding the light. Light tubes (and light fixtures with reagents in their lightbulb) now show their reagent contents upon examine. It's only fair to reward attentive people with a chance to avoid impending disaster, but on the other hand lightbulbs are transparent and you should just be able to look through them anyways. As a bonus, all of this SHOULD be handled in a way that doesn't put any unnecessary strain on machine processing or anything. Rejoice. Why It's Good For The Game Lightbulbs being reagent holders was a huge missed opportunity, with their only use being for the disappointingly ineffective plasma-rigging functionality. This expands on the idea, and reworks the original functionality to be much more interactive. Bigger sandbox! Deeper sandbox! Changelog cl add: Rigging light fixtures now works with more reagents than just plasma. Light fixtures will heat the reagents of their inserted lightbulb, up to a maximum of 1000 degrees. Lightbulb tubes now hold 20 reagents to make this more usable. add: Lightbulbs will now splash their contents on whatever they're shattered by. Their contents are also now visible upon examination.	2022-09-20 13:02:47 +12:00
Mickyan	df855c9238	Tweaks brightness for red, blacklight presets. Adds dim red light preset (#68576) ... Tweaked blacklight,red - Added dim red	2022-07-22 13:24:28 -04:00
distributivgesetz	763a10d1cc	Resonance cascade polishening, bugfixes and better logging (#67488) ... This PR rewrites almost all messages related to cascade events. Some messages felt kinda clunky to read or could have been written better. Overall, the new messages add to the experience as a cascade being a terrifying event in a way that I felt the old ones missed, and they make the event feel overall a lot sharper. While looking at the resonance cascade code, I noticed that there a lot of stuff about cascades in the air which was not touched on. So, as I do, this PR evolved into a polish and roundup PR for cascades. There was a lot of stuff still hanging out relating to the event, and although the big backend of it sits, there was still a bit left to be completed. Therefore this PR deserves more the title of the "Resonance cascade POLISHENING" instead of the "REFLAVAHRING". But yeah, you ever go on a massive tangent before?	2022-06-16 16:22:22 +01:00
Andrew	fc540a26cc	Night shift lights use power according to the brightness (#67667) ... * Night shift lights use less power, The last three APC buttons have tooltips * suggested grammar fix	2022-06-11 21:35:57 -04:00
Kapu1178	6d470992cb	This tail refactor turned into an organ refactor. Funny how that works. (#67017) ... * Fuck you (refactors ur tails) * Errors * Wow. Pain. * Fixes up probably everything * finish up here * Fixes hard del maybe * original owner hard del * garbage collection runtime * suck my peen byond * Mapped tails * motherfucker. * motherrfucker. again. * Whooopppppsie * yeah bad idea * Turns out external organs literally just sat in nullspace forever if their parent was deleted, and didnt Remove() themselves, causing harddels. * So anyways I repathed all organs * Fixes * really. * unit test... test * unit test-test but it passes linters this time because im a moh-ron * I've lost track of what im doing at this point * Hopefully fixes hard del? * meh * Update code/datums/dna.dm * things n stuff * repath from master pull	2022-05-30 21:18:34 -07:00
LemonInTheDark	1f51bd797e	Firelock optimization and behavior changes (#66250) ... * Firedoor optimizations Ok so firedoors were eating up a lot of cpu. They were doing this for one main reason. Clearing a fire alarm in an area involved doing a for(var/obj/machinery/light/light in src) loop. For those not in the know, in src in the context of areas involves filtering ALL the objects in an area. This is REALLY nasty. This fix reduced the total cpu of firedoor closing by a factor of 100. I am not kidding Edit: I was kidding, ghil fixed the oversight that caused this in the first place already My change is still good tho, it wasn't good even if only called occasionally I replaced it with a signal that lights register for on area change. I had to do some finicking to make the existing area sensitivity that machines have behave with this, but it's not too messy. I did the same signal treamtment to firealarms to clean them up a bit. I also did some futzing around in firedoor code to make changing behavior inside it easier. * Changes how fire alarms work slightly Rather then fully resetting alarms, and relying on the door itself to close back up, they will force all doors open for 3 seconds (down from a cooldown of 5 because 5 felt way too long) and then drop again if the firedoor has any well, actual problems. This meant adding two new vars, active and ignore_alarms. It also meant sightly changing the meaning of alarm_type, from the alarm that's activating us right now, to our current alarm. I think this is generally positive, since it makes the variable a bit easier to reason about. Oh and I reworked an existing cooldown to make it fit better into this mold. Ah and we can no longer drop atmos problems. This was an issue before, it was possible for a firelock to be in a problem state, but be unable to reflect that because of something that blocked the event reception, but no longer * Pain * Ensures area sensitivity will only be added if we do not already have the trait from innate state	2022-05-06 17:51:27 -07:00
ArcaneMusic	5f4d5a42d4	Arconomy: The bigger balance PR (REVISED EDITION) (#65795) ... This PR covers 4 Key features: Price Rebalancing Passive Income Gas Exports Lathe Tax Relevant Design Doc (Slightly out of date as a result of the discourse on the subject). https://hackmd.io/WlWgyRafTaiAqz6ouOqC-Q -- START DOCUMENT -- # Arconomy Version Two This is mostly me organizing a long list of thoughts that I'm not sure if I can properly describe and get across, but lets just work with what we got and go from there. ## There should probably be a relationship to time and profit So, part one of a series called "Arcane was completely wrong about game design", I made a rather large misstep in regards to designing arconomy, and nobody told me this until far, FAR after I had gone way too in on my own ideas: "There needs to be a relationship between time and money". Because Space Station 13 is a game that is built around rounds, either long, LONG rounds on MRP or 30 min - 1 hour long rounds in LRP, your whole orientation of the game is built around time. The longer you spend in a single round, the more you can do and mold the station and the game in a specific direction, whether it's from an admin event, doing your job, or going off on a wierd character based tangent. The issue here lies in a question I tried to answer in my previous design doc: > "Command players start with lots of money, and make mountains of money, and as a result, have so much money by the end of the shift that they're practically immune to the effects of the economy. > Assistant players start out with practically no money, find that the station is covered in costs that they'll never be able to practically afford, and decide that the economy is stupid and not worth utilizing altogether." Two fundimentally different outlooks on the same problem, caused by the pay discrepency as it existed originally. Since we have so many different jobs all at different paygrades, the option that made the most sense at the time was to completely remove paychecks alltogether because they would multiplicitively exacerbate the previous issue. While it would flood the in-game economy over time at high levels, it did add a sense of timescale to the existing in-game relationships. You **KNEW** that after x many minutes you would get that fancy hat, or that you would need to find cash in other ways to get it. Having that time-scale is helpful as we've moved to our 90 minute round average/goal. It also, similarly, means that we know exactly how many credits each job SHOULD have had access to before a major disaster calls for a shuttle call. But, in hindsight, that is a value that should be consistant for all players. If a single, unaided player looks at a 200 credit bill, that should have the same impact player to player, and not limit their access to jobs. ## Bounties just ain't that fun, but they stand to see improvement from where they are now So, guilty as charged, bounty running doesn't quite have the same charm as it used to have. For our friends just joining us, cargo used to have a single, per round laundry list of items that would payout to the cargo budget each shift. Each list would start with 10 items, one of which would randomly be assigned higher priority with a higher payout, and it would be cargo's job to ~~Break into each department and steal that thing~~ cooperate with jobs around the station to aquire funds for station crisis or when you just want to dick around and make stacks of cash. This had a distinct charm to it, but one element of it that majorly reduced the replayability of bounties was that they were severely limited in scope. Once you did your ONE drink bounty or your ONE chemical bounty, you no longer needed to interact with that department. My original goal was this: Make an unlimited bounty system, where crewmates were able to get a cut of their work as profit. To a degree, it's fairly successful! Crew do have a way to actively work with cargo to get paid for their labor, and they help cargo as a result by giving them free valuables. The issue lies in the fact that this has kinda flipped the relationship on it's head: Bounties stopped being cargo's job to outsource to the crew, and instead the crew's job that becomes dependent on cargo. In general, many bounties simply weren't meant to be repeatable content in the first place. And certainly not meant to be used for every job. Offloading it as a kind of fetchquest minigame so that all jobs can offset the loss of passive income? It's not the best choice. For jobs like botanists or scientists it's tolerable at best, frustrating at worst. Just look at the state of things like experisci-slime experiments or scanning furniture. It gets far worse when it's from the perspective of jobs that have *explicitly* limited supplies like security. No, a security player is not going to be allowed to haul away all the good metal handcuffs from the brig for a bounty, and no, you cannot take all the riot shotguns from the brig. Now, a few of these things were fixed over time, with mixed successes. Bounties started to be cleaned up in order to prevent limited quantity items from being an option for repeat bounties. Jobs that lack exports started to get some content for still allowing them to have repeatable exports (Like the Scanners for Security Officers to go on patrols). The BIG EXCEPTION to this is Restaurant Bots, but we'll hit that in a second. ## Getting everything on the same price scale has been a major improvement. Unironically one of the best changes made has been the idea that even if we lack that good time-credit scale from before, we didn't really have a "standard" to work off of when something new is added to the game and the dev needs to determine how much to make that thing cost. That's why the current costs of objects and values on-station are scaled off of a single define, the value of a crate sold on the cargo shuttle. > Yes, I'd like an APPLE. It's worth 3124151 CREDITS. NO, I don't know why the apple juice in the vendor is worth 415 CREDITS, nor do I CARE, GOOD MAN. From the back end, everything is scaled off the same define now. Paygrades are defined off of a different scale still, but that's fine. You know, from the cargo end of things, that a cargo player needs to ship off X number of empty metal crates to purchase a laser crate, or a pizza crate. Definate relationships help in solidifying the singular value of a product. If we decide that we want to rescale the in-game economy and provide space credits with more granularity, at least we know we can do it with a single line of code, and not looking at every single instance of something that charges the player money. ### Arconomy Tangent: We gotta nuke gas selling. This has been a long time coming and I know people are going to be upset at me, but look man. I have no idea how selling moles of gas works these days. It seems like with minimal resources, true atmos wizards are able to make singular cans of gasses with infinite moles of some kind of gas, and if it's exotic enough, they can make upwards of a million credits a can. I've seen multiple occasions where selling gas cans to cargo has allowed for players to buy a bike. For our Gen-Z zoomers reading this, players were never meant to BUY the bike. The bike is just a reskinned scooter meant as a cute little pokemon joke. If a player can actually buy a bike in a round, that's a sign that someone, somewhere, fucked up. We fucked up the whole system with atmos gas selling. We've now gone through metas of extracting miasma from lavaland for credits, we've gone through a meta where cargo starts building their own hydrogen burn chambers for simply produced gasses, we've seen time and time again that processed gasses in the funny space simulator just tends to be abused to death and back. I've had talks with TheFinalPotato on this in the past, and it just feels like a system that would need to be rewritten from the ground up, or looked at in terms of the whole cargo department. If I don't get to it first, the next cargo design doc someone writes **SHOULD**. ## Giving jobs content that integrates into the economy can be really fun. Tourism bots and the baked in ingredient shopping is fun! It's enabled for a fluff job that doesn't have too terribly much by way of serious responsibilites to integrate active income minigames into the gameplay of chefs and bartenders. It's fully optional, it's quick, and it's not even a full shift investment. These secondary tasks, which utilize jobs core gameplay loops in a new way, while rewarding them within the in-game economy are a decent way to keep players engaged with their jobs, and allow for them to use credits as a player resource as well as a primary job resource. **I AM NOT SAYING** that all jobs need to find tasks to arbitrarily reward players with credits for. The reason it works so well for jobs like the chef or bartender is because their job is already to make food and drinks, but they have so many options that they're not encouraged to make too wide of a variety of food, especially when botanists won't always make everything you need. The food market gives them an outlet to buy outlier ingredients and the tourists pay handsomely enough that you can offset your costs most or the time. I'll break this down as well into the three different methods of money-making in game as well, to guide someone on how to make good, secondary income content. | Primary | Secondary | Tertiary | | -------- | -------- | -------- | | This is something like passive paycheck income. You get this just purely for playing the game, and staying alive. | This is an active trade off between your job's specific content, where you are trading your time for something it is directly your responsibility to do. Eg. Tourist Bots. | An active task you are performing for income, but lacks the specialization of a job. EG. Bounties. | Jobs that excell at more service based tasks and less production based tasks should aim to aquire more seconary style economy integration, like medical, science, or security. ## The options for moving money around the station are actually pretty decent, but could be streamlined Bounty boards are pretty decent at being a way to pay crew members for single service jobs. However, bounty boards are pretty much dead content, in a sense. There's not much incentive to hunt down your department's bounty board. Similarly, most crew would just prefer to hand credits out by hand to prevent most kinds of abuse of their own credit supply. Long term and certainly a major personal outcome I'd like to see: Bounty boards and Newscasters should be merged together. Newscasters have some truely awful spaghetti and their being held together by shoe-strings and duct tape (This is slang for HTML). Bounty boards are... well they're functional, but they have the benefit of being built in TGUI. Merging the two's functions should cut down on wall-space, as well as improve the quality of a vast deal of code, and make money transfer on station slightly easier. Honestly, pretty happy with vend-a-trays. They're pretty decent store-machines on station and do their job pretty well when they get used. All in all I'm happy with how they work. Custom Vendors are clunky to a fairly major degree and I don't think most players get how to make them work on account of need a price tagger (not a sales tagger, that's the cargo item) to mark an object for it's sale value, then load it into a custom vendor sales unit, then load it into a custom vending machine, and that's only IF custom vending machines decide to work this year. Streamlining the tools, or perhaps just vending machines would certainly improve this as a service. ## Just ain't enough cool stuff to buy with credits. An ever-present problem, that we're just kinda stuck with. There's a decent number of issues involved with making content that can safely be gated with just credits. * If it's usable as a weapon, is it too dangerous to hand out to the crew at large? * Does security get potential oversight? * If it's illegal, does it go through cargo? * Does it HAVE to go through cargo? * If it's beneficial, is it going to invalidate the existance of a job? (Think old medkits!) * Is there anything that players WANT that's not a weapon, benefical to the station but not too strong, or quite literally traitor equipment? It's a tough question. Some items make complete sense to implement on a per job basis as either uncommon or premium equipment, while other items could potentially be moved to station-wide unique purchasables. # Takeaways: Look, these are just some possible solutions that I'm considering. I think that working alongside a maintainer who could actually give a damn on getting this system orderly and possibly alligned with our current design philosophy (Who also understands that a not-insignificant amount of current economy was abitrarly written by goofball an actual decade ago) could help iron this out into a clear and consise set of goals and milestones to make the in-game economy workable. Not balanced, but workable. * **Design a simple simulation for per round intake and outtake, to determine benchmark values for a 90 minute round.**  It would need to look something like this, as a kind of fucked up, Multi-Input Multi-Output Control Problem. Possibly could be done in simulink, but I'm not quite sure how to do that at this moment, so a less complex version might be fine. * **Look back at implementing crewmember incomes, but at a flat, more consistant rate over all jobs** My leading idea: 50 credit, uniform paygrade. No wild, unscaled pay rates based on what job is "important" or not. That line of thinking means that certain jobs should have more expensive equipment over other jobs, but then we're right back to the captain thinking that a cup of coffee is practically free where an assistant thinks that a screwdriver from the vendor is going to put them out of house and home. Improves time-relationship values with credits. This could lead way to heads of staff having some degree of control to giving raises or paycuts to crew-members, but perhaps at a very, VERY gradual rate. * **Perform another big-picture look at bounty cubes.** Potentially try to put bounties back in the hands of cargo, while still providing payouts to crewmates who assist in completing jobs. This may require some minor refactoring of the pricetag component, perhaps to even allow for multiple crewmembers to recieve profit from a payout. This means once again, look at making bounties workable for all jobs on the station, not making the objects requested literal lathe-fodder, and finding ways to benefit the station in some way with the task of bounty cubes, even if it's just for credits. Deceptively hard task. * **Add secondary tasks that integrate the economy into non-bounty-able jobs/departments** Like it says on the tin, look into ways to add content that improves economy integration into existing jobs, without necessarily changing what those jobs DO. The bounties for those jobs can still exist as a tertiary thing, but should be made clear that they're... tertiary. Chefs still make food and bartenders still serve drinks, but they have a way to hand them out for fun and profit. Some thoughts and ways to handle this potentially: *Science:* Perform intricate testing on anomalous materials using science equipment. Should NOT REWARD RESEARCH POINTS. Mr. OJ Headcoder will CHEMICALLY CASTRATE me, or you, if you do. *Medical:* Complete tricky or non-standard surgeries on dummies for medical data. Think like that meme from the TV show, House. "He needs Mouse bites to live. MORE MOUSE BITES." *Engineering:* Repair wacky machines that use both station-standard parts as well as solving quick puzzles. * **Look into more effective money sinks that are dynamic sensitive** Think, for example, about the station ransom event that spawns space pirates. What if instead of the captain just dumping credits from the cargo budget into the aether to prevent pirate spawns (They're bugged anyway to my knowledge to spawn anyway), crewmates had to cough up that dough before a time-limit, or risk a pirate spawn. For those of you who were scratching their heads at (Operational Costs!?) in the above controls diagram, this is the sort of thing I mean. Little, smaller things that might need to be purchased, invested in, or otherwise drain credits from the station over the course of the round. # Arconomy 2.0: Smarter, Better, Flashier. ## Roundstart Players begin each shift with a set amount of money, with the value being mostly uniform over the course of a shift assuming no interaction with economy. Jobs are split up into only 3 paygrades, Minimal, Crew, and Command. Minimal is reserved for jobs that are meant to fill population counts but lack a specialization, like prisoner and assistant. When starting the shift, a player will start with 5 paychecks worth of savings. This system is not designed for persistance, so you will always be able to tell how much money a player starts out with. Every 5 minutes, aka every economy tick, the player will recieve one paycheck, which is capped out at the standard crew member paycheck. This means that even if you start the shift as the captain, and begin the shift with 500 credits, you will recieve the same 50 credits as regular crew members. | Minimal Paycheck | Crew Paycheck | Command Paycheck | Frequency | | -------- | -------- | -------- |--------| | 125 Cr | 250 Cr | 500 Cr | Roundstart | | 25 Cr | 50 Cr | 50 Cr | Passive Income | ## Product Prices Products found in vending machines are defined by the amount of a player's paycheck they're meant to cost. Regular items use the PAYCHECK_CREW value, while more expensive or otherwise prohibitive items are defined by PAYCHECK_COMMAND. Items are defined in this uniform, horizontal fashion in order to maintain the equal value of credits over all jobs. A 100 credit medkit in medical should have the same value to a doctor as it does to a botanist. Jobs apply a discount to vending within their own department, so an engineering would have a discount on tools, and a doctor would have a discount on sutures. Items that are important to gameplay progression in a role are less expensive to their intended users. > **AUTHORS NOTE:** I am considering removing in-department discounts. In the benefit of making the value of purchasables more universal, deciding that credits shouldn't be spent within their own department just seems... rather fucking stupid. > Possibly move the discount to only the first few minutes of the shift, or perhaps as some kind of gameplay benefit to slowly increase in-department discount through gameplay milestones? Who knows 👻 > Some jobs have premium, high value items stocked in their vending machines that are not meant to be purchased at roundstart. These are meant to encourage players to save or combine resources to gain access. An example of this is insulated gloves. Other high value items can also be found in contraband through hacking vending machines. This remains unchanged. ## Markets The cargo department has been changed in order to improve player involvement with the economy, as well as to give cargo more variety in their merchandise while preventing a singular stale meta of products to purchase from. Yes, I'm looking at you, russian surplus crate. Lets start with what's remaining the same: * Cargo is a department that manages imports and exports of products, fulfilling departmental orders, and aquiring supplies dependent on the station's state. * Cargo encompasses the station's mail, mining, and flow of orders, as well as drone exploration. * A skilled cargo member is able to find high value items to sell back to centcom in exchange for more funds, to purchase those supplies. * Centcom may request bounties which crew can fulfill in exchange for credits, if they wish for additional work. **Now for the new design flow:** Cargo starts out with a new mechanic called a market. Markets hold existing export datums as well as purchasable products. The values of items will fluxuate up and down based on the market status, with in-game events or player actions raising or lowering the values of specific markets. At roundstart, cargo has a single market to sell to, which is Nanotransen. This will not incapsulate all the existing export datums in the game, just the *primary* exports that are used by players. Items that are exclusive to nanotrasen and required to play certain game modes, like mindshield implants or being able to sell crates, are included and will always be available to purchase. Additional markets can be unlocked through gameplay sources, such as: | Market Name | Source | Imports/Exports | | -------- | -------- |- | | The Syndicate | Emagging/Hacking the Console | Illegal Goods/Contraband | | The Clown Planet Commerse | Discovering the clown planet ruin | Pies, Horns, Pranking Equipment | |Terragov Sector Security Surplus | Killing any megafauna. | Weapons, Ammunition, Advanced Riot Gear. | | Mekki Materials Co. | Recovered loot from Exodrones | Materials and industrial equipment. | |Donk Co.| As a tip from tourist robots. | Foods and Drinks, Toys and Games.| |Waffle Co.| As above. | Bootleg products and wacky merchandise. | |The Research Consortium| Reward for completing any experiment tree. | Slime Cores, RnD Artifacts, Robotics Equipment | ...And more, if I can think of more. The purpose being, of course, to split up cargo's purchasable goods to be more instanced and unique, while also create unique situations where due to profitable markets, very specific exports are needed to help the department make money. End of document for now :@ArcaneMusic -- END DOCUMENT Price Shifting So, in-game items that have prices have a major issue on their hands, being that they were decided by how much money that job should make. This means that many of the jobs in-game have been given prices scaled to their job's income. That income I adjusted by removing passive income in #54161. While this was helpful to moving towards an active in-game economy, it resulted in items falling into distinct price brackets. A high paying job like security's items could never be purchased by someone like a botanist, but a job like a security officer had more capital and buying power than most other jobs in-game combined when moving down those brackets. We've done a simple normalization of scale to help in bring things closer to a semblance of equality. There are now 3 price brackets, PAYCHECK_LOW, PAYCHECK_CREW, and PAYCHECK_COMMAND. Command staff will still have a higher base level of money on-hand than other crew, and low paying wages that we on-station don't respect as being real jobs (assistant, prisoner) will have their items be intentionally cheaper to encourage active participation in the economy, but the difference in scale is now noticeably far closer to each other. This means that assistants can still interact with the economy as spenders, but if they want to be doing a lot of work with money, they'll need to put in work. Additionally, this means we arbitrarily enforce a system that allows for items to have uniformity in what they cost to other players. 50 credits for a wrench feels better when you know that other job critical items in-game are also around the same price, and it's equivalent to one paycheck. Paychecks are reintroduced Economy lost it's relationship to time. In a game where a single round takes 90+ minutes (Backed up not only by the head-coder's design direction as well as plenty of aggregate round data), having a relationship to time and how long it takes to afford something is a major consideration when you look at buying something. Also, we get to say that I was certifiably wrong in regards to the active economy thing, since we have very, VERY few active sources of content in-game that are very... fun? Bounties are literal fetch quests but something like tourists is at least more engaging and interactive with the round, and should be the direction we want economy-job integration to head in. Between having inflation as a price manipulation mechanic already in the code, as well as prices being roughly equalized in terms of their costs between jobs and their impact on the round, this allows for the reintroduction of paychecks to an extent. As an additional note, doing this meant tweaking down the syndicate briefcase of cash, so that instead of giving you 5000 credits for 1 TC, it now costs 5 TC to accompany the fact that this is now a rather significant amount of money, even on decently high population. Fun fact: the Syndicate Briefcase of Cash actually PREDATES the economy, and was NEVER ADJUSTED beyond the original implementation of the economy as a result! Gas Exports. ALRIGHT ARE YOU READY FOR SOME GRAPHS? I THOUGHT SO, YOU LOVE GRAPHS. So, gas exports are fucked, have always been fucked, and consistently have proven to be capable of breaking the in-game economy for a long time. This is no secret, I've been pinged with players getting billions, actual billions of credits using it multiple times in as many years. See, any round where a player manages to buy the bicycle is a round where I've fucked up, or someone fucked and I let it get past me. So here's how gas exports work right now. So, all of this hinges on the value of a single mole of gas, and some gasses enable you to make extremely, EXTREMELY profitable gasses through atmospheric gas wizardry However, even those less profitable gasses are still in an extremely high magnitude of value. Most gasses if you have a full can of it will net you OVER 10k credits. For scale, one crate being sold in cargo is 200 credits. That's a minimum of crates for pumping gas into a hollow metal box and praying it doesn't explode. So we adjusted the values accordingly. The baseline value of a single gas has been tweaked downward significantly. Even these values are still arguably very high, but I can play with it at the discretion of LemonintheDark. The green line at the top represents gasses that previously sold for 100 credits per mole, antinobilium I believe, and working downwards. I am going to try and enforce 10 credits per mole as the absolute maximum hard cap on gas exports, regardless of how many gasses we try to add in the future. Because the alternative is getting a gunjillion credits by huffing miasma into a tank of steel. And we ain't having that shit. Lathe Tax Part of the testing for this PR involved me modeling the SS13 economy in a given round as a kind of controls problem, with each source of income introduced in the round as a kind of input (Passive Income, Bounties, Tourists) in order to get a handle on roughly how much income a single round of SS13 will see per player on the given designed round-length, in order to estimate how much things are going to cost. Modeling how much players spend on a given round is variable enough that it'd be too difficult to accurately test without just throwing this up on a server and getting live data. However, from the appearance of my dataset, players would be making a LOT more money nowadays with all of the above changes implemented. In an attempt to curve that intake, I attempted to implement a small, low scale tax of printing items that would take a small amount of players income every time they print, as a way to add a basic economic side-effect to this mechanic. This has made a lot of people very angry and been widely regarded as a mixed decision. So, maintainers came up with an intended direction they want to see it, as they wanted to make sure that economy would remain a secondary system, that could still have an impact on round direction and the changes they want to see in the game. So, here's the intent: Lathe tax should exist in the form of printing things from protolathes outside of your department, not on autolathes or your own protolathe. We want to promote people talking and collaborating to access things if it's outside the scope of their department and they still want it, with theft still being a viable avenue of gameplay. Players will be charged 10 credits for printing a set of items not from their own protolathe, each. Printing an item can be paid for from your own ID card's bank account automatically, but the payment component has been buffed to handle physical money alternatives, as well as pulled money, similar to the luxury shuttle scanner gate's behavior. Borgs are still enabled to print from lathes, however instead of it costing them credits, they now take a self-significant power cost in order to do so, preventing them from being used as a roving bank account for printing. I'll look into this further as we don't want to invalidate mechanics like borgs being able to do organ based surgery or building machinery, but we don't want them to become credit cards, so place that under advisement. Tweaks and Updates: (Suggested by Ziiro) If the revolutionaries win, centcom will no longer enforce the Lathe Tax. (Suggested by about ~1000 people independently between my DMs, Reddit threads, the Feedback Thread, and elsewhere) Printing items only taxes you once per print. EG: If you print 10 Kitchen Knifes as an assistant from the service lathe, you will only be charged once instead of 10 times. For many of the reasons that I outlined above, this is a good change in a positive direction. Players get more ability to interact with the economy without having to do content that's becoming increasingly depreciated in my absence. Players also have a baseline consensus on what values of credits are high and low because jobs have been given an equalized standard in regards to the cost of certain items. Price fluctuations through inflation will now be more meaningful in situations where the economy becomes more relevant. The system will still encourage you to play a job that's productive to the status of the station through lower paycheck jobs existing as well. Gas exports are now reduced to the point that their value is appropriate for the first time... actually ever. Nice. The values of nearly every item purchasable by players has been rebalanced. Players will now start with less starting money, but will receive a paycheck once every 5 minutes. The value of gasses exported through the cargo department have been skewed way, WAY down in terms of price. The Syndicate briefcase of cash now contains now costs 5 TC, up from 1 TC, for 5000 credits. Printing items from lathes on station now costs a fee of 10 credits per item printed if it's from a lathe not under your department. The payment component has received additional handling for physical credits, as well as pulled credits/ID cards for those without hands.	2022-04-27 03:01:21 -07:00
Kyle Spier-Swenson	565319095f	Adds MC initialization stages. Earlier stages can fire while later ones init. Fixes tgui chat reconnection banner showing during init. (#66473) ... * Adds MC initialization stages. Earlier stages can fire while later ones init. Removes TICK_LIMIT_MC_INIT config for barely doing anything to speed up init and being inconvenient to work with if fires and inits can happen at the same time.	2022-04-24 21:29:06 -07:00
Ghilker	ffd1ae5fc0	Rebalanced Power consumption, increase for machines (#66059) ... Machinery power consumption rebalance.	2022-04-20 09:50:54 +02:00
Christmas5	c31f60a853	Set the plane for floor lights. (#65106) ... Floor lights are missing "plane" and the default sets them to -4, which makes them appear on top of tables and players.	2022-02-24 13:28:00 -06:00
Mickyan	378538d4ab	Fixes some light presets being brighter than intended (#64861) ... * fixes light presets * into the void with you	2022-02-15 17:20:37 -06:00
Ghom	c5d2b2e51e	Fixes layering issues brought by the FoV PR. (#63903) ... * Fixed most (not all) incorrect planes and layers detected by the unit test.	2022-02-09 19:40:00 +01:00
MacBlaze1	19e56abfc0	allows charging from lights to loop (#64548)	2022-01-31 19:26:35 -05:00
Ghom	9dfba9bb7c	Removes useless defines for mutation paths (#64512)	2022-01-30 01:19:23 -08:00
LemonInTheDark	f8aad14ae8	Harddel Fix Pack #42 + Better Live Reftracking Support (#63877) ... * Hard Del Fixes, Ref Tracking Changes	2022-01-12 22:46:13 +01:00
Tim	566b9ee1d8	Fix Turf Transparency for MultiZ (#62875) ... Fixes #62794 (Catwalk Tiles placed on the lower level of tram appear to be on the upper level) Fixes #57654 (Open Space shading not always applied) Fixes #53666 (When standing on a glass floor above a light on the Z level below you the light effect is rendered above the character. This makes light have ugly glows on the floors above. This also happens with grills and lattice.) Transparent turfs, catwalks, and lighting overlays were badly broken with MultiZ issues. This fixes any transparent turf to appear and be on the same z-level if it has the turf_transparent element. Catwalks will appear and be on the same z-level as well. They were initially glitching to top z-levels causing people to walk over an illusion that caused them to fall to their deaths. After I fixed these issues I noticed that lighting overlays were also glitching to top z-levels, which looked rather strange as there were lights in the middle of rooms and hallways with no supporting walls. Lights now appear under the transparent turfs properly. The mapping icons for catwalks displayed the wrong icon_state so I fixed that too. I made a big refactor for transparency and catwalks code that had to be done to get all of this to work properly. You no longer have to be afraid of falling off of glass floors, catwalks, or transparent tiles. Also lighting overlays don't glitch through upper z-levels anymore for transparent tiles.	2021-12-29 21:42:49 -08:00
ShizCalev	e100f3ca8c	Fixes ghosts' boo ability going on cooldown when the light they tried to flicker didn't flick (#62965)	2021-11-23 17:58:43 -08:00
esainane	b6f761468e	[MDB IGNORE] dir sanity, primarily on WALLITEMs (#62601) ... About The Pull Request Wall items mostly use the direction from the floor to the wall in the named mapping helper. Wall items mostly use the direction from the wall to the floor for the internal dir variable. This leads to a headache when it comes to working out what conflicts with what, and what needs placing where. Wall frames provided a member, inverse, which specified whether or not to invert the direction of the item when looking for conflicts. It was also used to specify whether to look for conflicts outside of the wall (cameras and lights appear external to the wall) or inside the wall (most wall items). This flag was set for Intercoms, APCs, and Lights. Since APCs and Lights expect a floor-to-wall direction, and Intercoms expect a wall-to-floor direction, this means that APCs and Lights were getting the correct direction, and Intercoms were getting the wrong direction. Some implications of this setup were: You could build an APC on top of another wall item, provided there was nothing external attached to the wall and the area didn't have an APC. You could stack Intercoms indefinitely on top of the same wall, provided you weren't in a one-tile wide corridor with something on the opposite wall. Or both! Here's twenty Intercoms placed on the wall, and a freshly placed APC frame after placing all Intercoms and deconstructing the old APC: endless-stack-of-intercoms Not everything used this inverse variable to adjust to the correct direction. For example, /obj/machinery/defibrillator_mount just used a negative pixel_offset to be visually placed in the correct direction, even though the internal direction was wrong, and never set! This also let you stack an indefinite number of defib mounts on the same wall, provided it wasn't a northern wall... except you could do this to northern walls too, since defibs weren't considered a wall item for the purposes of checking collisions at all! Ultimately, every constructable interior wall item either used this inverse variable to adjust to the correct placement, set a negative pixel_offset variable to have its offset adjusted to the correct placement, or overrode New or Initialize to run its own checks and assignment to pixel_x and pixel_y! Inventory: Table of various paths, related paths, and the adjustments they used Unfortunately, untangling /obj/structure/sign is going to be another major headache, and this has already exploded in scope enough already, so we can't get rid of the get_turf_pixel call just yet. This also doesn't fix problems with the special 2x1 /obj/structure/sign/barsign. Some non-wall items have been made to use the new MAPPING_DIRECTIONAL_HELPERS as part of the directional cleanup. tl;dr: All wall mounted items and some directional objects now use the same direction that they were labelled as. More consistent directional types everywhere. Why It's Good For The Game fml Changelog cl refactor: Wall mounted and directional objects have undergone major internal simplification. Please report anything unusual! fix: You can no longer stack an indefinite amount of Intercoms on the same wall. fix: Defibrillator Mounts, Bluespace Gas Vendors, Turret Controlers, and Ticket Machines are now considered wall items. fix: Wall mounted items on top of the wall now consistently check against other items on top of the wall, and items coming out of the wall now consistently check against other items coming out of the wall. fix: The various directional pixel offsets within an APC, Fire Extinguisher Cabinet, Intercom, or Newscaster have been made consistent with each other. fix: The pixel offsets of Intercoms, Fire Alarms, Fire Extinguisher Cabinets, Flashers, and Newscasters have been made consistent between roundstart and constructed instances. fix: Constructed Turret Controls will no longer oddly overhang the wall they were placed on. qol: Defibrillator mounts now better indicate which side of the wall they are on. fix: Some instances where there were multiple identical lights on the same tile have been fixed to only have one. /cl	2021-11-09 10:02:34 +13:00
Ghom	b79dd74fd0	Replaces a portion of C-style for loops with the more commonplace for loops, which are faster. (#62624) ... Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>	2021-11-07 16:42:41 -08:00
Mothblocks	0f3c4e51f7	Modernizing Radiation -- TL;DR: Radiation is now a status effect healed by tox healing, and contamination is removed (#62265) ... Implements the Modernizing radiation design document ( https://hackmd.io/@tgstation/rJNIyeBHt ) and replaces the current radiation sources with the new system, as well as replacing/removing a bunch of old consumers of radiation that either had no reason to exist, or could be replaced by something else. Diverges from the doc in that items radiation don't go up like explained. I was going to, but items get irradiated so easily that it just feels pretty lame. Items still get irradiated, but it's mostly just so that radiation sources look cooler (wow, lots of stuff around going green), and for things like the geiger counter. Instead of the complicated radiation_wave system, radiation now just checks everything between the radiation source and the potential target, losing power along the way based on the radiation insulation of whats in between. If this reaches too low a point (specified by radiation_pulse consumers), then the radiation will not pass. Otherwise, will roll a chance to irradiate. Uranium structures allow a delay before irradiating, so stay away!	2021-11-01 04:20:39 -03:00
esainane	30da0af679	Add local APC cache to /area (#61655) ... About The Pull Request for(var/obj/machinery/power/apc/APC in GLOB.apcs_list) in get_apc makes chuck norris shed a tear Why It's Good For The Game tears are bad Changelog cl code: /area now retains a local reference to the APC in the area, if any /cl	2021-10-02 14:31:09 +13:00
tralezab	6c01cc2c01	every case of initialize that should have mapload, does (#61623) ... ## About The Pull Request stop forgetting to include mapload, if you don't include it then every single subtype past it by default doesn't include it for example, `obj/item` didn't include mapload so every single item by default didn't fill in mapload  ## Regex used: procs without args, not even regex `/Initialize()` procs with args `\/Initialize\((?!mapload)((.)*\w)?` cleanup of things i didn't want to mapload: `\/datum\/(.)*\/Initialize\(mapload`	2021-09-24 17:56:50 -04:00
Kylerace	d9ee5e7297	moves obj_integrity and associated procs to the atom level (#61183)	2021-09-06 04:07:26 -07:00
TiviPlus	e629c36feb	Refactor area and turf lighting (#60954)	2021-08-25 15:07:38 -07:00
Ghilker	d33fd446fa	light code cleanup and update (#60785)	2021-08-23 13:00:39 -07:00