## About The Pull Request
What it says on the tin. Cargo now has new math for market elasticity,
each parameter and what it does is explained below
**1. Refactor**
1. **k_elasticity**: This is the elasticity as before applied on all
exports except now this is a floating-point value that swings from
`0->1` instead of 10e-10 like is the current case. This in laymen terms
is the percentile of an items actual cost that is sold on cargo [0 means
you get no credits, 0.5 means you get 50% of the items cost, 1 means you
get 100% of the items cost]. Whenever an item is sold on cargo this
value decreases by an amount that is determined by the next variable
2. **k_hit_percentile(default 5%)**: This is the value by which an
export `k_elasticity` decreases whenever an export is successful for
every unit of an item sold. The real formulae by which the exports
elasticity decreases is dependent on the total amount sold and is as
follows
<pre>k_elasticity -= amount sold (1 for most cases except stacks) *
k_hit_percentile</pre>
So subsequent exports yield lesser profits cause the elasticity
decreases. Now the rate at which the elasticity recovers is as follows
3. **k_recovery_time(default 10 minutes)**: This is the time (minimum
unit should be seconds) it takes for the elasticity to rebound back to
100% after it has reached full 0 but recovery process starts immediately
if it decreases at any point. So if elasticity becomes say 50% it means
it would take 5 minutes to reach 100% again
**2. Some Balance changes**
1. Profits earned from exporting gas is linear per mole sold so the more
gas you put in the more profits you get HOWEVER the max number of
credits you can make per canister is 15000 cr
2. Selling fish yields higher prices because it's no longer subject to
the old elasticity formula
3. Selling 50 sheets of anything will decrease future sale price by 10%
and will take 8 minutes to rebound back to 100% if it reaches 0
**3. Improvements:**
- `SSProcessing` subsystem no longer processes more than 180+ export
datums from round start itself but now starts out empty. It instead
processes only those exports whose elasticity has been impacted and
later cancels it after elasticity has reached 100% so performance of
this subsystem has been drastically improved
- export datums now respect `abstract_type` meaning they won't be
created and can be used as a skeleton body for subtypes. So datums like
`datum/material` & `datum/material/market` are not created anymore but
only their subtypes are so we save processing power & memory
- Shaved of a lot of dead exports that went unused
## Changelog
🆑
balance: cargo exports now have different prices with applied elasticity
code: Improved performance of export code
qol: stock blocks can be recycled for materials & show up as stock
blocks in order console sold items
refactor: refactored cargo export code in whole. Report bugs on GitHub
/🆑
---------
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
## About The Pull Request
ports https://github.com/DaedalusDock/daedalusdock/pull/1144
ports https://github.com/DaedalusDock/daedalusdock/pull/1147
full credit to @Kapu1178 for the juice
instead of `reacher.CanReach(target)` we now do
`target.CanBeReachedBy(reacher)`, this allows us to give special
behavior to atoms which we want to reach, which is exactly what I need
for a feature I'm working on.
## Why It's Good For The Game
allows us to be more flexible with reachability
## Changelog
🆑
refactor: refactored how reaching items works, report any oddities with
being unable to reach something you should be able to!
/🆑
## About The Pull Request
This PR makes the following changes to code relevant to shuttle
construction.
- (Un)welding shuttle engines now only checks if the tool has 1 fuel,
which is how much is already used in the process.
- Constructed shuttle engines that were built from anchored machine
frames start in the wrenched but unwelded state.
- Fixes a runtime that occurs when expanding shuttles.
- Fixes the incorrect logic in the shuttle blueprint UI responsible for
#92986.
- Makes several changes to the wording of several functions of the
shuttle blueprint UI in the hopes of better conveying what each button
does.
## Why It's Good For The Game
Fixes#92986, as well as some other issues I may not have found in my
brief search.
## Changelog
🆑
fix: You no longer need 40 welding fuel to start welding or unwelding
shuttle engines, despite only consuming 1.
fix: Shuttle engines constructed from anchored machine frames start in
the wrenched-but-unwelded state.
fix: Expanding custom shuttles from shuttle frames is once again
possible without href exploitation.
fix: Shuttle expansion now correctly checks for other shuttle docking
ports the expanded shuttle's footprint would encroach upon.
qol: Tries to make some of the buttons in the custom shuttle UI more
indicative of what they actually do.
/🆑
## About The Pull Request
Fixes#92188
1. The Accounting console now has a new UI
<img width="757" height="486" alt="image"
src="https://github.com/user-attachments/assets/0c6ce73f-ae1c-4a54-b6ba-bcc3b3232d13"
/>
2. The Accounting console can now dish out advances on paychecks, giving
you for full paycheck early. You can give up to 3 advances. This of
course means your next paycheck is not paid out when relevant.
3. The Accounting console can now change paycheck sizes of crewmembers -
up to 1.5x and down to 0.5x.
## Why It's Good For The Game
- Gives the HoP some more duties, now being able to dish out money on
request, reward good behavior, or punish bad behavior.
## Changelog
🆑 Melbert
add: Accounting Console: New UI!
add: Accounting Console: Now can give advances to crewmembers
add: Accounting Console: Can now give pay raises or pay cuts
add: Accounting Console: Now only printable in the security lathe
add: Accounting Console: A spare board is now now found in secure tech
storage.
fix: Fix vending machines adding payments to audit log twice.
fix: Non-crewmembers are no longer shown in the accounting console
/🆑
---------
Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com>
## About The Pull Request
Converts as many time vars expressed in deciseconds as I could find to
use time defines.
## Why It's Good For The Game
Makes these values neater and more readable.
## Changelog
🆑
code: Converted a lot of time-based variables to be expressed with time
defines.
/🆑
## About The Pull Request
This adds a `data` argument to the record_feedback used in the cargo
shuttle's `buy()` proc, so that when we parse the data on superset, we
have an additional field to filter by to better represent how some of
these personal orders are being compared against each other.
## Why It's Good For The Game
Namely, I've been trying to get my data together again to start writing
some design docs and get to fixing some issues again, and something's
been bothering me about how the superset data was being collected on
cargo crate purchases, so I've added an extra field to be able to better
sort between the collected data and better represent the different
methods of personal orders available via cargo, so we can make better
decisions about the collected data.
## Changelog
No player facing changes.
## About The Pull Request
- Fixes#82910
Cargo now adjusts the material market quantity & prices when the shuttle
is called from the order console itself instead of adjusting it after
the shuttle arrives 1 minute later. This has 2 implications
- If the market crashes 1 minute after calling the shuttle i.e when it
arrives, the ordered quantities are not affected because it retrieved
those sheets from the market at the time of calling the shuttle from the
order console
- If some orders could not be satisfied because there were not enough
materials at the time of calling the shuttle then instead of arriving
with an empty crate a detailed summary is displayed explaining which
orders could not be delivered & why, even cancelling the order if needed
**a) Order adjusted**
**b) Order adjusted & cancelled**
**c) Order fully cancelled**
## Changelog
🆑
fix: ordering materials from the GMM won't result in empty crates & will
display detailed feedback if there weren't enough sheets in the market
/🆑
## About The Pull Request
**1. Makes the machine creation process from both efficient.**
The machine frame no longer creates & deletes the machines old component
parts before moving in the new parts. It instead now passes its parts
directly to the circuit boards `apply_default_parts()` meaning the old
parts are never created and the new ones get applied directly. This also
mean it does not have to again call `RefreshParts()` as the machines
`Initialize()` proc will do that for us by default so the performance is
just faster now.
Flatpack box also benefits from this and it will need it as stated below
- Fixes#86514. As the circuit board is passed to the machine's
`Initialize()` proc during reconstruction so it sets it's
`all_products_free` from the board both during mapload & when player
constructed from either machine frame & flatpack
**2. Flatpack enhancements**
- The flatpack box now passes its stored circuit board into the machine
meaning any changes made like with a screw driver or such are preserved
in the newly created machine rather than the board getting deleted & the
machine creating the default board
- Flatpacker now accept custom component parts that replaces its stored
circuit board default parts. This implements
https://github.com/tgstation/tgstation/pull/91670#issuecomment-2977259973
meaning instead of the vendor created from the flatpacker starting out
empty it now accepts the refill canister and will package both of them
together. Then during deployment that stored canister is stored back in
the vendor meaning instead of starting out empty you get to carry over
all your previous stock
Depends on https://github.com/tgstation/tgstation/pull/91512 because of
named arg conflict. Keep this drafted till that gets merged
## Changelog
🆑
qol: flatpacker now accepts custom component parts(like vendor refill
canister) along with the circuit board so you can carry over your
previous stock during deployment rather than starting out empty
fix: flatpack boxes now passes its stored circuit board into the machine
thus preserving its properties instead of creating a default board in
the machine
fix: vending machines reconstructed on station from circuits loaded off
station(having free products) will continue to sell free products
code: machine construction via flatpacker/machine frame is faster
performance wise
/🆑
## About The Pull Request
Adds a remote which can be printed with sufficient research, or
auto-linked by mapping the remote ontop of a nav console. Once linked it
can send off or call the shuttle towards a home and away destination.
These destinations can be changed with alt+rmb.
## Why It's Good For The Game
Let people send and call their shuttle without being at the nav
computer. Really useful for antags that arrive on a shuttle, so their
shuttle can be safe in deepspace while they fuck about onstation.
(Should pirates have this?)
## Changelog
🆑 theOOZ, kittysmooch
add: Adds the shuttle remote item unlocked with shuttle engineering
research, it lets you remote control the whiteship or custom shuttles.
/🆑
## About The Pull Request
1. Mail is now shipped every 2 SSeconomy ticks, rather than every
SSeconomy ticks. The amount of mail per round will not change.
2. Mail is not shipped during Red or Delta alert. Mail will still
continue to pile up for if the station returns to blue alert.
## Why It's Good For The Game
1. The time between cargo shipments is like five minutes. This means you
get mail practically every cargo shipment, if only a few pieces. I think
it's a bit spammy, so doubling time between shipments means you actually
get substantial shipments of mail and you don't have to pay attention to
mail constantly.
2. In the event of an emergency and the cargo shuttle has to fly back
and forth for emergency supplies (like guns for a blob), being blocked
because of mail is annoying. It's also reasonable from an in character
perspective that they would hold your mail until the emergency is
resolved.
## Changelog
🆑 Melbert
qol: Mail is now shipped every 10 minutes rather than every 5 minutes.
The amount of mail remains unchanged (so you get 1 crate with 6 mail
instead of 2 crates with 3 mail each).
qol: Mail is no longer shipped while the station is on red alert - mail
held will be sent if the station returns to blue alert.
/🆑
## About The Pull Request
Flatpacks pass an arg into ``on_construction`` which makes vendors wipe
their inventory to prevent duping by repeatedly flatpacking a vendor to
refill its inventory.
Closes#91615
## Changelog
🆑
fix: Flatpacked vendors start empty to prevent duping
/🆑
## About The Pull Request
Removes some redundant var definitions from the custom shuttle flight
console.
Also defines the circuit var for custom shuttle flight consoles,
allowing maploaded/adminspawned instances of them to be disassembled.
## Why It's Good For The Game
Cutting down on redundant definitions is generally a good thing.
Also makes maploaded/adminspawned shuttle consoles work like the
constructed ones.
## Changelog
Redundant definition removal isn't a player-facing change.
🆑
fix: If you find a custom shuttle flight control console that was
created by an admin or loaded as part of the map, you can dismantle it
with a screwdriver.
/🆑
## About The Pull Request
This PR adds four small fixes:
- Custom shuttle docking consoles no longer runtime at the world border
- Custom shuttle docking consoles are no longer blocked by where the
linked shuttle currently is
- Shuttle blueprints don't runtime and bluescreen while on whiteships
- Custom shuttles don't cause a divide-by-zero runtime when installing
engines for the first time (and are calculated correctly)
And one major QOL tweak:
- Shuttle frames are now datums which can track their own size, as well
as track which custom shuttles are adjacent to them. This allows shuttle
blueprints to display the size of the shuttle that will be built or
expanded, as well as much more performantly report issues that would
prevent shuttle construction or expansion.
## Why It's Good For The Game
I've been informed of several issues and nice-to-haves regarding custom
shuttles, and caught several other issues in the process of implementing
the requested changes.
## Changelog
🆑
fix: Shuttle blueprints don't error out when opening them while on
non-custom shuttles.
fix: Custom shuttles calculate their engine count correctly, no longer
lagging behind by one engine (un)installation.
fix: Custom shuttle docking consoles are no longer blocked by where the
linked shuttle currently is.
qol: Shuttle blueprints now show you how large a shuttle frame is, along
with any issues preventing you from building or expanding a shuttle
using said frame.
/🆑
## About The Pull Request
People can now pet held mothroaches and pugs if they want to, or use
items on them, hopefully without causing many issues. After all, it only
took about a couple dozen lines of code to make...
...Oh, did the 527 files changed or the 850~ lines added/removed perhaps
catch your eye? Made you wonder if I accidentally pushed the wrong
branch? or skewed something up big time? Well, nuh uh. I just happen to
be fed up with the melee attack chain still using stringized params
instead of an array/list. It was frankly revolting to see how I'd have
had to otherwise call `list2params` for what I'm trying to accomplish
here, and make this PR another tessera to the immense stupidity of our
attack chain procs calling `params2list` over and over and over instead
of just using that one call instance from `ClickOn` as an argument. It's
2025, honey, wake up!
I also tried to replace some of those single letter vars/args but there
are just way too many of them.
## Why It's Good For The Game
Improving old code. And I want to be able to pet mobroaches while
holding them too.
## Changelog
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
## About The Pull Request
Continuation of #90365
- Formatted some usages of `set_holdable()` to be more readable
- `exception_hold` list now stores its values inside `
GLOB.cached_storage_typecaches`. This means we don't have to manage a
static typecache list per storage but can share the value across all
storages making memory management slightly more efficient
- Monkey cube boxes now cannot hold gorilla cubes cause that would make
gorilla cube boxes obsolete also now gorilla cube boxes can now only
hold gorilla cubes & not general monkey cubes(which gorilla cubes is a
subtype of) cause that would make monkey cube boxes obsolete. We are
specializing each box for that specific use case
## Changelog
🆑
code: further improved storage code
fix: monkey cube boxes can no longer hold gorilla cubes & vice versa
/🆑
## About The Pull Request
Reverts the storage initialization refactor and all subsequent related
PRs.
The original PR is below our standards both for code quality and
testing, and is majorly flawed at its core. This has been discussed with
other maintainers and headcoder(s?) over on discord. A lot of changes
from the PR could be brought over later, but in its current state it
should not have been merged.
- Closes#90322
- Closes#90313
- Closes#90315
- Closes#90320
- Closes#90312
- Closes#90344
## Why It's Good For The Game
This PR causes a series of major issues which cannot be resolved without
either completely rewriting a lot of the original PR, or bad code.
Not matching our standards is grounds for not merging a PR, and the fact
that a PR should not have been merged is a reason for a revert.
## Changelog
🆑
fix: Fixed a series of storage-related bugs caused by a refactor PR.
/🆑
## About The Pull Request
A Huge chunk of changes just comes from moving existing storage code
into new files & seperating `atom_storage` code into its own subtype
under the already existing `storage/subtypes` folder.
With that the changes in this PR can be organized into 3 categories.
**1. Refactors how `/obj/item/storage/PopulateContents()` initializes
storages**
- Fixes#88747 and every other storage item that has a similar variant
of this problem
The problem with `PopulateContents()` is that it allows you to create
atoms directly inside the storage via `new(src)` thus bypassing all the
access restrictions enforced by `/datum/storage/can_insert()` resulting
in storages holding stuff they shouldn't be able to hold.
Now how this proc works has been changed. It must now only return a list
of items(each item in the list can either be a typepath or a solid atom
or a mix of them in any order) that should be inserted into the storage.
Each item is then passed into `can_insert()` to check if it can fit in
the storage.
If your list contains solid atoms they must be first moved
to/Initialized in nullspace so `can_insert()` won't count it as already
inserted. `can_insert()` has now also been refactored to throw stack
traces but explaining exactly why the item could not fit in the storage
thus giving you more debugging details to fix your stuff.
A large majority of changes is refactoring `PopulateContents()` to
return a list instead of simply creating the item in place so simple 1
line changes & with that we have fixed all broken storages(medical
toolbox. electrical toolbox, cruisader armor boxes & many more) that
hold more items they can handle
**2. Organizes initialization of `atom_storage` for storage subtypes.**
All subtypes of `/obj/item/storage` should(not enforced) create their
own `/datum/storage/` subtype under the folder `storage/subtypes` if the
default values are not sufficient. This is the 2nd change done across
all existing storages
Not only does this bring code cleanliness & organization (separating
storage code from item code like how `/datum/wire` code is separated
into its own sub folder) but it also makes storage initialization
slightly faster (because you are not modifying default values after
`atom_storage` is initialized but you are directly setting the default
value in place).
You now cannot & should not modify `atom_storage` values inside
`PopulateContents()`. This will make that proc as pure as possible so
less side effects. Of course this principle is not enforced and you can
still modify the storage value after `Initialize()` but this should not
be encouraged in the future
**3. Adds support for automatic storage computations**
Most people don't understand how `atom_storage` values work. The comment
here clearly states that
55bbfef0da/code/game/objects/items/storage/toolbox.dm (L327-L329)
Because of that the linked issue occurs not just for medical toolbox but
for a lot of other items as well.
Which is why if you do not know what you doing, `PopulateContents()` now
comes with a new storage parameter i.e. `/datum/storage_config`
This datum allows you to compute storage values that will perfectly fit
with the initial contents of your storage. It allows you to do stuff
like computing `max_slots`, `max_item_weight`, `max_total_weight` etc
based on your storage initial contents so that all the contents can fit
perfectly leaving no space for excess.
## Changelog
🆑
fix: storages are no longer initialized with items that can't be put
back in after taking them out
refactor: storage initialization has been refactored. Please report bugs
on github
/🆑
## About The Pull Request
This PR adds some tweaks to make custom shuttles a bit easier to use,
and more useful.
- The station blueprints can be used to allow/forbid custom shuttle
docking in station/custom areas. Custom areas allow shuttle docking by
default, while station areas (apart from the asteroid) forbid it.
- A station area that allows shuttle docking can have a shuttle
built/expanded in it, as long as the area's APC isn't contained within
the frame used to construct/expand the shuttle.
- A shuttle frame does not need to contain the entirety of a custom
area, unless that frame contains the area's APC. If the frame doesn't
contain the entirety of the custom area, that section of the frame
becomes part of the default area, instead of a separate area.
- Custom shuttles will go off into the sunset at the end of the round,
as long as they have a welded engine.
- I think I saw a bug that caused engines to contribute twice the
intended power to the attached shuttle, possibly creating an exploit in
the case where the engine was broken while welded. I fixed that.
- Custom shuttle docking computers can cross over to any z-level
adjacent to the shuttle's z-level (or vertically-connected z-levels,
because docking computers can traverse stacked z-levels freely). This is
based on the new `zlink_range` var on all shuttle docking consoles,
which can be var-edited to provide the same functionality.
- Shuttle engines constructed from circuits now link to shuttles without
needing to be unanchored and reanchored.
## Why It's Good For The Game
The tweaks to shuttle construction and docking serve to address several
gripes I heard about players not being able to build/dock custom
shuttles in station areas. The means to do this have been locked behind
possession of the station blueprints.
I don't see what problem there would be with allowing custom shuttles to
leave the station at the end of the round, but I could lock it behind a
particular action (antag-exclusive or otherwise).
Custom shuttles don't quite have as much utility if you have to manually
travel to z-levels to drop off gigabeacons. Jumping to adjacent z-levels
one at a time is a bit more useful for space exploration.
## Changelog
🆑
add: The station blueprints can be used to toggle whether custom
shuttles can be built/expanded/docked within station areas.
qol: Custom areas do not have to be completely contained within shuttle
frames, as long as the APC isn't attached to the frame.
add: Custom shuttles with functioning engines will fly off into the
sunset when the emergency shuttle leaves.
add: Custom shuttle navigation computers can view space levels adjacent
to the one the shuttle is currently docked at.
fix: Constructed shuttle engines no longer contribute twice as much
engine power to shuttles, nor can they be used to add unlimited shuttle
power.
fix: Constructed shuttle engines now connect to shuttles when build,
rather than needing to be unachored and then reanchored.
/🆑
## About The Pull Request
This incredibly detailed PR adds the ability to construct custom
shuttles, which function similarly to whiteships.
To construct a custom shuttle, you need the following items:
- Shuttle frame rods
These rods can be hand-crafted by using 5 rods on 1 sheet of titanium,
or printed at a sci/engi/cargo lathe after researching the Shuttle
Engineering techweb node.
Lattices built with these rods, and catwalks/floors built on top of
these lattices, are valid for shuttle construction.
- Shuttle engines
Did you know shuttle engines have boards that weren't normally
obtainable? Well the board for one specific engine type is now available
from the sci/engi/cargo lathe after researching Shuttle Engineering. Of
course, the old options remain. You can steal engines from other
shuttles, including escape pods (it's not like engines are strictly
necessary for *those* shuttles anyways). Alternatively, the shuttle
engine supply pack is no longer locked behind the purchase of the BYOS.
- Flight Control & Navigation Console boards
These boards are printed at the sci/engi/cargo lathe after researching
the Shuttle Engineering techweb node.
If built on a custom shuttle, it will automatically link to it, unless
the shuttle already has such a console.
If built on a turf that is valid for custom shuttle construction, it
will automatically link to any shuttle constructed from or expanded with
that turf.
- Shuttle blueprints
Standard shuttle blueprints can be printed at the sci/engi/cargo lathe
after researching the Shuttle Engineering techweb node.
A cyborg upgrade granting access to a shuttle blueprint database can be
printed at the exofab after researching the aforementioned node.
Crude shuttle blueprints can be crafted by hand with a sheet of paper
and either a rainbow crayon or 10 uses of a blue crayon or spraycan.
If Science won't research the tech, you can also buy a goody pack
containing a flight control board, a docker board, two engine boards,
and a set of shuttle blueprints for 1200 credits, if you have aux base
access.
A shuttle can be constructed atop any continuous region of turfs
containing a shuttle rod lattice or a catwalk/tile built upon such.
Currently, this region cannot intersect any area other than space,
lavaland, the icemoon, or the station asteroid. Preexisting custom areas
can be included in the construction of the shuttle, but only if every
turf in the custom area is valid for shuttle construction.
In the shuttle blueprint UI, you can toggle a visualizer to display
which turfs fulfill all of the aforementioned conditions.
The following video goes through the basic process of shuttle
construction.
https://github.com/user-attachments/assets/3283422e-a201-4978-972d-67527b5df4ee
The blueprint used to construct the shuttle will be its master
blueprint. The master blueprint can be copied to other blank shuttle
blueprints (or to engiborgs with the shuttle database upgrade), and
allows the holder to perform a christening ritual on the shuttle to
rename it.
If a shuttle's master blueprint ceases to exist, a blank blueprint can
be linked to the shuttle to become the new master blueprint, or an
existing blueprint associated with that shuttle can be promoted to the
master blueprint.
Once constructed, the following options are available from the blueprint
UI to modify it:
- Create Area
Convert a continuous open area of the shuttle into a new area with the
name written in the above text input. This operates very similarly to
regular area construction.
- Rename Area
Change the name of the area you're currently in to the name written in
the above text input.
- Expand Area
Add a continuous open area of the shuttle to the neighboring area
selected from the dropdown to the left. This operates like regular area
expansion.
- Expand Shuttle
Expand a shuttle with valid frame turfs as defined above. These turfs
must be physically connected to the shuttle.
- Remove Area
Remove an area, giving its tiles to the default shuttle area.
- Cleanup Empty Space (implemented after the above video was recorded)
Removes all completely empty turfs from the shuttle. If all the turfs in
one of the shuttle's areas were removed, that area is deleted. If
absolutely no turfs of the shuttle remain, the shuttle itself is
deleted. Due to the ability for this action to delete the shuttle, only
the master blueprint can do it.
As mentioned above, the shuttle's master blueprint can be used to
christen its associated shuttle. To do this, fill a glass drink bottle
with some amount of reagents, then hit it against one of the shuttle's
walls from outside while holding the master blueprint. You will be
prompted to enter a new name for the shuttle. The variety of things that
can happen while inputting a new name can cause the christening rite to
fail in one of several humorous ways.
### Optional (Unless specifically requested by a maintainer) Todo's
- [x] A way for shuttle circuits to be obtainable without techweb nodes
- [x] A more convenient way to carry around shuttle engines or the means
to deploy them
- [ ] A shuttle construction guide available as a reference book
- [ ] Allow boards to be linked to shuttles before construction so they
can be used outside the shuttle
## Why It's Good For The Game
Shuttles have been part of the sandbox for an incredibly long time, but
their limited accessibility has rendered them the exclusive territory of
lucky space explorers or the few antagonists who get one off the bat
(nukies and pirates). Giving players the means to construct shuttles to
their liking opens up a variety of possibilities for gimmicks for antags
and non-antags alike.
Besides the applications for antaggery and crew-sided gimmicks, this
provides side content for several departments to engage with during the
relatively-frequent periods of time where they have little else to do as
part of their intended roles.
With respect to engineering, if the station isn't actively being
damaged, the supermatter is in perfect working order, and nobody is
clamoring for machine upgrades, engineers have little else to resort to
other than construction projects. While the BSA station goal provides an
incentive for engineers to construct dedicated rooms for the cannon, it
will not necessarily be available every round. Custom shuttles not only
provide such a construction project to pursue, but provide the rare
opportunity, as well as a very good reason, to set up an independent
power network, complete with its own power source.
While atmos techs have a lot to do with gas mixing and the crystallizer,
they rarely get the opportunity to set up working life support systems
outside of repairing the ones that get blown up. Custom shuttles will
frequently start with no air, and unless the design settled upon is an
open floor plan, it will have several independent chambers that cannot
so easily be profused with a proper airmix by just opening a canister.
Furthermore, if the air in a custom shuttle gets messed up, a proper
scrubber and distro network is a significantly less tedious method of
rectifying the problem than cleaning the air manually with portable
scrubbers and pumps.
Scientists, it can be argued, with their access to RPDs through
ordnance, have similar opportunities to atmos techs, even though the act
in and of itself is not exactly part of their duties. But compared to
the other job content they could be working with after they've completed
most of their gameplay loop, custom shuttle construction is a
substantially more active endeavor. And I know how much people complain
about late-game science content just being sitting around at a console
and making gamer gear. Roboticists can have a part to play in this too.
They can put their mech RCDs to a use other than 2D topdown Fortnite,
and with the shuttle database upgrade, they can help interested cyborgs
get in on the action.
Cargo is yet another department known for having significant amounts of
downtime during a considerable number of rounds. If every other
department has gone through their initial rounds of departmental orders,
and there isn't an active need for cargo to order lots of one thing or
another, cargo techs have little to do besides mail (at least on the
days where there **is** mail to deliver). Usually, if cargo techs do, in
fact, do something as a department when not presented with more pressing
duties, they order guns and other contraband. As funny as this is,
there's not a lot of variety in how this behavior manifests. With custom
shuttles, cargo can use their free time to plan, and execute, a unique
collective expression of design sensibilities, not limited by the size
and shape constraints of the cargo bay itself.
## Changelog
🆑 Y0SH1_M4S73R (with special thanks to Vect0r, whose original PR
inspired the implementation of these changes)
add: Shuttle blueprints, the tool used to construct and modify custom
shuttles. Print a set at a science, engineering, or cargo techfab after
researching Shuttle Engineering, or craft a crude set from the crafting
menu.
add: Shuttle blueprint database upgrade for engineering cyborgs,
printable from the Exosuit Fabricator after researching Shuttle
Engineering. A version of shuttle blueprints designed for use by
cyborgs.
add: Shuttle frame rods, usable to construct custom shuttles. Hand-craft
by using 5 rods on 1 titanium sheet, or by printing them at a science,
engineering, or cargo techfab after researching Shuttle Engineering.
add: Custom shuttle flight control and navigation boards, printable from
a science, engineering, or cargo techfab after researching Shuttle
Engineering.
add: Shuttle engine boards can be printed from a science, engineering,
or cargo techfab after researching shuttle engineering.
add: The shuttle engine supply pack is no longer locked behind the
purchase of the Build Your Own Shuttle kit.
add: Shuttle Construction Starter Kit goodie pack, containing a set of
shuttle blueprints, flight control and navigation console boards, and
two engine boards, can be purchased from cargo for 1200 credits.
Requires aux base access to purchase.
refactor: Shuttles now keep track of what areas are underneath each of
their individual turfs, so that the areas left behind on movement are
consistent with what they were beforehand.
refactor: Shuttle ceilings now place themselves down as baseturfs,
instead of only appearing if the turf above is open space.
/🆑
---------
Co-authored-by: vect0r <71346830+Vect0r2@users.noreply.github.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
## About The Pull Request
#87102 introduced a new clothing dirt component, which increases tint
when you get spraypainted. This PR expands it to work when you are
spraypainted and applies it to space helmets, gas masks and rad/bomb/bio
helmets, and gives all items a fancy overlay when
spraypainted/peppersprayed.
Spraypainting a person wearing an item with this component randomly
applies 2-3 levels of tint, potentially blinding them until they wash
their helmet or mask.
Additionally, driscoll mask has lost its eye covering, and welding gas
mask gained it - doesn't make sense for former to have it, and for
latter to be missing it.
## Why It's Good For The Game
Bomb suits and bio hoods are already extremely weak, while rad suits are
super situational when there are MODsuits with none of the downsides. 90
degree FOV is extremely punishing and makes them essentially unusable.
Space helmet slowdown was added because they gave pepperspray protection
with no downside, which this PR brings, so there's no reason to keep it
around considering how bad slowdown feels in our game.
Also spraypainting someone's visor is just extremely funny to me.
## Changelog
🆑
balance: Space helmets and bio/bomb/rad hoods have lost their
slowdown/FOV respectively, but now can have their visor covered by
spraypaint or pepper spray.
balance: Driscoll mask no longer protects your eyes, unlike welding gas
mask which received said protection.
/🆑
## About The Pull Request
I standardized stuff in AASs code, and all current reference to it. Also
added interactions for bounty cubes, weather reports and request
consoles, all of it can be changed from AASs UI.
Also it's easier now to add new config entries for AAS to proceed, and
it's now downstream friendly.
## Why It's Good For The Game
Well, because kind of order in code and because it's funny to make
custom messages for... Almost everything?
BTW any entry can be blocked from ingame changes, by default you can't
change Broken Arrival shuttle and Security Officer arrival
announcements, how it was before. But may be we should allow it - it's
an open question.
## Changelog
🆑
add: Many things now handles via AAS: Bounty Cubes, Request Consoles,
Brig Cells, Vending Machines and Orion Trails alerts, Weather Reports,
Cargo Order Console
code: Now anyone can make their own entry for AAS
refactor: AAS internals, also cleanup
/🆑
## About The Pull Request
refer to title
No code changes were made here, i just copypasted code around
The only real difference is that I removed a pretty useless define that
depended on TESTING because it got in my way of splitting emergency.dm
tbh i didnt want a 50k line refactor pr that nobody is going to review
so im getting it out of the way in a separate PR
## Why It's Good For The Game
Shuttle code is literally all over the place please help me oh gosh
## Changelog
Nothing player facing or developer facing (at least I really hope so)
