## About The Pull Request
Hey there,
A pretty bad bug (#76226) got through, but it was fixed pretty quickly
in #76241 (cf92862daf). I realized that if
we were testing all the away missions, that this could theoretically get
caught and not happen again. Regardless, unit testing gateway missions
has been on my to-do list for a while now, and I finally got it nailed
down.
Basically, we just have a really small "station" map with the bare bones
(_teeny_ bit of fluff, maploading is going to take 30 seconds tops
anyways let me have my kicks) with a JSON map datum flag that causes it
to load all away missions in the codebase (which are all in one folder).
Just in case some admins were planning on invoking the proc on
`SSmapping`, I also decided to gate a `tgui_alert()` behind it because
you never can be too sure of what people think is funny these days (it
really does lock up your game for a second or so at a time).
I also alphabetized the maps.txt config because that was annoying me.
## Why It's Good For The Game
Things that break on production could(?) be caught in unit testing? I
don't know if the linked issue I mentioned above would have been caught
in retrospect, but it's likely to catch more than a few upcoming bugs
(like the UO45 atmospherics thing at the very top) and ensure that these
gateway missions, which tend to be the most neglected part of mapping,
stay bug-free.
This is also helpful in case someone makes a new away mission and wants
to see if stuff's broken. Helps out maptainers a bit because very, very
technically broken mapping will throw up runtimes. Neato.
## Changelog
Nothing that players should be concerned about.
Let me know if there's a better way to approach this, but I really think
that having a super-duper light map with the bare basics to load up
gateway missions and then all nine-ish gateway missions can sequentially
load during init. I can't think of a better way to do it aside from some
really ugly `#ifdef` shit. Also also, it has the added benefit of being
a map that will always load your away mission without touching a single
shred of config (and it's not likely to break if you follow sane
practices such as making your own areas)
## About The Pull Request
Inspired by #74967 and #68459 , and the fact that Tramstation regresses
very often -
Adds a unit test, `required_map_items`, which ensures that certain
typepaths which should definitely be mapped onto every map is mapped
onto every map
It can also be used to ensure that items which should not be mapped in
multiple times are not, among other things.
I included a few examples -
- Min 1, max inf of each head of staff stamps
- Min 1, max 1 departmental order consoles
- Min 1, max inf comms console
- Min 1, max 1 Pun Pun
- Min 1, max 1 Poly
- Min 1, max 1 Ian
If, in the future, a mapper decides they (for some reason) do not want a
certain previously-required item on their map, the test can be adjusted
such that it allows excluding or something, but currently it should be
for items which require conscious thought about.
#### QA: Why not make this a linter?
I attempted to make this a linter before realizing two things
1. Someone might make a spawner which spawns the items, or they might
get placed in a locker, in any case this accounts for everything on init
2. Linters run on every map, non-station maps included
So I went with a test
## Why It's Good For The Game
#50468#61013#74967
Why is it always the CMO stamp?
## Changelog
Not necessary (unless I find a map missing something, then this will be
updated)
## About The Pull Request
- Any type of door can now operate as an elevator door
- emag action is linked to elevator panel
- Cargo elevator access fixed, lost in a skew somewhere
- Engineers can override safety controls
- Elevators near tram are connected to tram APC
- Creates a global list of elevator doors so that elevator procs don't
have to go through all of GLOB.machines
## Why It's Good For The Game
Elevator doors have their own controller, don't use the blast door
controller, have no similarities to poddoors. Emag works as expected,
some access issues fixed, and avoids searching GLOB.machines.
## About The Pull Request
Ensures that we don't get station areas which are disconnected
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
"Drake, why is this room depressurized?"
## Changelog
Alt Title: The End Of The 12 Month War
## About The Pull Request
### Hey! Listen! This PR _will_ cause a merge conflict with your PR!
Please ensure that you have the knowledge on how to handle merge
conflicts, found here:
https://hackmd.io/@tgstation/ry4-gbKH5#Assured-Merge-Conflict-Resolution
Supercedes #74023 entirely.
Port of the tooling introduced in
https://github.com/BeeStation/BeeStation-Hornet/pull/7970 (we already
had everything else), modified to meet /tg/'s requisites and culling
anything that was not entirely relevant (that I could see). It's not the
end of the world if I missed something tbh. Some aspects were commented
out since they may be relevant to downstreams who port this PR or to
enable (what I see to be) un-necessary warnings.
This is a culmination of a year's efforts, starting with _Red Rover,
Four Corners_ (#65290) and later _Opposing Corners_ (#65455). If you
don't understand why this PR exists or why it's necessary, I recommend
reading both of those.
Since then, several mappers (both in their own mapping as well as
tailored PRs) have worked on "flattening" out these tile turfs, however
I've continually wanted a function that would mass automate it (outlined
here https://tgstation13.org/phpBB/viewtopic.php?t=31872 - This
functionality might still be useful if added to UpdatePaths or another
type of script thereof, but I no longer have reason to keep the bounty
up).
It's finally here! Yippie! A new python file, courtesy of itsmeow at
BeeStation. Very awesome. As previously mentioned, a lot of alterations
had to be made for our mapping desires, but the results are quite
agreeable. There's a few assertions that this file makes that I had to
address:
* We have "colorless" tile decals. These are transparent, so they don't
do anything. By default, bee would make these "white tiles", but we have
no such thing. I decided to just add a maplint and an UpdatePaths to
guard against this silliness (only Delta and Tram) had it.
* For some reason, it labels already-converted decals with the default
direction as an error state. I might touch this up in the coming hours,
but for now I surpressed the error due to how many false warnings it was
spitting out.
There's a few ways this tool can be improved, but I lack the knowledge
on how to do so:
* Make it so that we can run the map merger to fix the keys of the map
in the `update_map` function, rather than run the fixer-upper python
file. We can live without this to be honest. It's actually slightly good
because it forces you to look at all of the MapMerge Warnings, and you
can ascertain any potential errors without it silently passing you by
and hitting the repository (or at least those that we haven't linted for
yet).
* Be able to pass in any regex to "flatten" anything. That's way out of
scope for what I want to do here though.
## How do you use this tool?
I made a readme.
363852cb17/tools/MapTileAggregator/readme.md
### Mapping March
oh hey it's pretty neat that this PR came out in mapping march, what a
nice qol for mappers as the month enters the home stretch. ckey is
san7890
## Why It's Good For The Game
slimmer DMM files, better mapping practices. cool new tool. so nice.
## Changelog
Nothing that really affects players, but a short summary for all those
reading this PR:
* All "corner" turf decals are flattened, and there's now a tool that we
store that you can re-run to keep stuff flat in case you like mapping
one way and want to fix it at the end.
* We (should) now lint against useless uncolored turf decals since that
was completely garbo as far as our codebase is concerned.
* UpdatePaths for fixing up uncolored turf decals, yippie!
If you want to review this PR, may I suggest the file filter. You don't
need to look at any of the DMM files I already did:
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
One of the walls in the Runtimestation cargo bay was, amongst all of the
reinforced walls used everywhere else on the station, a regular, normal
wall. I noticed it a few months ago and now compulsively check up on it
every time I open runtime for testing. I think it's time to finally put
it to rest.
I don't know if this was put here for any particular reason. I'm
assuming it's just a goof that went unnoticed because it was covered by
a cargo screen.
## Why It's Good For The Game
Consistency in mapping.
Reduces the number of lines in the runtimestation.dmm file by a total of
four. That's an improvement to efficiency on some microscopic,
imperceptible scale, right?
## Changelog
🆑
fix: a wall covered by a screen on runtimestation has been modified into
a reinforced wall.
/🆑
## About The Pull Request
It's the season of giving and so here at Nanotrasen we've partnered with
a new supplier in order to create a limited run of Luxury Escape Pods.
These larger, carpeted pods with extra windows and smoother, quieter
engines will be rolling out soon to stations who do particularly well on
their quarterly earnings reports!
<details>
<summary>Redact Before Sending</summary>
Of course, that funding had to come from somewhere. Stations with a
particularly poor performance may have to settle for the budget option
until results improve.
</details>
In order to facilitate station traits modifying escape pods, I made a
subtype of stationary shuttle dock specifically for escape pods.
There is a map update script which will replace existing pod docks with
the new one, it also cuts down on some map var edits.
I was worried that varying the pod size would cause problems but it
actually went surprisingly smoothly, only Kilo had a couple of plating
turfs in the way. This might cause problems for maps in development
though, if they are relying on escape pods being a _very_ specific size.
## Why It's Good For The Game
I just think it's neat.
But more station traits = more variance between rounds = more fun, I
guess?
Varying how large escape pods might be can create interesting dilemmas
between crew about how to fit into them, at least about how tall they
need to make the pile of prone people.
The escape pod dock subtype might help out newer mappers a little bit,
as it means fewer var edits to copy/paste from other maps.
## Changelog
🆑
add: New station traits can vary how large and comfortable the station
escape pods are.
/🆑
* A lot of shuttle code improvements
* Makes use of ``as anything`` in many places
* Adds mapload to connect_to_shuttle()
* Renames many vars, including shuttle 'id' var to 'shuttle_id' and engine 'state' to 'engine_state'.
* Engines now weakref their attached ship, and disconnect when unwrenched from it.
* Removes check for force when deleting a mobile docking port, being deleted should still clear your stuff, regardless of being forced.
Because of all the above, I was able to remove a few pointless checks scattered around, like engine's alter_engine_power()
* better comment for port_id
* Fixes Cargo, Arrivals, and Pirate ships.
* Merge branch 'master' into shuttlecode-oh-no
* last few
* fixes the CI
* fixes
* Fixes infinite engines
* Revert "Merge branch 'master' into shuttlecode-oh-no"
This reverts commit 94eba37de9fe3f4a01dc40bb064771b764f379e3.
* trammies
* whiteship tram
* Makes use of ?. instead
apparently this is what weakrefs use, so 🤷
* i hate supernovaa41
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* removes lateinit that I never implemented
* adds _ref to weakref var name
* small change to weld time define
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
* Elevators are a bit more friendly part 1
- Emaggable elevator buttons / support for emaggable device assemblies
- Delayed travel between floors
- Elevators can now show a warning sign to areas below while travelling
- Elevators can now optionally wound heavily instead of gibbing
* Adds supoprt for "lift doors"
* Comment tweak
* Splitting these variables
* Functional prototype
* multiz debug
* Elevator button framework
* Unifies these behaviors
* Emergency doors
* Lift button framework
* UI closes on floor change
* Testing changes
* Fix
* UI Tweaks
* Panel works pretty swell
* Minor tweaks
* Move to static
* Bonus tram change
* User experience
* Slight tweak to mapload stuff
* This is silly
* Some UI tweaks, need to update css
* CSS and ui overhaul
* Documentation updates.
* Multi-z lift support
* Multitile lift fix
* Fixes some minor problems with grav gen
* Fixes gravity generator completely obliterating your ears by having several gravity generator soundloops (now there's only 1) by starting soundloop on creation, during parent's Initialize (so it doubled since things like grav gen part (a generator inside the generator??), starts a soundloop too, now the station's gen just starts the loop if it spawns on)
* Fixes offstation gravity generator looking like it's turned on when it isn't, and fixes it having sound when it's off.
* Removes /station grav gen subtype, because it was frankly useless.
* Adds some early returns to gravity generator's process, and removes the unused set_state proc, which was replaced with enable() and disable() in the radiation rework.
* Lastly, removes grav gen parts from QDEL_NULL'ing their soundloop twice, since they called parent's Destroy() that did it for them anyways.
* fixes minor typo
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* more grav gen code improvement
This commit is solely focused on code improvement.
* gravity_field and sound_loop was moved from gravity generator to main gravity generator, since they're the only place it was used.
* Added checks for a main part across generator part procs, rather than using ? randomly.
* Autodocs all Gravity generator vars
* Adds better var names in for() loops, makes use of as_anything, and renames parts to generator_parts.
* Adds some better var names in general.
* Adds an UpdatePaths
* fixes infinite del loop
* fix to harddels
* Update gravitygenerator.dm
* merge conflict moment
* fix maps
* fixes merge conflict
* Update gravitygenerator.dm
* updates the updatepath
* Update gravitygenerator.dm
* Update gravitygenerator.dm
* merge conflict
* set_broken()
* Update gravitygenerator.dm
* unregister signal on destroy
* Update gravitygenerator.dm
* middle part
* Update gravitygenerator.dm
* more improvement + moves grav code to grav file
* Update gravitygenerator.dm
* handles map merge conflicts
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* [MDB Ignore] Shifts all (sane) varedited signs to directionals
Hey there,
So we have these cool new sign directionals now, but we still have all of the old pixel-shifted pre-fabrications lying around. So, I added an UpdatePaths (as well as Updated the Paths) to be a bit better at using directionals, because directionals are pretty neato.
This should update every single var_edit that used the proper 32 pixelshift (some of them used 28, and I'm unable to account for that automatically with current tooling) into a proper subtype. Mappers tend to learn by looking at well established maps, so it's always important to ensure that the well-established maps use the most recent tooling (i.e.: bring them up to the surface) and avoid needless excess lines in maps.
* The Commit With All The Maps
OH GOD OH FUCK
* Renames the UpdatePaths
Three main things I do:
Reinforce the remap that i have made with code changes, making the atmos control devices sane and easy to put if someone else stumbles upon this part of the code again. (a4aea1e - f16e620)
Splits the ordnance areas and renames them, kills ordnance misc and things that have nothing to do with ordnance (anymore?) moves them to exp_lab (useful stuff here) and aux_lab (fluff stuff here like laser range in delta or second circuit lab in tram). (0c99f9f- 3c82a88)
Adds a roundstart program disk containing nt frontier to the ordnance office table. Added a hint to file manager there too to help give players a nudge on how to publish papers. (fd747dc)
First one: Makes mapping these things not require varedit, nicer for other people that dont know how the atmos control stuffs works.
Second one: Misc lab has nothing to do with ordnance jesus christ. Also ord hallway is now irrelevant, our ordnance labs are very far from box now. Will probably make downstreams a bit angry for a while though since they might not be fully up to date on the ordnance maps.
Third one: Pretty much justified it in the about section.
Why is this not atomic: This touches all five maps and needs code backing, so I might as well combine them into one maintenance PR instead of giving my peers merge conflict three times.
* 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
So, for the last few days on production, Space Ruin generation has refused to work. Why is this? It's because in #67107 (cfc2330528), we repathed `/area/space` to `/area/misc/space` (lol i should have paid attention to that) without updating everything in code to match. I couldn't seem to get `/area/misc/space` to properly work somehow (this could have also been something I was doing wrong), but I worked it back to just making everything vanilla `/area/space` and all of those unwanted behaviors should be squashed out. Let's get the game working again.
I manually audited all 4,710 instances of airlocks across all maps for upper casing
You'll never guess what I found.
UPDATE: We now have a grep to check for mistitled airlocks, and it's in this PR!
Areas.dmi right now houses all of our mapped turfs icons (which is roughly 400 icons). Not an issue, but it's incredibly large and clunky to navigate right now. This isn't an issue for the average coder and/or player code diving, but it is for mappers wanting to add new turfs. Currently, the file has some organization, but its still an overall mess. This PR aims to slice the behemoth with multiple .dmi files corresponding to specific areas.
I also plan to repath /area/* -> /area/station/* for station turf only. This is to clean it up, as most other turfs follow this format (that being /area/turf_zone/*).
I'm also writing an update paths file as I go along.
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.
This PR rework the atmos turbine into a 3x1 multiblock machine.
The calculations are now done by simulating the flow of gases and expansion work that they do inside the turbine (heavily simplified), now a pressure differential between the inlet and outlet will heavily change the output of current that the machine is able to deliver.
The machine will not use stock parts for upgrades, but instead it will use 3 main components that are to be made by hand (except for the first tier that can be printed)
Those are compressor part, rotor part and stator part.
There are 4 tiers to them where the last one will use metallic hydrogen to be made, but will significantly increase the output and resistance of the machine.
-- Docs for the turbine:
A work based engine that “simulates” the flow of gas to calculate the energy produced by the moving gases.
These gases cool down while passing through due to the work done on the turbine blades and the expansion it get inside the machine
The new turbine
The machine will be expanded into a 1x3 multiblock machine that will accomodate 3 parts to it:
An input compressor
An output turbine
A core rotor
There are 3 other main component that are:
The Compressor Blade part
The Rotor Shaft part
The Stator Generator part
These three are the main (and only) upgrade path the machine can follow.
Parts
Input Compressor
It handles the input of gases inside the machine, it contains the Compressor Blade part.
This part moves the gas in, compresses it and increases its temperature by the amount of work the compression of the gas does.
Output Turbine
It handles the output of the gases outside the machine, it contains the Stator Generator part.
The gases moving through will expand 6x the initial volume and cools down before getting expelled.
Core rotor
Main part of the multiblock machine. It contains all the logic for building and processing the turbine.
Can be connected to a computer for control.
Contains the Rotor Shaft part.
Upgrades
The three installable parts can be upgraded with specific sheets to improve their efficiency and resistances. Each tier up will increase the max RPM reachable by the turbine and the max input temperature that the machine can take before starting to be damaged.
Each first tier part can be printed in any Lathe (proto/auto) but it requires hand crafting with different materials to be upgraded.
Compressor Blades can be upgraded with plasteel, titanium and metallic hydrogen.
Rotor Shaft can be upgraded with plasteel, titanium and metallic hydrogen.
Stator Generator can be upgraded with titanium, metallic hydrogen and zaukerite.
-- End docs
Fixes#50667 (Infinite power generation by piping turbine output into its input. This worked because there was no temperature threshold, and the cost of applying pressure via pumps was lower then the power generated -Lemon)
Better turbine in many aspects, preparation for SM rework
About The Pull Request
Hey there,
#65038 was quite good for newscasters, but since it merged bounty boards and newscasters in the same /obj/ and replaced all instances of either, you would end up with stuff like this:
Yes, those are all on the same direction. So, I manually reviewed every single newscaster appearance across all of our maps that have newscasters and ensured that the placement/duplication was sane. I also noticed that some maps had built stuff to account stuff for the old shape of the old newscasters, so that was rearranged as seen.
Why It's Good For The Game
image
Newscaster (singular) is good. Newscasters (plural) is iffy at best.
Also, some of the new newscasters were buried under posters. Who knows how long they've been under there. I've updated them to what I felt would make the most sense from a mapping standpoint.
Changelog
cl
fix: Nanotrasen realized how much they were spending on newscasters that got buried under posters and the like, so the corporation decided to stock the crew with juuuuust enough. They have saved a lot of money from this venture, and the economy will promptly begin to skyrocket to new heights.
/cl
This PR moves the in-game Newscaster over to TGUI, which is one the most bothersome html to tgui projects on the codebase being that it's gone untouched for like... over 4 years now after the introduction of tgui. Newscasters are widely used in-game by players wanting to be deranged whistleblowers, noir detectives, and journalists. They're flavorful, fun, and we still use an html window to make them run so it looks like it's from 2003.
* Four Corners, Red Rover: An Exploration in Decaled Trends
You there! What exactly is wrong with this photograph?!
You don't need to tell me, I've boxed it out. There's four individual corners for the decalling. This is weird. You may be asking: Why don't they use the "full tile" turf decals? Let me demonstrate.
Look at the difference between the one at left and the one in the middle. The turf decal totally smothers the nice contrast lines afforded to use by the base turf, causing it to have smooth, clammy exterior. This is probably why no mapper ever uses the full turf decal, much to the chagrin of people who stare at how big the size of this repo is.
Now, what's that on the right? Why, it's the new sprite (and pathing I made) to help counter-act this issue! This perfectly lines up with the contrast lines of the base turf, allowing us to have a non-flattened visualization, while not having four fucking turf decals a turf load upon initialization. How epic!
I've also added "contrasted" variants of the "half" and "anticorner" turf decals for future use. I probably won't go through and update this in this PR, but the opportunity remains available.
I may or not map this change across all the maps. We shall see.
* neutral corners
we love vsc
* no wait
i forgot a bunch of potential edgecases so we'll have to go back. yellow should be fine but neutral, dark, blue, and green should get a second look over
* recheck
found some stuff, probably missed out on others. let us commence forth
* MISTAKE
nearly a fucko bwoingo
* final pass
it compiles and i've had enough, someone else can probably figure it out from this point onwards
* #65230 goated my timbs
now we wait for linters to fail
* YOU DIDN'T SAY THAT THE FIRST TIME
LINTERS AAFAFAFF
* The Purge Of Non-Auto APCs
This PR removes all non-autonaming/varedited APCs found across our miscellaneous maps.
It's a lot better to use these than the varedited ones. We've also been seeing some weird CI stuff crop up lately, so this is a good step to make to rule out some potential causes of that.
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
## About The Pull Request
Fixes#61594#59556 changed atmos tanks so that they do not automatically connect to adjacent pipes, but can support up to 4 directional connection, and merge with neighboring tanks to form one large one. Old tanks would connect based on their dir variable. New tanks would not. A work around was to varedit both dir *and* initialize_direction variables to the same value in the map editor - but this is not expected behavior for mapping.
This adds a check for mapload in the tank's initialize proc. If the tank is initializing during mapload, dir will be copied to initialize_directions (as it is in most other atmos devices), and the tank will connect in the specified direction(s).
The behavior of player constructed tanks is unchanged.
## Why It's Good For The Game
The primary purpose of these large, constructed atmos tanks is to provide a bulk source of gas to a map, such as a plasma tank for the incinerator, or air supply tanks to ruins or disconnected parts of the station. This enables them to be readily used for their purpose.
This fixes the 41 broken atmospheric tanks currently mapped in the codebase.
First off, I am aware of the Feature Freeze for this month. This PR was initially started in #60401 about a month ago to break the changes into smaller PRs. The end result for this PR is a poor man's attempt at roguelike procedural generation. Enjoy!
Link to the README for how the new spawner system works.
Added the following new random mapping spawners:
pen, crayon, stamp, paper, pamphlet, briefcase, folder, wardrobe closet, wardrobe closet colored, backpack, narcotics, permabrig_weapon, permabrig_gear, prison, material, carpet, ornament, generic decoration, statue, showcase, paint, tool, tool_advanced, tool_rare, material_cheap, material, material_rare, toolbox, flashlight, canister, tank, vending_restock, atmospherics_portable, tracking_beacon, musical_instrument, gambling, coin, money_small, money, money_large, drugs, dice, cigarette_pack, cigarette, cigar, wallet_lighter, lighter, wallet_storage, deck, toy, toy_figure, booze, snack, condiment, cups, minor_healing, injector, surgery_tool, surgery_tool_advanced, surgery_tool_rare, firstaid_rare, firstaid, patient_stretcher, medical supplies, crate, crate_abandoned, girder, grille, lattice, spare_parts, table_or_rack, table, table_fancy, tank_holder, crate_empty, crate_loot, closet_private, closet_hallway, closet_empty, closet_maintencne, chair, chair_maintence, chair_flipped, chair_comfy, barricade, data_disk, graffiti, mopbucket, caution_sign, bucket, soap, box, bin, janitor_supplies, soup, salad, dinner
Removed deprecated wizard trap, vault, and armory spawners.
This PR kills off the transforming subtype of /obj/item/melee and replaces it with a component to handle the transforming behavior, /datum/component/transforming.
The transforming component handles updating the variables of an item when it's transformed. Things like force, sharpness, whetstone force bonus, and attack verbs. Similar to the two-handed component, but instead of transforming into a two-hander it remains a one handed weapon.
The "nemesis" behavior (dealing addition damage to certain factions) of the transforming subtype was moved to the cleaving saw only, since it was the only transforming item that used it. In the future, this can be made into a bespoke element/component as well.
The following weapons and items have been updated to use this component:
Energy Swords / Sabers / Bananium Energy Sword
Energy Circular Saw
Energy Dagger
Energy Axe
Toy Energy Sword
Holographic Energy Sword
Switchblade
Advanced Medical Tools (Laser scalpel, Mechanical Pinches, Searing Tool)
Advanced Engineering Tools (Hand Drill, Jaws of Life / Syndicate Jaws of Life)
Combat Wrench
Cleaving Saw
Telescopic Batons / Contractor Batons
Roasting Stick
Telescopic Riot Shield
Energy Shield / Bananium Energy Shield
This PR also touches up the code around the various above items.
Repaths everything referring to "toxins" while actually meaning either the room in science or plasma gas. While this PR might be disrespectful to our forefathers, given this is (I believe) a holdover from as far back as the Exadv1 days, this has constantly irked me since I started working with the code. None of the player-facing stuff has referred to plasma as toxin since before 4407 hit, besides the Toxins Lab, and yet all of the type-paths are still pointing at toxins, making it a nightmare to search for in a map editor, and making the code needlessly easy to confuse with that of toxin damage. So this just fires it into the sun.
Anything relating to Toxins, the science subdepartment, now makes reference to Ordnance instead. This felt fitting enough given the focus of the subdepartment is around the creation of and testing of explosives.
Anything relating to plasma gas has, fittingly, been made to refer to plasma gas.
Edit: Ah yes, I feel I should probably apologise off the bat for the size of this PR- the code touched is mostly atmos machinery and simplemobs, a few sprites here and there, and of course the station maps + a few offstation maps.
Makes the code more legible and makes mapping less painful.
(The payment has been made)
Stationary gas tanks have been in a terrible place for a long time, this addresses some of the issues with a more balance focused change coming in a second mapping pr after this one.
Stationary gas tanks have been made constructable and act similarly to canisters in that they can be damaged, repaired, and over-pressurized to explode. Additionally, they can be made with any rigid material and their stats depend on that material. A glass tank is going to have far less pressure capability than one made of plasteel.
In terms of gameplay there are two main differences now: Adjacent stationary tanks will merge together both graphically and with their internal storage. Any port on any of the tanks can access this shared storage. Also stationary tanks no longer magically have many times the volume for gas as the tile it's in, instead they have a pressure cap and a normal amount of volume.
Of interest to coders this pr also adds a generic grouping datum that acts similar to how pipe networks work. It maintains a listing of all adjacent objects whose type falls within a specified filter. In this case it's used for the gas tanks to know of every other tank in the group. I'll be looking into spreading it's usage elsewhere where this can replace existing one off systems.
Some (de)construction:
First a glass tank is constructed which is then immediately damaged by the high pressure in the gas storage that is now shared. After repairing it for a moment another metal tank is built.
Adds commission plaques- these commemorate the day a station was added to the game (adjusted for SS13 time) and the day it was removed (in the case of removed stations). If I got any of the dates wrong, please feel free to tell me.
They're added to every in rotation station, as well as the Derelict and Runtime Station.
Many thanks to Fikou for providing the git hashes for each commit to add/remove a station:
It's a neat nod to the maps' OOC history, as well as simply being some nice flavour.
How these new pipes work.
-Smart pipes autoconnect to nearby smart pipes
-They are now color coded, so they only connect to the same colored pipe, the GREY pipe is the wildcard and can connect to every other color, so be aware of this
-ALL components spawned by the RPD can be colored (from pumps to connectors, from pipes to manifolds), if you leave them GREY they can connect to every other color. Color adapters can be colored, but they'll still connect two pipes with different colors. BUILDABLE machines are GREY (thermomachines, cryo, HFR) so be aware of this
-Trying to go across another smart pipe will now build a bridge pipe automatically already colored of the color you choose, so you don't have to place it yourself anymore (is still available in the RPD tho)
-ALL binary components, layer manifolds, color adapters and bridge pipe can be put ONTOP of a smart pipe, but not on another of these. Smart pipes can't be placed on top of these pipes, so you have to build them first.
-Lcrossings can't be made anymore (sorry y'all i tryed, if someone have a way of doing them ping me on discord)
-REMEMBER you still have 5 layers to go, these rules apply to the same layer pipes, so if you do a crossing on different layers you won't see a bridge pipe appear.
Adds the High-performance liquid chromatography machine - a new roundstart method of detecting purity, as well as a method of partially purifying reagents.
A single machine has been added to each of the 4(5) maps - this lets people determine their purity based off the size of the green (pure portion) to the orange (impure portion) of a reagent's peak shown on the mas spectroscopy display. If a reagent is impure - it will be displayed as red.
In addition to this function, the HPLC can purify reagents by selecting a range of them and pressing the purify button. This will cost some time depending on the mass of the reagent and will purify it up it's default purity (in the tweaked reagent cases - 75%, for the reagents I've yet to get to - 100%). It will also reduce the volume accordingly (so in essence you are reducing the volume of the impure parts).
The sprite itself will indicate when it's running, so you don't need to be nearby it or use the UI to know when it's done
