mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-19 20:15:47 +01:00
docker-container
20 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Leland Kemble
|
d49c825f8e |
Bitrunning glitches take much longer to escape their simulation if there are remaining active bitrunners (#95934)
## About The Pull Request For every living, connected bit avatar remaining in the simulation, the `do_after()` for leaving the simulation as a bitrunning glitch ghost role is multiplied by 5. The base timer remains at it was, two seconds. Additionally, there is an exception in place for the "Island Brawl" domain, which is the FFA with infinite respawns. It still multiplies by 5 for each active bitrunner, but that multiplier is reduced by 1 for each death, so you likely only have to kill one wave of bitrunners for normal escape time. Additionally, because of necessity for the exception and also basic good sense, bitrunning points are no longer component-based on specific turfs in the domain, and are held in the server. It never should have been a component, it had no reason to be one. This, as a consenquence, also fixes that you could completely softlock any domain using points by simply crowbarring the turf that the crate was yet to spawn on. ## Why It's Good For The Game Yesterday, I saw one of the lamest things I've ever seen in the game. A bitrunning glitch spawns in, walks literally right by two bitrunners as they ask who he is, and leaves the simulation to go on a killing spree unburdened. There was extenuating circumstances in that situation, but it still was a miserable breakdown of what I think the intended gameplay of a bitrunning glitch is, and shows how ridiculously easy it is to simply not engage with the intended hurdle in your path. The primary(and, really, only) job of a glitch is to kill bit avatars, and this PR makes it significantly more difficult to just... walk by them to go on your killing spree on station. Work, then play. ## Changelog 🆑 balance: For every living, connected bitrunner remaining in a domain, bitrunning glitches will take five times longer to escape. fix: You can no longer softlock any virtual domain that uses points by crowbarring the reward turf before the crate spawns. /🆑 |
||
|
MrMelbert
|
a91f04d435 |
Being absorbed now makes you into an imaginary friend of the changeling (#94956)
## About The Pull Request When you get absorbed by a changeling, you get made into an imaginary friend of the changeling that absorbed you <img width="349" height="185" alt="image" src="https://github.com/user-attachments/assets/03b00f37-8428-49c9-90c0-c165429e0674" /> <img width="290" height="223" alt="image" src="https://github.com/user-attachments/assets/b40fe663-736b-4184-a50f-18376905a79a" /> <img width="682" height="161" alt="image" src="https://github.com/user-attachments/assets/982102da-7e15-4a9c-93ef-3e12dc72d7d8" /> This imaginary friend doesn't show up on health scan (obviously), and they communicate via hivemind chat, meaning all other changelings are capable of hearing them If your body is revived, you get yoinked out of the hivemind as you'd expect You also have a button to eject yourself from the hivemind (if you prefer to observe). And the ling themselves has a button to eject people from their hivemind that are being annoying ## Why It's Good For The Game Makes being absorbed a little less of a bummer, now you can tag along and maybe even give them some tips about how your character would act if they choose to disguise as you. ## Changelog 🆑 Melbert add: When you get absorbed by a changeling, you get made into an imaginary friend of the changeling that absorbed you. refactor: Refactored how people are returned to their bodies after occupying separate bodies, such as bitrunners and ghost roles. Report any oddities or failure to return correctly. /🆑 |
||
|
Archemagus
|
6f834fb418 |
AAS code cleanup (#93158)
## About The Pull Request - Added full support for RETA system - Categorized all configs for search purposes - Added channel check for most usages of get_announcement_system() calls ## Why It's Good For The Game ## Changelog 🆑 code: Little AAS code cleanup. Added full RETA support. Grouped configs for search purposes. /🆑 |
||
|
MrMelbert
|
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 /🆑 |
||
|
Kapu1178
|
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. |
||
|
Archemagus
|
8a5898212b |
Automated Announcement System refactor (#89276)
## About The Pull Request I standardized stuff in AASs code, and all current reference to it. Also added interactions for bounty cubes, weather reports and request consoles, all of it can be changed from AASs UI. Also it's easier now to add new config entries for AAS to proceed, and it's now downstream friendly. ## Why It's Good For The Game Well, because kind of order in code and because it's funny to make custom messages for... Almost everything? BTW any entry can be blocked from ingame changes, by default you can't change Broken Arrival shuttle and Security Officer arrival announcements, how it was before. But may be we should allow it - it's an open question. ## Changelog 🆑 add: Many things now handles via AAS: Bounty Cubes, Request Consoles, Brig Cells, Vending Machines and Orion Trails alerts, Weather Reports, Cargo Order Console code: Now anyone can make their own entry for AAS refactor: AAS internals, also cleanup /🆑 |
||
|
Y0SH1M4S73R
|
25eb08420a |
Temporary bodies return players to minds without bodies (#89323)
## About The Pull Request There are a couple of cases where ghost roles that give the temporary body component prevent you from returning to the round when they really shouldn't. The particular cases are: - You entered a temporary body while you had no body, but could be recovered via means such as podcloning - You enter a temporary body, and while in that body, your original body is permanently removed while your mind could be recovered via means such as podcloning - Basketball This PR addresses those cases by allowing the temporary body component to operate with a null `old_body`, and allowing the temporary body component to be given to ghosts whose minds don't have bodies. ## Why It's Good For The Game Erroneous DNRs caused by code oversights are probably very undesirable to the playerbase. ## Changelog 🆑 fix: Joining a minigame or taking certain ghost roles, while you have a mind without a body, will no longer DNR you, just in case you can be resurrected by some means. fix: If your old body is permanently destroyed while you are playing a minigame or as certain ghost roles, you will still return to your character's original mind, just in case you can be resurrected by some means. fix: The basketball minigame now gives its players and referee temporary bodies. /🆑 |
||
|
grungussuss
|
58501dce77 |
Reorganizes the sound folder (#86726)
## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑 |
||
|
Timberpoes
|
6808a082eb |
Assorted changes to job assignment code and logging. Runtime free, guaranteed or your money back. Price: $£0. (#85947)
## About The Previous Pull Request #85308 reverted by #85929  ~~Causes the round to not start when a player isn't eligible for any jobs at a specific priority level due to runtimes trying to `pick()` from an empty list aborting the entire job assignment stack.~~ (Fixed???? by https://github.com/tgstation/tgstation/pull/85947/commits/e0e9f2f430079d4ab7097abe12e75f934131a638) Maybe we should test merge this for a mo just to make sure no more cheeky runtimes pop up before merging. ## About The Pull Request This PR does a couple of minor things: Makes the job debug logging a bit easier to follow. Minorly brings some SSjob code up to code standards, converting proc names to snake_case and doing some otherm is cleanup. Refactored some stuff into different procs, updated some comments. And some major things: Changes the job assignment logic. Old behaviour > Assign dynamic priority roles > Force one Head of Staff (if possible) > Assign all AIs > Assign overflow roles (bugged in 2 ways) > Shuffle the available jobs list once, at the start of the random job assignment loop > Pick and assign random jobs for random players from High prefs down, with a priority on Head of Staff roles > Handle everyone that couldn't be assigned a random job New behaviour > Assign dynamic priority roles > Assign all Head of Staff roles to players with High prefs > If no Head of Staff was made in the above way, force one Head of Staff (if possible) > Assign all AIs > Assign overflow roles (fixed) > Prioritise and fill unfilled head roles at each job priority pref level, from High prefs down. > Build a list of all jobs that each unassigned player could be eligible for at the above pref level. > Pick a job from that list at random and assign it to the player. > Handle everyone that couldn't be assigned a random job. In reality there should be little impact on overall job assignment, the code changes read more as semantics. For example, the priority check for filling Head slots will have the same candidate pool in both old and new versions, but in the new version we're more clearly saying that Heads are important and we want to prioritise filling them for the sake of round progression even though the outcome in new and old is the same. A key change will lead to an increase in assistants - Overflow fixes. Currently the code block to do early assignments to the Overflow role doesn't work - or works but not as you'd expect. The idea was is that because enabling the Overflow role in the prefs menu is an On/Off toggle that sets the job to High priority when enabled and prevents any other High priority pref, players that have the Overflow role enabled will **always** get it. It's their highest priority job with infinite slots. So we do a pass right at the start to give everyone with the Overflow role enabled that role and save us wasting time later on in random job code giving them that same role but with more work. The problem is the code for this only assigns the Overflow role to people with it set to Low priority in their prefs, resulting in log readouts like: ``` [2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1 [2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority [2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0 ``` Where nobody gets pre-assigned the overflow role because their prefs are all set to the High priority from being toggled... Except wait a second, some people have it at Medium priority when it should just be a No Role/High Priority Role toggle? And herein we meet a problem. My hypothesis is that traits and stuff that change the overflow have allowed players to set the "ordinary" overflow role of Assistant to Medium and/or Low priority. This still shows as enabled in the prefs menu, but leads to an outcome where a player with assistant enabled is assigned Cook instead. ``` [2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1 [2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority ... [2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority ... [2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0 ``` So players with the Overflow job pref set to Low (an unexpected state, should be disabled or High) would be guaranteed to get that role if none of the higher priority Head of Staff/AI/Dynamic roles took over via the bugged "force overflow for people with the pref enabled" proc. Players with the Overflow job pref set to High would be guaranteed to get that role if none of the higher priority Head of Staff/AI/Dynamic roles took over via the random job assignment code giving them their Highest priority role thanks to the infinite job slots of the Overflow. And players with the Overflow job pref set to Medium (an unexpected state, should be disabled or High) would get Assistant if the shuffle step of the available jobs list put Assisstant before any of the other jobs they had prefs enabled for at Medium that weren't already filled, otherwise they'd get another random job. This code is now changed to ignore the priority the player has set when looking for people to fill the overflow role. As long as it **is** enabled, the player will get it unless they're forced into a dynamic ruleset role (AI when malf rolls) or a Head of Staff role due to their other prefs (they have RD set to med or low, and no other player has a Head of Staff at high so they get randomly picked and miss the overflow role). This will increase the number of assistants in shifts where their pref state has Assisstant in the bugged Medium priority, but doesn't change it for bugged Low and not-bugged High/On priority. On the other side of the coin, we have how the random jobs are picked. They're kinda not random, and I noticed this reading the logs then reading the code. The list of available jobs to pick from is randomly shuffled - but only **once**. All players pull from a list of jobs in the same order. So you end up with a log block like this: ``` [2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist [2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0 [2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2 [2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist [2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0 [2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2 [2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2 [2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2 [2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook [2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0 [2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1 [2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz [2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1 ``` The list is shuffled into an order of something like `list("Scientist", "Botanist", "Cook", "Sec Officer", ...)` then iterated over for each player. So every random job selection goes: > "Does Player1 have Scientist enabled and at the right priority? No? Okay, Botanist? Yes? You get botanist." > "Does Player2 have Scientist enabled and at the right priority? No? Okay, Botanist? Yes? You get botanist." > "Does Player3 have Scientist enabled and at the right priority? No? Okay, Botanist has no slots left so we'll remove it from the list. Okay, Cook? Yes? You get cook." > "Does Player4 have Scientist enabled and at the right priority? No? Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec Officer? ..." This can lead to stacked individual departments if it gets randomly rolled to the start of the list in the shuffle, and completely empty departments if they end up at the end. On high pop shifts this is probably less of an issue. Player prefs add noise to this and as departments at the front fill up, those at the back pick up some of the lower pref players. But have you ever had a shift where there's just like... No fucking sec even though there's tons of players? The logging (before I made changes in this PR) was a bit ass, but my hypothesis there is that sec officer was shuffled right at the end of the random job list, so every other department was filled up before sec officers were picked. To mitigate this, I made the list shuffle every single time the game picks a random available job for the player. This should lead to a more balanced selection of available jobs by avoiding situations where the code is biased towards packing some departments by accident. ## Why It's Good For The Game Overflow fixes mean people who go to their prefs and see the Overflow Role is On will all have the same experience - They will be the Overflow role. More random random job selection should prevent individual departments having a jobs be stacked when it would have otherwise been possible for a more balanced selection but the code unintentially biased random departments to be overstaffed and understaffed each shift. ## Changelog 🆑 fix: Having the Overflow Role set to On will properly ensure you get that role at a High priority as intended by the game code. fix: Job selection is now a little bit more random. Fixes an unintentional bias in random job assignment that could lead to feast-or-famine for roles where everyone is assigned one job and nobody is assigned another job. /🆑 |
||
|
Jeremiah
|
008876823c |
Adds two new BR maps, basic mobs, BR tweaks & fixes (#85292)
## About The Pull Request Title. Adds two new maps: - Grasslands Hunt (peaceful) - Meta Central (easy) These maps add a new basic revolutionary mob and significantly upgrades the ai of basic deer. This fixes an issue where modular maps were not correctly spawning mobs or adding them to the "mutable candidates" for antagonists. There's also some balance changes to bitrunning vendor prices, which are generally now lower. This change is unrelated to the PR as a whole so I'm okay with removing it if there's concern ### photos <details> <summary>expand</summary>   </details> ### todo - [x] Fix the revolutionary death anim - [x] Make deer run when injured ## Why It's Good For The Game New maps as a general positive for bitrunning Bug fixes Makes vendor choices for bitrunning-exclusive items generally less of a chore to get ## Changelog jlsnow301, MMMiracles, KikoWen0, Ben10Omintrix 🆑 add: Added two new bitrunning maps: Grasslands Hunt and Meta Central. add: Deer are now more complex animals, granting them enhanced ability to run amok and chew your favorite plants. balance: Reduced the cost of most BR vendor items. fix: Fixes an issue where modular virtual domains spawned less mobs than intended. fix: These modular spawns are now valid mutation targets to become an antagonist. /🆑 --------- Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> |
||
|
Kyle Spier-Swenson
|
4d1639b04c |
Revert "Assorted changes to job assignment code and logging." (#85929)
Reverts tgstation/tgstation#85308  |
||
|
Timberpoes
|
1eef540054 |
Assorted changes to job assignment code and logging. (#85308)
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
|
||
|
Jeremiah
|
5dc1d36ee4 |
Bitrunning: Combat domain [READY] (#84196)
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. --> <!-- You can view Contributing.MD for a detailed description of the pull request process. --> ## About The Pull Request Finally dusts off this project to make a deathmatch style bitrunning map. Don't be too intimidated by the file diff, lots of code organization + resized a large map. Changes: 1. Reuses the gateway beach map as a combat zone (99% of the file diff) (maptainers: i just added spawners and areas) 2. Alters how bitrunning handles spawning: Custom spawns are now available, which can be anything Misc organization: - Splits netpod.dm into separate files. - Fixes some wording in vdom map documentation. - Organizes vdom variables a bit. - Adds a permanent hololadder spawn. How bitrunning deathmatch works: - Temporary spawners are offered to both ghosts and bitrunners. - Runners spawn in like usual. Ghost can use the spawner menu. - Ghosts work to prevent avatars from collecting side objectives or try to cause mass brain damage. - The domain completes after a number of deaths accrue. Any faction. Blood for the blood god, etc. - This map can be played solo. ANY deaths. <!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! --> ## Why It's Good For The Game I've been toying with the idea of a deathmatch style map for some time. I liked syndicate assault, the spawners were intentionally left there, and the possibility of player-controlled players made the experience more tense and challenging. This PR leans into this idea: The virtual world is dangerous. Players get a chance to compete on both sides here. It offers a lot of variety to bitrunning other than "run for box". It's also very lucrative if ghosts join in. <!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. --> ## Changelog <!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. --> 🆑 add: Added a bitrunning deathmatch map: Island Brawl. Both ghosts and runners get many more spawns than normal. fix: Lowered the static vision time in domain load in. /🆑 <!-- Both 🆑's are required for the changelog to work! You can put your name to the right of the first 🆑 if you want to overwrite your GitHub username as author ingame. --> <!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. --> |
||
|
Jeremiah
|
1116f150eb |
Bitrunning: Tweaks, QoL and removals (#84125)
## About The Pull Request See changelog for shortlist 1. **Threat changes.** I was a bit unsatisfied with the rate of antag spawns. These have been increased considerably. The clamped probability has been increased from 1-10 to 5-15. The probability increases from 5 to 15 as domains are completed. Generally, in a standard round, the chance of spawning at least one antag should be around ~50% at 7 domains completed. Emagging a server doubles this rate. 2. **Map changes.** Starfront saloon was a cool idea on paper: A totally modular map. However, it looked very uninspired and was so much of a chore on the map loading system that it prompted players to admin help how long it took, thinking it was broken. I've removed the map. I have others I want to implement that don't look so bad. 3. **QoL changes**. Ghost observer experience is improved. Previously, you could click netpods to view their avatar, and now you can click the hololadder to return. I've included examine text to show this. The server's examine text will now also give you clues that it's emagged (ghost only). The examine text on hololadders has also been improved. 4. **Bitrunning antags.** These were designed as temporary, but they were everything but. Spawning as one would prevent your revival, which just isn't a good tradeoff for something that's going to get deleted in a minute. Now, this system uses temp bodies just like CTF, so you can return once you're dead. (exception: coming station side) 5. **Maps**: Syndicate assault is still one of my favorites, but there's cheesy exploits like instantly breaking the display case to lock down the ship, turning on turrets which are EXTRA lethal, etc. I've added some pistols to the closets and removed some of these exploits. 6. **Cooldown**: Yes, no one seems to upgrade these ever, and it proved a poor technique to encourage bitrunners to leave their rooms. I had other plans to encourage this, not included here, so I think lowering the cooldown time is beneficial. 3min -> 2min > [!NOTE] > File diff: removed a map ## Why It's Good For The Game Closes #83787 General updates and QoL for bitrunning to keep it fresh. I was quite disappointed with the scaling of threat, and most players haven't even seen bitrunning antags except when I admin spawn them. These numbers aren't hard set in my mind, and could be adjusted. I generally want bitrunning easier to access and more "temporary" which is in keeping with its design doc. ## Changelog 🆑 fix: Bitrunning made more illegal: Increased the rate at which antags spawn. fix: "Temporary" bitrunning antagonists and spawners are made actually temporary. You will return to your original body after death, just like CTF. add: Added more examine text for ghosts to bitrunning equipment. balance: Server cooldown reduced by 1 minute at base level. add: As an observer, you can now switch views between station and virtual domain by clicking the hololadder and netpod respectively. del: Removed the starfront saloon BR map. fix: Syndicate assault map: Added pistols, reduced exploits. /🆑 |
||
|
Jeremiah
|
fce52097ee |
Fixes some bitrunning related issues [no gbp] (#83184)
## About The Pull Request Properly allows bitrunning antagonists to come station side A few issues were resolved: - Event title was too lengthy, it's been renamed - IDs were not being named properly for cyber police. Cybertac would appear as "unknown" - Runtime at examining cyber police ID because it had an erroneous account - Teleporting station side would delete your organs and leave you a broken husk of a mob ## Why It's Good For The Game Fixes #83181 ## Changelog 🆑 fix: Bitrunning antagonists no longer gib on teleport fix: Cyber tac now have a visible name / ID fix: Renamed the bitrunning malfunction event to just "Malfunction: x" /🆑 --------- Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com> |
||
|
Rhials
|
6aa0dee37f |
Virtual Domains now have certain areas protected from ghost role interference (#82960)
## About The Pull Request This touches up on the bitrunning ghost roles that come with some maps, namely Corsair Cove and Syndicate Assault. The gist of it is: Ghost role spawners and Digital Anomalies (the random event boss mobs) are now restricted from entering the VDOM safehouse, and other areas where critical equipment is stored. Here's an example from Syndicate Assault -- The X-ed out area is considered "out of bounds" for digital anomalies/ghost roles:  Additionally, this also fixes the matter of pirate ghost role spawns creating their own antag datum/pirate team, which would carry into the roundend report. Since these are no longer legitimate pirate spawners and are now specifically designed spawners for virtual domains. Naturally, emagging the server jailbreaks all of these restrictions and notifies any virtual entities. The new subtype of spawners should also be scalable enough that new VDOMs should be able to implement new ghost role spawners with ease. ## Why It's Good For The Game It's one thing to have sentient mobs to fight, which can shake up the otherwise somewhat static nature of bitrunning maps, but when players are tossing equipment, spawncamping, or otherwise making it impossible for the runners to fight them it ends up being unfun for everyone involved. You can't get into a good fight with a bitrunner avatar if their only recourse is to wipe the map and everything (YOU) in it. This ensures a level of fairness between the (typically vindictive) ghost roles of a VDOM and the players. Also, pirate spawns don't make a new pirate team/datum. That's one of the fixes I was aiming for with this. ## Changelog 🆑 Rhials balance: Virtual domain ghost roles can no longer enter the safehouse/"equipment" areas of a domain. fix: Pirate virtual domain ghost roles will no longer make a pirate team antag datum. /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> |
||
|
13spacemen
|
357799c8a5 |
Removes Orbit Polling Component, SSpolling improvement (#81748)
When I made SSpolling, jlsnow gave me his blessing to delete the orbit polling component [where you orbit something for 20 seconds before it chooses a ghost from the orbiters] It's only used in a few places like soulstones replacing jobbanned/inactive players, etc. Also upgraded SSpolling; you can now place a little icon on the sides in the chat message, chat message looks a lot nicer, the alert pic and the jump target don't have to be the same anymore, and I made it be able to pre-pick candidates since 90% of the use cases would just want 1 candidate Also prints to chat who the chosen one was Also made slime intelligence potions ask the user for a reason, which will be displayed in the alert poll |
||
|
Y0SH1M4S73R
|
640bb71ec8 |
Bitrunning glitches that don't escape their domain don't show up in the roundend report (#79910)
## About The Pull Request Exactly what the title says. I was planning to fully refactor glitches to function more like lavaland elites, which they operate more similarly to, but I was lazy and also discovered the `show_in_roundend` var on `/datum/antagonist` - setting that to `FALSE` does the thing I cared most about. Making them still appear in the roundend report if they escape was Fikou's idea. ## Why It's Good For The Game Does the roundend report really need to list a hostile that will cease to exist soon after killing the only characters it can interact with? ## Changelog 🆑 qol: Bitrunning glitches will not show up in the roundend report unless they escape the virtual domain. /🆑 |
||
|
Jeremiah
|
ba5ae73dac |
Adds more bitrunning antagonists + fixes (READY) (#79522)
## About The Pull Request Reopened #78997 Larger patch for bitrunning that addresses a few issues. - Two new antagonists: cyber tac and netguardian - Quantum server emag opportunity - Modular mob packs: Like random spawners, but for groups - Antag spawning fixed: vdom antags now have up to a 10% chance to spawn based on domains loaded - Virtual domains are no longer all fullbright by default, only the outdoorsy ones - Actually deletes legion map file, since it was removed in #79424 <details> <summary>images</summary> The netguardian prime   The glitch effect - this mob is being mutated  Cyber tac (t2 antagonist)  </details> ## Why It's Good For The Game - Bitrunning antagonists are so incredibly rare that it's underwhelming to play as one for the solid second they offer if you even get the role - Bitrunners had basically no traitor route to follow, they became assistants with black outfits Fixes #79465 <details> <summary>More info</summary> Bitrunners don't have any type of traitor options. If they're made into traitors, there's nothing bitrunner related they can do, and their access is particularly bad so it's like they're a worse assistant. I've coupled this with the bitrunning antagonist system, which is now fixed.\. Bitrunners can now attempt to coax these entities to come onto the station, however they are not given any form of allegiance for doing so (and are quite counterable). Previously, vdom antagonists relied on so many factors to spawn that it basically wouldn't happen. Now, it runs on the server each time there is a map loaded, with increasing probability as the round progresses. This builds up the list of spawnable antagonists, of which two are new, including an entirely new giant mech megafauna. This is the first "megafauna-esque" basic mob in the game. Its AI is bad, it's really only meant to be player controlled, but this does mean an admin can spawn them. Being mech, they are very counterable with ion rifles and the like. Several refactors, rewrites, and overall bug fixes are included in this PR. Lastly, I added a framework for making bitrunner maps more random, the modular mob spawning system, which works in conjunction with random crate locations. </details> ## Changelog jlsnow301, infraredbaron 🆑 add: Bitrunning Patch 1 features a host of changes! add: Added randomized mobs to virtual domains, which will be indicated with a unique icon. add: New emag interaction with the quantum server. Antags will spawn more frequently, and they can hack themselves onto the station. You have been warned. add: Both living and dead players can now see which mob is going to spawn an antagonist in the vdom. add: Two new vdom antagonists: Cyber Tac and the NetGuardian. These unlock at specific thresholds. balance: You can no longer stack copies of the same ability with bitrunning disks. balance: Some of the disk items have been replaced with stronger versions. fix: You can no longer spy on crew using the advanced camera console on syndicate assault. fix: Fixed the spawning mechanism of virtual domain antagonists. You should now have a chance of playing as one. This chance increases as more domains are completed. fix: Vdom antagonists shouldn't spawn at the end of the run any longer. fix: The preference for vdom antagonists has been changed to factor in the new types. Check your preferences! fix: The quantum server will now show its balloon alerts to all observers. fix: Random domains should be fully random again. /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
Jeremiah
|
550ec9b1d9 |
Cleans up signal use in bitrunning [NO GBP] (#79426)
## About The Pull Request Atomized #78997 Broke up duplicate signal usage - though they do the same thing, this is convention & it makes it easier to debug Removed custom alert subtypes in favor of just setting values directly Removed some unnecessary vars like the console ref from the server Since I'm just copying this over, it has added exam text for net pods, which fixes an issue reported to me in Discord ## Why It's Good For The Game Code improvement ## Changelog 🆑 add: Added some clarity to the range of netpods (4 tiles) in their exam text. /🆑 |