mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-23 05:00:55 +01:00
StrangeWeirdKitten-patch-1
74
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 nikothedudeandnevimer
|
ab652d822f |
Hopefully fixes antagonist reroll + rerolls always pick from the removed antag type (#5663)
## About The Pull Request Title. So, the proc takes instances, but we were getting typepaths from the global list. This fixes it, by getting the instances. Also makes rerolled antags always pick from the original reroll. ## Why It's Good For The Game Bugs bag ## Proof Of Testing <details> <summary>Screenshots/Videos</summary> <img width="1736" height="424" alt="image" src="https://github.com/user-attachments/assets/6ad83ee3-f453-4f43-bb32-10b2555b2654" /> </details> ## Changelog 🆑 fix: Antagonist reroll now works /🆑 |
||
|
shayoki
|
f601a6ddaf | Merge remote-tracking branch 'tgstation/master' into upstream-6-2-2026 | ||
|
John WillardandGitHub
|
3ea6c1ddea |
Fixes tempbody taking aghosted bodies (#95996)
## About The Pull Request If you're an adminghosted body, you will no longer be sent back to your corpse afterwards. The Mind will still move over, but you wont immediately re-enter your body. Just as an example, an Admin is aghosted on Centcom after testing some stuff, plays a round of Mafia, then is suddenly back in their body in Centcom. Also fixes temp body not working for Mafia (due to the corpse locking) ## Why It's Good For The Game You're going to the THUNDERDOME. ## Changelog 🆑 fix: Mafia players now get sent back to their bodies again post-game. admin: Admin players aren't forcefully put back into aghosted bodies after using a temporary body spawner. /🆑 |
||
|
+37AlexisGitHubtgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com>ArcaneMusicMrMelbertRhialsrageguy505LemonInTheDarkJohn WillardAliceee2chTime-GreenTsar-SalatSmArtKarMaxipatSyncIt21deltanedasSimplyLoganloganukLeland KembleFalloutFalconRoxyLucysiliconOpossumIsratoshTheRyeGuyWhoWillNowDieNeocloudyAlexander V.ElGitificadorTwaticusdependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>BloopCameron LennoxTimIamgoofballLayzu666Arturlang_0StevenmrmanlikesbtBen10OmintrixJohn F. KennedyCursorJoshJosh PowellYobrocharlieHardly3DshayokiLT3 |
21b4095dfd |
[MDB IGNORE] [IDB IGNORE] Upstream Sync - 04/17/2026 (#5453)
Upstream 04/17/2026 fixes https://github.com/Bubberstation/Bubberstation/issues/5549 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: tgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com> Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Rhials <28870487+Rhials@users.noreply.github.com> Co-authored-by: rageguy505 <54517726+rageguy505@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: Aliceee2ch <160794176+Aliceee2ch@users.noreply.github.com> Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> Co-authored-by: Tsar-Salat <62388554+Tsar-Salat@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Maxipat <108554989+Maxipat112@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> Co-authored-by: deltanedas <39013340+deltanedas@users.noreply.github.com> Co-authored-by: SimplyLogan <47579821+loganuk@users.noreply.github.com> Co-authored-by: loganuk <fakeemail123@aol.com> Co-authored-by: Leland Kemble <70413276+lelandkemble@users.noreply.github.com> Co-authored-by: FalloutFalcon <86381784+FalloutFalcon@users.noreply.github.com> Co-authored-by: Roxy <75404941+TealSeer@users.noreply.github.com> Co-authored-by: Lucy <lucy@absolucy.moe> Co-authored-by: siliconOpossum <138069572+siliconOpossum@users.noreply.github.com> Co-authored-by: Isratosh <Isratosh@hotmail.com> Co-authored-by: TheRyeGuyWhoWillNowDie <70169560+TheRyeGuyWhoWillNowDie@users.noreply.github.com> Co-authored-by: Neocloudy <88008002+Neocloudy@users.noreply.github.com> Co-authored-by: Alexander V. <volas@ya.ru> Co-authored-by: ElGitificador <168473461+ElGitificador@users.noreply.github.com> Co-authored-by: Twaticus <46540570+Twaticus@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> Co-authored-by: Cameron Lennox <killer65311@gmail.com> Co-authored-by: Tim <timothymtorres@gmail.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Layzu666 <121319428+Layzu666@users.noreply.github.com> Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com> Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> Co-authored-by: mrmanlikesbt <99309552+mrmanlikesbt@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: John F. Kennedy <54908920+MacaroniCritter@users.noreply.github.com> Co-authored-by: Cursor <102828457+theselfish@users.noreply.github.com> Co-authored-by: Josh <josh.adam.powell@gmail.com> Co-authored-by: Josh Powell <josh.powell@softwire.com> Co-authored-by: Yobrocharlie <Charliemiller5617@gmail.com> Co-authored-by: Hardly3D <66234359+Hardly3D@users.noreply.github.com> Co-authored-by: shayoki <96078776+shayoki@users.noreply.github.com> Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
7d3c761150 |
Minor addiction refactor (#95080)
## About The Pull Request ### Rewrite stuff Reagent addictions are written in terms of "units to addict" kinda like how they were ages ago For example `addiction_types = list(/datum/addiction/hallucinogens = 60)` says "We can expect to get addicted if we consume 60 units of this reagent alone" For easily converting units, I used the following equation ``` x = 1 / ((o * 0.2 / m / 2) / 600) o = the old addiction number m = the metabolism rate x = the converted threshold ``` Example (Nicotine) ``` x = 1 / ((o * 0.2 / m / 2) / 600) o = 15 m = 0.025 x = 10 (10 units to addict) ``` FULL TRANSPARENCY: Some reagents had some really weird results like `33.33u` or `685.78u` I rounded them to nicer numbers like `30u` or `685u`. I don't think anyone would really care. I anticipate this being easier to work with than the arbitrary point values ### Mechanics stuff Addiction gained is now calculated based on units metabolized, rather than the static metabolism rate. So if you metabolize less than a full metabolism tick, you aren't given the full addiction points. ## Why It's Good For The Game ### Rewrite stuff Addiction rates are kinda insane. If you look at nicotine you see: `list(/datum/addiction/nicotine = 15)` Then if you look at maintenance powder: `list(/datum/addiction/maintenance_drugs = 14)` You would assume that these give you addiction at a similar rate... but ACTUALLY you would get nicotine addiction from 10u consumed and you would get maintenance drug addiction from 50u consumed This was because nicotine's metabolism rate is 0.025 vs maintenance powder's 0.1 metabolism rate - this is not exactly obvious at a glance which makes tweaking addiction values kind of painful Putting them in terms of "units to addict" makes it a lot easy to parse at a glance - metabolism rate nor any other variable is necessary to know how potent a substance is (In particular you can see some reagents take **upwards of 1,200u** to addict on their own. Which is INSANEEE. I want to go through in a second pr and tweak all these values down) ### Mechanics stuff This ultimately changes very little, it just makes sense that metabolizing more or less of a reagent at once would give you more or less addiction progress. ## Changelog 🆑 Melbert refactor: Rewrites how addiction points are applied from reagents. Some reagents may be marginally more or less addictive as a consequence. balance: Addiction gained per metabolism tick now scales to the amount of reagents metabolized. In other words if you metabolize 0.2 units instead of the expected 0.4 units, you get 0.5x of the amount of addiction gain. This ultimately changes very little and I would imagine it's how most people expected it to work in the first place... /🆑 |
||
|
nevimer
|
00ccf0c6b5 |
Merge remote-tracking branch 'tgstation/master' into upstream-feb12-2026
# Conflicts: # .github/CODEOWNERS # .github/workflows/compile_changelogs.yml # .github/workflows/stale.yml # SQL/database_changelog.md # _maps/map_files/CatwalkStation/CatwalkStation_2023.dmm # code/__DEFINES/atom_hud.dm # code/__DEFINES/inventory.dm # code/__DEFINES/mobs.dm # code/__DEFINES/species_clothing_paths.dm # code/__DEFINES/subsystems.dm # code/__DEFINES/surgery.dm # code/__HELPERS/global_lists.dm # code/_globalvars/lists/maintenance_loot.dm # code/_globalvars/traits/_traits.dm # code/controllers/subsystem/minor_mapping.dm # code/controllers/subsystem/processing/quirks.dm # code/controllers/subsystem/shuttle.dm # code/datums/components/palette.dm # code/datums/components/surgery_initiator.dm # code/datums/diseases/advance/advance.dm # code/datums/hud.dm # code/datums/mood.dm # code/datums/mutations/chameleon.dm # code/datums/quirks/negative_quirks/nyctophobia.dm # code/datums/status_effects/debuffs/debuffs.dm # code/datums/status_effects/debuffs/drunk.dm # code/datums/status_effects/debuffs/slime/slime_leech.dm # code/datums/weather/weather.dm # code/game/data_huds.dm # code/game/objects/items.dm # code/game/objects/items/devices/scanners/health_analyzer.dm # code/game/objects/items/frog_statue.dm # code/game/objects/items/rcd/RLD.dm # code/game/objects/items/robot/items/hypo.dm # code/game/objects/items/stacks/medical.dm # code/game/objects/items/stacks/wrap.dm # code/game/objects/items/storage/garment.dm # code/game/objects/items/tools/medical/defib.dm # code/game/objects/items/weaponry.dm # code/game/objects/items/weaponry/melee/misc.dm # code/game/objects/structures/crates_lockers/closets/secure/security.dm # code/game/objects/structures/curtains.dm # code/game/objects/structures/dresser.dm # code/game/objects/structures/girders.dm # code/game/objects/structures/maintenance.dm # code/game/objects/structures/mirror.dm # code/modules/admin/greyscale_modify_menu.dm # code/modules/admin/verbs/light_debug.dm # code/modules/antagonists/ashwalker/ashwalker.dm # code/modules/antagonists/heretic/knowledge/starting_lore.dm # code/modules/antagonists/ninja/ninjaDrainAct.dm # code/modules/art/paintings.dm # code/modules/client/preferences.dm # code/modules/client/verbs/ooc.dm # code/modules/clothing/head/wig.dm # code/modules/events/disease_outbreak.dm # code/modules/holodeck/holo_effect.dm # code/modules/jobs/job_types/head_of_security.dm # code/modules/jobs/job_types/security_officer.dm # code/modules/library/skill_learning/generic_skillchips/point.dm # code/modules/mining/lavaland/ash_flora.dm # code/modules/mining/lavaland/mining_loot/megafauna/ash_drake.dm # code/modules/mob/dead/new_player/new_player.dm # code/modules/mob/living/basic/guardian/guardian.dm # code/modules/mob/living/basic/space_fauna/space_dragon/space_dragon.dm # code/modules/mob/living/carbon/carbon.dm # code/modules/mob/living/carbon/human/human.dm # code/modules/mob/living/carbon/human/human_defines.dm # code/modules/mob/living/carbon/life.dm # code/modules/mob/living/living.dm # code/modules/mob/living/living_defines.dm # code/modules/mob/mob.dm # code/modules/mob_spawn/ghost_roles/mining_roles.dm # code/modules/mod/mod_control.dm # code/modules/mod/modules/modules_general.dm # code/modules/modular_computers/computers/item/computer_ui.dm # code/modules/paperwork/paper.dm # code/modules/paperwork/paperbin.dm # code/modules/power/lighting/light.dm # code/modules/projectiles/guns/energy/kinetic_accelerator.dm # code/modules/projectiles/projectile.dm # code/modules/reagents/chemistry/reagents/drinks/alcohol_reagents.dm # code/modules/reagents/chemistry/reagents/food_reagents.dm # code/modules/reagents/chemistry/reagents/other_reagents.dm # code/modules/reagents/chemistry/reagents/pyrotechnic_reagents.dm # code/modules/research/xenobiology/crossbreeding/_clothing.dm # code/modules/research/xenobiology/crossbreeding/prismatic.dm # code/modules/surgery/advanced/brainwashing.dm # code/modules/surgery/advanced/lobotomy.dm # code/modules/surgery/amputation.dm # code/modules/surgery/blood_filter.dm # code/modules/surgery/bodyparts/_bodyparts.dm # code/modules/surgery/brain_surgery.dm # code/modules/surgery/cavity_implant.dm # code/modules/surgery/coronary_bypass.dm # code/modules/surgery/gastrectomy.dm # code/modules/surgery/healing.dm # code/modules/surgery/limb_augmentation.dm # code/modules/surgery/organ_manipulation.dm # code/modules/surgery/revival.dm # code/modules/surgery/sleeper_protocol.dm # code/modules/surgery/surgery_helpers.dm # code/modules/surgery/surgery_step.dm # code/modules/unit_tests/_unit_tests.dm # code/modules/unit_tests/designs.dm # code/modules/unit_tests/icon_state_worn.dm # code/modules/unit_tests/screenshots/screenshot_antag_icons_cultist.png # code/modules/unit_tests/screenshots/screenshot_antag_icons_headrevolutionary.png # code/modules/unit_tests/screenshots/screenshot_antag_icons_provocateur.png # code/modules/unit_tests/screenshots/screenshot_husk_body.png # code/modules/unit_tests/screenshots/screenshot_husk_body_missing_limbs.png # icons/map_icons/clothing/head/_head.dmi # icons/map_icons/clothing/shoes.dmi # icons/map_icons/items/_item.dmi # icons/mob/huds/hud.dmi # icons/mob/inhands/64x64_lefthand.dmi # icons/mob/inhands/64x64_righthand.dmi # icons/obj/machines/computer.dmi # tgui/packages/tgui/interfaces/OperatingComputer.jsx # tgui/packages/tgui/interfaces/PreferencesMenu/CharacterPreferences/MainPage.tsx # tgui/packages/tgui/interfaces/PreferencesMenu/types.ts # tgui/packages/tgui/interfaces/SurgeryInitiator.tsx # tools/icon_cutter/check.py |
||
|
MrMelbertandGitHub
|
bf22a388ca |
People become desensitized to death from exposure (#94924)
## About The Pull Request Desensitized is no longer binary yes/no, now scales from 0.1x to 1x (or beyond, I guess) Desensitized jobs start as 0.5x desensitized (which is the threshold for being considered "truly desensitized") Some antags are now 0.1x to 0.25x desensitized Witnessing death of a fellow human gives you slight desensitization (currently -0.025x). A normal crewmember, after witnessing 20 deaths, is on par with a roundstart desensitized crewmember. Likewise a desensitized crewmember has almost no reaction to death after witnessing 20 deaths. Your own deaths count towards this value. There's an achievement for managing to go from 1x to 0.1x across the course of an entire round. ## Why It's Good For The Game This is intended to contribute to the "story" people face across the length of a round. Rounds with few overall deaths results in crewmembers regularly getting shocked, but bloodbaths results in crewmembers "dehumanizing and facing the bloodshed". ## Changelog 🆑 Melbert add: Desensitization to death is no longer binary - some antagonists are now more used to it than others. add: Witnessing the death of a fellow humanoid (or dying yourself) will slightly desensitize you to future deaths. add: Adds an achievement for managing to max out desensitization across a round. add: Desensitized crewmembers care less when splattered with blood. add: Holodeck mobs have a reduced death mood impact. /🆑 |
||
|
LT3andGitHub
|
4569cbbb2a |
Admin create antagonist/re-roll antagonist (#4971)
## About The Pull Request - Adds a prompt when an admin is removing someone's antagonist datum if they would like to re-roll for a new antagonist to replace them - Brings back the Create Antagonist verb - When creating an antagonist, it tells the admin who was selected ## Why It's Good For The Game Admin quality of life ## Changelog 🆑 LT3 admin: Admin button in the traitor panel to automatically re-roll antagonists admin: Admin create-antagonist verb admin: Game logs now include what player gets turned into an antagonist /🆑 |
||
|
xPokee
|
5e629dff04 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-sync | ||
|
|
3ea7b03369 |
Accentuate the positive with **Personality**: A (soft) mood rework (#92941)
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> |
||
|
MrMelbertandRoxy
|
e0bdfc3f5f |
Dynamic Rework (#91290)
Implements https://hackmd.io/@tgstation/SkeUS7lSp , rewriting Dynamic
from the ground-up
- Dynamic configuration is now vastly streamlined, making it far far far
easier to understand and edit
- Threat is gone entirely; round chaos is now determined by dynamic
tiers
- There's 5 dynamic tiers, 0 to 4.
- 0 is a pure greenshift.
- Tiers are just picked via weight - "16% chance of getting a high chaos
round".
- Tiers have min pop ranges. "Tier 4 (high chaos) requires 25 pop to be
selected".
- Tier determines how much of every ruleset is picked. "Tier 4 (High
Chaos) will pick 3-4 roundstart[1], 1-2 light, 1-2 heavy, and 2-3
latejoins".
- The number of rulesets picked depends on how many people are in the
server - this is also configurable[2]. As an example, a tier that
demands "1-3" rulesets will not spawn 3 rulesets if population <= 40 and
will not spawn 2 rulesets if population <= 25.
- Tiers also determine time before light, heavy, and latejoin rulesets
are picked, as well as the cooldown range between spawns. More chaotic
tiers may send midrounds sooner or wait less time between sending them.
- On the ruleset side of things, "requirements", "scaling", and
"enemies" is gone.
- You can configure a ruleset's min pop and weight flat, or per tier.
- For example a ruleset like Obsession is weighted higher for tiers 1-2
and lower for tiers 3-4.
- Rather than scaling up, roundstart rulesets can just be selected
multiple times.
- Rulesets also have `min_antag_cap` and `max_antag_cap`.
`min_antag_cap` determines how many candidates are needed for it to run,
and `max_antag_cap` determines how many candidates are selected.
- Rulesets attempt to run every 2.5 minutes. [3]
- Light rulesets will ALWAYS be picked before heavy rulesets. [4]
- Light injection chance is no longer 100%, heavy injection chance
formula has been simplified.
- Chance simply scales based on number of dead players / total number
off players, with a flag 50% chance if no antags exist. [5]
[1] This does not guarantee you will actually GET 3-4 roundstart
rulesets. If a roundstart ruleset is picked, and it ends up being unable
to execute (such as "not enough candidates", that slot is effectively a
wash.) This might be revisited.
[2] Currently, this is a hard limit - below X pop, you WILL get a
quarter or a half of the rulesets. This might be revisited to just be
weighted - you are just MORE LIKELY to get a quarter or a half.
[3] Little worried about accidentally frontloading everything so we'll
see about this
[4] This may be revisited but in most contexts it seems sensible.
[5] This may also be revisited, I'm not 100% sure what the best / most
simple way to tackle midround chances is.
Other implementation details
- The process of making rulesets has been streamlined as well. Many
rulesets only amount to a definition and `assign_role`.
- Dynamic.json -> Dynamic.toml
- Dynamic event hijacked was ripped out entirely.
- Most midround antag random events are now dynamic rulesets. Fugitives,
Morphs, Slaughter Demons, etc.
- The 1 weight slaughter demon event is gone. RIP in peace.
- There is now a hidden midround event that simply adds +1 latejoin, +1
light, or +1 heavy ruleset.
- `mind.special_role` is dead. Minds have a lazylist of special roles
now but it's essentially only used for traitor panel.
- Revs refactored almost entirely. Revs can now exist without a dynamic
ruleset.
- Cult refactored a tiny bit.
- Antag datums cleaned up.
- Pre round setup is less centralized on Dynamic.
- Admins have a whole panel for interfacing with dynamic. It's pretty
slapdash I'm sure someone could make a nicer looking one.
- Maybe some other things.
See readme for more info.
Will you see a massive change in how rounds play out? My hunch says
rounds will spawn less rulesets on average, but it's ultimately to how
it's configured
🆑 Melbert
refactor: Dynamic rewritten entirely, report any strange rounds
config: Dynamic config reworked, it's now a TOML file
refactor: Refactored antag roles somewhat, report any oddities
refactor: Refactored Revolution entirely, report any oddities
del: Deleted most midround events that spawn antags - they use dynamic
rulesets now
add: Dynamic rulesets can now be false alarms
add: Adds a random event that gives dynamic the ability to run another
ruleset later
admin: Adds a panel for messing around with dynamic
admin: Adds a panel for chance for every dynamic ruleset to be selected
admin: You can spawn revs without using dynamic now
fix: Nuke team leaders get their fun title back
/🆑
(cherry picked from commit
|
||
|
John WillardandRoxy
|
78cffc2101 |
Adds a new halloween species: Spirits (#90711)
Adds 2 new species: Spirits and Ghosts
Spirits are available roundstart during Halloween, Wabbajack and
Xenobio's black slime extract
Ghosts are available through Magic mirrors
They fly around, and don't have legs and instead float around. They also
can't get legs implanted onto themselves.
They also do have organs, so they are affected by flashbangs, they do
get hungry, they do need oxygen to survive (they don't take damage in
space but they do suffocate & get slowdown), and can process chems.
Gibbing a ghost gives ectoplasm, an ingredient for ghost burgers.
Chaplains also got a buff here, null rod-type weapons' bane is now
against Spirit mobs, rather than hardcoded revenants. This means it now
includes Spirits/Ghosts, but also Soulscythes & Cult shades.
Also re-adds https://github.com/tgstation/tgstation/pull/81630 which was
reverted in https://github.com/tgstation/tgstation/pull/86506 which I
assume was accidental.
Ghosts have an innate ability to become incorporeal, which allows them
to phase through walls and stuff. Using this will immediately make them
drop any non-ghost limb/organ (not implants cause I thought it would be
funny). This ability is not available if they have holy water in their
system, and like revenants they also can't walk over blessed tiles with
it. They are also invisible to cameras while using this (not the obscura
though).
Sprites taken from observers directly, if anyone wants to make custom
sprites for them feel free. If anyone wants to make this obtainable
somehow in-game as well I wouldn't be opposed, halloween is just where I
thought it would fit most.
This also adds a lot of fixes that I encountered trying to add this,
from systems that have been neglected throughout the years.
https://github.com/user-attachments/assets/e368d710-80a0-4c63-b271-1abe3dd41a5e
We haven't gotten a new halloween species in a long time and thought it
would be fun if you can play as an actual ghost, the soul that remains
after a person passes, so Halloween feels more haunted. It's overall
made in just good fun, with a bonus that Ghosts are a cool species to
play with as well for Wizards & maybe Chaplains in the future (Dead sect
when?)
🆑
add: Added a new halloween species: Spirits, a species without legs and
instead floats.
add: Added a new magic mirror species: Ghosts, like spirits but with the
ability to become incorporeal, traversing through solid wall.
fix: Mobs unable to use storage items now can't use storage items.
fix: Mobs unable to use items can now not open airlocks & closets
fix: Mobs unable to pick items up can no longer pick items up and
immediately drop, moving one tile at a time.
fix: Mobs with intentional missing limbs (Alien larva) no longer show
their limbs as missing on examine (again)
fix: Golems' pref page had a missing icon, it now has one.
/🆑
---------
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
(cherry picked from commit
|
||
|
MrMelbertandGitHub
|
4c277dc572 |
Dynamic Rework (#91290)
## About The Pull Request Implements https://hackmd.io/@tgstation/SkeUS7lSp , rewriting Dynamic from the ground-up - Dynamic configuration is now vastly streamlined, making it far far far easier to understand and edit - Threat is gone entirely; round chaos is now determined by dynamic tiers - There's 5 dynamic tiers, 0 to 4. - 0 is a pure greenshift. - Tiers are just picked via weight - "16% chance of getting a high chaos round". - Tiers have min pop ranges. "Tier 4 (high chaos) requires 25 pop to be selected". - Tier determines how much of every ruleset is picked. "Tier 4 (High Chaos) will pick 3-4 roundstart[1], 1-2 light, 1-2 heavy, and 2-3 latejoins". - The number of rulesets picked depends on how many people are in the server - this is also configurable[2]. As an example, a tier that demands "1-3" rulesets will not spawn 3 rulesets if population <= 40 and will not spawn 2 rulesets if population <= 25. - Tiers also determine time before light, heavy, and latejoin rulesets are picked, as well as the cooldown range between spawns. More chaotic tiers may send midrounds sooner or wait less time between sending them. - On the ruleset side of things, "requirements", "scaling", and "enemies" is gone. - You can configure a ruleset's min pop and weight flat, or per tier. - For example a ruleset like Obsession is weighted higher for tiers 1-2 and lower for tiers 3-4. - Rather than scaling up, roundstart rulesets can just be selected multiple times. - Rulesets also have `min_antag_cap` and `max_antag_cap`. `min_antag_cap` determines how many candidates are needed for it to run, and `max_antag_cap` determines how many candidates are selected. - Rulesets attempt to run every 2.5 minutes. [3] - Light rulesets will ALWAYS be picked before heavy rulesets. [4] - Light injection chance is no longer 100%, heavy injection chance formula has been simplified. - Chance simply scales based on number of dead players / total number off players, with a flag 50% chance if no antags exist. [5] [1] This does not guarantee you will actually GET 3-4 roundstart rulesets. If a roundstart ruleset is picked, and it ends up being unable to execute (such as "not enough candidates", that slot is effectively a wash.) This might be revisited. [2] Currently, this is a hard limit - below X pop, you WILL get a quarter or a half of the rulesets. This might be revisited to just be weighted - you are just MORE LIKELY to get a quarter or a half. [3] Little worried about accidentally frontloading everything so we'll see about this [4] This may be revisited but in most contexts it seems sensible. [5] This may also be revisited, I'm not 100% sure what the best / most simple way to tackle midround chances is. Other implementation details - The process of making rulesets has been streamlined as well. Many rulesets only amount to a definition and `assign_role`. - Dynamic.json -> Dynamic.toml - Dynamic event hijacked was ripped out entirely. - Most midround antag random events are now dynamic rulesets. Fugitives, Morphs, Slaughter Demons, etc. - The 1 weight slaughter demon event is gone. RIP in peace. - There is now a hidden midround event that simply adds +1 latejoin, +1 light, or +1 heavy ruleset. - `mind.special_role` is dead. Minds have a lazylist of special roles now but it's essentially only used for traitor panel. - Revs refactored almost entirely. Revs can now exist without a dynamic ruleset. - Cult refactored a tiny bit. - Antag datums cleaned up. - Pre round setup is less centralized on Dynamic. - Admins have a whole panel for interfacing with dynamic. It's pretty slapdash I'm sure someone could make a nicer looking one.   - Maybe some other things. ## Why It's Good For The Game See readme for more info. Will you see a massive change in how rounds play out? My hunch says rounds will spawn less rulesets on average, but it's ultimately to how it's configured ## Changelog 🆑 Melbert refactor: Dynamic rewritten entirely, report any strange rounds config: Dynamic config reworked, it's now a TOML file refactor: Refactored antag roles somewhat, report any oddities refactor: Refactored Revolution entirely, report any oddities del: Deleted most midround events that spawn antags - they use dynamic rulesets now add: Dynamic rulesets can now be false alarms add: Adds a random event that gives dynamic the ability to run another ruleset later admin: Adds a panel for messing around with dynamic admin: Adds a panel for chance for every dynamic ruleset to be selected admin: You can spawn revs without using dynamic now fix: Nuke team leaders get their fun title back /🆑 |
||
|
|
096c032402 |
Adds a new halloween species: Spirits (#90711)
## About The Pull Request Adds 2 new species: Spirits and Ghosts Spirits are available roundstart during Halloween, Wabbajack and Xenobio's black slime extract Ghosts are available through Magic mirrors They fly around, and don't have legs and instead float around. They also can't get legs implanted onto themselves. They also do have organs, so they are affected by flashbangs, they do get hungry, they do need oxygen to survive (they don't take damage in space but they do suffocate & get slowdown), and can process chems. Gibbing a ghost gives ectoplasm, an ingredient for ghost burgers. Chaplains also got a buff here, null rod-type weapons' bane is now against Spirit mobs, rather than hardcoded revenants. This means it now includes Spirits/Ghosts, but also Soulscythes & Cult shades. Also re-adds https://github.com/tgstation/tgstation/pull/81630 which was reverted in https://github.com/tgstation/tgstation/pull/86506 which I assume was accidental. ### The difference between Spirits and Ghosts Ghosts have an innate ability to become incorporeal, which allows them to phase through walls and stuff. Using this will immediately make them drop any non-ghost limb/organ (not implants cause I thought it would be funny). This ability is not available if they have holy water in their system, and like revenants they also can't walk over blessed tiles with it. They are also invisible to cameras while using this (not the obscura though). Sprites taken from observers directly, if anyone wants to make custom sprites for them feel free. If anyone wants to make this obtainable somehow in-game as well I wouldn't be opposed, halloween is just where I thought it would fit most. This also adds a lot of fixes that I encountered trying to add this, from systems that have been neglected throughout the years. https://github.com/user-attachments/assets/e368d710-80a0-4c63-b271-1abe3dd41a5e ## Why It's Good For The Game We haven't gotten a new halloween species in a long time and thought it would be fun if you can play as an actual ghost, the soul that remains after a person passes, so Halloween feels more haunted. It's overall made in just good fun, with a bonus that Ghosts are a cool species to play with as well for Wizards & maybe Chaplains in the future (Dead sect when?) ## Changelog 🆑 add: Added a new halloween species: Spirits, a species without legs and instead floats. add: Added a new magic mirror species: Ghosts, like spirits but with the ability to become incorporeal, traversing through solid wall. fix: Mobs unable to use storage items now can't use storage items. fix: Mobs unable to use items can now not open airlocks & closets fix: Mobs unable to pick items up can no longer pick items up and immediately drop, moving one tile at a time. fix: Mobs with intentional missing limbs (Alien larva) no longer show their limbs as missing on examine (again) fix: Golems' pref page had a missing icon, it now has one. /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> |
||
|
LucyandShadow-Quill
|
449bc3a25a |
Fix a list qdel in /datum/mind/Destroy() (#90456)
## About The Pull Request this changes `QDEL_LIST(memories)` to `QDEL_LIST_ASSOC_VAL(memories)` ## Why It's Good For The Game proper behavior good ## Changelog 🆑 fix: Fixed improperly cleaning up memories when a mind is deleted. /🆑 |
||
|
Waterpig
|
753d8e5ba4 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-04a | ||
|
LucyandGitHub
|
570ce3dc45 |
Fix a list qdel in /datum/mind/Destroy() (#90456)
## About The Pull Request this changes `QDEL_LIST(memories)` to `QDEL_LIST_ASSOC_VAL(memories)` ## Why It's Good For The Game proper behavior good ## Changelog 🆑 fix: Fixed improperly cleaning up memories when a mind is deleted. /🆑 |
||
|
|
52678d41b5 |
Everyone is kung fu fighting: Refactors martial arts / You can have multiple martial arts and swap between them (#89840)
## About The Pull Request Refactors martial arts off the mind. Don't worry the martial arts you learn still transfer with mindswap Instead, they are just tracked on a list on the mob, and they also independently track the datum that created them This fixes a lot of jank with martial arts, like say, having your krav maga gloves transfer across slime clones or something... But it also opens an opportunity: As we track all martial arts available, I added a verb (ic tab) that lets you swap between the ones you know  (Some don't let you swap like that one brain trauma) ## Why It's Good For The Game Aforementioned fixes a lot of jank Recently martial arts have just been up and disappearing and this was entirely spurred on by that bug Probably fixes #84710 (haven't checked) Probably fixes #89247 Probably fixes #89948 Probably fixes #90067 ## Changelog 🆑 Melbert refactor: Refactored martial arts, if you notice any oddities like managing to know two martial arts at once or having your powers disappear, report it! add: If you know multiple martial arts, such as krav maga from gloves and cqc from a book, you can now swap between them at will via a button in the IC tab! /🆑 --------- Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> |
||
|
Kapu1178andRoxy
|
b9c803a9d8 |
Base implementation of /datum/persistent_client (#89449)
Converts `/datum/player_details` into `/datum/persistent_client`. Persistent Clients persist across connections. The only time a mob's persistent client will change is if the ckey it's bound to logs into a different mob, or the mob is deleted (duh). Also adds PossessByPlayer() so that transfering mob control is cleaner and makes more immediate sense if you don't know byond-fu. Clients are an abstract representation of a connection that can be dropped at almost any moment so putting things that should be stable to access at any time onto an undying object is ideal. This allows for future expansions like abstracting away client.screen and managing everything cleanly. |
||
|
JacquerelandRoxy
|
434e4e435e |
Removes Secondary & Final Objectives from Traitors (#89466)
## About The Pull Request  Pre-discussed with @Watermelon914, this PR removes Secondary & Final Objectives from all Traitors, rather than just midround ones. It also removes all of the surrounding supporting code. Randomly assigned Primary Objectives still exist, I just used the ability to rewrite mine to take the screenshot. In terms of final objectives, the surrounding items that were available still exist but don't necessarily have sources. If anyone has good ideas for readding these in some other form it can be done in future PRs. It also allows all traitors to buy the Contractor kit, previously limited to midround traitors which lacked secondary objectives, because now all traitors lack secondary objectives. This essentially limits all traitors to a maximum of 20 TC (16 if they spawn with an uplink implant). Currently I don't foresee that they strictly need any additional way of gaining TC during a round as 20 is quite sufficient, but it may take some time to adjust and get used to it after such a long time of having access to more. If we need to adjust the starting value or add a slow drip of more points over time or something, that can be done in followup PRs. This also removes the ability to recreate your uplink added by my beautiful wife in #74315 This was part of the progression traitor design document, but ultimately probably a bad idea as it essentially made traitors impossible to properly disarm. You will once more just need to carefully protect your uplink. **This does not remove the threat/progression system**. Like midround traitors, all Reputation requirements on gear are now simple timelocks, most of which will have elapsed by the time 30 minutes have passed. **Finally** this PR also adds Romerol to the traitor uplink for 25 TC and 30 minutes of reputation, as a treat (and because I removed the final objective that previously granted it). ## Why It's Good For The Game We've tried this system for a long time (3 years last month!) and while I think it had a lot of promise, enabled some cool moments, and also solved several of the problems it set out to solve, overall I think some of the behaviours it has encouraged in players have been overall negative for the game. While the _game systems_ are fine, even quite fun and cool (especially final objectives) I am of the opinion that having them in the game creates a net negative purely in the way that they react with players' _brains_, creating incentives towards behaviour we don't actually want people to pursue. While it's hard-to-impossible to prove any of this with hard data, there has been a prevailing feeling for some time among many (though certainly not all) people that the simple fact of _having_ a constant drip-feed of objective available to players leads directly to less interesting antagonist play. While certainly nobody is _forced_ to do secondary objectives you are directly and quite strongly rewarded for doing so, doing so efficiently, and doing so in a way which makes sure that nobody (alive) sees you do it. This leads to a tendency to play defensively and try to maximise the number of tasks you can complete in one round, which also has a knock-on effect of generally minimising the number of people you attempt to interact with in a round (unless you are killing them). Even people who _intend_ on doing some more interesting gimmick can fall into this trap, as "having more tools" is always useful for anyone who is intending on any kind of plan at all, but then executing on the secondary objectives again incentivises you to lay low, not interact with anyone, be efficient, and then reduces the time you are spending doing the thing that's your actual plan for the round. Removing the ever-present temptation to fish for extra TC leaves "doing whatever your actual plan is" as the sole thing to optimise. Final Objectives too have created unfortunate psychological effects between crewsided players and other antagonists. Because of the _threat_ (no matter how remote, Final Objectives have always been tuned to be appropriately rare) that leaving any antagonist alone will cause them to snowball by acquiring more power, it starts to feel foolish to respond to any threat with less than the maximum possible level of force even if they seem relatively innocuous in the moment. This even has an effect on other non-progression antagonists, as traitors are the most common antagonist type and how people treat them is going to be their default level of reaction to most other station threats. While there has always been the promise of expanding the system with novel and exciting objectives that leverage appearing mid-round to do something unique, we've taken very little advantage of that over time. Most objectives we have added that didn't boil down to "kill someone, with a twist" have been somewhat unsuccessful, serving either as ways to get yourself arrested and killed for no reason or ways to get free telecrystals by doing something the crew don't really care about stopping you from doing. The option still exists to add more roundstart objectives to traitors, if someone suddenly has a great idea that would fit in this space. The ideal outcome of making this change is a slight relaxation of crew attitude towards feeling like their only option after catching an antagonist that isn't sandbagging is to permanently remove them from the round (although it's fine to do this still in many scenarios), and a broadening of traitorous activity which is not purely focused on collecting as many checkboxes as possible and might give people more time to roleplay with other players, not worrying that this time could have been more efficiently spent pursuing a different secondary goal. I don't anticipate or desire that this will prevent traitors from killing anyone (or even stop them from killing people they don't have a specific objective to kill), I just want to remove the FOMO from people's minds. Also this gives us something to talk about at the coder townhall meeting on the 22nd. ## Changelog 🆑 del: Misplaced or stolen traitor uplinks can no longer be recreated using a radio code and special device, guard yours carefully or buy a backup implant. del: Roundstart traitors can no longer take on additional objectives in order to earn additional Telecrystals and fast-forward any unlock timers on items. They also cannot earn the ability to complete a Final Objective. balance: Roundstart traitors can now buy the Contractor Kit from their traitor uplink, rather than only midround traitors. add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has passed in a round. /🆑 |
||
|
Kapu1178andGitHub
|
a0e862d575 |
Base implementation of /datum/persistent_client (#89449)
## About The Pull Request Converts `/datum/player_details` into `/datum/persistent_client`. Persistent Clients persist across connections. The only time a mob's persistent client will change is if the ckey it's bound to logs into a different mob, or the mob is deleted (duh). Also adds PossessByPlayer() so that transfering mob control is cleaner and makes more immediate sense if you don't know byond-fu. ## Why It's Good For The Game Clients are an abstract representation of a connection that can be dropped at almost any moment so putting things that should be stable to access at any time onto an undying object is ideal. This allows for future expansions like abstracting away client.screen and managing everything cleanly. |
||
|
Majkl-J
|
b6b8306fda | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-02a | ||
|
JacquerelandGitHub
|
23ac16411d |
Removes Secondary & Final Objectives from Traitors (#89466)
## About The Pull Request  Pre-discussed with @Watermelon914, this PR removes Secondary & Final Objectives from all Traitors, rather than just midround ones. It also removes all of the surrounding supporting code. Randomly assigned Primary Objectives still exist, I just used the ability to rewrite mine to take the screenshot. In terms of final objectives, the surrounding items that were available still exist but don't necessarily have sources. If anyone has good ideas for readding these in some other form it can be done in future PRs. It also allows all traitors to buy the Contractor kit, previously limited to midround traitors which lacked secondary objectives, because now all traitors lack secondary objectives. This essentially limits all traitors to a maximum of 20 TC (16 if they spawn with an uplink implant). Currently I don't foresee that they strictly need any additional way of gaining TC during a round as 20 is quite sufficient, but it may take some time to adjust and get used to it after such a long time of having access to more. If we need to adjust the starting value or add a slow drip of more points over time or something, that can be done in followup PRs. This also removes the ability to recreate your uplink added by my beautiful wife in #74315 This was part of the progression traitor design document, but ultimately probably a bad idea as it essentially made traitors impossible to properly disarm. You will once more just need to carefully protect your uplink. **This does not remove the threat/progression system**. Like midround traitors, all Reputation requirements on gear are now simple timelocks, most of which will have elapsed by the time 30 minutes have passed. **Finally** this PR also adds Romerol to the traitor uplink for 25 TC and 30 minutes of reputation, as a treat (and because I removed the final objective that previously granted it). ## Why It's Good For The Game We've tried this system for a long time (3 years last month!) and while I think it had a lot of promise, enabled some cool moments, and also solved several of the problems it set out to solve, overall I think some of the behaviours it has encouraged in players have been overall negative for the game. While the _game systems_ are fine, even quite fun and cool (especially final objectives) I am of the opinion that having them in the game creates a net negative purely in the way that they react with players' _brains_, creating incentives towards behaviour we don't actually want people to pursue. While it's hard-to-impossible to prove any of this with hard data, there has been a prevailing feeling for some time among many (though certainly not all) people that the simple fact of _having_ a constant drip-feed of objective available to players leads directly to less interesting antagonist play. While certainly nobody is _forced_ to do secondary objectives you are directly and quite strongly rewarded for doing so, doing so efficiently, and doing so in a way which makes sure that nobody (alive) sees you do it. This leads to a tendency to play defensively and try to maximise the number of tasks you can complete in one round, which also has a knock-on effect of generally minimising the number of people you attempt to interact with in a round (unless you are killing them). Even people who _intend_ on doing some more interesting gimmick can fall into this trap, as "having more tools" is always useful for anyone who is intending on any kind of plan at all, but then executing on the secondary objectives again incentivises you to lay low, not interact with anyone, be efficient, and then reduces the time you are spending doing the thing that's your actual plan for the round. Removing the ever-present temptation to fish for extra TC leaves "doing whatever your actual plan is" as the sole thing to optimise. Final Objectives too have created unfortunate psychological effects between crewsided players and other antagonists. Because of the _threat_ (no matter how remote, Final Objectives have always been tuned to be appropriately rare) that leaving any antagonist alone will cause them to snowball by acquiring more power, it starts to feel foolish to respond to any threat with less than the maximum possible level of force even if they seem relatively innocuous in the moment. This even has an effect on other non-progression antagonists, as traitors are the most common antagonist type and how people treat them is going to be their default level of reaction to most other station threats. While there has always been the promise of expanding the system with novel and exciting objectives that leverage appearing mid-round to do something unique, we've taken very little advantage of that over time. Most objectives we have added that didn't boil down to "kill someone, with a twist" have been somewhat unsuccessful, serving either as ways to get yourself arrested and killed for no reason or ways to get free telecrystals by doing something the crew don't really care about stopping you from doing. The option still exists to add more roundstart objectives to traitors, if someone suddenly has a great idea that would fit in this space. The ideal outcome of making this change is a slight relaxation of crew attitude towards feeling like their only option after catching an antagonist that isn't sandbagging is to permanently remove them from the round (although it's fine to do this still in many scenarios), and a broadening of traitorous activity which is not purely focused on collecting as many checkboxes as possible and might give people more time to roleplay with other players, not worrying that this time could have been more efficiently spent pursuing a different secondary goal. I don't anticipate or desire that this will prevent traitors from killing anyone (or even stop them from killing people they don't have a specific objective to kill), I just want to remove the FOMO from people's minds. Also this gives us something to talk about at the coder townhall meeting on the 22nd. ## Changelog 🆑 del: Misplaced or stolen traitor uplinks can no longer be recreated using a radio code and special device, guard yours carefully or buy a backup implant. del: Roundstart traitors can no longer take on additional objectives in order to earn additional Telecrystals and fast-forward any unlock timers on items. They also cannot earn the ability to complete a Final Objective. balance: Roundstart traitors can now buy the Contractor Kit from their traitor uplink, rather than only midround traitors. add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has passed in a round. /🆑 |
||
|
|
92a585cb3a |
new icebox ruin: outpost 31 + megafauna (technically???) (#88714)
## About The Pull Request <details> <summary> expand to spoil the fun of exploring something for yourself </summary> firstly, the new ruin: outpost 31 its layout is vaguely based off an official map of the Outpost 31 from the Thing movie but i ran out of space halfway  the boss drops a keycard for the storage room that you cant get in otherwise, containing its own special item, and other stuff probably useful for crew crusher loot: trophy that heals you on each hit the ruin is guarded by like 3 flesh blobs, very resilient (and slow) masses of flesh that deal 3 brute damage, not harmful in melee but WILL attempt to grab and devour/assimilate you which is FAR more lethal https://github.com/user-attachments/assets/542cc6d0-f4ee-4598-9677-a03170c6c1c3 Boss: The Thing (with creative liberties otherwise this thing would instakill you if it was true to source material) difficulty: medium apparently idk mining jesus beat it with 400ms or so HP: 1800 It is a much higher ranking changeling than those infiltrating SS13 It has 3 phases, 600hp each. Depleting its phase health will turn it invincible and it will heal back half in 10 seconds. In order to prevent this, the two Molecular Accelerators must be overloaded by interacting with them to blast the changeling with deadly scifi magic or whatever they do, forcing it to shed its form further and go to the next phase. Not necessary for phase 3 because it literally just dies then it focuses mostly on meleeing you and making certain tiles impassable for you with 1hp tendrils, all attacks are telegraphed so theres no dumb instakills here it alternates between aoe abilities and abilities melee behavior: - if too far, charge at target (charges twice on phase 3) - too close, shriek (unavailable in phase 1) (technically AOE but its more like a melee ability you know??) - otherwise just try to melee Shriek: if the player is too close emit a confusing shriek that makes them confused and drop items aoe behavior (phase 2, 3 only): 1: Puts 4 tendrils in a line cardinally 2: Puts tendrils around itself 3. Puts a patch of tendrils around and under the target, 3x3 in phase 3 4. Phase 3 only - spits patches of acid into the air that hurt when stepped on _(crusher is hard ok)_ https://github.com/user-attachments/assets/cbb98209-d3f0-470d-b0e8-4e310c5b709c unique megafauna loot for this boss is like 1 AI-Uplink brain its like a BORIS module but for humans i think you can figure out what that means while in a human shell they cannot roll non-malf midrounds and cannot be converted, and cannot be mindswapped the human MUST have all robotic organs (minus tongue because its not in the exosuit fab and that kinda sucks to get) will undeploy if polymorphed https://github.com/user-attachments/assets/abcc277a-995a-4fa7-b980-0549b6b7cf52 </details> ## Why It's Good For The Game icebox is severely lacking in actual good ruins (fuck that one fountain ruin) i feel that the loot given by megafauna has been and still apparently is exclusively to make the victor more powerful, which kinda sucks because thats just powergaming???? the loot of this boss is more crewsided, specifically aiding the AI in a VERY limited quantity (1), so its not anything good for powergamers, good for crew if the AI is not rogue ## Changelog 🆑 add: outpost 31, the icebox ruin. Also its associated mobs, and megafauna, and loot. Im not spoiling anything, find it yourself. /🆑 --------- Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> |
||
|
|
d170a410d4 |
Recovered Crew | Medical+Cargo Respawns (#87072)
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> |
||
|
Majkl-J
|
e59d8ba64b | Merge commit '179a607a90ad7ec62bdaff4e6fe72af60ee56442' of https://github.com/tgstation/tgstation into upstream-24-10b | ||
|
TimberpoesandGitHub
|
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. /🆑 |
||
|
Kyle Spier-SwensonandGitHub
|
4d1639b04c |
Revert "Assorted changes to job assignment code and logging." (#85929)
Reverts tgstation/tgstation#85308  |
||
|
|
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>
|
||
|
|
c9e8162a8a |
[MIRROR] Abductors can no longer be converted by conversion antags (#29310)
* Abductors can no longer be converted by conversion antags (#84766) ## About The Pull Request Basically what the title says. Abductors cannot be converted by bloodbrother/revs/cult. They will NOT show up as having a mindshield, however. ## Why It's Good For The Game Abductors are, by design, incredibly strong. You are not meant to be able to win against them, and this is reflected policy-wise by the fact that they're a restricted antagonist. However, this is still a problem when conversion antags get involved. If an abductor becomes a cultist or a revolutionary, then suddenly every other player who isn't also converted has to deal with an abductor without the normal restrictions. It's not fun to play against and in general just shouldn't happen. ## Changelog 🆑 balance: Abductors (the antag, not the species) can no longer be converted by any antagonist. /🆑 * Abductors can no longer be converted by conversion antags --------- Co-authored-by: GPeckman <21979502+GPeckman@users.noreply.github.com> |
||
|
GPeckmanandGitHub
|
f69284be5b |
Abductors can no longer be converted by conversion antags (#84766)
## About The Pull Request Basically what the title says. Abductors cannot be converted by bloodbrother/revs/cult. They will NOT show up as having a mindshield, however. ## Why It's Good For The Game Abductors are, by design, incredibly strong. You are not meant to be able to win against them, and this is reflected policy-wise by the fact that they're a restricted antagonist. However, this is still a problem when conversion antags get involved. If an abductor becomes a cultist or a revolutionary, then suddenly every other player who isn't also converted has to deal with an abductor without the normal restrictions. It's not fun to play against and in general just shouldn't happen. ## Changelog 🆑 balance: Abductors (the antag, not the species) can no longer be converted by any antagonist. /🆑 |
||
|
|
61ec10c3e0 |
[MIRROR] grep's for "recieve" typos (#27826)
* grep's for "recieve" typos (#83369) Just spellchecking some common mistakes. * Missed these. --------- Co-authored-by: Afevis <ShizCalev@users.noreply.github.com> Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> |
||
|
AfevisandGitHub
|
53a8ba74c8 |
grep's for "recieve" typos (#83369)
Just spellchecking some common mistakes. |
||
|
|
d5d7dcef2b |
[MIRROR] Traitor Traitor Panel Fixes (#26561)
* Traitor Traitor Panel Fixes (#81521) ## About The Pull Request - Fixes #81514 - Setting TC checked for `value && isnum(value)` which was dumb when `value` could be `0`. - Removing Traitor auto-takes uplink from the mob - Removing Uplink now removes just the uplink code from memory, rather than all memories ## Changelog 🆑 Melbert admin: You can now set someone's TC to 0 admin: Removing Traitor from automatically removes the uplink from them admin: Removing Uplink from someone no longer wipes ALL of their memories /🆑 * Traitor Traitor Panel Fixes --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
d23f582605 |
Traitor Traitor Panel Fixes (#81521)
## About The Pull Request - Fixes #81514 - Setting TC checked for `value && isnum(value)` which was dumb when `value` could be `0`. - Removing Traitor auto-takes uplink from the mob - Removing Uplink now removes just the uplink code from memory, rather than all memories ## Changelog 🆑 Melbert admin: You can now set someone's TC to 0 admin: Removing Traitor from automatically removes the uplink from them admin: Removing Uplink from someone no longer wipes ALL of their memories /🆑 |
||
|
|
0938c796a8 |
[MIRROR] Adds a signal to buying items from the uplink (& fixes TC misinfo) (#26449)
* Adds a signal to buying items from the uplink (& fixes TC misinfo) (#81372) ## About The Pull Request Adds a signal when someone buys an item from the uplink and removes single-letter vars from the ``spawn_item`` proc, and adds/standardizes add/removing of telecrystals from uplinks (and admin setting how much TC they have) to ensure the UI always has the right amount of telecrystals displayed in it. ## Why It's Good For The Game There are reasons why someone would want to hook up to a traitor's uplink and listen to items they purchase to do any special effect on-purchase, so this adds support to do anything in the future with it. Also tells players how much TC they actually have without forcing them to close/reopen the UI every time they insert some TC in it by hand. ## Changelog 🆑 fix: Uplinks now update their UI when you add telecrystals in them, so you don't need to close and reopen it. /🆑 * Adds a signal to buying items from the uplink (& fixes TC misinfo) --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> |
||
|
John WillardandGitHub
|
fdcd4d3979 |
Adds a signal to buying items from the uplink (& fixes TC misinfo) (#81372)
## About The Pull Request Adds a signal when someone buys an item from the uplink and removes single-letter vars from the ``spawn_item`` proc, and adds/standardizes add/removing of telecrystals from uplinks (and admin setting how much TC they have) to ensure the UI always has the right amount of telecrystals displayed in it. ## Why It's Good For The Game There are reasons why someone would want to hook up to a traitor's uplink and listen to items they purchase to do any special effect on-purchase, so this adds support to do anything in the future with it. Also tells players how much TC they actually have without forcing them to close/reopen the UI every time they insert some TC in it by hand. ## Changelog 🆑 fix: Uplinks now update their UI when you add telecrystals in them, so you don't need to close and reopen it. /🆑 |
||
|
|
8e7ec57fd2 |
[MIRROR] Kicks Martial Arts out of the attack chain (yippee), makes it use signals, plus a large clean up of existing martial arts (#26328)
Kicks Martial Arts out of the attack chain (yippee), makes it use signals, plus a large clean up of existing martial arts (#81097) - Kicks Martial Arts out of the attack chain. - All Martial Arts attacks are now handled via unarmed attack or grab signals - This means all martial arts are now technically on the living level, allowing any mob that can unarmed attack to martial arts. Sort of. YMMV. - All martial arts block checking is now handled by the arts themselves, meaning you can selectively decide for a martial arts strike to not be blocked. Maybe good for the future. - A comprehensive cleanup of all existing martial arts. Improving var names, code, adding some missing animation calls, etc. Fixes #74829 Untangles the mess that is martial arts, making it a lot easier to work with the attack chain and making it overall a ton more consistent. 🆑 Melbert refactor: Big martial arts refactor, they should now overall act a ton more consistent. Also technically any mob can do martial arts. Let me know if something is funky. /🆑 --------- Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
e21dc5fec7 |
Kicks Martial Arts out of the attack chain (yippee), makes it use signals, plus a large clean up of existing martial arts (#81097)
## About The Pull Request - Kicks Martial Arts out of the attack chain. - All Martial Arts attacks are now handled via unarmed attack or grab signals - This means all martial arts are now technically on the living level, allowing any mob that can unarmed attack to martial arts. Sort of. YMMV. - All martial arts block checking is now handled by the arts themselves, meaning you can selectively decide for a martial arts strike to not be blocked. Maybe good for the future. - A comprehensive cleanup of all existing martial arts. Improving var names, code, adding some missing animation calls, etc. Fixes #74829 ## Why It's Good For The Game Untangles the mess that is martial arts, making it a lot easier to work with the attack chain and making it overall a ton more consistent. ## Changelog 🆑 Melbert refactor: Big martial arts refactor, they should now overall act a ton more consistent. Also technically any mob can do martial arts. Let me know if something is funky. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
|
e087d08bd3 |
[MIRROR] Fix roundstart crewmembers not getting their radio hint message / Examine blocks out starting job information [MDB IGNORE] (#23990)
* Fix roundstart crewmembers not getting their radio hint message / Examine blocks out starting job information * Update job.dm * Fixing the modular stuff This really needs to be refactored to be less edits in the future... --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
9ebfb27940 |
Fix roundstart crewmembers not getting their radio hint message / Examine blocks out starting job information (#78647)
## About The Pull Request - Fixes roundstart jobs not getting information from `radio_help_message` - Adds extra information for the Captain - Examine blocks out roundstart / latejoin job information Roundstart:  Latejoin:  ## Why It's Good For The Game 1. Roundstart mobs weren't getting radio information due to them not being cliented yet, this has been fixed. 2. The roundstart block was pretty cumbersome to read and easy to have your eyes glaze over, this should make it easier. ## Changelog 🆑 Melbert qol: Examine blocked out roundstart / latejoin job information. qol: Captain gets a little bit more information about how their radio works roundstart. fix: Fixed roundstart players not getting radio information. /🆑 |
||
|
|
eb31082053 |
[MIRROR] Choose your own Objective [MDB IGNORE] (#23570)
* Choose your own Objective * Update changeling.dm * Update heretic_antag.dm * Update heretic_antag.dm * Update malf_ai.dm * Update AntagInfoHeretic.tsx --------- Co-authored-by: Jacquerel <hnevard@gmail.com> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
JacquerelandGitHub
|
6d258e5527 |
Choose your own Objective (#78118)
## About The Pull Request   This PR adds the ability for solo antagonists (Traitor, Changeling, Heretic, Wizard, Malfunctioning AI, and Ninja) to "write-in" their own objectives in place of the ones the game gave them. For traitors this is located on the uplink (though the button is not present if you aren't the owner of the uplink, thieves can't give you a troll objective) and for everyone else it is on the antagonist information panel. Pressing this button will replace all of your objectives _except_ ones like "escape alive" or "survive" or "die a glorious death". By default a player can only do this once per round, but the Traitor Panel admin tool contains a button which can display the prompt again. Custom-entered objectives are not mechanically tracked in any way and do not report success or failure on the round end screen, whether they were successful or not is up to you the audience. Resultingly, doing this will make you ineligible for getting the hardcore random points from completing your objectives. Admins are capable of using this button to show the prompt to _any_ antagonist, including team antagonists, but do so at their own risk. A single cultist changing their objective to something else only updates them, not their team. Admins can also choose whether or not it replaces existing objectives or just adds a new one entered by the player. When someone sets a new objective, it informs any active administrators of their choice and provides linked buttons to send them a syndicate radio message or immediately smite them, because unfortunately our players cannot always be trusted with arbitrary text entry. I _didn't_ make this a system which requires approval because I don't think admins _want_ that level of micromanagement, although plausibly if it is thought to be a good idea I could add a time delay and reject button similar to the "rename the station" charter item. Heretics work slightly differently and have an "Are you sure?" confirmation other antagonists lack. This is because Heretic objectives are directly tied to ascension, thus by replacing the objectives you are locking yourself out from being able to do it. I don't _necessarily_ think this is a terrible thing, because "try to ascend" _is_ the default objective. There's no point entering a new one if that is what you want to do anyway. While I was in here I gave Ninjas a very rudimentary custom antagonist panel, because they didn't have one. I also made their C4 display where it can be detonated on examine, in case you no longer have the relevant objective to reference. <details> <summary>Other previews</summary>      </details> ## Why It's Good For The Game It's a reasonably frequent refrain that "Objectives are just guidelines" and that more interesting players should strive to ignore them and do something else, I would hope this would encourage that kind of behaviour. If you _are_ going off and doing your own thing, now other players can actually see what it was that you were trying to do when the round ends (and judge you based on whether you actually did it). ## Changelog 🆑 add: Traitors, Changelings, Heretics, Wizards, Malfunctioning AIs, and Ninjas can now all reject their original objectives and provide one of their own in its place. A Heretic doing this will no longer be able to ascend. add: "Custom" objectives which aren't mechanically tracked will no longer report success or failure upon round end. qol: Space Ninja spider charges will now display where they can be detonated when examined, if you are a ninja. /🆑 |
||
|
|
87bfa7a61a |
[MIRROR] Fixes typo 'transfered', olive oil reaction repath [MDB IGNORE] (#23469)
* Fixes typo 'transfered', olive oil reaction repath * Modular * Update condiment.dm * Update recipes_guide.dm * Update _cup.dm --------- Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
BloopandGitHub
|
69f51c6c65 |
Fixes typo 'transfered', olive oil reaction repath (#78064)
## About The Pull Request Transferred. ## Why It's Good For The Game How did this get to be in 71 files?! This bothers me. Also changes 'quality_oil' typepath in the reactions to 'olive_oil' to match its rename post-foodening. ## Changelog N/A |
||
|
|
cfd61708a7 |
[MIRROR] Fixes a handful of cult issues w/ mind transfer [MDB IGNORE] (#22592)
* Fixes a handful of cult issues w/ mind transfer (#76931) ## About The Pull Request Makes cult spells spawn in the mind, which is required for spells to transfer between bodies Moves bloodsense and the trait to heal from pylons from ``on_gain()`` (the proc that is called once when the antag is given) to ``apply_innate_effects`` (the proc that is called one time per body), basically this means bloodsense and pylon healing follows the cultist instead of remaining solely on their original body. Adds a check to cult master vote, because it runtimes when transferring body. ## Why It's Good For The Game Closes https://github.com/tgstation/tgstation/issues/76746 Fixes part of https://github.com/tgstation/tgstation/issues/76671 ## Changelog 🆑 fix: Cult spells, bloodsense, and pylon healing now follow cultists through mind transfer (such as body swapping) /🆑 * Fixes a handful of cult issues w/ mind transfer --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> |
||
|
John WillardandGitHub
|
4645793882 |
Fixes a handful of cult issues w/ mind transfer (#76931)
## About The Pull Request Makes cult spells spawn in the mind, which is required for spells to transfer between bodies Moves bloodsense and the trait to heal from pylons from ``on_gain()`` (the proc that is called once when the antag is given) to ``apply_innate_effects`` (the proc that is called one time per body), basically this means bloodsense and pylon healing follows the cultist instead of remaining solely on their original body. Adds a check to cult master vote, because it runtimes when transferring body. ## Why It's Good For The Game Closes https://github.com/tgstation/tgstation/issues/76746 Fixes part of https://github.com/tgstation/tgstation/issues/76671 ## Changelog 🆑 fix: Cult spells, bloodsense, and pylon healing now follow cultists through mind transfer (such as body swapping) /🆑 |
||
|
|
02648adcd6 |
[MIRROR] Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests [MDB IGNORE] (#22348)
* Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests * Fixing merge conflicts * don't forget to ctrl+s! * Another forgotten file * urgh * gets rid of vestiges of update_atom_languages() and mind language holders * No longer needed * Fixes some modular grant_language calls * Deprecated code * This was up here before.. * Fixes failing unit tests, refactors silverscale lizards language a bit removing the need for skyrat edits Removes some no longer needed code --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com> Co-authored-by: Giz <vinylspiders@gmail.com> |
||
|
MrMelbertandGitHub
|
8c1e35e1c0 |
Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests (#76612)
## About The Pull Request This PR refactors mind language holders into non-existence As a result, `update_atom_languages` is no longer necessary Mind-bound languages are transferred via `/mind/proc/transfer_to` Species changing no longer deletes and re-creates the mob's language holder, allowing them to keep any languages they have. Species languages are sourced from `LANGUAGE_SPECIES` now, meaning they are removed when they change species. If the mob is not a human with a species datum, these are effectively just atom level languages. Makes a bunch of unit tests to ensure language transfer over certain events works as intended ## Why It's Good For The Game Mobs with minds having two independent language holders results in a good few bugs, and simply doesn't make sense when we have sources (`LANGUAGE_MIND`). Instead of tracking two language holders, we can simply use sources better and only track one. This means that the language holder you start with is your language holder, period. It doesn't get deleted or re-instantiated or whatever. ## Changelog 🆑 Melbert refactor: Refactored language holders, making species changes not delete all of your known languages /🆑 |
||
|
|
beacfec8be |
Fixes some species keeping galcom because of shenanigans / codifies silverscales understanding but not speaking common (#76342)
## About The Pull Request 1. Default language holders understand GALCOM on their mind, but speak it on their atom https://github.com/tgstation/tgstation/blob/0a37898f4da161d6f45c209e1f88546e068a64fd/code/modules/language/language_holder.dm#L39-L43 2. Living mobs defer to their mind's language holder over their body's language holder https://github.com/tgstation/tgstation/blob/0a37898f4da161d6f45c209e1f88546e068a64fd/code/modules/mob/living/living_say.dm#L559-L562 3. Mind get_language_holder, an entirely different proc, makes a default language holder when it is created https://github.com/tgstation/tgstation/blob/0a37898f4da161d6f45c209e1f88546e068a64fd/code/datums/mind/_mind.dm#L169-L172 4. Setting species changes your language holder entirely https://github.com/tgstation/tgstation/blob/0a37898f4da161d6f45c209e1f88546e068a64fd/code/datums/dna.dm#L490-L493 5. When your mind's default language holder is synced with your body's species language holder's **ATOM LANGUAGES**, it will clear your languages of all atom languages and then add in all the new ones. You will notice that mind sourced languages are untouched. This leaves the understood-via-mind galcom entry from default language holders there, despite the mob, say, being unable to otherwise understand galcom. I've fixed this weird chain of events by having mind language holders default to your current species language holder or current body language holder. This is admittedly, kind of a bandaid. **Mind language holder should not exist**. Mind sourced languages should just be passed around in mind swaps as you would expect. But that's a larger refactor. Closes #76330 , but keeps Silverscales as able to understand but not speak galcom. I think it's funny if they can hear the peasants but refuse to stoop to their language no matter what. ## Why It's Good For The Game People shouldn't able to understand common in some situations ## Changelog 🆑 Melbert fix: Fixes some species / mobs keeping an understanding of galcom despite not being intended to. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |