## About The Pull Request
Upon getting stabbed in your eyes or having a bullet fly through your
head there's a chance (minor for stabbing, extremely low for headshots)
you'll receive a new "Eye Puncture" wound which causes profuse bleeding
out of your now-empty eye hole. Once healed you'll have to deal with a
scar on your eye which cannot be cured and requires surgical
replacement. Eye scarring will reduce your eyes' max health by 15, give
you a minor screen tint and a fancy visual on your character sprite.
Getting scarring on both eyes will turn you completely blind.
This PR also introduces a new quirk which gives you eye scarring on the
eye of your choice and an eyepatch to go alongside it, just make sure
that it sits on the right eye.
Also added medical(white) subtype of eyepatches to loadout for those who
want that version instead. Credits to AnturK on discord for the idea.
## Why It's Good For The Game
Its a neat lil' feature that makes the game more immersive, and unlocks
more roleplay opportunities for players. New quirk gives access to this
feature for players who want to make it a part of their character's
backstory (or maybe as a part of permanent scar roleplaying).
## Changelog
🆑
add: Getting stabbed or shot in the eyes has a chance of giving you a
new wound and a semi-permanent scar, blinding you on one side
add: Added new "Scarred Eye" quirk which blinds you on one eye but gives
you a fancy eyepatch
add: Medical eyepatches have been added to loadout
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
# Conflicts:
# code/_globalvars/traits/_traits.dm
# code/_globalvars/traits/admin_tooling.dm
# code/modules/surgery/organs/internal/eyes/_eyes.dm
## About The Pull Request
movement subsystem now has the SS_BACKGROUND flag removed
excuse me if this isnt any correct like i know daedalus did this for
some reason at best
## Why It's Good For The Game
(stuff controlled by) movement ss is not actually THAT costly (compared
to Throwing)
(when i nuked metastation on local)
and i think being able to move when you slip on oil or whatever eg
jetpacks during lotsa lag is pretty important
this does not actually make it immune to lag it just seems to mitigate
the issue by a slight margin
## Changelog
🆑
code: Movement Subsystem no longer is a background subsystem. This means
that you should no longer get stuck after slipping on oil during
instances of high usage.
/🆑
## About The Pull Request
Turns out that if you don't test if you fix works, it probably won't!
I've actually managed to test this one, and even though it gave me a
handshake error when joining the other server, at least the fade in
worked! The fadeout is set up in the same way, so it should be fine
## Why It's Good For The Game
ACTUALLY fixes#29496
## Changelog
🆑
fix: ACTUALLY fixes server hop fade in
/🆑
## About The Pull Request
closes#2486
Introduced a signal for when a bank account receives a paycheck,
allowing future paycheck related quirks and features to be improved.
Untied two variables related to the life savings quirk from bank
accounts and moved them to the quirk, saving small amounts of memory
usage.
Made life savings quirk actually pay you out, adding money without
robbing the departmental account.
## Why It's Good For The Game
Code runs better and nicer, quirks work as they should
## Proof Of Testing
<details>
<summary>Screenshots/Videos</summary>
</details>
## Changelog
🆑
fix: fixed rations permanently setting your income to 0.5 instead of
decreasing the modifier
fix: fixed life savings quirk not doing anything
code: Improved the way paycheck bound quirks handle their code, making
it run faster
/🆑
---------
Co-authored-by: Cyprex <35031555+Cyprex@users.noreply.github.com>
## About The Pull Request
Forgot to check if I could make it modular before making pull request,
it can be. Updating a previous PR to be modular where it makes sense.
Some files are left as commented edits where it makes more sense to do
so.
## Why It's Good For The Game
Better follows contribution guidelines.
## Proof Of Testing
Functions the same way/no changes in how it runs, just how code is
structured.
## About The Pull Request
Removes all fragments of veteran code from the game.
## Why It's Good For The Game
It should help maintainers when doing upstream syncs as it removes some
non-modular code. Also we have no use for the veteran system.
## Proof Of Testing
It compiled and ran.
## Changelog
Nothing player facing.
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
## About The Pull Request
Adds the Fundamentally Evil quirk. The quirk does nothing in of itself.
If an Empath examines you, they will be shaken up by the fact that you
are totally evil.
Mindreaders can literally see that you're evil. If they're ALSO evil, it
gives a gives a unique message.
Honorbound chaplains can freely attack you without first declaring you
evil. You are already evil. There is no outward tells for this fact, but
if the chaplain pays attention to the medical records, you might have a
problem on your hands.
You are significantly harmed by holy water and holy explosions. So don't
drink holy water if you can help it.
## Why It's Good For The Game
I just think it'd be funny to have some crew, for whatever reason, be
fully committed to being evil for no reason other than it is funny to
bother empaths.
I want a chaplain to come to the realization that I'm evil and see what
happens.
## Changelog
🆑
add: Fundamentally Evil quirk. You might act normal, but you know deep
down that you totally don't give a shit about anyone but yourself.
Empaths better watch out.
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
Co-authored-by: ATH1909 <42606352+ATH1909@users.noreply.github.com>
# Conflicts:
# code/controllers/subsystem/processing/quirks.dm
## About The Pull Request
Add `?` operator to `alt_job_titles` accesses
## Why It's Good For The Game
Fixes#2209
## Proof Of Testing
Spawned in as a guest with my proper equipment and title.
<details>
<summary>Screenshots/Videos</summary>
</details>
## Changelog
Nothing relevant to players
## About The Pull Request
I'm "cooking" the materials system a bit, specifically the code
responsible for applying and removing effects. My goal is to move most
of the code to the objects-side, split it in smaller procs that can be
more easily overriden or called for object-specific modifiers and
effects, while also revamping things all around to better support items
made from multiple materials (the cleric mace will most likely be one in
this PR, with the handle and tip made of different materials).
PR NO LONGER WIP, TESTED AND ALL, CLERIC MACES CAN NOW BE MADE OF TWO
MATERIALS.
## Why It's Good For The Game
One of the nastiest flaws with the materials system is that it's just
unfeasable to have items made of multiple mats (with effects enabled)
right now, as they easily tend to override each other, where some of the
modifiers and effects should only be applied the main material.
Beside, the system's starting to show signs of its time, from the
several type checks used to apply different effects, the one letter
variables to the the material flags that are still being passed down as
arguments when you can access them from the atom/source arg anyway. It
would be disonhest of me if I went ahead and coded material fishing rods
or whatever fish fuckery with materials without ensuring it won't
further the technical debt the feature currently has.
## Changelog
🆑
refactor: Refactored materials code. report any issue.
add: Cleric maces (The autolathe-printable weapon design from outer
space) can now be made of two different materials.
balance: Buffed cleric maces a little.
fix: toolboxes' stats are now affected by materials again.
/🆑
---------
Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com>
## About The Pull Request
Before there were two settings for human authority:
`ENFORCE_HUMAN_AUTHORITY` and `ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE`
The first, if enabled, would not let non-humans be heads of staff unless
they had a specific var on their job set to TRUE.
The second, if enabled, would simply ignore that var and reject the
non-human anyways.
This PR replaces both of those settings with a single one,
`HUMAN_AUTHORITY`. You can set it to one of four settings:
* "OFF": human authority will be turned OFF. Non-Humans will be able to
be heads of staff.
* "HUMAN WHITELIST": human authority will be turned OFF, HOWEVER; if a
job has its new `human_authority` variable set to
`JOB_AUTHORITY_HUMANS_ONLY`, then whoever picks that job will be forced
to be human.
* "NON-HUMAN WHITELIST": human authority will be turned ON. However, if
a job has its `human_authority` variable set to
`JOB_AUTHORITY_NON_HUMANS_ALLOWED`, a non-human can become that job.
This is what we have now, it works the same as if
`ENFORCE_HUMAN_AUTHORITY` were turned on. This is also what I've set as
the default value.
* "ENFORCED" human authority will be turned ON. Non-Humans will never be
able to be heads of staff. This is what
`ENFORCE_HUMAN_AUTHORITY_ON_EVERYONE` used to do.
You can also now set the `human_authority` variable through
`jobconfig.toml`!
## Why It's Good For The Game
Allows more configuration options for downstreams, and lets keyholders
and headmins have more options over how to set up human authority.
## Changelog
🆑
config: Both human authority settings were combined into a singular one,
allowing for more flexibility
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
# Conflicts:
# config/game_options.txt
# config/jobconfig.toml
## About The Pull Request
`SSpolling.poll_ghosts_for_target` returns a 0 length list when no
candidates are chosen so it will spawn an AI core without a client, so
instead of `if(isnull(ghost)` we do `if(!ismob(ghost))`.
closes https://github.com/tgstation/tgstation/issues/86976
## Changelog
🆑 grungussuss
fix: fixed a clientless AI spawning when a ghost poll for syndicate
modsuit AI had no volunteers
admin: AI rolebanned players can no longer role for Syndicate modsuit AI
/🆑
## About The Pull Request
Fixes#86899
Assigning head positions doesn't use the `available_occupations` list
and instead just iterates through all command roles direct from some
department job helper, jumping over any that are at capacity.
This means the `available_occupations` list doesn't get updated when
head positions are assigned and can lead to an edge case where two
players can both get a single-slot job. The first player gets it via
`fill_all_head_positions_at_priority()`. The second player gets it via
being given a random role when any now-full head job doesn't get removed
from the `available_occupations` list.
There are many ways to fix this. The solution I've opted for is removing
command roles from the `available_occupations` list entirely, letting
`fill_all_head_positions_at_priority()` handle the logic for this
exclusively.
## Why It's Good For The Game
I feex.
## Changelog
🆑
fix: Fixes a bug where the game would assign multiple players to
single-slot command roles.
/🆑
This autoloads the up/down traits for every map instead of having to
manually add those traits to the JSON.
More automation good. Also let's people experiment with larger maps like
a multi-z lavaland.
🆑
code: Automatically link maps multi-z up/down traits
/🆑
## About The Pull Request
AI controllers do not respect their tick limits, behaving as if they
need to process all controllers in one tick.
This means every time the idle subsystem runs we process 500 controllers
at once. This is bad, and induces overtime for free, which sucks.
I can't think of a reason we would need to do all this work at once.
## About The Pull Request
ai controllers that have exhausted all their current behaviors now stop
processing until the next cycle, so we no longer need to do these checks
on every process fire. idle behaviors are now instead handled by a new
low priority subsystem. these are the costs before/after roughly 25
minutes into the round
## Why It's Good For The Game
improves ai performance
## Changelog
🆑
/🆑
## About The Pull Request
ai controllers that fail planning no longer process until theyre able to
plan again. this makes it so /process is called less thus you'll have
less AI competing against one another for cpu. also converts idle
behaviors into singletons
## Why It's Good For The Game
AIs that dont have a plan dont do anything during processing so its
better to just make them sit out the cycle instead of draining cpu
## Changelog
🆑
/🆑
## About The Pull Request
reduces the cost of the planning subsystem. instead of calculating
able_to_plan on every fire for every mob, we only calculate it when a
mob queues/dequeues a behavior. also converts behavior lists into lists
rather than lazylists to reduce the amount of checks we do on process.
these are the differences after ran on tracy.
## Why It's Good For The Game
reduces the cost of ai planning subsystem
## Changelog
🆑
/🆑
3591 individual conflicts
Update build.js
Update install_node.sh
Update byond.js
oh my fucking god
hat
slow
huh
holy shit
we all fall down
2 more I missed
2900 individual conflicts
2700 Individual conflicts
replaces yarn file with tg version, bumping us down to 2200-ish
Down to 2000 individual conflicts
140 down
mmm
aaaaaaaaaaaaaaaaaaa
not yt
575
soon
900 individual conflicts
600 individual conflicts, 121 file conflicts
im not okay
160 across 19 files
29 in 4 files
0 conflicts, compiletime fix time
some minor incap stuff
missed ticks
weird dupe definition stuff
missed ticks 2
incap fixes
undefs and pie fix
Radio update and some extra minor stuff
returns a single override
no more dupe definitions, 175 compiletime errors
Unticked file fix
sound and emote stuff
honk and more radio stuff
## About The Pull Request
Adds the following new general shuttle events:_
**Hitchhiker**
- 1% chance
- A single assistant in an EVA suit and some PBJs in a suitcase
**Assistant Wave**
- 0.1% chance
- Spawns 10 assistants with internals
- For clarity, they don't get sent to the shuttle, but get launched at
it from space. It's a scuffle of 10 assistants trying to get in without
being spaced or succumbing to the cold/pressure
**Intern Wave**
- Admin only
- Unarmed and armed version
- Spawns centcom interns, with a little announcement to warn they're
coming
I've also fixed projectiles bugging out and admin forced shuttle events
not activating if they were added after the shuttle launched
<details>
<summary>Admin only events added</summary>
**Nukie**
Spawns a single nukie, armed with a shotgun, pistol and edagger.
Basically the deathmatch nukie loadout, you dont want to fight this
**Meaty ores**
Meaty-ores meteors. Have a 4% chance to hit the shuttle, posing a
potential hazard
**3 player controlled fire-sharks**
3 fire sharks controlled by players. Not much to talk about here
**Fireball Wave**
Shoots a wave of fireballs at the shuttle. I think it's cool but
apparently shuttle walls and windows deflect fireballs so it's kind of
moot unless you're outside :/
</details>
## Why It's Good For The Game
The assistant and hitchhiker events are some flavoring that I thought up
a while ago. The Hitchhiker is just intentionally a flavor addition, but
the assistant wave and intern wave can be used by admins to repopulate
or retake the emergency shuttle as well.
## Changelog
🆑
add: Adds an assistant and hitchiker shuttle event, replenishing the
crew mid flight!
admin: Adds two intern wave shuttle events
code: You can now supply shuttle events with outfits!
code: You can now shoot projectiles with the shuttle events!
fix: Fixes projectiles bugging out when fired in shuttle transit space
fix: Fixes admin forced shuttle events not activating when added mid
transit
/🆑
## About The Pull Request
Changes map votes to be based on a persistent tally count.
Tallies for maps are cached between rounds and are added to by map
votes.
When a map is chosen, and it wasn't the only valid one, the tallies for
said chosen map will be reset.
Refactors map vote handling and moves it from SSmapping to SSmap_vote.
Rock the Vote has been removed as a result of this refactor.
## Why It's Good For The Game
Makes it more likely that all maps will be played over the course of a
server instead of always being truly random.
Removes some clutter off of SSmapping.
🆑
refactor: Map Votes are now carried over between rounds. When a map vote
is actually a contest, the winning map will have its votes reset.
/🆑
## About The Pull Request
This pull request aims to fix the wiki manuals. Currently the wiki
manuals just show "You start skimming through the manual..." because of
a bad link (http://www.tgstation13.org/wiki instead of
http://tgstation13.org/wiki) which is fixed with this PR, but the issue
does not end there. Because BYOND uses trident for its `browse()`
function, a lot of Javascript and HTML elements do not function
properly, disallowing the removal or blocking of hyperlinks which break
the book entirely if they are clicked.
Therefore, as a temporary solution (until BYOND 516 is released with
webview2) when the user opens a book they are prompted with the
following:
Although not the best solution, it makes the books have a function again
and are usable.
Fixes https://github.com/tgstation/tgstation/issues/77315.
## Why It's Good For The Game
Makes books work again so new players can use them to be guided to the
wiki resources.
## Changelog
🆑
fix: fix wiki manuals by making them open wiki page on browser
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
So this was caused by the change in
https://github.com/tgstation/tgstation/pull/86012 .
They tried to fix a case for polls with `amount_to_pick` set to _greater
than 1_ having null entries in the returned lists, and succeeded at
that.
However, in doing so they messed up the control flow of the proc such
that now it's returning early with an empty `list()` whenever the amount
is _equal to 1_.
The assumption was, when `amount_to_pick` was equal to 1 specifically
then the return value would be either a `null` value or the valid mob.
However, now what was being returned was either a `list()` or the valid
mob because that code was no longer ever being reached.
For example
Fixes https://github.com/NovaSector/NovaSector/issues/4427
Fixes both bugs in a way that should not cause any problems, and adjusts
documentation to make it clearer what the return value of this proc is
expected to be.
## Why It's Good For The Game
Fixes a bug that pretty much effects the majority of ghost polls as most
of them are only asking for 1 player.
## Changelog
🆑
fix: fixes pulsing tumor failing to spawn the elite if no ghosts respond
to the poll and leaving you in a bugged state, and possibly other
related issues
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
123 changed files and multiple crashes after writing broken regex, I
replaced most remains of direct spans with macros. This cleans up the
code and makes it easier to work with in general, see justification for
the original PR. I also fixed a bunch of broken and/or unclosed spans
here too.
I intentionally avoided replacing spans with multiple classes (in most
cases) and spans in the middle of strings as it would impact readability
(in my opinion at least) and could be done later if required.
## Why It's Good For The Game
Cleaner code, actually using our macros, fixes borked HTML in some
places. See original PR.
## Changelog
Nothing player-facing
## About The Pull Request
This PR significantly enhances how zero-g movement works. Its no longer
locked to one of 8 directions, everything now has inertia and is
affected by weight. This means that throwing a piece of wire will no
longer completely reverse your movement direction, and that being thrown
out of mass driver no longer will slow you down to a halt at some point.
This leads to following gameplay changes:
* Guns now accelerate you. Ballistics have higher acceleration than
lasers, and higher calibers have higher acceleration than smaller ones.
This means that firing full-auto weapons in zero-g will make you drift
and accelerate significantly. While this can be a hilarious way to
travel in space, it makes using them trickier.
* Impacting a wall or an object while moving at high speeds will cause
you to violently crash into it as if you were thrown. Careful when
exploring!
* Jetpacks now have inertia. Changes introduced in #84712 have been
mostly reverted, although speed buff has been reduced to 0.3 instead of
0.5 (although this is compensated by new movement mechanics, so overall
speed should be roughly equal). All MODsuit jetpacks now possess the
speed boost. Advanced MODsuit jets (which has also been added back) and
captain's jetpack instead have higher acceleration and stabilization
power, providing much more precise control over your movement.
* Firing guns while moving on a jetpack will partially negate your
pack's acceleration, slowing you down. Non-advanced jetpacks'
stabilization is not enough to compensate for heavy caliber weaponry as
sniper rifles, shotguns or rocket launchers.
* You no longer instantly decelerate upon sliding along a wall. Instead,
it may take a few tiles if you are moving at extreme speeds. Passing
over lattices still allows you to grab onto them!
As space movement is angle-based instead of dir-based now, its much more
smooth than before due to using new movement logic.
Example of jetpack stabilization in action:
https://github.com/tgstation/tgstation/assets/44720187/6761a4fd-b7de-4523-97ea-38144b8aab41
And, of course, you can do this now.
**This pull request requires extensive gameplay testing before
merging**, as a large amount of numbers have been picked arbitrarily in
an attempt to keep consistency with previous behavior (guns and
normal-sized items applying 1 drift force, which is equal to what
everything applied before this PR). Jetpacks and impacts may also
require adjustments as to not be frustrating to use.
Closes#85165
## Why It's Good For The Game
Zero-G refactor - currently our zero-g movement is rather ugly and can
be uncomfortable to work with. A piece of cable being able to accelerate
you the same as a duffelbag full of items when thrown makes no sense,
and so does instantly changing directions. Inertia-based version is
smoother and more intuitive. This also makes being thrown into space
more of a hazard (possibly opening the door for explosive
decompressions?)
Jetpack inertia and gun changes - this is mostly a consequence of
inertia-based movement. However, zero-g combat being preferred during
modes like warops was an issue due to it negatively affecting everyone
without jetpacks which are in limited supply onboard. This reverts the
mobility changes which severely impacted space exploration, while making
zero-g combat more dangerous and having it require more skill to be a
viable option.
## What's left
- [x] Refactor moth wings to use jetpack code
- [x] Refactor functional wings to use jetpack code
- [x] Locate and fix a recursion runtime that sometimes occurs upon
splattering against a wall
- [x] Add craftable tethers and modify engineering MOD tethers to use
the same system
## Changelog
🆑
add: You can now craft tether anchors, which can be secured with a
wrench and attached to with right click. They won't let you drift into
space and you can adjust tether length/cut it via lmb/rmb/ctrl click on
the wire.
add: MOD tethers now remotely place and connect to tether anchors
instead of throwing you at where they landed.
balance: MOD tethers can now be used in gravity
balance: Jetpacks are now inertia-based.
balance: Guns can accelerate you significantly in zero-g.
balance: All jetpacks now give you equal speed buff, however advanced
MOD ion jets and captain's jetpack have higher acceleration/deceleration
values.
refactor: Refactored zero-g movement to be inertia-based and utilize
angles instead of directions.
/🆑
## About The Pull Request
This pull request fixes the link you get redirected to when you click
the "Rules" button on the top right of the game. Before it redirected to
http://www.tgstation13.org/wiki/Rules but the correct link is
http://tgstation13.org/wiki/rules (the www part is the problem).
## Why It's Good For The Game
Makes the rules button direct you to the correct link, making it easier
for someone to view the rules of the server.
## Changelog
🆑
fix: fixed link for the rules button
/🆑
## About The Pull Request
<details>
- renamed ai folder to announcer
-- announcer --
- moved vox_fem to announcer
- moved approachingTG to announcer
- separated the ambience folder into ambience and instrumental
-- ambience --
- created holy folder moved all related sounds there
- created engineering folder and moved all related sounds there
- created security folder and moved ambidet there
- created general folder and moved ambigen there
- created icemoon folder and moved all icebox-related ambience there
- created medical folder and moved all medbay-related ambi there
- created ruin folder and moves all ruins ambi there
- created beach folder and moved seag and shore there
- created lavaland folder and moved related ambi there
- created aurora_caelus folder and placed its ambi there
- created misc folder and moved the rest of the files that don't have a
specific category into it
-- instrumental --
- moved traitor folder here
- created lobby_music folder and placed our songs there (title0 not used
anywhere? - server-side modification?)
-- items --
- moved secdeath to hailer
- moved surgery to handling
-- effects --
- moved chemistry into effects
- moved hallucinations into effects
- moved health into effects
- moved magic into effects
-- vehicles --
- moved mecha into vehicles
created mobs folder
-- mobs --
- moved creatures folder into mobs
- moved voice into mobs
renamed creatures to non-humanoids
renamed voice to humanoids
-- non-humanoids--
created cyborg folder
created hiss folder
moved harmalarm.ogg to cyborg
-- humanoids --
-- misc --
moved ghostwhisper to misc
moved insane_low_laugh to misc
I give up trying to document this.
</details>
- [X] ambience
- [x] announcer
- [x] effects
- [X] instrumental
- [x] items
- [x] machines
- [x] misc
- [X] mobs
- [X] runtime
- [X] vehicles
- [ ] attributions
## Why It's Good For The Game
This folder is so disorganized that it's vomit inducing, will make it
easier to find and add new sounds, providng a minor structure to the
sound folder.
## Changelog
🆑 grungussuss
refactor: the sound folder in the source code has been reorganized,
please report any oddities with sounds playing or not playing
server: lobby music has been repathed to sound/music/lobby_music
/🆑
## About The Pull Request
Rewrites a good chunk of express console code, removing one letter
variables, duplicate code and straightening all the staircases with
early returns. RIP cooldowns in ui_data()
Mapped-in consoles now actually work, as currently they initialize
before SSshuttles which results in them having a completely empty packs
menu. This is fixed by making them report themselves to SSshuttles which
will call package init on them once it itself initializes.
Emagging the console will update the prices in the UI, and emagged
consoles will try to send at least 1 package instead of requiring the
budget to have enough funds to send all 5 pods. Because when you press a
button with a price tag on it, you'd expect at least something to
happen.
Beacons now reset their offsets when anchored because thats been
triggering my OCD. Upgrade disks aren't deleted and instead drop when
the console is deconstructed.
## Why It's Good For The Game
Code is crunchy, stuff is broken, prices aren't displayed correctly when
the console is emagged and you'd expect at least something to arrive
when you press a button with a price that you can afford.
## Changelog
🆑
fix: Mapped in express supply consoles now work instead of displaying an
empty UI.
fix: Emagged express supply consoles now display updated prices.
refactor: Rewrote a large chunk of express supply console code
balance: Express supply consoles now drop their upgrade disk upon being
deconstructed, and emagged consoles now will try to send at least one
package to the station if cargo budget doesn't have enough funds for all
5.
/🆑
## About The Pull Request
This swaps out the pirate spawner on the Meta Central VDOM with the
subtype specifically meant for virtual domains. That thing wasn't
actually a virtual domain spawner, it was just a regular one.
This applies the necessary restrictions/roles being applied to pirates
who spawn on that map. It will also make #86794 work on the Metastation
Central map, rather than only affect the Corsair Cove map (which used
the correct spawner type).
This also adds the Announce to Ghosts flag to Meta Central, as is
uniform for maps with ghost roles. Doing so also enables the VDOM
selector UI indicator that ghost roles can spawn on the map.
This whole thing started as an attempt to fix#86785 but I was too slow
and someone beat me too it. Darn.
## Why It's Good For The Game
Ensures #86785 will be closed properly.
## Changelog
🆑 Rhials
fix: The Meta Central Virtual Domain now uses the proper ghost role
spawner, meaning you can't eavesdrop on syndie comms using their
headset.
/🆑
## About The Pull Request
ai controllers that fail planning no longer process until theyre able to
plan again. this makes it so /process is called less thus you'll have
less AI competing against one another for cpu. also converts idle
behaviors into singletons
## Why It's Good For The Game
AIs that dont have a plan dont do anything during processing so its
better to just make them sit out the cycle instead of draining cpu
## Changelog
🆑
/🆑
## About The Pull Request
In #86711 we made it so adjusting the trim of an id card also updated
the job on the associated bank account to match, but we forgot to update
`bank_accounts_by_job` to match this.
This made it so Curator painting patronage cuts wouldn't get updated to
match the trim, and would risk issues with removing it from
`bank_accounts_by_job` if the bank account were to get deleted.
In this pr we add a `update_account_job_lists(...)` proc that updated
`bank_accounts_by_job` to match.
This fixes our issues.
Additionally, we update `vv_edit_var(...)` to also run this when
changing related values, such that it actually removes and adds the
values when needed.
## Why It's Good For The Game
Fixes a bug, helps with VVediting bank account jobs.
## Changelog
🆑
fix: Changing a bank account's job to or from Curator actually changes
whether they get a cut from painting patronage.
admin: VVediting a bank account's account_job actually updates what job
the account is associated with. Currently only matters for Curators.
admin: VVediting a bank account's add_to_accounts actually removes it
from or adds it to the job to account associations. Currently only
matters for Curators.
/🆑
## About The Pull Request
So, I've been looking into manually loading job traits today, and it
seems the buttons don't appear until you reconnect. Upon further
investigations, it turns out that the code doesn't support showing lobby
buttons outside of SSstation init. To add injury only up to three
buttons can be displayed for some stupid reason (the lack of code for x
offsets), plus the buttons aren't relocated when one is removed, thus
possibly leaving behind an empty gap.
This PR fixes all of that, while removing some crumbs of shitcode from
new players' HUDs and making sure to remove datum traits and references
are removed when the trait is deleted (usually never the case outside
VV).
## Why It's Good For The Game
Lobby buttons should ALWAYS be shown to the player if the relative trait
is loaded, the only exception being the conditions set by the trait
itself (for job traits is the job age and whether the game has started
or not), while the offsets of the lobby buttons should stay synced with
how many are being displayed to the new player at any given time, so if
a button is deleted, the others are relocated to avoid having leaving an
empty gap behind.
Beside, this is necessary for the lobby button for the playable pun pun
to show up during Monkey Day.
## Changelog
N/A, all backend.
## About The Pull Request
Closes#61216Closes#57516
Arcane gave greenlight on this PR as its unlikely that this'll be
cheesed or affect balance in any way, and in worst case scenario mass
account changes will just summon space IRS on the offending HoP
## Changelog
🆑
fix: Changing ID card's trim now properly adjusts linked bank account's
job, allowing you to receive bounties for your new job
/🆑
## About The Pull Request
First things first, credit to tmyqlfpir aka Feignsleep for making the
initial cargo crate import code. I probably butchered it when I messed
with it to make it only import on console so make sure to yell at me if
there are issues.
This PR does several things.
FIRST it brings Tarkon up to date with Interdyne as far as cargo goes.
In this case, that means an express cargo console, selling pad, and
powerator tied to a budget account.
Second, thing, both Interdyne and Tarkon now have access to cargo
company items. Its a bit janky but it should do for at least now. With
how it was done, we should be able to add unique items to the consoles
for each faction, although that might need some work.
As a minor note, I also nerfed the interdyne powerator. It had a 2x
multiplier and I'm not sure that is really needed.
## Why It's Good For The Game
Cargo goes brrrt, also Tarkon could use some love.
## Proof Of Testing
## Changelog
🆑
add: Cargo Companies are now available to offstation factions
add: Tarkon now has a cargo setup available to them
balance: rebalanced something
/🆑
---------
Co-authored-by: The Sharkening <95130227+StrangeWeirdKitten@users.noreply.github.com>
Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com>
Co-authored-by: Swift <jackwars4@gmail.com>
## About The Previous Pull Request
#85308 reverted by #85929
~~Causes the round to not start when a player isn't eligible for any
jobs at a specific priority level due to runtimes trying to `pick()`
from an empty list aborting the entire job assignment stack.~~
(Fixed???? by
e0e9f2f430)
Maybe we should test merge this for a mo just to make sure no more
cheeky runtimes pop up before merging.
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
## About The Pull Request
[Ties new active turfs to SSair's "frame
window"](cf46d8b1fc)
Currently, if you add a new active turf midway through processing, it
will be handled as a PART of that fire's processing.
This combined with some bullshit with archive means that placing one
source of diffs down can lead to a 1 tick spread instantly, ONLY if no
turfs are actually active.
(The following is one tick of atmos processing)
This runs counter to the existing archiving system, and violates the
principles of active/inactive turfs of being an optimization over
processing every cell individually.
The fix is to uh, not do that.
It also solves the highly edge case of a turf that's activated by
something reacting to its temp change, alone in a 1x1 with no neighbors
possibly causing an infinte stall in ssair.
I'm also cleaning up add to active a bit, zypher's idea should have 0
cost.
[Makes turf to turf activation fully diamond
shaped](2528fb2764)
Turf sharing operates off the archived gas list, but the check to see if
we SHOULD share was working off the normal gas/temp values.
This meant diff evening out was DIRECTIONAL (due to the directional
ordering of atmos adjacent turfs)
This is fixable by just using archive for these things.
This does require an additional arg to compare() which DOES matter at
this scale but I don't want to split compare into two procs I don't
think and it should be relatively minimal.
This means cleaner debug outputs, hopefully less pointlessly activated
turfs, and a more consistent activation/sharing order (we aren't
dropping turfs randomly now!)
https://github.com/user-attachments/assets/347d3cd6-542f-48e6-aa83-40e7e9b11635
(spreading w/o this change as an example of the former issues)
https://github.com/user-attachments/assets/da1ecbce-28b6-4241-8ac6-517b690c9ba6
---------
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
## About The Pull Request
This is a remake of https://github.com/tgstation/tgstation/pull/84501
with a few small changes to avoid mapping issues. This time it's
restricted to a once-in-a-year event, mainly because neither Jacq and
Lemon were ok with the possibility of Pun Pun being posibly playable all
year, however Jacq said he's fine with it being available on the
holiday, while Lemon isn't around on Discord atm so I don't know what
he's to say.
The trait makes pun pun playable and gives them the job of being a
busser (waiter) in the cafeteria. They're clever and can use tools most
other monkeys can't, but cannot be humanized, while also being unable to
speak Galactic Common. Should they roll traitor, they'll be able to buy
syndicate monkey reinforcements and equipment, which it can also use,
being a monkey itself.
## Why It's Good For The Game
This is a fairly unique job, like the Cargo Gorilla, due to the fact
it's not a conventional humanoid crew member nor the AI or a cyborg. I
thought this was a fun idea, though I met some obstacles and the
original PR was DNM'ed and then closed. However, the trait perfectly
fits the theme of the holiday, making a good compromise since Pun Pun
will stay AI-controlled the rest of the year, as Jacquarel and Lemon
want it to be. It can also be added by an admin through VV, whether
they're planning some shenanigean or just want to add something more to
the round.
## Changelog
🆑
add: Pun Pun is a playable crewmember during Monkey Day (14 December).
/🆑
## About The Pull Request
### New stuff
Introduces lone infiltrator back.
Introduces midround malf
### Removals
Predictable chaos has been removed as its system of trying for antags
more often in smaller numbers is now part of every storyteller. Hooray
midrounds!
### Event adjustments
Meteors can no longer repeat-run. For some reason the default tg value
for them was 3 max occurences.
### Track changes
Tracks are now simpler to manage as they fill by a consistent value of
1, instead being of variable lengths dependent on the storyteller. These
still need adjustments depending on how the testing rounds go
The Roleset track has been changed to the Crewset track and its rollable
events split between it and ghostsed
The unused Objectives track has been killed and changed for the Ghostset
track, containing ghost rolls
This means that ghost rolls should be a guarantee, even if just 1 rolls
during a round. This will probably need more adjustment and tweaking.
Also had lone infiltrator reintroduced for this reason.
### Votes
Votes no longer prevent the last storyteller voted, but the last type of
teller voted. This means that going Fragile>Chill>Fragile is no longer
possible, and rounds should alternate between the low intensity and high
intensity tellers.
Default Andy is always available
Bomb, Clown, Gamer are of the high intensity category
Fragile, Chill, Extended are of the low intensity category
### Fixes
Fixes track points sometimes going into the negatives, makes roundstart
point distribution more random. Some other minor stuff is also fixed.
The flaky error may have been fixed by this but I haven't tested
Fixes voidwalker spawning wrongly on planetary maps
## Why It's Good For The Game
Should make antag rolling less round start ready dependent, also takes
what predictable chaos does and applies it to every teller because the
concept of trying to roll antags super often is actually pretty fucken
good.
It also makes the system less convoluted and fixes some bugs
## Proof Of Testing
Needs TM to iron out track points once I'm done making them.
## Changelog
🆑
add: Added Lone infiltrator ghost midround
add: Added Malf AI midround
del: Removes predictable chaos as all tellers now use its main gimmick
as a baseline
qol: Storyteller votes now prevent a constant voting streak of the same
type of tellers
balance: All storytellers now roll antags more often, but in smaller
numbers per roll
balance: Clown storyteller no longer cares about event weights and just
does whatever rng decides
balance: Meteors can no longer run repeatedly in a single round
balance: Makes ghost roles actually roll somewhat frequently
fix: Fixed a few bugs with storytellers, namely the tracks sometimes
going into negatives, and voidwalker running on planet maps
refactor: Refactored how storytellers handle tracks to be easier to code
with
/🆑
---------
Co-authored-by: The Sharkening <95130227+StrangeWeirdKitten@users.noreply.github.com>
## About The Pull Request
I've come to realize manually updating all fishing stuff on the very
much outdated wiki would be a colossal pain in the rear, so I've decided
to automate a few bits to generate autowiki lists containing information
about fish, fish traits, bait, hooks, reels, fishng rods, fish sources
and fish experiments.
Now tested.
## Why It's Good For The Game
Making a huge autowiki for a feature that's being constantly updated (by
me) but still has a particularly lame and outdated page on the wiki.
## Changelog
N/A
