mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-02-05 13:59:16 +00:00
e2dda1cea51d2b85f10eaa33df49ace4ec79bf2e
67 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
SyncIt21
|
8aa93de044 |
Fixing cell power usage (Part 3) (#82204)
## About The Pull Request Continuation of #82198 Fixes these issues in #82196 - Borg hypo spray - Borg projectile dampen - Borg chameleon - Firelance - MODlink scryer - Emergency light usage ## Changelog 🆑 fix: Fixed more energy usages for cells(Part 3). See PR 82204 for details /🆑 --------- Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com> |
||
Pickle-Coding
|
c1f11f26ce |
Converts arbitrary energy units to the joule. Fixes conservation of energy issues relating to charging cells. (#81579)
## About The Pull Request Removes all arbitrary energy and power units in the codebase. Everything is replaced with the joule and watt, with 1 = 1 joule, or 1 watt if you are going to multiply by time. This is a visible change, where all arbitrary energy units you see in the game will get proper prefixed units of energy. With power cells being converted to the joule, charging one joule of a power cell will require one joule of energy. The grid will now store energy, instead of power. When an energy usage is described as using the watt, a power to energy conversion based on the relevant subsystem's timing (usually multiplying by seconds_per_tick or applying power_to_energy()) is needed before adding or removing from the grid. Power usages that are described as the watt is really anything you would scale by time before applying the load. If it's described as a joule, no time conversion is needed. Players will still read the grid as power, having no visible change. Machines that dynamically use power with the use_power() proc will directly drain from the grid (and apc cell if there isn't enough) instead of just tallying it up on the dynamic power usages for the area. This should be more robust at conserving energy as the surplus is updated on the go, preventing charging cells from nothing. APCs no longer consume power for the dynamic power usage channels. APCs will consume power for static power usages. Because static power usages are added up without checking surplus, static power consumption will be applied before any machine processes. This will give a more truthful surplus for dynamic power consumers. APCs will display how much power it is using for charging the cell. APC cell charging applies power in its own channel, which gets added up to the total. This will prevent invisible power usage you see when looking at the power monitoring console. After testing in MetaStation, I found roundstart power consumption to be around 406kW after all APCs get fully charged. During the roundstart APC charge rush, the power consumption can get as high as over 2MW (up to 25kW per roundstart APC charging) as long as there's that much available. Because of the absurd potential power consumption of charging APCs near roundstart, I have changed how APCs decide to charge. APCs will now charge only after all other machines have processed in the machines processing subsystem. This will make sure APC charging won't disrupt machines taking from the grid, and should stop APCs getting their power drained due to others demanding too much power while charging. I have removed the delays for APC charging too, so they start charging immediately whenever there's excess power. It also stops them turning red when a small amount of cell gets drained (airlocks opening and shit during APC charge rush), as they immediately become fully charged (unless too much energy got drained somehow) before changing icon. Engineering SMES now start at 100% charge instead of 75%. I noticed cells were draining earlier than usual after these changes, so I am making them start maxed to try and combat that. These changes will fix all conservation of energy issues relating to charging powercells. ## Why It's Good For The Game Closes #73438 Closes #75789 Closes #80634 Closes #82031 Makes it much easier to interface with the power system in the codebase. It's more intuitive. Removes a bunch of conservation of energy issues, making energy and power much more meaningful. It will help the simulation remain immersive as players won't encounter energy duplication so easily. Arbitrary energy units getting replaced with the joule will also tell people more meaningful information when reading it. APC charging will feel more snappy. ## Changelog 🆑 fix: Fixes conservation of energy issues relating to charging powercells. qol: APCs will display how much power they are using to charge their cell. This is accounted for in the power monitoring console. qol: All arbitrary power cell energy units you see are replaced with prefixed joules. balance: As a consequence of the conservation of energy issues getting fixed, the power consumption for charging cells is now very significant. balance: APCs only use surplus power from the grid after every machine processes when charging, preventing APCs from causing others to discharge while charging. balance: Engineering SMES start at max charge to combat the increased energy loss due to conservation of energy fixes. /🆑 --------- Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
Bilbo367
|
466b3df048 |
Refactor removing unused defines. (#82115)
## About The Pull Request Refactors a lot of the unused defines. ## Why It's Good For The Game Refactors a lot of the unused defines. ## Changelog Nothing player facing --------- Co-authored-by: san7890 <the@san7890.com> |
||
MrMelbert
|
5f2f9e67ad |
Add compile option for compiling in MAP_TEST mode, which disables common annoyances when testing new maps (#81697)
## About The Pull Request Adds `MAP_TEST` compile flag. This compile flag blocks common things which make it difficult to test a map. Things this applies to: - Rats no longer spawn. - Rat spawning will (obviously) break up the powernet, which is INCREDIBLY annoying when trying to test if all the rooms of the station are wired correctly (or testing which rooms lose power first, etc) - Light tubes no longer break on initialize. - Random light breakages can easily cause mappers to accidentally over light a room. - Roundstart command report is not printed. - Might be a personal preference, but it's kinda annoying to hear the alert over and over again. - Random events do not trigger. - Some events such as gravity generator outage can trigger with 0 population. - Random camera breakage event can cause over-placement of cameras. - Other stuff tends to just get in the way. - Station traits do not trigger. - Probably the biggest annoyance. Many traits modify the map in some way which disrupts testing. - Roundstart landmarks don't self deletes. - Allows mappers to use sdql to find them. - Mapping verbs start enabled. Obviously more things can be added if they come up. |
||
|
SyncIt21
|
4495ea2e4d |
Refactors how machines are deconstructed (#81291)
## About The Pull Request This refactors how machines are deconstructed in the following ways - You can no longer override `obj/machinery/deconstruct()`. If you want customized behaviour then override `on_deconstruction()` instead. This comes with the added benifit of no longer needing to check for the `NO_DECONSTRUCTION` flag because the machine base proc does that for us & if it finds that flag it won't proceed to call `on_deconstruction()` meaning no machine will have a chance to spawn anything which is the current behaviour. This is required to make #81290 work for all machines at least so that machine can send the `COMSIG_OBJ_DECONSTRUCT` signal without subtypes overriding & forgetting to call the parent proc - `dump_contents()` only gets called when the machine is deconstructed not destroyed thus not leaving behind any of its contents inside. Fixes https://github.com/tgstation/tgstation/pull/81290#issuecomment-1925752583 ## Changelog 🆑 fix: machines that should not drop contents when deleted no longer do. refactor: refactors how machines are deconstructed. report bugs on github. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
LemonInTheDark
|
0638b11dad |
Fire Alarm Lights (Lit version) (Also lumin cleanup) (#80384)
## About The Pull Request [Removes redundant uses of luminosity]( |
||
|
LemonInTheDark
|
f03084c1ca |
FOV is Dead (Long Live FOV) (#80062)
## About The Pull Request FOV as it is currently implemented is incompatible* with wallening. I'm doin wallening, so we gotta redo things here. The issue is the masking of mobs. Wallening relies on sidemap (layering based off physical position), which only works on things on the same plane (because planes are basically sheets we render down onto) So rather then masking mobs, let's reuse the masking idea from old fov, and use it to cut out a bit of the game render plane, and blur/over-saturate the bit that's masked out. My hope is this makes things visible in light, but not as much in darkness, alongside making more vivid shit more easily seen (just like real life) Here's some videos, what follows after is the commits I care about (since I had to rip a bunch of planes to nothing, so the files changed tab might be a bit of a mess) Oh also I had to remove the darkness pref since the darkness is doing a lot of the heavy lifting now. I'm sorry. Edit: NEW FOV SPRITES! Thanks dongle your aviator glasses will guide us to a better future. https://github.com/tgstation/tgstation/assets/58055496/afa9eeb8-8b7b-4364-b0c0-7ac8070b5609 https://github.com/tgstation/tgstation/assets/58055496/0eff040c-8bf1-47e4-a4f3-dac56fb2ccc8 ## Commits I Care About [Implements something like fov, but without the planes as layers hell]( |
||
san7890
|
5ce9d5806d |
Scopes NODECONSTRUCT_1 from flags_1 to obj_flags (#80104)
This flag only worked on the `/obj/structure` and `/obj/machinery` level, so let's rescope it from `flags_1` and put it where it belongs - `obj_flags`. Bitflag operators should be scoped to their subtype specific bitfield, not really useful to have this take up a spot on the `/atom` level if absolutely nothing other than `/obj`s use it. |
||
|
san7890
|
7f7688b60a |
Demotes the "electrical conductivity" flag from flags_1 to obj_flags (#80033)
## About The Pull Request
Code to handle this flag only ever existed on the `/obj` sublevel, so
there's no need for it to be on the `/atom` level `flags_1`. There was
probably a point in time in which mobs or turfs conducted electricity
but there's zero code for it anymore so we truly just live in a society
now.
## Why It's Good For The Game
Frees up a slot on `flags_1` (which is really nice actually), proper
scoping of certain bitflag stuff, etc.
## Changelog
Not relevant to players.
I may have screwed something up, will be doing a few passes on this
myself to ensure all the search and replaces went alright but we should
be good™️
|
||
|
MrMelbert
|
c1ed62915b |
Adds UPSIDE_DOWN movetype for negative gravity / makes Atrocinator affected by less things (#79785)
## About The Pull Request Fixes #79764 I was going to tackle this issue by slamming `TRAIT_NO_SLIP_ALL` on Atrocinator users and calling it a day, but like, that didn't feel proper. So I thought hey, we could just give them the flying movetype, even though they technically aren't flying it means they're unaffected by things that flying would make you unaffected by. Nope, this means the mob technically "negates gravity", so no falling and no feetsteps. Let's try floating - this give us feetsteps but no falling upwards. So instead of going back to square one, with `TRAIT_NO_SLIP_ALL`, I decided to go for the more complex route of just adding a movetype. Hence, move type `UPSIDE_DOWN`. This covers situations where a mob would be "floating" above the ground, but still walking. ...Negative gravity. This means overall the Atrociator acts more as you'd expect - you don't slip on ice, you don't trigger bear traps or mouse traps, you can walk over railings, unaffected by conveyor belts, etc. ## Why It's Good For The Game Makes the Atrocinator a lot more consistent with how you'd expect for it to work. Admittedly it is a bit niche use of movetypes, but it can possibly be expanded to more things in the future, who knows? I applied it to mobs on meat spikes (even though they don't move), just for proof of concept. ## Changelog 🆑 Melbert fix: Atrocinating mobs will now behave more as you'd expect. Meaning they don't slip on wet patches, can't trigger bear traps / landmines / mouse traps, ignore conveyors, and can walk over tables and railings. fix: Floating mobs are unaffected by conveyor belts, acid (on the ground), glass tables fix: Floating mobs won't squish stuff like roaches anymore fix: Fixes bear traps triggering on floating / flying mobs /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
MrMelbert
|
f1863d9ae0 |
Removes weird arg in machinery get_room_area (#79645)
## About The Pull Request This argument was only ever used as a pseudo dot operator. Not only that but it was typed as `/area`, yet the only place that passed something to it passed `/obj/machinery/light`s. So I axed it. |
||
ArcaneMusic
|
a77ac3e4f1 |
Adds a new component so that items that are "attached" to walls will now drop/deconstruct on turf destruction. (#77417)
## About The Pull Request Adds a new component, called wall_mounted, which applies on the wallframe objects on construction, as well as a number of wall frame objects and structures to cover mapped in, roundstart objects of the like. I might have forgotten a few, but this covers the vast majority that players will run into in a given round. This will cover wall destruction, turf explosion, the whole nine yards, and call that object/structure/machine's deconstruct proc. We have some special handling for intercoms as well since they're apparently items. So most basic case is this: You have a wall. that wall holds a sign. If you examine the wall, it tells you that the wall is currently supporting the **Example Sign**. It tells you that if the wall is damaged or destroyed, the sign will **fall off the wall.** So, if you were to welder, bomb, or hulk your way through that wall, it would call the deconstruct() proc on that sign, and fall off the wall, leaving an item sign at the foot of the wall. ## To-Do - [x] Stop breaking all wallmounts when operating shuttles (Signal conflict with COMSIG_TURF_CHANGED 😔) - [x] Confirm that the ~~deconstruct~~ designated proc of each wallmount falling is sane for the intended object - [x] Clean up the contents of the wall_mounted component to reduce copy-paste on object init. - [x] Add it to more stuff that may just not have a directional helper? - [x] ~~Change how APC construction is handled to make it easier!~~ - [x] ~~Don't accidently nerf malf AI into the ground I guess~~ ## Why It's Good For The Game Closes #22283. Helps close more of #47526. Closes #54983. Closes https://github.com/wall-nerds/wallening/issues/90. All of these objects are "wall mounts". It stands to reason that they're mounted to the walls they appear to be attached to. This attempts to rectify them by giving them a turf link to the turf they're mounted to, and then upon changes to that turf, dropping or breaking that object. It'll need a little more polish to get to 100%, since I can see a few more issues to iron out first, but I'm dropping this here for now to get some feedback and put some fire under me to get this completed. ## Changelog 🆑 add: Wall mounted objects (Things like APCs, Air Alarms, Light switches, Signs, Posters, Newscasters, you name it) will now fall to the ground and break or deconstruct when their attaching wall is changed or broken. /🆑 |
||
Hatterhat
|
c6ac468b90 |
second pass over the SC/FISHER code, incl. bitflags and PDAs (#78330)
## About The Pull Request makes `COMSIG_HIT_BY_SABOTEUR` return a bitflag in order to close #78297 (i am very sorry) fixes #78298 extends flashlight disabling to modular computers incl. PDAs because somehow i forgot that they had flashlights. ## Why It's Good For The Game my code sucks and i should make it suck less, actually ## Changelog i don't think i get to put a code improvement tag if it's not playerfacing and it's my own fault 🆑 fix: Flares and candles no longer sound like flashlights when being turned on. fix: Getting shot by an SC/FISHER now disables PDA lights for consistency's sake. /🆑 --------- Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com> |
||
|
Hatterhat
|
ac18420676 |
John Splintercell: a gun that is only good for shooting out lights (#78128)
## About The Pull Request adds the SC/FISHER lightbreaker self-charging energy pistol, which does 0 damage. As a joke.  https://github.com/tgstation/tgstation/assets/31829017/97572baa-7421-4800-a60e-2db03f4adc6d <details><summary>actual details, in case the video wasn't good enough:</summary> unless you shoot at light fixtures,  floodlights,  or people with flashlights/seclites (even on helmets or guns) (it still does 0 damage, it just turns off their lights. not permanently)  it also works on crusher lights. and cyborg headlights. i don't have a screenshot for it. doesn't work on flares though. also it can shoot past machines and lockers  </details> (also adds a variable for deciding how loud a dry fire sound is, in case you want to make your gun's empty sound be less loud.) ## Why It's Good For The Game Adds a silly little tool for silly little men who either really hate lightbulbs or want to recreate the experience of being John Splintercell, the lightbulb-assasinating secret agent from Fork Echelon. ## Changelog 🆑 add: The SC/FISHER disruptor pistol, a very compact, permanently silenced energy gun, is now stocked in Nanotrasen-accessible black markets with a price generally somewhere between 400 and 800 credits. Aspiring users are warned that it's really bad for trying to actually kill people. Caveat emptor. add: Guns now have a dry_fire_sound_volume variable, allowing for guns to be less loud when trying to fire while empty. fix: Closets and crates now properly count as structures for pass flags again. /🆑 --------- Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com> |
||
Paxilmaniac
|
52138a8380 |
Makes the bulbs of lights emissive (#77327)
## About The Pull Request As Vekter pointed out, the lights can look like they aren't actually on in certain situations now that they longer have that awful active overlay with a million invisible pixels. This fixes that problem by making the bulbs emissive when they're on. ## Why It's Good For The Game Light looking like they're on when they're on is important for a lot of things.  ## Changelog 🆑 fix: The bulbs of lights will now have an emissive glow when on, making it so they appear active no matter how dark the area surrounding them happens to be. /🆑 |
||
Ghom
|
5d5492e111 |
Implements usage of the REVERSE_DIR macro throughout the code. (#77122)
## About The Pull Request Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro. ## Why It's Good For The Game Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir, 180)` call, being a simple set of binary operations. To sum it up, micro optimization. ## Changelog N/A |
||
nikothedude
|
f44adfde1e |
Refactors vendor tipping and adds 2 new malf modules: Remote vendor tipping, and the ability to roll around and crush anything in your path. (#76635)
## About The Pull Request Title. Vendor tipping code is now on /atom/movable, and any movable can fall over like a vendor does. Things like crits have been moved to type-specific availability tables, their effects are now held in their own proc, are now random per crushed item, have probability weights, etc. In the process of making this PR I also had to fix another issue, where a bunch of take_damage() overrides had incorrect args, so that explains the take_damage changes I made. Tipping now also attacks any atoms on the target, given they use integrity. Adds 2 new malf modules. 1. REMOTE VENDOR TIPPING: A mid-cost and mid-supply module allows malf AIs to remotely tip a vendor in any of the 8 directions. After 0.5 seconds of delay and a visual indicator (along with other warnings), the vendor falls over. 1.1. In the process of making this I had to expand a arrow sprite to have orthogonal directions, which is why you may see the testing dmi being changed. 2. CORE ROLLING: A mid-cost but low-supply ability that allows the AI to roll around and crush anything it falls on, including mobs. This has a 5% chance to have a critical hit so it isnt THAT terrible - plus it's guaranteed to never stunlock. It's real utility lies in the fact the AI now has limited movement without borgs. Also, the psychological factor. As a bonus, vendor tipping now uses animate and transforms instead of replacing matrices. ## Why It's Good For The Game 1. Generifying vendor tipping code is just good, period. It's a very wacky and silly little piece of code that really doesn't need to be isolated to vendors exclusively. ANY big and heavy object can fall over and do a ton of damage. 1.1. Also, adding weights to critical hits is really good, because it lets things like the headgib finally be a lot less terrifying, as they're a lot less likely to happen. 2. Remote vendor tipping is a bit of a goofy ability that isn't really THAT practical but has a chance of catching someone unaware and doing some serious damage to that person alone. 2.1. Atop of this, vendor tipping isn't that loud of an action as say, blowing things up, or doing a plasma flood. Even overrides aren't this silent or a non-giveaway. A vendor falling on someone, though, is a mundane thing that happens a lot. This is a decent way to assassinate people before going loud (or at least, damage people) that isn't offered yet. 4. 3.1. For real though, AIs rolling around is just fucking hilarious. The ability to move isn't offered right now (which isn't that much of a bad things), but with sufficiently limited charges (or limits to how many times you can buy the ability), this can be a funny little t hing that lets the AI potentially hide somewhere on the sat (or just relatively close to the sat, such as engineering [it can't go through the teleporter with this but it can go through transit tubes]) without the need for borgs. 3.2. Also, it lets the AI sacrifically execute people by blowing up their brains. |
||
Senefi
|
aeccefb7c2 |
Metastation Medbay Lighting Tweaks (#77012)
## About The Pull Request
Adjusts some of the lights in metastation medbay to improve overall
theming of specific rooms.
Rooms changed:
- Morgue
- Medbay Hallway
- Cold Storage
- Chem Storage
- Break Room
- Clinic
- Primary Surgical Theatre
- Psychiatrists Office
This makes use of a new preset, Dim Cold Lights, and also implements a
Dim Warm Light counterpart.
## Why It's Good For The Game
More presets for mappers to use for lights, and subtle changes to the
lights in medbay to make each light feel more impactful, darkening the
rooms more when lights break and improving the overall theme of specific
rooms via the use of color temperature and intensity.
## Changelog
:cl:Senefi
add: Some Metastation Medbay lights have been moved and adjusted.
/🆑
|
||
|
LemonInTheDark
|
41f20bc3ce |
[MDB IGNORE] Angled Lights & Lighting Prototyping Tool (#74365)
## About The Pull Request Hello friends, I've been on a bit of a lighting kick recently, and I decided I clearly do not have enough things to work on as it is. This pr adds angle support to static lights, and a concepting/debug tool for playing with lights on a map. Let's start from first principles yeah? ### Why Angled Lights? Mappers, since they can't actually see a light's effect in editor, tend to go off gut. That gut is based more off what "makes sense" then how things actually work This means they'll overplace light sources, and also they tend to treat lights, particularly light "bars" (the bigger ones) as directional. So you'll have two lights on either sides of a pillar, lights inside a room with lights outside pointing out, etc.  This has annoying side effects. A lot of our map is overlit, to the point that knocking out a light does.... pretty much nothing. I find this sad, and would like to work to prevent it. I think dark and dim, while it does not suit the normal game, is amazing for vibes, and I want it to be easier to see that. Angled lights bring how lights work more in line with how mappers expect lights work, and avoids bleedover into rooms that shouldn't be bled into, working towards that goal of mine. ### How Angled Lights? This is more complex then you'd first think so we'll go step by step  Oh before we start, some catchup from the last time I touched lighting code. Instead of doing a lighting falloff calculation for each lighting corner (a block that represents the resolution of our lights) in view we instead generate cached lightsheets. These precalculate and store all possible falloffs for x and y distances from a source. This is very useful for angle work, since it makes it almost totally free. Atoms get 2 new values. light_angle and light_dir Light angle is the angle the light uses, and light_dir is a cardinal direction it displays in We take these values, and inside sheetbuilding do some optional angle work. getting the center angle, the angle of a pair of coords, and then the delta between them. This is then multiplied against the standard falloff formula, and job done. We do need some extra fenangling to make this all work nicely tho. We currently use a pixel turf var stored on the light source to do distance calculations. This is the turf we pretend the light source is on for visuals, most often used to make wall lights work nice. The trouble is it's not very granular, and doesn't always have the effect you might want. So, instead of generating and storing a pixel turf to do our distance calculations against, we store x and y offset variables. We use them to expand our working range and sheet size to ensure things visually make sense, and then offset any positions by them. I've added a way for sources to have opinions on their offsets too, and am using them for wall lights. This ensures the angle calculations don't make the wall behind a light fulldark, which would be silly. ### Debug Tool? In the interest of helping with that core problem, lights being complex to display, I've added a prototyping tool to the game. It's locked behind mapping verbs, and works about like this. Once the verb is activated, it iterates over all the sources in the world (except turfs because those are kinda silly), outlining and "freezing" them, preventing any future changes. Then, it adds 3 buttons to the owners of a light source.  The first button toggles the light on and off, as desired. The third allows you to move the source around, with a little targeting icon replacing your mouse The second tho, that's more interesting. The second button opens a debug menu for that light  There's a lot here, let's go through it. Bit on the left is a list of templates, which allow you to sample existing light types (No I have no idea why the background is fullwhite, need to work on that pre merge) You can choose one by clicking it, and hitting the upload button. This replaces your existing lighting values with the template's, alongside replacing its icon and icon state so it looks right. There are three types as of now, mostly for categorization. Bar, which are the larger typically stronger lights, Bulb, which are well, bulbs, and Misc which could be expanded, but currently just contains floor lights. Alongside that you can manually edit the power, range, color and angle of the focused light. I also have support for changing the direction of the light source, since anything that uses directional lighting would also tie light dir to it. This isn't *always* done tho, so I should maybe find a way to edit light dir too. My hope is this tool will allow for better concepting of a room's lights, and easier changing of individual object's light values to suit the right visuals. ### Lemon No Why What Ok so I applied angle lights to bars and bulbs, which means I am changing the lighting of pretty much every map in the codebase. I'm gonna uh, go check my work. Alongside this I intend to give lighting some depth. So if there's room to make a space warmer, or highlight light colors from other sources, I will do that. (Images as examples)  I also want to work on that other goal of mine, making breaking lights matter. So I'll be doing what I can to ensure you only need to break one light to make a meaningful change in the scene. This is semi complicated by one light source not ever actually reaching fullbright on its own, but we do what we must because we can.  I'm as I hope you know biased towards darker spaces, I think contrast has vibes. In particular I do not think strong lights really suit maintenance. Most of what is used there are bulbs, so I'm planning on replacing most uses with low power bulbs, to keep light impacts to rooms, alongside reducing the amount of lights placed in the main tunnels  **If you take issue with this methodology please do so NOW**, I don't want to have to do another pass over things. Oh also I'm saving station maps for last since ruins are less likely to get touched in mapping march and all. ### Misc + Finishing Thoughts Light templates support mirroring vars off typepaths using a subtype, which means all the templates added here do not require updating if the source type changes somehow. I'd like to expand the template list at some point, perhaps in future. I've opened this as a draft to make my intentions to make my changes to lights known, and to serve as motivation for all the map changes I need to do. ### Farish Future I'm unhappy with how we currently configure lights. I would like a system that more directly matches the idea of drawing falloff curves, along with allowing for different falloffs for different colors, alongside extending the idea to angle falloff. This would make out of engine lighting easier, allow for nicer looking lights (red to pink, blue to purple, etc), and improve accessibility by artists. This is slightly far off, because I have other obligations and it's kinda complicated, but I'd like to mention it cause it's one of my many pipedreams. ## Changelog 🆑 add: Added angle lighting, applies it to most wall lights! add: Adds a lighting prototyping tool, mappers go try it out (it's locked behind the mapping verb) /🆑 --------- Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
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> |
||
|
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 /🆑 |
||
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. /🆑 |
||
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. |
||
|
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. |
||
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> |
||
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' |
||
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 /🆑 |
||
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> |
||
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.
/🆑
|
||
|
LemonInTheDark
|
60e85fa947 |
Polishes some side sources of light and color (#73936)
## About The Pull Request [Circuit Floor Polish]( |
||
|
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 |
||
|
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. /🆑 |
||
|
LemonInTheDark
|
6e4c4c51e3 |
Adds depth to firealarm lighting, makes starlight more pretty (#72327)
## About The Pull Request [Messes with fire alarm/fire light lighting]( |
||
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> |
||
|
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> |
||
|
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> |
||
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 |
||
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> |
||
|
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) |
||
|
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. |
||
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. |
||
|
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. |
||
Mickyan
|
df855c9238 |
Tweaks brightness for red, blacklight presets. Adds dim red light preset (#68576)
Tweaked blacklight,red - Added dim red |
||
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? |
||
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 |
||
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 |
||
|
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 |
||
|
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.
|
||
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. |
