mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-29 17:03:53 +01:00
088409bbe376a7adcd4d1fb747cf4a5e4f257c5b
162 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Timberpoes
|
6808a082eb |
Assorted changes to job assignment code and logging. Runtime free, guaranteed or your money back. Price: $£0. (#85947)
## 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 https://github.com/tgstation/tgstation/pull/85947/commits/e0e9f2f430079d4ab7097abe12e75f934131a638) 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. /🆑 |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
Time-Green
|
095f7e3b70 |
Death of mutant bodyparts AND external organs (#85137)
## About The Pull Request Removes mutant bodyparts and external organs from the game completely Digitgrade behaviour was mutant bodypart for no reason Cat ears now work with the bodyparts overlay system, same as all the other external organs (since all their behaviour is now just on /organ It doesn't remove all the /external types, but moves all behaviour to /organ. I'll follow up with a PR wiping all the /external organ types, but it's just conflict heaven so not this PR I've also streamlined a lot of duplicate/weird species regeneration code Melbert did the same PR as well but due to a lack of time (?) I have absorbed his PR to double nuke mutant bodyparts ## Why It's Good For The Game Frees us from the chain of unmodular code, and kills my greatest nemesis (after the shuttle meteor murder bug) ## Changelog 🆑 Time-Green and MrMelbert Refactor: External organ behaviour has been moved to /organ, ears now use the same system as the other organs Refactor: Mutant bodyparts are dead! This likely does not mean much to the average person but it's very dear to me code: Improves digitgrade handling in preference code /🆑 I have absorbed #85126, using Melberts code to improve and add some missing changes. Mainly improving the functioning of preferences and digitgrade legs. I didn't take over the hairstyle improvements. --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Kyle Spier-Swenson
|
4d1639b04c |
Revert "Assorted changes to job assignment code and logging." (#85929)
Reverts tgstation/tgstation#85308  |
||
|
Timberpoes
|
1eef540054 |
Assorted changes to job assignment code and logging. (#85308)
## 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.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
|
||
|
DATAxPUNGED
|
34aa2bc50e |
Paraplegics can choose to not have legs. (#85716)
## About The Pull Request This is a bounty that was made by ophaq, and claimed by me. Gives paraplegic the option to be an amputee, and appear on station without their legs. They are still paralyzed, so no amount of mechanical legs is gonna let them walk again. ## Why It's Good For The Game Character customization is a good thing and lets people make their little characters suffer in new ways, this one in specific *actively lowers your max HP*, which is gonna certainly be fun. ## Changelog 🆑 qol: Paraplegics can now opt into appearing on the shift without their legs. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
LemonInTheDark
|
4b4e9dff1d |
Wallening [IDB IGNORE] [MDB IGNORE] (#85491)
## What's going on here Kept you waitin huh! This pr resprites most all walls, windows and other "wall adjacent" things to a 3/4th perspective, technical term is "tall" walls (we are very smart). If you're trying to understand the technical details here, much of the "rendering tech" is built off the idea of split-vis. Basically, split a sprite up and render it on adjacent turfs, to prevent seeing "through" walls/doors, and to support seeing "edges" without actually seeing the atom itself. Most of the rest of it is pipelining done to accommodate how icons are cut. ## Path To Merge Almost* all sprites and code is done at this point. There are some things missing both on and off the bounty list, but that will be the case forever unless we force upstream (you guys) to stop adding new shit that doesn't fit the style. I plan on accepting and integrating prs to the current working repo <https://github.com/wall-nerds/wallening> up until a merge, to make contribution simpler and allow things like bounties to close out more easily This pr is quite bulky, even stripping away map changes it's maybe 7000 LOC (We have a few maps that were modified with UpdatePaths, I am also tentatively pring our test map, for future use.) This may inhibit proper review, although that is part of why I am willing to make it despite my perfectionism. Apologies in advance. Due to the perspective shift, a lot of mapping work is going to need to be done at some point. This comes in varying levels of priority. Many wallmounts are offset by hand, some are stuck in the wall/basically cannot be placed on the east/west/north edges of walls (posters), some just don't look great good in their current position. Tests are currently a minor bit yorked, I thought it was more important to get this up then to clean them fully. ## What does it look like?       ## Credits <details> <summary>Historical Mumbojumbo</summary> I am gonna do my best to document how this project came to be. I am operating off third party info and half remembered details, so if I'm wrong please yell at me. This project started sometime in late 2020, as a product of Rohesie trying to integrate and make easier work from Mojave Sun (A recently defunct fallout server) with /tg/. Mojave Sun (Apparently this was LITERALLY JUST infrared baron, that man is insane) was working with tall walls, IE walls that are 48px tall instead of the normal 32. This was I THINK done based off a technical prototype from aao7 proving A it was possible and B it didn't look like dogwater. This alongside oranges begging the art team for 3/4th walls (he meant TGMC style) lead to Rohesie bringing on contributors from general /tg/, including actionninja who would eventually take over as technical lead and Kryson, who would define /tg/'s version of the artstyle. Much of the formative aspects of this project are their work. The project was coming along pretty well for a few months, but ran into serious technical issues with `SIDE_MAP`, a byond map_format that allows for simpler 3/4th rendering. Due to BULLSHIT I will not detail here, the map format caused issues both at random with flickering and heavily with multiz. Concurrent with this, action stepped down after hacking out the rendering tech and starting work on an icon cutter that would allow for simpler icon generation, leaving ninjanomnom to manage the project. Some time passed, and the project stalled out due to the technical issues. Eventually I built a test case for the issues we had with `SIDE_MAP` and convinced lummox jr (byond's developer) to explain how the fuckin thing actually worked. This understanding made the project theoretically possible, but did not resolve the problems with multi-z. Resolving those required a full rework of how rendering like, worked. I (alongside tattle) took over project development from ninjanomnom at this time, and started work on Plane Cube (#69115), which when finished would finally make the project technically feasible. The time between then and now has been slow, progressive work. Many many artists and technical folks have dumped their time into this (as you can see from the credits). I will get into this more below but I would like to explicitly thank (in no particular order) tattle, draco, arcanemusic, actionninja, imaginos, viro and kylerace for keeping the project alive in this time period. I would have curled up into a ball and died if I had to do this all myself, your help has been indispensable. </details> <details> <summary>Detailed Credits</summary> Deep apologies if I have forgotten someone (I am sure I have, if someone is you please contact me). I've done my best to collate from the git log/my memory. Thanks to (In no particular order): Raccoff: Being funny to bully, creating threshold decals for airlocks aa07: (I think) inspiring the project ActionNinja: Laying the technical rock we build off, supporting me despite byond trying to kill him, building the icon cutter that makes this possible ArcaneMusic: Artistic and technical work spanning from the project's start to literally today, being a constant of motivation and positivity. I can't list all the stuff he's done Armhulen: Key rendering work (he's the reason thindows render right), an upbeat personality and a kick in the ass. Love you arm Azlan: Damn cool sprites, consistently Ben10Omintrix: You know ben showed up just to make basic mobs work, he's just fuckin like that man BigBimmer: A large amount of bounty work, alongside just like, throwing shit around. An absolute joy to work with Capsandi: Plaques, blastdoors, artistic work early on CapybaraExtravagante: Rendering work on wall frames Draco: SO MUCH STUFF. Much of the spritework done over the past two years is his, constantly engaged and will take on anything. I would have given up if not for you Floyd: Early rendering work, so early I don't even know the details. Enjoy freedom brother Imaginos16: A guiding hand through the middle years, handled much of the sprite review and contribution for a good bit there Iamgoofball: A dedication to detail and aesthetic goals, spends a lot of effort dissecting feedback with a focus on making things as good as they can be at the jump Infrared: Part of the impetus for the project, made all the xenomorph stuff in the MS style Jacquerel: A bunch of little upkeep/technical things, has done so much sprite gruntwork (WHY ARE THERE SO MANY PAINTING TYPES) Justice12354: Solved a bunch of error sprites (and worked out how to actually make prs to the project) Thanks bro! Kryson: Built the artstyle of the project, carrying on for years even when it was technically dying, only stopping to casually beat cancer. So much of our style and art is Kryson KylerAce: Handled annoying technical stuff for me, built window frame logic and fully got rid of grilles. LemonInTheDark: Rendering dirtywork, project management and just so much fucking time in dreammaker editing sprites Meyhazah: Table buttons, brass windows and alll the old style doors Mothblocks: Has provided constant support, gave me a deadline and motivation, erased worries about "it not being done", gave just SO much money to fill in the critical holes in sprites. Thanks moth MTandi: Contributed art despite his own blackjack and hookers club opening right down the road, I'm sorry I rolled over some of your sprites man I wish we had finished earlier Ninjanomnomnom: Consulted on gags issues, kept things alive through some truly shit times oranges: This is his fault Rohesie: Organized the effort, did much of the initial like, proof of concept stuff. I hope you're doin well whatever you're up to. san7890: Consulting on mapper UX/design problems, being my pet mapper Senefi: Offsetting items with a focus on detail/the more unused canidates SimplyLogan: Detailed map work and mapper feedback, personally very kind even if we end up talking past each other sometimes. Thank you! SpaceSmithers: Just like, random mapping support out of nowhere, and bein a straight up cool dude Tattle: A bunch of misc project management stuff, organizing the discord, managing the test server, dealing with all the mapping bullshit for me, being my backup in case of bus. I know you think you didn't do much but your presence and work have been a great help Thunder12345: Came out of nowhere and just so much of the random bounties, I'm kind of upset about how much we paid him Time-Green: I hooked him in by fucking with stuff he made and now he's just doin shit, thanks for helping out man! Twaticus: Provided artistic feedback and authority for my poor feeble coder brain, believed in the project for YEARS, was a constant source of ❤️ and affirmation unit0016: I have no god damn idea who she is, popped out of nowhere on the github one day and dealt with a bunch of annoying rendering/refactoring. Godspeed random furry thank you for all your effort and issue reports Viro: A bunch of detailed spriting moving towards 3/4ths, both on and off the wallening fork. If anyone believed this project would be done, it was viro Wallem: Artistic review and consultation, was my go-to guy for a long time when the other two spritetainers were inactive Waltermeldon: Cracked out a bunch of rendering work, he's the reason windows look like not dogwater. Alongside floyd and action spent a TON of time speaking to lummox/unearthing how byond rendering worked trying to make this thing happen ZephyrTFA: Added directional airlock helpers, dealt with a big fuckin bugaboo that was living in my brain like it was nothing. Love you brother And finally: The Mojave Sun development team. They provided a testbed for the idea, committed hundreds and hundreds of hours to the artstyle, and were a large reason we caught issues early enough to meaningfully deal with them. Your work is a testament to what longterm effort and deep detailed care produce. I hope you're doing well whatever you're up to. Go out with a bang! </details> ## Changelog 🆑 Raccoff, aa07, ActionNinja, ArcaneMusic, Armhulen, Azlan, Ben10Omintrix, BigBimmer, Capsandi, CapybaraExtravagante, Draco, Floyd, Iamgoofball, Imaginos16, Infrared, Jacquerel, Justice12354, Kryson, KylerAce, LemonInTheDark, Meyhazah, Mothblocks, MTandi, Ninjanomnom, oranges, Rohesie, Runi-c, san7890, Senefi, SimplyLogan, SomeAngryMiner, SpaceSmithers, Tattle, Thunder12345, Time-Green, Twaticus, unit0016, Viro, Waltermeldon, ZephyrTFA with thanks to the Mojave Sun team! add: Resprites or offsets almost all "tall" objects in the game to match a 3/4ths perspective add: Bunch of rendering mumbo jumbo to make said 3/4ths perspective work /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: san7890 <the@san7890.com> Co-authored-by: = <stewartareid@outlook.com> Co-authored-by: Capsandi <dansullycc@gmail.com> Co-authored-by: ArcaneMusic <hero12290@aol.com> Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com> Co-authored-by: SomeAngryMiner <53237389+SomeAngryMiner@users.noreply.github.com> Co-authored-by: KylerAce <kylerlumpkin1@gmail.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Runi-c <5150427+Runi-c@users.noreply.github.com> Co-authored-by: Roryl-c <5150427+Roryl-c@users.noreply.github.com> Co-authored-by: tattle <article.disaster@gmail.com> Co-authored-by: Senefi <20830349+Peliex@users.noreply.github.com> Co-authored-by: Justice <42555530+Justice12354@users.noreply.github.com> Co-authored-by: BluBerry016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: Emmett Gaines <ninjanomnom@gmail.com> Co-authored-by: Rob Bailey <github@criticalaction.net> Co-authored-by: MMMiracles <lolaccount1@hotmail.com> |
||
|
DrTuxedo
|
277e57683e |
Radio Sounds (#85115)
## About The Pull Request Now talking into radio and hearing radio messages produces a sound. Using LOUD-MODE makes a unique sound. https://github.com/user-attachments/assets/891d9b9a-5313-4aac-9fef-56d0a7286bf1 https://github.com/user-attachments/assets/112a3587-46ea-413e-89e4-2da7b54c3d62 **YOU CAN DISABLE IT IN THE GAME PREFERENCES** ## Why It's Good For The Game People REALLY tend to miss radio messages, especially from the heads. This makes it so they can hear when some interesting or important chatter is going on. Unless all of the heads of staff decide to dispute in the Common, subordinates will start noticing messages from their bosses in their channels more often. Also, these sounds are tickling my ears, in a good way. ## Changelog 🆑 DrDiasyl aka DrTuxedo sound: Hearing and talking into the radio now produces a sound. Heads get a special sound. /🆑 |
||
|
itseasytosee
|
bb79c3859f |
Changes some default values from character creation and random characters (#84905)
## About The Pull Request Departmental Backpacks are now the default instead of grey backpacks. Jumpsuits are now default for all characters. ## Why It's Good For The Game I think there is an issue with assuming that female characters should be wearing jumpskirts by default. Jump skirts are comedic. They are frivolous, completely unrealistic, and with many of the sprites, overtly feminizing. By making them the default for women, we are essentially saying: "Women by default should be wearing clothes that extenuate their femininity, even at the cost of practicality." Many of the jumpskirt sprites are very puffy and frilly. This is despite the fact that jumpsuits are usually seen as agendered in workplace settings, and feminine in the fashion industry. There is nothing wrong with any given player wanting to put their character in this kind of clothing, regardless of gender. However, by asserting that women should be dressed in frivolous and feminizing attire, I believe this to be a form of objectification, and not something we should promote. I have not changed the ability to set your preference to jumpskirt should you desire. I have not altered the presence of jumpskirts anywhere on the map. ## Changelog 🆑 image: Changed some default options in the character creator. /🆑 |
||
|
_0Steven
|
5e753b6788 |
Offset render relays for non-offsetting planes to match highest matching render plane (#84184)
## About The Pull Request **Alternate title: "Fix blind people getting so blind they become deaf when going down a flight of stairs"** So 'bout half a week to a week ago I overheard a friend complaining about blind people not seeing runechat on lower multi-z levels. Asked a bit, apparently they'd reported this about half a year ago, and it's still an issue. So in my never-ending hubris I decided to just go and fix it! Now, admittedly? I really _really_ do not get the rendering system we use. The simple options were right out: we can't allow the fullscreens plane to be offset, as this causes issues with looking up/down, or disallow runechat from being offset, which causes issues with runechat from other levels. After poking our very cool and smart rendering guy several times over the course of the last week, this is what we got to: ### The technical bits We simply make the rendering relays for non-offsetting plane masters point to the highest rendering plane that matches the target. We do this by offsetting the rendering relays in place, by adjusting their plane and layer values to match the new offset, with a new `offset_relays_in_place(new_offset)` proc called in `/datum/plane_master_group/proc/transform_lower_turfs(...)`. Importantly, we compare the current layer values to what they should've been, so we don't accidentally override relays with custom-set layers. This fixes our issue (as tested on wawastation): <details> <summary>Images</summary>    </details> ## Why It's Good For The Game Fixes #80376. ## Changelog 🆑 fix: You can see runechat above fullscreen overlays on lower multi-z levels again. Rejoice, blind players. Please report any weird rendering layering issues. /🆑 |
||
|
MrMelbert
|
5b3c32e5cf |
Adds informed default values for a bunch of preferences (to produce less outlandish random characters) (#84726)
## About The Pull Request Goes through a bunch of character preferences and adds informed default values which produce less wacky results. Basically part 2 of #84443 . Preference randomization now results in a character similar to that pictured in the original pr. Of course, you can still make your character look as wacky as ever.  ## Why It's Good For The Game Basically, fully random characters look horrendous, and unless you're playing a non-human, you stick out like a sore thumb if you hardcore random or just decide to random appearance. Ultimately, full-random people will stick out less, which I think is good. ## Changelog 🆑 Melbert qol: Random player characters now look less like rainbow vomit and more like some of the most average people you know. /🆑 |
||
|
DATAxPUNGED
|
b46cabef82 |
Adds a breathing sound while using internals of any kind (#84529)
## About The Pull Request Spess men will now hear their own breathing while using internals, most noticeable while on space. It's low enough that it shouldn't affect anything normally, and only the person with internals can hear it. If you have misophonia or for some other reason dislike the sound, it can also be toggled off in the game settings. ## Why It's Good For The Game It truly makes you FEEL like you're breathing via a mask connected with an oxygen tank. It also, potentially, can remind you that your internals are on when it's not needed. ## Changelog 🆑 DATA_, with sounds made by Beebblie sound: You will now be able to hear your muffled breathing while using internals. This can be turned off in the game settings. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Jeremiah
|
f48814ed71 |
Changes bitrunning hacker alias sanitization (#84518)
## About The Pull Request Bitrunning hacker names now permit most characters while staying within the IC filter and length requirements. Made some helper procs to keep it organized ## Why It's Good For The Game You can now name yourself things like An1me_Sn1p3r ## Changelog 🆑 fix: Bitrunning hacker aliases are now much more permissive /🆑 |
||
|
carlarctg
|
0d05492e73 |
Fixed quirk conflict between transhumanist and prosthetic limb (#84325)
## About The Pull Request Transhumanist and prosthetic limb no longer conflict. If you pick the same limb for both it uses the weaker prosthetic (dumbass) Made the name for prosthetic limb global list more intelligible ## Why It's Good For The Game > Transhumanist and prosthetic limb no longer conflict. If you pick the same limb for both it uses the weaker prosthetic (dumbass) I wanted to RP a guy with a robotic voicebox and prosthetic limb but the game didn't let me, which I thought was pretty lame! Since the root issue is likely that both can have the same limb which ends up as Free Points as transhuman takes priority, I just added a check to ensure that can't happen and is overridden by the negative instead. Any transhumanist mood point benefits are made up for by the bad limb. > Made the name for prosthetic limb global list more intelligible It was bad ## Changelog 🆑 qol: Transhumanist and prosthetic limb no longer conflict. If you pick the same limb for both it uses the weaker prosthetic (dumbass) code: Made the name for prosthetic limb global list more intelligible /🆑 |
||
|
Afevis
|
135a27c286 |
Fixes toggling ship ambience not doing anything until you enter an area with a different kind of ambient sound (#84204)
🆑 ShizCalev fix: Toggling ambient ship sounds will now instantly turn it on/off. /🆑 |
||
|
Jeremiah
|
9ab7d8f2e8 |
Bitrunning: Avatars get silly hacker names (#84279)
## About The Pull Request Bit avatars now get corny names while spawning in to the virtual domain. You can change your alias in prefs or have it randomized for s0meth1ng 1337. Added sechud icons (and thereby orbit ui icons) for bit avatars since "Cyb3rHaxx0r" might be confusing to find in the living players section. ## Why It's Good For The Game This was done as a request and after discussion in the code channel. A little bit of character persistence across simulations. ## Changelog 🆑 add: Bitrunning: You can now choose your hacker alias in prefs. add: Bit avatars get orbit icons. /🆑 |
||
|
Afevis
|
d12576371c |
Fixes ambient sound preferences runtiming every time a client connects (#84202)
fixes #84200 forgot to pass the value that's sent while preferences are still initializing. |
||
|
MrMelbert
|
48acfd680f |
Fix ambience pref not being toggleable in game (#84087)
## About The Pull Request The only time people were added to the ambience SS's list is when you log in, meaning if you toggle the preference on/off mid game, it does nothing. Fixes #61495 ## Changelog 🆑 Melbert fix: Enabling or disabling ambience mid round will properly enable or disable ambience qol: Added descriptions differentiating "Ship ambience" from "ambience" /🆑 |
||
|
Time-Green
|
4fd0e28f42 |
Refactors body markings into bodypart overlays (#83744)
## About The Pull Request Refactors body markings (lizard and moths) into the bodypart overlays system I've also renamed the icon states for lizard bodymarkings (downstreams with lots of lizard body markings might have problems with this) ## Why It's Good For The Game Gives us better controle over /human appearances. I didn't add any means of actually changing them on the person (aside from genetics. how would that even work? with a waterproof marker?), but makes it easy for when/if I do. Also unloads mutant_bodyparts more, moving is yet closer to full species dedatumization ## Changelog 🆑 refactor: Lizard and moth markings now use the bodypart overlay system /🆑 |
||
|
MrMelbert
|
d244c86ce6 |
Adds Character Loadout Tab to preferences (with just a small handful of items to start) (#83521)
## About The Pull Request Adds a Character Loadout Tab to the preference menu This tab lets you pick items to start the round with  This also has some additional mechanics, such as being able to recolor colorable items, rename certain items (such as plushies), set item skins (such as the pride pin)  ## Why It's Good For The Game This has been headcoder sanctioned for some time, just no one did it. So here we are. Allows players to add some additional customization to their characters. Keeps us from cluttering the quirks list with quirks that do nothing but grants items. ## Changelog 🆑 Melbert add: Character Loadouts del: Pride Pin quirk (it's in the Loadout menu now) /🆑 |
||
|
IsaacExists
|
e9c45c44a5 |
Blindfold Color Preference (#83670)
## About The Pull Request When selecting the Blindness quirk, you now have the option to choose a specific color for the blindfold much like how the tagger quirk handles spray can color preference. The blindfolds used to always take a blend RGB of both eye colors and apply it to the blindfold, now it _should_ only do that if you have the blind-personnel blindfold directly spawned on your eyes. If not, then it just handles it like how it did before this PR was submitted, and mobs generally shouldn't have the blind-personnel blindfold if they aren't blind anyways.  ## Why It's Good For The Game While it isn't a big deal if your eye color matches the blindfold, some players (like a certain someone I know) would rather have their eye color be distinct, as such if you have a blue eye color on both eyes but want a purple or red blindfold, you don't have to go out of your way to paint it, which generally wouldn't work the way you'd want it to. In other words, it allows you to customize your character with more freedom, but only applies to those who willingly choose to suffer in the game. Being blind is fun! =) ## Changelog 🆑 add: You may choose a color preference for your blindfold with the blindness quirk. /🆑 |
||
|
_0Steven
|
e5a3a6bb81 |
Fix smoker quirk preferences (#83378)
## About The Pull Request So the smoker quirk would always reset back to "Random" whichever preferences you selected, just in the menu. Looking into why this was happening, it seemed to be failing at the point where it deserializes and sanitizes your selected value, specifically at the point where it'd compare it to the list of possible preferences. This seemed to be because the value it got back from tgui had removed the `\improper` text macro, while the value in the list was saved with that text macro. It's not actually useful here, so we remove it using `format_text(...)` when setting up the list, and this makes it work again. We also split it off from the previous used proc used for setting up the list: ```dm /proc/setup_junkie_addictions(list/possible_addictions) . = possible_addictions for(var/datum/reagent/addiction as anything in .) . -= addiction .[addiction::name] = addiction ``` Because the smoker list doesn't actually use reagents. I'm surprised this successfully got the name values for the non-reagents in the first place. ## Why It's Good For The Game Fixes #83277. Fixes #82538. ## Changelog 🆑 fix: Smoker quirk users can select a favourite brand again. /🆑 |
||
|
MrMelbert
|
0cc5cfb178 |
Random Name Generation refactor, generate random names based on languages (for species without name lists, like Felinids and Podpeople) (#83021)
## About The Pull Request This PR moves random name generation for species onto their languages. What does this mean? - For species with a predefined name list, such as Lizards and Moths, nothing. - For species without predefined name lists, such as Felinids, their names will now be randomly generated from their language's syllables.   (In the prefs menu:)  Why? - Well, we actually had some dead code that did this. All I did was fix it up and re-enable it. - Generates some pretty believable in-universe names for various languages that are lacking name lists. Obviously defined lists would be preferred, but until they are added, at least. - Moves some stuff off of species, which is always nice. - Also hopefully makes it a tad easier to work with name generation. There's now a standard framework for getting a random name for a mob, and for getting a random name based on a species. Misc: - Adds a generic `species_prototype` global, uses it in a lot of places in prefs code. - Makes `GLOB.species_list` init via the global defines - Deletes Language SS - Alphabetizes some instances of admin tooling using the list of all species IDs - Docs language stuff - Deletes random_skin_tone, it does pretty much nothin ## Changelog 🆑 Melbert refactor: Random Name Generation has been refactored. Report any instances of people having weird (or "Unknown") names. qol: Felinids, Slimepeople, Podpeople, and some other species without defined namelists now automatically generate names based on their primary language(s). qol: More non-human names can be generated in codewords (and other misc. areas) than just lizard names. /🆑 |
||
|
san7890
|
5f44545da8 |
Moves "sprite accessories" (e.g. Hair, Undergarments, Mutant Bits) from GLOB to a datasystem (#82847)
This is just a revitalization of #80275. ## About The Pull Request On the tin, basically demotes everything related to setting up and storing these bulky lists generated from reading `/datum/sprite_accessory` subtypes from living in a global space that will instead be in a compartmentalized subsystem for accesses. Also a lot of code modernization and micro-improvements (unquantifiable) ## Why It's Good For The Game Same exact expected results, just accessed in a different way.  There's a few reasons why I want this to happen. * The `GLOB` space is too clogged. There are at least a thousand variables on `GLOB`, and it's extremely painful to access stuff on production/local through view variables when you're debugging stuff like this. It's also painful when there is stuff that _should_ live on `GLOB` that you might want to see in VV/Debugger but are forced to either have to scroll a mile to find what you want or wait a long while for it to load. The less bulky lists we have of stored initialized datums, the better. * `make_datum_reference_lists()` is a consequence of wack stuff like this where we're reliant on certain things being initialized in the `GLOB` portion of world initialization _before_ subsystems/static variables load - most of these datum lists in the aforementioned proc doesn't _really_ need to be ready to go before `world.New()` for example. We'll sadly have to abuse `PreInit()` for now, but it really is something that has to be ready to go due the critical dependence that stuff like Preferences has on it. * We don't have to have the procs live in a global namespace either. Instead of passing in `GLOB.XList` or `DSstorage.XList` every single time, we can instead just move the proc setup on the subsystem and use `XList` in a more native fashion. * It's easier to find what you need. To me, it's a lot nicer to ctrl+click the DS and go to the variables to find something I'm looking for instead of having to scavenge around for any footprint/trace of the global I want to look for. This is more trivial than the other two, but that's something I like to think about when I go to bed. I also had to refactor a bit of the code to accommodate the limitations of the new DS system, but it should be a lot cleaner anyways. ## Changelog Not relevant --- Also nothing should have broken but it's a good thing we have screenshot unit tests to prove me wrong. |
||
|
san7890
|
c403a6eccc |
Wraps lowertext() to ensure proper stringification. (#82442)
## About The Pull Request Fixes #82440 This PR just creates a new macro, `LOWER_TEXT()` (yes the irony is not lost on me) to wrap around all calls of `lowertext()` and ensure that whatever we input into that proc will be stringified using the `"[]"` (or `tostring()` for the nerds) operator. very simple. I also added a linter to enforce this (and prevent all forms of regression) because I think that machines should do the menial work and we shouldn't expect maintainers to remember this, let me know if you disagree. if there is a time when it should be opted out for some reason, the linter does respect it if you wrap your input with the `UNLINT()` function. |
||
|
John Willard
|
611c48be40 |
Monkeys now use height offset (and monkey tail works) (#81598)
This PR adds the ability for monkeys to wear any jumpsuit in the game, and adds support for them to wear things like coats, gloves, and shoes (though this cannot be obtained in-game and is solely achieved through admins, which I also improved a bit upon by adding a defined bitfield for no equip flags). This reverts a lot of changes from https://github.com/tgstation/tgstation/pull/73325 - We no longer check height from limbs and such to bring sprites down, instead monkeys now work more similarly to humans, so the entire PR was made irrelevant, and I didn't really want to leave around dead code for the sake of having a human with longer legs. I've now also added support for Dwarfism, which makes monkeys look even smaller. Very minor change but at least now the mutation doesn't feel like it does literally nothing to monkeys (since they can already walk over tables). Here's a few examples of how it can appear in game (purely for demonstration, as it is currently intentionally made impossible to obtain in-game, though if someone wants to change that post-this PR now that support is added, feel free): Tails have been broken for a while now, the only reason you see them in-game is because they are baked into the monkey sprites. This fixes that, which means humans can now get monkey tails implanted into them (hell yeah) and monkeys can have their tails removed (also hell yeah) |
||
|
AnturK
|
1f1669e334 | Fixes banned/days remaining preferences display for non-dynamic ruleset antagonists. (#82506) | ||
|
Skeleton-In-Disguise
|
da3294d896 |
adds preferences to transhumanist (#82435)
## About The Pull Request You may remember this, that's because I accidentally deleted it before while trying to change things. Anyways! Adds drop-down selections and new options to transhumanist. also fixes a minor typo Previously, you could choose your replaced limb by taking prosthetic limb, setting what you want changed, and then switching to transhumanist, since they used the same preference previously. ## Why It's Good For The Game Transhumanist felt strange because it was hypothetically a voluntary operation, but the augmentation clinic just spun the wheel on what you got replaced. From a role-playing perspective, being unable to choose is uninteresting and confusing. Also it always says your limb being was being replaced with a robotic arm and that annoyed me. Now that you are able to select your replacement part, I've added two new options, the robotic voice box, good for a more prominent change then a limb that will be hidden for most of a round, and flashlight eyes, for when you are truly committed to being rushed directly to robotics seeing the bright future ahead of humanity! ## Changelog 🆑 add: Transhumanist now allows you to select your augmentation add: Transhumanist can now provide a robotic voice box, or flashlight eyes spellcheck: Transhumanist's roundstart text has been re-written to not be wrong /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
DATAxPUNGED
|
a02dc8221c |
[NO GBP] Fixes Alcoholic quirk selection and addiction in general not being forever. (#82403)
## About The Pull Request Fixes #82346 Also fixes a bug where Junkie, Smoker, and Alcoholic would not give you more addiction once yours ran out. ## Changelog 🆑 fix: Fixes Alcoholic quirk selection fix: Fixes Junkie, Smoker, and Alcoholic not giving you more addiction when you come clean. /🆑 |
||
|
DATAxPUNGED
|
a155c23d2e |
[THE QUIRKENING] Adds customization options to Organ Prosthetic, Junkie, Smoker, and Alcoholic! (#82051)
## About The Pull Request Lets people pick: - The shitty organ they spawn with (still has the restrictions of not being possible to get heart when you are a plasmamen, for example) - Their favorite alcohol to blackout with - Their favorite brand of cigs - Their favorite brand of drugs! A lot of the code was taken from a downstream, made by @Floofies, i already had my own implementation but it was buggy and not nearly as clean, then i was made aware of theirs. ## Why It's Good For The Game Character Customization is good and fun and lets people have more choice in their roleplay. ## Changelog 🆑 add: Prosthetic organ users are now allowed to pick what they want to start with. add: Junkie of all kinds, including smokers and alcoholics, are also able to pick their favorite type. /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
_0Steven
|
bbbeb9b20e |
Allow hemiplegic users to pick which side is disabled (#81992)
## About The Pull Request Broadly this code is copied over from the preference code used for picking prosthetic limbs, with a few changes to make it fit. It also changes how the quirk displays in the medical records, now mentioning which side is disabled instead of just half their body. ## Why It's Good For The Game So of course, first and foremost, I want it personally. I'm now running a hemiplegic character on Manuel, and I want to able to pick which side is hemiplegic to match me using heterochromatic eyes to make it look like they're missing an eye. It's minor, but I think it'd be nice. Then, because of that, I think it'd be nice to have for posterity. If I want it, and I can code it, then the next person who wants it doesn't have to, y'know? Lastly, gameplay-wise, it doesn't really matter which side is hemiplegic, you're permanently missing an arm and a leg either way. So I feel there's practically no 'powergaming concerns' to be had when it's this utter shitass to use regardless and the benefits to be gained would be infinitesimally small in comparison. ## Changelog 🆑 add: Hemiplegic now lets you pick which side is disabled. add: The medical records text for hemiplegics now shows which side is disabled. /🆑 |
||
|
Dani Glore
|
495fde6a2c |
Add: 2 Quirks Configs (#81033)
## About The Pull Request This PR adds two new config options for quirks: - *Flag* `DISABLE_QUIRK_POINTS` - When enabled, disables quirk points balancing. - When enabled, players can select positive quirks without first selecting negative ones. - When enabled, the quirk points balance visually hides itself on the Quirks page. - *Number* `MAX_POSITIVE_QUIRKS` - Limits the maximum quantity of positive quirks which players can select using the Character Preferences page. - I ported this from the old `MAX_QUIRKS` define. - When set to `0`, players won't be able to select any positive quirks, and they won't appear on the Quirks page. - When set to `-1`, players will be able to select any quantity of positive quirks. - When commented-out or undefined, the default is `6`. - When set to `0` or `-1`, the positive quirk balance visually hides itself on the Quirks page. ## Why It's Good For The Game There is some downstream repositories asking for the quirks system to be configurable. Additionally, I always find myself tweaking these values on my own private servers and I thought it would be nice to share my edits. Usually I was simply commenting-out sections of this code in order to get the same result, so it helps to have an official way to disable quirk points. ## Changelog 🆑 A.C.M.O. config: Added two new config flags for quirks, DISABLE_QUIRK_POINTS and MAX_POSITIVE_QUIRKS. /🆑 |
||
|
Time-Green
|
ca61d0f868 |
Turns mush cap into an extorgan (#80952)
Pretty self explanatory. I suppose this isn't a 100% fix or refactor, since it adds a UI for their features and makes it removable, but also these never happen 🆑 code: The mushroom cap is now an external organ (jungle station will never happen) fix: Mushpeople caps are no longer solid black /🆑 |
||
|
Mothblocks
|
723ced5d7b |
Make spritesheets cacheable by default, killing a lot of overtime in the round start spike (#80522)
## About The Pull Request Makes all spritesheets cache by default. This wasn't the case originally because some spritesheets like vending machines relied on in world state, but none of them do anymore because that's whack. Also fixes a bug that would cause half completed caches to break other stuff. This didn't happen in real gameplay, but would've happened if you tried to change cachable on anything while you already had a tmp folder. ## Changelog 🆑 fix: Cut down a significant amount of time that caused the start of rounds to lag. /🆑 |
||
|
LemonInTheDark
|
f03084c1ca |
FOV is Dead (Long Live FOV) (#80062)
## About The Pull Request FOV as it is currently implemented is incompatible* with wallening. I'm doin wallening, so we gotta redo things here. The issue is the masking of mobs. Wallening relies on sidemap (layering based off physical position), which only works on things on the same plane (because planes are basically sheets we render down onto) So rather then masking mobs, let's reuse the masking idea from old fov, and use it to cut out a bit of the game render plane, and blur/over-saturate the bit that's masked out. My hope is this makes things visible in light, but not as much in darkness, alongside making more vivid shit more easily seen (just like real life) Here's some videos, what follows after is the commits I care about (since I had to rip a bunch of planes to nothing, so the files changed tab might be a bit of a mess) Oh also I had to remove the darkness pref since the darkness is doing a lot of the heavy lifting now. I'm sorry. Edit: NEW FOV SPRITES! Thanks dongle your aviator glasses will guide us to a better future. https://github.com/tgstation/tgstation/assets/58055496/afa9eeb8-8b7b-4364-b0c0-7ac8070b5609 https://github.com/tgstation/tgstation/assets/58055496/0eff040c-8bf1-47e4-a4f3-dac56fb2ccc8 ## Commits I Care About [Implements something like fov, but without the planes as layers hell](https://github.com/tgstation/tgstation/commit/a604c7b1c8d74cd27af4d806d85892c1f7e35ba8) Rather then masking out mobs standing behind us, we use a combo color matrix and blur filter to make the stuff covered by fov harder to see. We achive this by splitting the game plane into two, masking both by fov (one normally and one inversely), and then applying effects to one of the two. I want to make the fov fullscreens more gradient, but as an effect this is a good start [Removes WALL_PLANE_UPPER by adding a WALL_PLANE overlay to material walls (init cost comes here)](https://github.com/tgstation/tgstation/commit/25489337392f708cb337fbf05a2329eacdfc5346) @Mothblocks see this. comment in commit explains further but uh, we need to draw material walls to the light mask plane so things actually can be seen on them, but we can't do that and also have them be big, so they get an overlay. Sorry, slight init time bump, about 0.5 seconds. I can kill it with wallening. [Moves SEETHROUGH_PLANE above ABOVE_GAME_PLANE](https://github.com/tgstation/tgstation/commit/beec4c00e01d34a04fba7c2bb98a9b70d27ead82) I don't think it actually wants to draw here @Time-Green I think this was you so pinging for opinion [Resprites FOV masks to be clean (and more consistent)](https://github.com/tgstation/tgstation/pull/80062/commits/f02ad13696b3b17658af612c62848b48609d785d) [f02ad13](https://github.com/tgstation/tgstation/pull/80062/commits/f02ad13696b3b17658af612c62848b48609d785d) This is 100% donglesplonge's work, he's spent a week or so going back and forth with me sharpening these to a mirror shine, real chill ## Why It's Good For The Game Walls are closing in ## Changelog 🆑 LemonInTheDark, Donglesplonge image: Redoes fov "mask" sprites. They're clean, have a very pleasant dithering effect, and look real fuckin good! del: Changed FOV, it no longer hides mobs, instead it blurs the hidden area, and makes it a bit darker/oversaturated /🆑 ###### * It's technically possible if we start using render targets to create 2 sets of sources but that's insane and we aren't doing it |
||
|
Jacquerel
|
90b974071d |
Sign up for Cargorilla from the lobby (#79776)
## About The Pull Request If the station rolls the "Cargo Gorilla" trait, a button will now be visible on the lobby. Clicking on this button before the round has started will add you to a list of participants, one of whom will be selected to become a gorilla when the round begins. If nobody signs up (because they're really boring I guess) the job will instead appear on the latejoin menu. Once someone has become the gorilla the button will disappear.  While implementing this I noticed that an inverted check means we were never populating the "GLOB.cargo_sloth" field which means the station trait wasn't even working. BEHIND THE SCENES This also adds a generic "job station trait" which can be expanded in the future. Future developers can extend this to add other "rare jobs" with relative ease. By default I have made it so all subtypes of this trait are mutually exclusive, only one can roll at a time. This also means that I have converted "cargo gorilla" into a job, which applies most of the code previously located in the mob's typepath or in the station trait. The fact that it is a job means that **admins** can enable any number of gorillas to be present on the latejoin menu (but not the roundstart one, as it is not possible to add Cargo Gorilla to your occupation preferences) if they so desire. The random beurocratic station trait, event, and traitor item (and the job console) are not able to add gorilla slots. Because I changed "Cargo Gorilla" to a job it now no longer exists on the map until a player gains the role, and there wasn't a non-hacky way to copy the name of this round's cargo sloth. Instead I just added a small cargo gorilla name list. ## Why It's Good For The Game Makes the presence of a fun trait more visible to players. Means that people who aren't observing get a chance to be a monkey. This is a framework several other people have wanted to exist for their own features. ## Changelog 🆑 Jacquerel and Fikou qol: If the station rolls the "Cargo Gorilla" station trait. you will be able to sign up for the role from the game lobby. qol: If nobody signs up to be the Cargo Gorilla then you can select it from the Late Join menu and arrive on the arrival shuttle. fix: The Cargo Gorilla will actually spawn. /🆑 |
||
|
aaaa1023
|
7a7a206754 |
pixel perfect 4x (#79660)
## About The Pull Request Adds pixel perfect 4x and 4.5x scaling. I tested it and it seems to work though 4.5 scaling causes very slightly distorted pixel sizes. There's also a bit of letterboxing but I think that happens with all of the pixel perfect settings. ## Why It's Good For The Game better fits 4k monitors and isn't stretch to fit ## Changelog 🆑 qol: adds pixel perfect 4x, 4.5x, and 5x /🆑 |
||
|
Rhials
|
33b82e8bef |
Nukie Aliases and Some Hairspray (#79653)
## About The Pull Request Nuclear operatives now receive an alias for their first name, instead of a default human name. This alias is randomly selected, or can be set in your name preferences.  This does not affect Operative Leaders selecting the team's last name. This means that **operative names are now "[Alias chosen by player] [Team name chosen by leader]".** There is a list of default aliases, in case no alias has been selected. I randomly came up with a bunch of stuff from the top of my head and put it in a text file. If you think of something better, choose it yourself! **OH, ALSO:** There's some hair dye in the Firebase dorms now. Useful if you want to further differentiate between your Operative/Crew characters, or just look pretty. ## Why It's Good For The Game No longer shall nukies be "your character but with a different name". Now you can give yourself a bit more identity instead of just a random name. More customization options means more opportunities for people doing interesting stuff, and to branch away from the beaten path of boring meta strats. ## Changelog 🆑 Rhials add: Nuclear Operatives, in an attempt to appeal to the more "tacticool" members of their cause, have begun using callsigns to designate themselves. Check your preferences to set your Operative Alias! qol: At the request of the more vain members of the cause, hair dye has been added to the Operative Firebase dorms. /🆑 |
||
|
Jeremiah
|
ba5ae73dac |
Adds more bitrunning antagonists + fixes (READY) (#79522)
## About The Pull Request Reopened #78997 Larger patch for bitrunning that addresses a few issues. - Two new antagonists: cyber tac and netguardian - Quantum server emag opportunity - Modular mob packs: Like random spawners, but for groups - Antag spawning fixed: vdom antags now have up to a 10% chance to spawn based on domains loaded - Virtual domains are no longer all fullbright by default, only the outdoorsy ones - Actually deletes legion map file, since it was removed in #79424 <details> <summary>images</summary> The netguardian prime   The glitch effect - this mob is being mutated  Cyber tac (t2 antagonist)  </details> ## Why It's Good For The Game - Bitrunning antagonists are so incredibly rare that it's underwhelming to play as one for the solid second they offer if you even get the role - Bitrunners had basically no traitor route to follow, they became assistants with black outfits Fixes #79465 <details> <summary>More info</summary> Bitrunners don't have any type of traitor options. If they're made into traitors, there's nothing bitrunner related they can do, and their access is particularly bad so it's like they're a worse assistant. I've coupled this with the bitrunning antagonist system, which is now fixed.\. Bitrunners can now attempt to coax these entities to come onto the station, however they are not given any form of allegiance for doing so (and are quite counterable). Previously, vdom antagonists relied on so many factors to spawn that it basically wouldn't happen. Now, it runs on the server each time there is a map loaded, with increasing probability as the round progresses. This builds up the list of spawnable antagonists, of which two are new, including an entirely new giant mech megafauna. This is the first "megafauna-esque" basic mob in the game. Its AI is bad, it's really only meant to be player controlled, but this does mean an admin can spawn them. Being mech, they are very counterable with ion rifles and the like. Several refactors, rewrites, and overall bug fixes are included in this PR. Lastly, I added a framework for making bitrunner maps more random, the modular mob spawning system, which works in conjunction with random crate locations. </details> ## Changelog jlsnow301, infraredbaron 🆑 add: Bitrunning Patch 1 features a host of changes! add: Added randomized mobs to virtual domains, which will be indicated with a unique icon. add: New emag interaction with the quantum server. Antags will spawn more frequently, and they can hack themselves onto the station. You have been warned. add: Both living and dead players can now see which mob is going to spawn an antagonist in the vdom. add: Two new vdom antagonists: Cyber Tac and the NetGuardian. These unlock at specific thresholds. balance: You can no longer stack copies of the same ability with bitrunning disks. balance: Some of the disk items have been replaced with stronger versions. fix: You can no longer spy on crew using the advanced camera console on syndicate assault. fix: Fixed the spawning mechanism of virtual domain antagonists. You should now have a chance of playing as one. This chance increases as more domains are completed. fix: Vdom antagonists shouldn't spawn at the end of the run any longer. fix: The preference for vdom antagonists has been changed to factor in the new types. Check your preferences! fix: The quantum server will now show its balloon alerts to all observers. fix: Random domains should be fully random again. /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
nikothedude
|
49414f7821 |
Adds a little button to quirks that allows for relatively easy customization (#79251)
## About The Pull Request Title. Adds a little cog button that expands a popper with a preference list of relevant preferences. https://github.com/tgstation/tgstation/assets/59709059/5718ad5d-fadb-489f-9a31-9e7173c6f35a ## Why It's Good For The Game Customizable quirks are cool. Having a proper framework for customizable quirks is even cooler. Good UX is even COOLER. ## Changelog 🆑 code: Quirks are now customizable on the quirks page instead of on the character prefs page /🆑 --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
nikothedude
|
4e4e8266ac |
Allows TGUI labelled lists to use tooltips, and enables this behavior on preferencelists + adds descs to most character preferences (#79356)
## About The Pull Request Title. https://github.com/tgstation/tgstation/assets/59709059/c9fa7d41-6ca4-4b8b-97ec-fdfdd437ce25 ## Why It's Good For The Game The inability to use descriptions in character preferences really limits the context you can give to readers, which becomes a big problem when preferences become complicated or laden with policy that must be given to the reader. ## Changelog 🆑 qol: Character preferences now have descriptions as tooltips - hover over their names to see them /🆑 |
||
|
MrMelbert
|
04936d9a5a |
Adds Food Allergies as a counterpart to Medicine Allergies (#79118)
## About The Pull Request Adds food allergies as a counterpart to medicinal allergies. This is about as you would expect. Eating food you are allergic to causes Anaphylaxis, which can be cured with epinephrine. If you are not cured rapidly, you will shortly fall into a coma and die. There is a preference for choosing your character's allergy. Not all food types are viable allergen types: Only `"Alcohol", "Bugs", "Dairy", "Fruit", "Grain", "Meat", "Nuts", "Seafood", "Sugar", "Vegetables"`. You also get a dogtag like med allergies. Minor implementation detail: I added a "dangerous" level of food quality / scale, so I gave it to the Death Sandwich. ## Why It's Good For The Game This was a request, and I saw it fairly harmless, so I said why not. Similar to Medicine Allergy, it adds a small mechanic to concern yourself with when you visit the kitchen, encouraging you to get a bit more familiar with food types before diving into food at the kitchen. As it is not as impactful as Medicine Allergy, it is only a -2 quirk. ## Changelog 🆑 Melbert add: Adds Food Allergies as a -2 quirk. You can select which food you're allergic to or rock a random option. /🆑 |
||
|
Cruix
|
f31532ed89 |
Added a larger afro hairstyle (#78709)
## About The Pull Request It's exactly 6 months from April 1st, so this is a date for very serious PRs only. We've all seen that one tip at the beginning of the round:  So the afro must be really big, right? Having one must be a very large sacrifice in the realm of pixel-based combat, right? WRONG.  This is the largest afro currently available. Absolutely pathetic. It's not even the largest hairstyle in terms of pixel volume. Here's a bigger one.   The sprite overlaps the tile above by 6 pixels, which is noticeable, but not enough to interfere significantly with gameplay (apart from having a sacrificially larger hitbox).  This could already be done by creating a new .dmi file with larger, non-square pixel bounds, but that's a less than elegant solution. Instead, added a y offset var to hair sprite accessory datums. ## Why It's Good For The Game The self-expressive merits of having more hairstyles should be self-evident, so I will make a mathematical argument here. Everyone knows that the coolness of an afro is determined by its volume. As a 2-D sprite, the closet equivalent we have is area. An afro is, approximately, a circle, so the area can be calculated as πR^2, with R being the maximum distance from the top of the head to the top of the sprite bounding box. The current largest afro has a height of 6 pixels. This new afro has a height of 12 pixels. As a result, impressiveness increases by a factor of 4: ```math coolness_{new\ \ afro} \over coolness_{old\ \ afro} ``` ```math π12^2 \over π6^2 ``` ```math 12^2 \over 6^2 ``` ```math 144 \over 36 ``` ```math 4 ``` This means that, for the intrusion of a mere 6 pixels into our northern neighbor's bounding box, we get **quadruple** the coolness. ## Changelog 🆑 add: Added Afro (Huge) hairstyle /🆑 --------- Co-authored-by: Cruix <discoveryian2@gmail.com> |
||
|
Cruix
|
d1df5e1755 |
Fixed spritesheet images for sprite accessories with no icon_state (#78710)
## About The Pull Request Some sprite accessories (such as bald and shaved) do not have icon states, and these are stored as nulls in the GLOB lists. When generating sprite sheets, nulls were simply returning the basic head icon without scaling it in the same manner as the other sprites were scaled. Old:  New:  ## Why It's Good For The Game Having some hairstyles be scaled differently in the spritesheets looks bad. ## Changelog 🆑 fix: Some icons for selecting character preferences are no longer scaled incorrectly. /🆑 Co-authored-by: Cruix <discoveryian2@gmail.com> |
||
|
DATAxPUNGED
|
33b2124112 |
You can now pick the limb you want replaced with the Prosthetic Limb Quirk. (#78517)
## About The Pull Request The Prosthetic Limb quirk allows you to pick the limb you want. The default is still random ## Why It's Good For The Game Good for character customization, which is always nice. Statics who got a specific limb replaced can now represent that properly in-game. Also, this makes the quirk show up on the dummy on the character customization again. This *does* cause a slight issue where when you switch to another character, it keeps the previous' skin color, but it's minor enough that i think the benefits are worth the drawback. If asked i will make it not appear on the dummy though. ## Changelog DATA_, with great help from Kapu🆑 add: You can now choose the prosthetic you want with the Prosthetic Limb quirk. /🆑 |
||
|
Iamgoofball
|
dd87788877 |
TTS: Gas Mask muffling, Hailer Mask voice effects, support for more filters that use samplerate, voice effects for lizards, ethereals, and xenomorphs. (#78567)
## About The Pull Request https://github.com/tgstation/tgstation/assets/4081722/7c8df2e2-8795-4048-b11e-e831f749a097 https://github.com/tgstation/tgstation/assets/4081722/d0bec7fd-25b1-4bdd-98a6-0ebfea749551 https://github.com/tgstation/tgstation/assets/4081722/31c0259a-2bd4-4575-a758-a2044ccf17b0 ## Why It's Good For The Game Improves TTS audio immersion. ## Changelog 🆑 qol: Gas masks now muffle your voice with TTS. qol: Security Hailer masks now disguise your voice to protect your right to brutalize greytiders. qol: Lizards, Ethereals, and Xenomorphs now have a vocal effect. qol: Security Records now show someone's voice name. /🆑 |
||
|
Jeremiah
|
a3849062b8 |
Feature: bitrunner, a new supply role (READY) (#77259)
## About The Pull Request [Design doc](https://hackmd.io/@shadowh4nd/r1P7atPjn) Adds a new supply role centered on short dungeon-esque runs with a focus on unifying the job with the fun part. Some virtual domains are combat related, some are silly, some focus on "objectives". Avatar health is linked to your physical presence and retries are limited. <details> <summary>Photos, WIP</summary> Net pod stasis  Server loaded  Server cooldown  the quantum console UI  Cyber police antag page  A safehouse  Domain info page, every domain gets this (and sometimes help text)  Me getting steamrolled in one of the missions  Ghost roles getting notified that server is kicking them out  Players enjoying the new combat missions  Players exploring some of the virtual maps  (Not part of the PR, but)  New bitrunner vendor  </details> ## Why It's Good For The Game Content, firstly, and moreso being supply department content. The framework that this implements is a great (preauthorized) replacement for two systems which are collecting dust: BEPIS and the gateway. They integrate into this system and it's a direct upgrade. This adds a way for the players on station to generate materials (if that remains). The nice part about it is that I can throw balance and believability to the wind, as unlike its unrelated predecessor VR or away missions, bitrunning entirely washes its hands of the map and mobs each reboot. It offers a very expandable map framework to add content and it's all fairly well documented. I'd like to add a feature that represents the idea that jobs don't have to be mundane and "external" jobs can stay tied to the main gameplay loop. ## Changelog jlsnow301, kinneb, mmmiracles, ical92, spockye 🆑 add: Adds Bitrunning to supply department- a semi-offstation role that rewards teamwork. add: Adds new machines to complement the job- net pod, quantum server, quantum consoles, and the nexacache vendor. add: Adds several new maps which can be loaded and unloaded at will. add: Some flair for the new bitrunning vendor. add: Adds a new antagonist for the virtual domain only. Short lived ghost role that fights bitrunners. del: Removes the BEPIS machine, moves its tech into the Bitrunning vendor. /🆑 <!-- 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. --> --------- Co-authored-by: MMMiracles <lolaccount1@hotmail.com> Co-authored-by: Ical <wolfsgamingtips@gmail.com> Co-authored-by: spockye <79304582+spockye@users.noreply.github.com> Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com> Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com> |
||
|
Rhials
|
9ae14f62a9 |
Nuclear operatives can now be other species. Pref toggle to always be human as operative (#77970)
## About The Pull Request  When #16075 was created in the ancient year of 2016, it was a stopgap solution to plasmamen spawning in with a regular nukie outfits and burning to death. As a result, nukies have been human-only for the past seven years. I come to you today to remove the stopgap, and once again enable non-human nukies. This was approved in the past (#59590), and I'm assuming that approval is still valid. Let's take a look at how things work: Spawning in as a Nuclear Operative (leader included), Lone Operative, Clown Operative, or Reinforcement will now set your species to the one if your prefs. That means lizard, cat, plasma, and ethereal nukies are all on the table now. Plasmamen now have their own syndicate envirohelm/suit combo. It doesn't look fantastic (it's just a palette swapped roboticists envirosuit) but I think it's serviceable at least. When the operative antag datum is given, and the owner is a plasmamen, they will instead be given an alternate outfit with these equipped. Loneop plasmamen will instead be given a MODsuit with the plasma stabilizer MODule installed. These MODules also spawn in the firebase lockers in case they're needed. **But what about the AI?** Fortunately for the balancebrains in the crowd, there is a preference (enabled by default!) to always roll human as an operative. The AI still has to reasonably assume that nukies are human until proven otherwise so please don't think this will affect the rules of engagement for anyone not _directly opting into it._  (This pref will only appear if you have a nukie job enabled in the antag menu!) Huge thanks to Melbert who let me peek at his code on a branch trying to do the same thing. My approach ended up being entirely on the antag datum, with nothing on the job datum. ## Why It's Good For The Game Rectifies a curious change made long long ago. Expands customization to nukies while not affecting balance for those who care. ## Changelog 🆑 Rhials add: Nuclear operatives have expanded the scope of their hiring practices. Members of all species can now roll nukie! qol: The preferences menu now has an option to always be human when being selected for a nuclear operative role. Check it out! image: Plasmaman operative envirosuits. /🆑 |
||
|
Ghom
|
fed2abfc05 |
Added sounds for unlocking achievements. (#77968)
## About The Pull Request Unlocking an achievement now plays a sound. Which sound is played depends on the associated preference of the player, found in the Sound category of the game preferences UI. The current options are a [glockenspiel ping](https://freesound.org/people/FunWithSound/sounds/456965/), a [beeps jingle](https://freesound.org/people/Eponn/sounds/619838/) and a ["tada!" fanfare](https://freesound.org/people/plasterbrain/sounds/397355/), with the obvious fourth option to not play a sound at all. All sounds are from Freesound and are public domain. As such, attributions are not required. The sounds have been also converted to .OGG mono 44.1 Khz in accordance to the standards. ## Why It's Good For The Game Enhancing the player feedback for unlocking an achievement with choosable sounds. ## Changelog 🆑 sound: Unlocking an achievement now plays a sound by default. You can change it in the Sound category of the game preferences. /🆑 |
||
|
Nerevar
|
0345de3582 |
New Backpack Type: Messenger Bags! (#77871)
## About The Pull Request  From downstream with love! These are mechanically identical to a normal backpack or satchel, just with more drip. Also a little bit of :o)  These will exist both in prefs and in drobes/lockers.  Sprites by Zydras. ## Why It's Good For The Game We love fashion here. We love it so much. And most backpacks are too in-your-face to fit well with a lot of 'fits. ## Changelog 🆑 Nerev4r & Zydras image: Adds messenger bags to character setup and drobes/lockers! /🆑 --------- Co-authored-by: Snakebittenn <12636964+Snakebittenn@users.noreply.github.com> Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com> |
