mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-06-19 13:14:05 +01:00
088409bbe376a7adcd4d1fb747cf4a5e4f257c5b
914 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 grungussuss
|
58501dce77 |
Reorganizes the sound folder (#86726)
## 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 /🆑 |
||
|
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. /🆑 |
||
|
MrMelbert
|
aefa22166c |
Heretic Influences use alt appearances (so ghosts can now see them (semi-transparent)) (#85932)
## About The Pull Request Removes the rather overcomplicated system behind heretic influences and makes them use alt appearances Fixes a few bugs involving alt appearances that I noticed in making them I made this PR 7 months ago and forgot to Pr it ## Why It's Good For The Game Less complex codes and lets observers get a cut in on the action. Should fix #77530 ## Changelog 🆑 Melbert refactor: Refactored heretic influences a tiny bit, now ghosts can see them! Report any oddities. /🆑 |
||
|
tgstation-ci[bot]
|
9a9b428b61 |
Wallening Revert [MDB Ignore][IDB Ignore] (#86161)
This PR is reverting the wallening by reverting everything up to
|
||
|
John Willard
|
1880003270 |
Reworks silicon/ai access checking & fixes some ui_act's (#84964)
## About The Pull Request Currently to check for Silicon access, we do: ``if is silicon or is admin ghost or has unlimited silicon privileges or has machine remote in hand`` What has unlimited silicon privileges? Bots, Drones, and admin ghosts. To check for AI access, it just checks for AI instead of silicon, and doesnt check for unlimited silicon privileges. This was kinda silly, so I thought I should make this a little easier to understand. Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or ``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost, since now instead of being a var on the client, we moved it to using the same trait but giving it to the client instead, but since we have to keep parity with previous functionality (admins can spawn in and not have this on, it only works while as a ghost), I kept previous checks as well. No more type checks, removes a silly var on the mob level and another on the client. Now while I was doing this, I found a lot of tgui's ``ui_act`` still uses ``usr`` and the wrong args, so I fixed those wherever I saw them, and used a mass replace for the args. Other changes: - machinery's ``ui_act`` from https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin ghosts no longer get kicked off things not on cameras. This was my fault, I overlooked this when adding Human AI. - Human AI's wand gives AI control as long as it's in your hand, you can swap to your offhand. I hope this doesn't end up going horribly, otherwise I'll revert this part. It should let human AIs not have their UI closed on them when swapping to eat food or use their door wand or whatnot. - Bots previously had special checks to scan reagents and be unobservant, I replaced this with giving them the trait. I also fixed an instance of unobservant not being used, so now statues don't affect the basic creature, whatever that is. ## Why It's Good For The Game This is an easier to understand way of handling silicon access and makes these mobs more consistent between eachother. Other than what I've mentioned above, this should have no impact on gameplay itself. ## Changelog 🆑 fix: Statues don't count as eyes to creatures. fix: Human AIs and Admin ghosts no longer get kicked off of machines that aren't on cameranets. /🆑 |
||
|
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>
|
||
|
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> |
||
|
Holoo
|
f4ea731e09 |
fixes ghost huds (#85164)
## About The Pull Request Fixes https://github.com/tgstation/tgstation/issues/85120 I think it was introduced by https://github.com/tgstation/tgstation/pull/84984 ## Why It's Good For The Game fix good ## Changelog 🆑 fix: fixed ghost huds /🆑 |
||
|
SmArtKar
|
dfb12f91d6 |
HUD traits now apply their corresponding hud automatically. Most clothing/item/etc sources of HUDs now only use traits (#84984)
## About The Pull Request Currently if you want to apply a HUD you usually add both its trait and the HUD itself. Only exceptions are things like simplemobs where you should avoid adding the hud trait since it adds security/med DB access and such, but there is no cases where you'd want to apply the trait and not apply the hud. Requested by Melbert about a week ago.  ## Why It's Good For The Game This makes working with HUDs significantly easier, as you no longer have to bother with manually adding/removing them. Also potentially removes an edge case where if your hud could get removed while keeping the trait. ## Changelog 🆑 refactor: HUD traits now apply their corresponding hud automatically /🆑 |
||
|
SmArtKar
|
c5ac7b7297 |
Ghosts once again can see people's true names and roundstart jobs (#84951)
## About The Pull Request #83186 made it so ghosts are fooled by disguises, like wearing a mask and an ID. This PR fixes that behavior, instead always displaying the person's real name and their face/ID name (if their face name is somehow different from real name) in brackets. Additionally, this PR makes orbit menu prioritize "real" job name and icon, aka the ones the person spawned with. If they don't have an assigned job, it will fall back to current behavior of looking it up from their ID. Also, searching people includes both their fake and real name. ## Why It's Good For The Game Ghosts really, really shouldn't be fooled by wearing a gas mask and an ID. **Especially** admin ghosts. ## Changelog 🆑 qol: Ghost orbit menu now always displays person's real name and their roundstart job and cannot be fooled by disguises. /🆑 |
||
|
SmArtKar
|
c3f66f6274 |
Stopping orbiting now automatically breaks you out of autoobserve (#84987)
## About The Pull Request If you move off someone you automatically stop autoobserve (stop viewing their UI and seeing from their perspective) ## Why It's Good For The Game Only way to stop autoobserve right now is via orbit UI, and following in chat does not break you out of it either. And if you have closed your orbit window, you need to open it from ghost tab as you no longer have a button for it, which can be annoying. ## Changelog 🆑 qol: Stopping orbiting now automatically breaks you out of autoobserve /🆑 |
||
|
The Sharkening
|
b643391e5a |
Ambience Buzz Handling Changes + Ambience buzz requires enviorment power (#84479)
## About The Pull Request Partial port of https://github.com/DaedalusDock/daedalusdock/pull/996 - Fixes ambience prefrence inconsistancy issues with Observers unable to turn off the ambience buzz. - Ambience buzz requires a working, existing, charged APC with power to the enviorment. - Moves ``update_ambience_area()`` and ``refresh_looping_ambience()`` into ``code\controllers\subsystem\ambience.dm`` for better organization. ## Why It's Good For The Game Mostly to tackle a prefrence bug where ghosts are unable to turn off ambience buzz. But this also includes ambience buzz requiring a powered area. Makes the station feel more dead when there's no enviorment power. There should also be no buzzing inside space. ## Changelog 🆑 Kapu (ported by StrangeWeirdKitten) fix: Ambience buzz will now respect ship ambience prefrences for observers. sound: Ambience buzz requires APC enviorment power to function /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
SyncIt21
|
9c9a5d28ff |
Some alt & ctrl click improvements (#84203)
## About The Pull Request Improved code quality of both so they resemble each other. Some of the new specs are as follows 1. Moved` COMSIG_CLICK_ALT` & `COMSIG_CLICK_ALT_SECONDARY` up i.e. before `can_perform_action()` making them pure hooks not bound by any action checks giving components full control over them 2. Removed range check(`CAN_I_SEE`) & view check(`is_blind()`) out of the base alt click proc. They now only apply to living mobs and don't apply to ghosts(ghosts don't get blind & see everything) & revenants (the range check still applies for revenants though). This was actually a bug because these 2 checks were only meant to see if the loot panel could be opened (as stated in https://github.com/tgstation/tgstation/pull/83736#discussion_r1628097941) but because they are at the top of the proc they also apply to all alt click actions which is not intended. Also, by moving these checks down to mob subtype levels some of the snowflake checks like this https://github.com/tgstation/tgstation/blob/7579e0e1734ee40b33ce1fd3fc5c2dd08fe30404/code/_onclick/click_alt.dm#L23 can be removed. We should not check for subtypes within the parent type proc but instead have subtypes override their parent procs to implement custom behaviour 3. Removed redundant signals like` COMSIG_XENO_SLIME_CLICK_ALT` in favour of just `COMSIG_MOB_ALTCLICKON` 4. While looking for alt click signal overrides I found alt click for style meter was run timing, that's fixed now ## Changelog 🆑 fix: alt click runtime no more when using style meter code: improved alt & ctrl click code /🆑 |
||
|
SyncIt21
|
c60556217e |
[NO GBP] Admin ctrl+shift works only on the clicked ghost (#84005)
## About The Pull Request - Fixes #83995 ## Changelog 🆑 fix: ctrl+shift clicking on a ghost will only quick spawn that clicked target and not you /🆑 |
||
|
Afevis
|
4e08eb644c |
Fixes LateSpawn runtime when someone latejoins as the only command member (#83974)
the mob's key was already transferred from this mob to the new one
before this. guess we've been lucky to never see this runtime on live.
```
[2024-06-14 05:40:50.631] RUNTIME: runtime error: Called is_banned_from without specifying a ckey.
- proc name: stack trace (/proc/_stack_trace)
- source file: code/__HELPERS/stack_trace.dm,4
- usr: ShizCalev (/mob/dead/new_player)
- src: null
- usr.loc: null
- call stack:
- stack trace("Called is_banned_from without ...", "code/modules/admin/sql_ban_sys...", 19)
- is banned from(null, /list (/list))
- ShizCalev (/mob/dead/new_player): AttemptLateSpawn("Chief Medical Officer")
- /datum/latejoin_menu (/datum/latejoin_menu): ui act("select_job", /list (/list), /datum/tgui (/datum/tgui), /datum/ui_state/new_player_sta... (/datum/ui_state/new_player_state))
- /datum/tgui (/datum/tgui): on act message("select_job", /list (/list), /datum/ui_state/new_player_sta... (/datum/ui_state/new_player_state))
- /datum/callback/verb_callback (/datum/callback/verb_callback): InvokeAsync()
- /datum/callback/verb_callback (/datum/callback/verb_callback): InvokeAsync()
- /datum/tgui (/datum/tgui): on message("act/select_job", /list (/list), /list (/list))
- /datum/tgui_window (/datum/tgui_window): on message("act/select_job", /list (/list), /list (/list))
- tgui Topic(/list (/list))
- ShizCalev (/client): Topic("type=act%2Fselect_job&payload=...", /list (/list), null, null)
-
```
|
||
|
SyncIt21
|
47be0bffc2 |
Ctrl click refactor (#83784)
## About The Pull Request Same idea as #82656 but for ctrl click & ctrl shift click cause why not - Does your signal & `can_perform_action()` checks using `interaction_flags_click` flags before delegating the event down to `ctrl_click()` proc. - The one new change now is that `ctrl_click()` proc is now blocking, meaning returning `CLICK_ACTION_SUCCESS` or `CLICK_ACTION_BLOCKING` will stop the object from getting grabbed/pulled. So remember to return these values if you want to stop the grab action or return `NONE` if you want to process the click but still want the object to get grabbed as well ## Changelog 🆑 refactor: Ctrl click & Ctrl shift click has been refactored. Please report bugs on GitHub /🆑 |
||
|
SyncIt21
|
b6369a47b4 |
Mouse drag & drop refactored attack chain (#83690)
## About The Pull Request Mouse drag & drop has been refactored into its own attack chain. The flowchart below summarizes it  Brief summary of each proc is as follows **1. `atom/MouseDrop()`** - It is now non overridable. No subtype should ever touch this proc because it performs 2 basic checks a) Measures the time between mouse down & mouse release. If its less than `LENIENCY_TIME`(0.1 seconds) then the operation is not considered a drag but a simple click b) Measures the distance squared between the drag start & end point. If its less than `LENIENCY_DISTANCE`(16 pixels screen space) then the drag is considered too small and is discarded - These 2 sanity checks for drag & drop are applied across all operations without fail **2. `atom/base_mouse_drop_handler()`** - This is where atoms handle mouse drag & drop inside the world. Ideally it is non overridable in most cases because it also performs 2 checks - Is the dragged object & the drop target adjacent to the player?. Screen elements always return true for this case - Additional checks can be enforced by `can_perform_action()` done only on the dragged object. It uses the combined flags of `interaction_flags_mouse_drop` for both the dragged object & drop target to determine if the operation is feasible. We do this only on the dragged object because if both the dragged object & drop target are adjacent to the player then `can_perform_action()` will return the same results when done on either object so it makes no difference. Checks can be bypassed via the `IGNORE_MOUSE_DROP_CHECKS` which is used by huds & screen elements or in case you want to implement your own unique checks **3. `atom/mouse_drop_dragged()`** - Called on the object that is being dragged, drop target passed here as well, subtypes do their stuff here - `COMSIG_MOUSEDROP_ONTO` is sent afterwards. It does not require subtypes to call their parent proc **4. `atom/mouse_drop_receive()`** - Called on the drop target that is receiving the dragged object, subtypes do their stuff here - `COMSIG_MOUSEDROPPED_ONTO` is sent afterwards. It does not require subtypes to call their parent proc ## Why It's Good For The Game Implements basic sanity checks across all drag & drop operations. Allows us to reduce code like this https://github.com/tgstation/tgstation/blob/8c8311e624271a6f6decba8cd643b33b9904534a/code/game/machinery/dna_scanner.dm#L144-L145 Into this ``` if(!iscarbon(target)) return ``` I'm tired of seeing this code pattern `!Adjacent(user) || !user.Adjacent(target)` copy pasted all over the place. Let's just write that at the atom level & be done with it ## Changelog 🆑 refactor: Mouse drag & drop attack chain has been refactored. Report any bugs on GitHub fix: You cannot close the cryo tube on yourself with Alt click like before /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
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) /🆑 |
||
|
_0Steven
|
1e60447ada |
Fix crew records not accounting for quirks for latejoiners (#83740)
## About The Pull Request So crew records weren't actually showing the right quirks for latejoiners, and in at least one instance (heterochromatic eyes) even the fingerprint was wrong. The latter seemed to be caused by a recent fix pr making the quirk actually update your dna, for the sake of paradox clones/changelings. Looking into it, this seemed to be because we assign quirks to latejoiners _after_ injecting them into the manifest: https://github.com/tgstation/tgstation/blob/b7225d8486476fc4971ef32ed3c83fd778e7e46d/code/modules/mob/dead/new_player/new_player.dm#L218-L244 See line 219 and 244. So we move manifest injection to be _after_ quirk assignment: ```dm (line 242-246) if((job.job_flags & JOB_ASSIGN_QUIRKS) && humanc && CONFIG_GET(flag/roundstart_traits)) SSquirks.AssignQuirks(humanc, humanc.client) if(humanc) // Quirks may change manifest datapoints, so inject only after assigning quirks GLOB.manifest.inject(humanc) ``` This fixes it. ## Why It's Good For The Game Makes quirks actually show in the medical records for latejoiners. Makes latejoiners with heterochromatic eyes not have the wrong fingerprint in the security records. _Probably_ fixes #83681. Fixes #56469. ## Changelog 🆑 fix: Latejoiners with heterochromatic eyes no longer have the wrong fingerprint in the security records. fix: Latejoiners actually have their quirks visible in the medical records. /🆑 |
||
|
Jeremiah
|
a3940a4a96 |
Updates to orbit ui [READY] (#83186)
## About The Pull Request Pretty big orbit ui refactor. Check changelog for full list of features. <details> <summary>screenshots</summary> In game  Sort by department  Did you know ninjas had a hud icon that hasn't worked for four years?  Criticals  Orbit blade https://github.com/tgstation/tgstation/assets/42397676/99681548-bfb3-4895-9c95-3b650df71107 </details> ## Why It's Good For The Game Some QoL for the orbit menu, giving more info on where action is and isn't. Removes more of the uselocalstate hook which is deprecated anyways ## Changelog 🆑 fix: Fixed an issue preventing space ninjas from having a hud icon add: ORBIT UI CHANGES: add: AFK players are greyed out. add: Living NPCs now display health. add: Icons displayed are now based on hud icons, which includes icons for player-visible antagonists add: You can now sort by job department (click health icon) add: Round ending "critical" items will be listed at the top. add: Click the settings button to expand for more info add: Your current orbit target is highlighted. /🆑 |
||
|
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. |
||
|
LemonInTheDark
|
c514facd5f |
Removes redundant update_parallax_contents calls (#82644)
## About The Pull Request Off shuttle move doesn't need to happen because shuttles use abstract move which calls it anyway Similar story for the ghost stuff, this was actually causing pretty common double calls so we may actually get somethin out of this Oh and something in air which is past me knifing me in the back |
||
|
Zephyr
|
7f8752be14 | Admin Verb Datums MkIII | Now with functional command bar (#82511) | ||
|
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. |
||
|
Jeremiah
|
9723b4b317 |
Replaces even more deciseconds with SECONDS (#82438)
## About The Pull Request
Using these search regexes:
Ending in 0:
`addtimer\((.*),\s?(\d{1,3})0\b\)`
replacement:
`addtimer($1, $2 SECONDS)`
Two digit ending in odd:
`addtimer\((.*), (\d)([1-9])\)$`
replacement:
`addtimer($1, $2.$3 SECONDS)`
Single digit ending odd:
`addtimer\((.*), ([1-9])\)$`
replacement:
`addtimer($1, 0.$2 SECONDS)`
## Why It's Good For The Game
Code readability
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
|
||
|
John Willard
|
a15a1b88ed |
Basic mobs now use z-level turnoff instead of simple (#82469)
## About The Pull Request On one compile of MetaStation, I saw that there's 45 basic mobs on the station, 256 on lavaland (the number growing from tendrils), and 59 in all other z levels combined. While we do expect Lavaland to be visited every round, at least it won't be running during the times when no one is there, but even more importantly, space exploration is something not done every round, so we don't have any reason to waste our resources on AIs that will never be interacted with. Simple animals had an easy solution to this: If no one is on the Z level, their AI turns off If someone is on the Z level, they are idle unless needed. The last simple animals that exists right now are bots, megafauna, geese, gondolas, and some minor ones like mimic, zombie, dark wizard, soulscythe, etc. Point is, we're very much nearly done going through all simple animals, so this code is being wasted just to ensure things like cleanbots won't work if no one is on the z level, something I doubt happens often, so I took their code and made it work for basic mobs instead. I could've done both but I thought it would look very bad, and maybe this is a good incentivize to get more basic mob conversions. There's one major change here and it's that we're missing the "Idle" mode, some basic mobs like the Lavaland village seems to be made with intent that they'll be running even if players aren't around, so this sets up a future PR that makes idle AI easier to add, and I want to make sure those cases are taken into account. ## Why It's Good For The Game We don't need to always be processing these basic mobs, and sets us in the future to hopefully also implement idle AIs. ## Changelog 🆑 balance: Basic mob AIs with no mobs on the Z level now stop. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
Bilbo367
|
466b3df048 |
Refactor removing unused defines. (#82115)
## About The Pull Request Refactors a lot of the unused defines. ## Why It's Good For The Game Refactors a lot of the unused defines. ## Changelog Nothing player facing --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
LemonInTheDark
|
ef714c1c34 |
Overlay Lighting Color/Intensity Pass (#81425)
## About The Pull Request I was looking at screenshots of the game and realized we had a lot of light sources that were really... flat. Medium intensity, not colored at all, cringe. So I went over all the uses of overlay styled lighting (since I've done matrix lighting already) and gave them more unique features. Colors that match the sprite they're used with, intensity to produce vibes, that sort of thing. It's kinda impossible to go one by one cause there's a LOT. I may have gone a bit overboard with a few, I'm messing around with some things like giving bots colors based off their department, etc. We'll see how this all turns out. Oh also I tweaked how the cone of overlay lighting is drawn. It seemed a bit too present to me so I dropped the alpha down from like 200 to 120 at max (so it's roughly half of the mask's alpha so it's less overwhelming ## Why It's Good For The Game Lighting should be impactful, subtle and colorful <details> <summary> Old Lights </summary>           </details> <details> <summary> New Lights </summary>           </details> ## Changelog 🆑 add: Tweaked the saturation, color and intensity of a bunch of lights /🆑 |
||
|
John Willard
|
9ac81e1a64 |
New station trait job: Human AI (#81681)
## About The Pull Request This PR does many things, I'll try to explain the basic/background stuff to the main thing first: 1. Adds a new remote that allows a human to function like an AI. It controls a fly that will fly around the station slowly, and when it reaches a machine then the person can interact with it as if they were an AI. This required changing a lot of silicon/AI checks with one that also checks for this remote, and some messing with shared ui state. 2. Moves req_access from the obj and bot to ``/atom/movable`` which lets it be shared between the two, no more copy-paste and one side lacking features/checks/signals the other has. 3. Adds a check for AI config for AI-related station traits, which was lacking prior Now for the good part... Adds a new station trait that replaces the AI with a Human. This person is equipped with an AI headset (including Binary), an advanced camera console, an omni door wand, the machine controller, and their laws. They are immune to the SAT's turrets (even if set to target borgs) and are slow outside of the SAT, mimicing the actions of the AI. They interact with the world through their advanced camera console, which allows them to do most AI stuff needed, and the holopad they can connect to without having to ring first (like Command can). They are given a paper with the laws they must follow, but since they are human they are able to bend it. Cyborgs that run the default lawset are "slaved" to them via an unremovable law 0, so the Human AI can bend the laws if they really need to (for their own survival n such), and make the cyborgs obey their commands above laws, but in general this shouldn't be a frequent occurrence. This does take into account the unique AI trait, so it's not guaranteed Asimov. When this station trait rolls, all Intellicards, AI uploads, and AI core boards are destroyed and are unresearchable. They can be spawned by admins in-game if necessary. Maybe in the future we can also exclude Oldstation from this but I haven't really decided. Extra perks: Human AI spawns with a Robotic voicebox (unless they are a body purist) and teleport blocking implant, so they can't use teleporters to bypass their on-station slowdown. They also have an infinite laser pointer that can be used to blind through their camera console. This is unfortunately nerfed from the recent borg balance PR that removed its stun. This was meant to be the alternative to no longer being able to permanently lock borgs down like AIs can (or more than one, for that matter). They aren't affected by Roburgers, Acid, and Fuel's toxicity. Bots salute them like they do Beepsky (which is now a trait) They spawn with SyndEye to replace the AI's tracking ability They do not have a bank account ### The machine remote The machine remote has a little fly in it that flies to the machines it is pointed to, working as the arms and legs of the Human AI. It scans the machine and punches in the action the AI does, and is how the AI accesses basically anything. This fly slowly moves from one machine to the next, and can be recalled with Alt Click. It works on machines and bots. ### Video (Low quality to fit Github) https://github.com/tgstation/tgstation/assets/53777086/e16509f8-8bed-42b5-9fbf-7e37165a11e8 ## Why It's Good For The Game I've seen a funny screenshot one day of a person replacing the AI by using a bunch of door remotes, camera console, crew monitoring console, and a few other things. I've been thinking about that for a few years and really wanted to make it official if not easier to make possible, because it is an incredibly funny interaction. This makes it a reality, and while they aren't as powerful as regular AIs, I think it makes for better and funnier in-game moments. With the same weight as Cargorilla (1), I hope this wouldn't be rolling too often and ruin rounds, but instead show off the different capabilities that Humans and AIs can do, to do the job of an AI. You win some you lose some. ## Changelog 🆑 JohnFulpWillard, Tattax add: Adds a new station trait job: The Human AI. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
MrMelbert
|
47dc38fee2 |
Let's you talk through action figures, plushies, and toy mechs with .l and .r. Also a big clean up of say because its support for non-mobs was lackluster. (#81848)
|
||
|
MrMelbert
|
18e25329a8 |
Fixes jank with moving down Zs as a ghost (#81837)
## About The Pull Request Caused by goof's PR. Because for some reason observers overridde `up` to skip checks but not `down`. ## Changelog 🆑 Melbert fix: Moving "down" as an observer is no longer janky. /🆑 |
||
|
MrMelbert
|
01c20ddc03 |
Fix dead mobs changing their mob tag causing obsever weakrefs to not function (#81585)
## About The Pull Request Fixes #81578 Fixes #81559 Fixes #81308 In #69634 mob tag generation was moved to `/mob/New` But dead mobs also do this in initialize  So dead mobs skipped over a tag This is whatever, until it's not: If something makes a weakref of an observer in `/observer/Initialize` before its parent call, which shuffles the mob tag around, uh oh now our weakref points to a non-existent ref! So what's making the weakref? No clue but apparently chasms ## Changelog 🆑 Melbert fix: Chasms no longer break your verbs /🆑 |
||
|
LemonInTheDark
|
70651816c2 |
Fixes complex lights not handling moving well, renames lighting defines (#81423)
## About The Pull Request [Fixes static lights not moving](https://github.com/tgstation/tgstation/commit/ffef43c05a55dae414ef94558ecf9b9df709ded7) Worked fine when the owner moved, but if the owner was inside something else, it would try and trigger an update on the PARENT's lights, which are obviously not us. [Renames MOVABLE_LIGHT and STATIC_LIGHT to better describe what they do](https://github.com/tgstation/tgstation/commit/de73a63bd4d97783c69c95370726d1c253ffb8fe) People keep trying to change the lighting system of lamps and it makes me mad. I choose OVERLAY_LIGHT and COMPLEX_LIGHT here, I couldn't figure out a better name for turf matrix lighting. Suggestions welcome ## Why It's Good For The Game Closes #80005 Hopefully improves understanding of lighting at a glance ## Changelog 🆑 fix: Fixes fancy lights not updating their source location when picked up and moved /🆑 |
||
|
LemonInTheDark
|
08734e4610 |
Better Ghost Hair (#81262)
## About The Pull Request What we were doing before was basically just take the difference of each component against 255, multiply it with 0.4, and then add that in. This was bad, and looked bad. Fucked up hue something fierce, just not good. I noticed this in my rgb2num work, but it didn't occur to me to deal with it. Now seems like a good time tho. We'll use hsv to deal w this. First, reduce the saturation by 15% and bump luminosity by 15%. Then we'll just clamp them to sensible max/minimums to prevent blowing them out totally, and we good. ## Why It's Good For The Game Should make ghost hair look a bit nicer, I'm happy with it       Closes #81261 ## Changelog 🆑 add: Ghost hair looks better now. Insert nerd shit about RGB vs HSL color space here, go watch a youtube video or whatever. /🆑 |
||
|
LemonInTheDark
|
18075704e9 |
Implements rgb2num, uses it to replace all our manual rgb reading. Redoes HSV management (#81182)
## About The Pull Request [Converts all manual extraction of rbg with rgb2num. It's just better](https://github.com/tgstation/tgstation/commit/ae798eabd5aa94dd577169553905d3efd7a7136d) [Yanks out old HSV management, replaces it with list stuff](https://github.com/tgstation/tgstation/commit/4997e86051d6388e495524dccba1f3258a47bb48) There's this old lummy era clunky code that passed HSV as text We can now cleanly replace it with passing hsv as lists from a rgb2hsv proc So let's just do that. Also, cleans up spraytan code (and ethereal lighting) ## Why It's Good For The Game Code better |
||
|
Pink
|
22cf3eb0cf |
Moves Hardcore Random logging from Admin.log to Game.log (#81066)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request I moved the bit that says: ADMIN: guy started hardcore random with cancer, for a score of 2 into game.log <!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! --> ## Why It's Good For The Game I don't see why this wound up in Admin.log. Doesn't contain any admin info, relate to actions done by admins, etc. <!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. --> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> <!-- 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. --> |
||
|
13spacemen
|
8d3371daa0 |
Ghosts can see info about Wanted Status and Sec Records (#80692)
## About The Pull Request Ghosts can examine people to see Wanted Status and view their Sec Records which show crimes ## Why It's Good For The Game More fun observer experience. You can already see the "W" hud, so more info is nice  ## Changelog 🆑 qol: Ghosts can now view Wanted Status and Sec Records by examining people /🆑 |
||
|
Bloop
|
f9effc2e18 |
Fixes some observer hard dels (#80757)
## About The Pull Request Tin. This was another /image hard del that I came across within a given round. AFAIK this was occurring because `updateallghostimages()` removes refs of these images from GLOB.ghost_images_default and GLOB.ghost_images_simple, and this proc was being called after `QDEL_NULL()`. So they were still in the lists at the time of the qdeletion. We don't need to be qdeleting them at all though so let's just set them to null.  ## Why It's Good For The Game Reduces the lag. ## Changelog 🆑 fix: fixed an /image hard del in ghost code /🆑 |
||
|
MrMelbert
|
f4bf6f8ce2 |
Revert "Fixes observers spamming admin logs when observing themselves" (#80470)
Reverts tgstation/tgstation#80407 Fixes #80460 Fixes #80485 I don't think this was a good fix, we should be preventing people from observing themselves outright. Not "they can observe themselves but skip the actual observe-part of observing". Also it breaks observing. |
||
|
Diamond_
|
75e4c46a5b |
Fixes observers spamming admin logs when observing themselves (#80407)
## About The Pull Request Fixes #77034 by adding in a check to do_observe to prevent observers from observing themselves. It does prevent them from observing their own bodies and seeing their hud and entire inventory as a ghost, but that's not a major problem because they probably either remember what they had if it's so important to constantly see what's on their mob or it doesn't matter. Additionally they can just use re-enter corpse so whatever. ## Why It's Good For The Game Observers can no longer intentionally or even completely accidentally flood admin logs from their observetarget not resetting due to them observing themselves. ## Changelog 🆑 fix: Observers observing themselves no longer floods admins' logs. /🆑 |
||
|
Fikou
|
a3fa541e2e |
Bridge Assistant Station Trait (#80279)
## About The Pull Request adds a station trait which adds a new role, the bridge assistant he is designed to help commandeer the bridge and help out other heads when needed. he is armed with the mini energy gun (the one heads used to have on kilostation), a flash, a toolbelt (with an inducer), some cool shades and a swanky scarf. as he is a nerd he is weak and unable to twohand weapons, preventing him from wielding the fire axe. currently he does not have a mindshield but he cannot roll antag he currently has access to the bridge, announcement console, eva, teleporter, gateway, maint, and a weapon permit (somewhat (not really other than for nerds) interestingly this is the first job that isnt assistant that doesnt have access to any lathes, so he doesnt have orm access unlike all the other jobs (except assistant)) the trait also makes a coffee machine spawn on the bridge here is some useful art of your role  and ingame screenshots    ## Why It's Good For The Game Adds upon the station trait job system with a straight forward role that IS just a human (unlike the cargorilla), and is pretty basic with no custom assets or whatever other than hud icons Having the bridge assistant in some rounds seems like a neat way to protect it since it gets fucked up in like half the time, while also not having enough mechanical depth or gameplay as to warrant it as a permanent role ## Changelog 🆑 add: Bridge Assistant job accessible from a station trait. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
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. /🆑 |
||
|
distributivgesetz
|
f7cb0f8018 |
Rename notify_ghost_cloning to notify_revival (#80096)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request Renames - `/mob/proc/notify_ghost_cloning` to `/mob/proc/notify_revival` - `/mob/dead/observer/proc/notify_cloning` to `/mob/dead/observer/proc/send_revival_notification` - `/atom/movable/screen/alert/notify_cloning` to `/atom/movable/screen/alert/revival`. I could have found a way to merge both procs together but default parameters keep me up at night. <!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! --> ## Why It's Good For The Game Conciseness, code that is named after a removed feature is silly. <!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. --> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> nothing playerfacing <!-- 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. --> |
||
|
Mothblocks
|
714ff3ec54 |
Remove /datum/game_mode, we SSdynamic now [again] (#79965)
I don't remember what was hard about this last time it took me like 20 minutes this time so I'm scared. Removes dynamic simulations, only I have used them and it's a lot more complicated now with this. I plan on making Dynamic simulations a part of moth.fans anyway |
||
|
san7890
|
de2c9a78d2 |
Fixes Ghostize Runtime (#79927)
## About The Pull Request  I had this runtime sitting around for who-knows-how-long so I decided I would just fix it today. `ghostize()` is expected to work on all subtypes of `/mob` so it's a bad idea to access a variable that only exists on `/mob/living` (and there is no real point to move `timeofdeath` up a level imo, we already have too much clutter there and `/mob/camera/imaginary_friend` would _never_ need it). ## Why It's Good For The Game We should only access variables like these when when they exist. ## Changelog No shot a player would ever notice this |
||
|
lizardqueenlexi
|
9df358f79c |
Hardcore random will not assign incompatible quirks. (#79825)
## About The Pull Request Fixes #78114. Fixes #78505. Grumble grumble, code rot. #77727 inadvertently broke hardcore random quirk selection, making it not actually check the compatibility of quirks before adding them. This means that quirks that were never meant to go together could be randomly assigned, which broke all kinds of things. I've simply made it properly check for the typepath rather than checking typepaths against names, making it actually function as intended. ## Why It's Good For The Game Certain quirks are incompatible for a reason. Prevents unintended combos that break in unexpected ways. ## Changelog 🆑 fix: Hardcore Random will no longer assign incompatible quirks. /🆑 |
||
|
Jeremiah
|
bbe440b3d6 |
More standardization for ghost notifications (READY) (#79596)
## About The Pull Request I'm still not satisfied with how ghost notifications work. This gives every notification with a source (99% of all notifications, in other words) a link to jump/orbit. Currently, notifications with "play" interactions would only get the interact link, so jumping to the source was pretty annoying. It removes posting the entire message in the alert tooltip, as some got pretty lengthy and it didn't seem to fit. To replace this, they will always use headers After:    NOTIFY_JUMP and NOTIFY_ORBIT have been merged, since the only difference seems to be whether it's a turf. The result shaves off some redundant lines of code, since most-every usage of notify_ghosts uses NOTIFY_ORBIT. ## Why It's Good For The Game More standardization for the ghost notification system. Adds a few alert headers that never had them. All in all, makes it easier for creators to throw alerts at ghosts ## Changelog 🆑 qol: Nearly every ghost alert should now feature a "VIEW" button, even those with click interaction. del: Ghost alerts no longer show the entire message in the tooltip, instead have been replaced with titles. /🆑 |
||
|
Jeremiah
|
153e06dc04 |
Partially reverts ghost announcements (#79221)
## About The Pull Request #79139 turned out to be quite annoying, it wasn't taken into account that these alerts can stack (ie: spiders). Of course, I poked around the code and found some inconsistencies in the process. For instance, there were usages of Topic for custom action behavior which could've been consolidated. There were other instances where jump (the default action) doesn't give a link at all, which I think it should anyway, since the screen toast gives you this. I've standardized it more, meaning you can use "NOTIFY_PLAY" without writing a custom link and topic handler (for instance, MMIs) ## Why It's Good For The Game Fixes #79198 Fixes #79195 ## Changelog 🆑 fix: Ghost alerts have been tuned down a bit. /🆑 |
