mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-10 15:45:05 +01:00
docker-container
32 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Alexis
|
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> |
||
|
theOOZ
|
5464a0225b |
[NO GBP] Fixes queue'ing of roundstart ruleset (#94899)
## About The Pull Request https://github.com/tgstation/tgstation/pull/94843 broke the queue'ing of roundstart rulesets by handing the proc which processes this instances while it expected typepaths. ## Why It's Good For The Game Sorry! |
||
|
theOOZ
|
fdd96d7d23 |
queued_rulesets list uses proc to unqueue (#94843)
## About The Pull Request Makes unqueue'ing rulesets use a `unqueue_ruleset()` proc, just like `queue_ruleset()` Takes singletons instead of type paths. ## Why It's Good For The Game Consistently uses these procs when adding or removing rulesets from the queue. There was already a proc for adding, so having one for removing suits. This PR removes any case of directly editing the `queued_rulesets` list. This should make the code cleaner, among other things. ## Changelog 🆑 code: Adding or removing rulesets from the queue list is done by procs instead of directly editing the list. /🆑 |
||
|
Bloop
|
a7b1f8f77a |
Adds more detailed logging data to dynamic (#93060)
## About The Pull Request Tin. It annoyed me how useless the logging was for forcing a dynamic ruleset. "but preparation failed!" (ok, but why?) So this just adds more detailed explanations for why the preparation failed. <img width="640" height="47" alt="image" src="https://github.com/user-attachments/assets/cc1f9e94-293e-422d-bd16-0ae5f28fd1eb" /> ## Why It's Good For The Game Better logging and clearer admin messages. ## Changelog 🆑 qol: improves admin logging of forced dynamic events. /🆑 |
||
|
MrMelbert
|
5cddf64930 |
Fixes some cases of dynamic reading defined values over config values (#92126)
## About The Pull Request Fixes #92125 Very simple, when working without an instantiated datum we would read from the config manually, but some places neglected to do that. So I added a macro to help in the future. ## Changelog 🆑 Melbert fix: Fixes some places where dynamic configs were not being read correctly /🆑 |
||
|
MrMelbert
|
421204a281 |
Fix high impact rulesets being disregarded for roundstart selection (#91883)
## About The Pull Request Fixes #91882 `RULESET_HIGH_IMPACT` is checked in `get_weight`, but by the time `get_weight` is called for roundstart rulesets, no rulesets are selected. So we need to add logic in `pick_roundstart_rulesets` Not super big fan of this fix - I think it'd be a lot cleaner if all the rulesets recalculated their weights, but this is a needed temp fix. ## Changelog 🆑 Melbert fix: Multiple high impact rulesets will no longer roll simultaneously unless dynamic picks "high chaos" /🆑 |
||
|
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 /🆑 |
||
|
TiviPlus
|
88c2213f1e |
Force UTC±0 for time2text logging and IC times (#90347)
## About The Pull Request This won't actually do anything on live, since those are all set to UTC±0 currently Pins logging and IC uses of time2text to UTC±0 instead of using the system timezone (byond default) Timezones not being set to utc0 caused issues before (and is again) All timezones are now passed explicitly to make it more likely it's cargo culted properly at least Deletes worldtime2text cus it was gameTimestamp default args ## Why It's Good For The Game Server timezone changes probably shouldn't affect logging, round times, file hashes, IC time, when you caught fish, etc ## Changelog 🆑 refactor: Logging and IC timestamps will now always use UTC±0 and not be affected by server system timezone changes fix: Station and round times will not longer be incorrect if the system timezone is not UTC±0 /🆑 --------- Co-authored-by: TiviPlus <572233640+TiviPlus@users.noreply.com> |
||
|
Kashargul
|
dfa7f2bb62 |
some more 516 compat fixes (#89766)
Ports the helpers from https://github.com/BeeStation/BeeStation-Hornet/pull/12240 This should fix some more of the 516 issues that I've seen while giving a quick check through the code The remaining browse should work now. Also fixing another sass warning while being on it. ## About The Pull Request ## Why It's Good For The Game ## Changelog 🆑 fix: tgui say 516 will no longer change channels when the button is used to drag it fix: tgui say 516 will no longer leak radio messages into the wrong channel fix: runechat flickering when faded up messages fade out /🆑 |
||
|
Vekter
|
83e179ee21 |
Drastically simplifies the roundstart report (#89150)
## About The Pull Request The roundstart report has been changed in the following ways: - There are now only four alert levels: Yellow Star (0-65 Threat), Red Star (66-79 Threat), Black Orbit (80-99 Threat), and Midnight Sun (100 Threat). - The roundstart report is now 100% accurate. - Extended rounds will still show the "No credible threat" alerts, but this should only happen if an admin sets the round to Extended. ## Why It's Good For The Game The current roundstart report system is too granular as it is now, which leads to situations where players will suicide 5-10 minutes into the round due to the threat level being too low. Making it potentially random was meaningless, because players would just act on whatever it said without actually giving the round a chance to do anything. I also feel like this brings back a fair bit of paranoia to the round, as low threat levels would often just result in people expecting nothing to happen. That can be fun when the report is lying, but it doesn't happen often enough to really make it worth keeping. We tested this a few months ago and the results seemed positive. We also had a lot of discussion about the matter and, while I'm open to changing implementation in some ways, I'm pretty set on this being a beneficial change, at least in the short term until we can make Dynamic more interesting. I kept the high threat level stuff because it's fun to know some crazy shit might happen. I might bring back the random threat level thing to differentiate between those but I don't really care tbh; the targeted behavior here is people bailing on low threat rounds, not people knowing it's a high threat round. ## Changelog 🆑 Vekter balance: The roundstart report will now display a more broad, less specific message about threat levels when between 0 and 80 threat. /🆑 |
||
|
Aylong
|
1795c18aea |
Fix a bunch of html UI's for 516 (#88917)
## About The Pull Request Moved broken on 516 UI's to browser datum They now work and have a dark theme Most of them are admin ones (All except 1) I tried to check all the raw HTML UI's by typing `<< browse(` into the VSC search and going through each element, but I might have missed something. What worked as it was, I didn't touch, except for the Dynamic control UI's ## Why It's Good For The Game Admin can do their things on 516 Coders/Mappers can debug some stuff on 516  ## Changelog 🆑 fix: Admin/Debug UI's (Especially the Game Panel) now work properly on Byond 516, instead of showing raw HTML /🆑 |
||
|
John Willard
|
2e4d70afe5 |
Updates href uses for 516 (#88699)
## About The Pull Request Was just scrolling through the Paradise github since they seem to have more work done for 516 to see if there's anything I can port over, found this and thought why not. Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105 Specifically, updaing all hrefs to use the internal ``byond://``, and adding it to grep. ## Why It's Good For The Game More work towards 516. ## Changelog Nothing player-facing. |
||
|
MrMelbert
|
75696ab873 |
Fixes random stuff spilling into ooc tab (#88221)
## About The Pull Request `boldannounce` is NOT for use ICly it's only for OOC stuff. `bolddanger` is identical it just doesn't carry the same baggage ## Changelog 🆑 Melbert fix: Stuff like the SM exploding will no longer output to your OOC tab /🆑 |
||
|
Penelope Haze
|
b67a0901f2 |
Fix issues discovered via TypeMaker (#87596)
## About The Pull Request Fixes issues with var typing and proc arguments, discovered using OpenDream's WIP TypeMaker feature (using improvements I haven't PR'd upstream yet). ## Why It's Good For The Game Codebase maintenance. |
||
|
Jerry
|
314217b5cf |
Separate forced injection between latejoin and midround (#87557)
## About The Pull Request Fixes an issue mentioned in https://github.com/tgstation/tgstation/issues/72526, where pressing "Now!" in the game panel for injecting a latejoin, caused midround one to occur as well. This was because the same boolean was used for forcing both, which caused both to happen. * Closes https://github.com/tgstation/tgstation/issues/72526 ## Why It's Good For The Game Improves admin tools by fixing a bug. ## Changelog 🆑 admin: doing a latejoin injection no longer causes a midround one as well /🆑 |
||
|
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. /🆑 |
||
|
klorpa
|
e1bf793264 |
Spelling and Grammar Fixes (#86022)
## About The Pull Request Fixes several errors to spelling, grammar, and punctuation. ## Why It's Good For The Game ## Changelog 🆑 spellcheck: fixed a few typos /🆑 |
||
|
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>
|
||
|
larentoun
|
e43a90f912 |
Dynamic - fixes a comment for proc/lorentz_to_amount() (#85291)
## About The Pull Request I'm not going crazy, right? This comment must be wrong unless my math is wrong...  ## Why It's Good For The Game Comments don't lie so people don't get their hairs out if their values don't match with comments |
||
|
grungussuss
|
8db012a90f |
White dwarf meta knowledge check fix (#83633)
## About The Pull Request There is two values for round threat, the shown value and the real value, sometimes the shown threat can be 0, while the real threat is higher, which in turn does not trigger the green alert on getting the classified report and does not make a special announcement, "Thanks to the tireless efforts of our security and intelligence divisions, there are currently no credible threats to [station_name()]. All station construction projects have been authorized. Have a secure shift!", nor does it enable all station construction projects, so we should disable being able to fake white dwarf on classified report. ## Why It's Good For The Game Knowing when your classified report is fake is meta knowledge and shouldn't be a thing. ## Changelog 🆑 grungussuss fix: fixed getting a fake white dwarf report when the shift isn't extended mode, which lead to meta knowledge being used. /🆑 |
||
|
Rhials
|
862a029cfa |
Adds a few more pulsar star station trait reports (#83591)
## About The Pull Request This adds some more station-trait dependent Pulsar Star reports, much like the "Clown Planet" report triggered by the bananium shipments trait. For those of you not up to speed - When pulsar star (no meaningful threat report is provided) rolls, and a relevant station trait is active, the generic report is replaced with one pertaining to that trait. It's better to just check the code changes to get a full picture, but I'll give some summaries on what the individual reports are here: **Assistant Gimmick Outfits** - "Grey Sky", and a warning to monitor the recently emboldened assistants on-station. **Intern** - The intern has forgotten to actually include the report in his message. What a goof! **Ion Stormfront** - Oh dear, the electromagnetic interference is messing with the report broadcast.  **Endless Snowstorm** - Ice Giant, Too much snow, we can't give an actual report. Stay safe! **Wise Cow Invasion** - Cow Planet. [We're gonna go fast and we're gonna go far with a steady driving bass and a rhythm guitar.](https://www.youtube.com/watch?v=BPqPYszbSFI) ## Why It's Good For The Game Seeing the goofy clown planet message always made me think "dang, this feels like underutilized material" and can give command some prompting on what to tell the crew beyond "yeah we don't know what threat level it is". Maybe it'll prompt someone to do a gimmick based on the report? Who knows! It's just an added dash of flavor at the end of the day. Admittedly, some are a bit silly, but also rare (requiring both a specific station trait and the 8% pulsar star chance) so I think its fine. ## Changelog 🆑 Rhials add: Adds some more station-trait dependent pulsar star reports. Keep an eye on that roundstart command report! /🆑 |
||
|
Time-Green
|
6348dc9a7c |
Fixes admins not being able to force some rulesets with Stationwide Background Checks station trait (#83657)
Fixes #83631 Instead of not initializing the ruleset we just forbid it 🆑 fix: admins can force rulesets on background checks station trait (fucking lame) /🆑 |
||
|
Time-Green
|
328d001047 |
STATION TRAIT GAMEMODE: Station-Wide Background Checks (#83307)
## About The Pull Request Adds a new station trait: Station-Wide Background Checks! It does two things: 1. Blocks most crew-side antagonists. No traitors, changelings, spies, heretics, etc. You won't be able to fully trust your crew though, as Space changelings, Paradox Clones, Obsesseds and Blob Infected are excempted crew-antags since a background check doesn't really help here. Other antagonists still spawn: pirates, revenants, blobs, aliens, nukies, wizards etc. Expect a LOT more of these, as Dynamic is gonna put threat somewhere... 2. Reduces dynamics threat slightly, configurable per server, but defaults to 15. It is essentially the first "dynamic gamemode". ## Why It's Good For The Game Blocking crew antagonists changes the shifts dynamic, similair to old warops. Security can "trust" crew to not be antagonists, and instead can focus more on petty crimes and hunting down external threats. Due to the increased chance of external threats and reduced chance of internal threats, the crew can focus its defenses outwards. Don't worry about your coworker killing you (intentionally/probably), but do worry a lot more about the pirates trying to break through your hull, or alien nests growing in virology. I've also reduced total threat count slightly because the idea of 90 threat being dumped into ghost spawns kinda terrifies me and I do want people to be able to let their guard down a slight bit. It can be reduced/disabled for servers that already tend to lower threats. I think it's a lot of fun to change the paranoia dynamic, and a fun deviation from a normal round of spaceman13. ## Changelog 🆑 add: Station-Wide Background Checks (station trait, rare): Disables crew antagonists, but get a lot more non-crew antagonists /🆑 I want to do more like these (this was just an example I threw into discord to annoy @Mothblocks but I realized I kinda liked), and this is a good opportunity to gather community feedback and see how it plays! --------- Co-authored-by: carlarctg <53100513+carlarctg@users.noreply.github.com> |
||
|
Mothblocks
|
bc4e7d3b4e | Remove data systems in favor of global datums (#82943) | ||
|
Jeremiah
|
c1a775efe1 |
Implements data systems (#82816)
## About The Pull Request Subsystems currently come in two different flavors: 1. Systems that process at intervals with the master controller 2. Global data containers that do not fire And I think they should be split up... This moves 4 non firing, non init subsytems -> datasystem ## Why It's Good For The Game Clarity in code |
||
|
Horatio22
|
29f645ca63 |
Rephrases advisory level descriptions (#82585)
## About The Pull Request
Some of the station alert descriptions contained grammatical errors.
This PR corrects some word choice, punctuation, and grammar mistakes as
well as editing some sections for clarity. For example, Pulsar Star's
current warning
> "Your sector's advisory level is Pulsar Star. A large unknown
electromagnetic field has stormed through nearby surveillance equipment.
No surveillance data has been able to be obtained showing no credible
threats to Nanotrasen assets within the Spinward Sector. The Department
advises maintaining high alert against potential threats, regardless of
a lack of information."
has been changed to
> "Your sector's advisory level is Pulsar Star. A large, unknown
electromagnetic field has stormed through nearby surveillance equipment
causing major data loss. Partial data was recovered and showed no
credible threats to Nanotrasen assets within the Spinward Sector;
however, the Department of Intelligence advises maintaining high alert
against potential threats due to the lack of complete data."
## Why It's Good For The Game
Readability is important
## Changelog
🆑
spellcheck: grammar fixes in the roundstart advisory warnings
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
|
||
|
MrMelbert
|
5f2f9e67ad |
Add compile option for compiling in MAP_TEST mode, which disables common annoyances when testing new maps (#81697)
## About The Pull Request Adds `MAP_TEST` compile flag. This compile flag blocks common things which make it difficult to test a map. Things this applies to: - Rats no longer spawn. - Rat spawning will (obviously) break up the powernet, which is INCREDIBLY annoying when trying to test if all the rooms of the station are wired correctly (or testing which rooms lose power first, etc) - Light tubes no longer break on initialize. - Random light breakages can easily cause mappers to accidentally over light a room. - Roundstart command report is not printed. - Might be a personal preference, but it's kinda annoying to hear the alert over and over again. - Random events do not trigger. - Some events such as gravity generator outage can trigger with 0 population. - Random camera breakage event can cause over-placement of cameras. - Other stuff tends to just get in the way. - Station traits do not trigger. - Probably the biggest annoyance. Many traits modify the map in some way which disrupts testing. - Roundstart landmarks don't self deletes. - Allows mappers to use sdql to find them. - Mapping verbs start enabled. Obviously more things can be added if they come up. |
||
|
Zephyr
|
c76df7f37a |
Station Goals are now handled by SSstation instead of a global list (#81177)
## About The Pull Request You can now get station goals in a slightly better way over using a `locate() in` call on a global list. The Meteor Satellite goal no longer stores a giant list of ALL OBJECTS in view. And now correctly only counts turfs. ## Changelog 🆑 fix: Meteor Satellites no longer erroneously count every piece of paper as a protected turf. fix: As a result the station goal is slightly more difficult /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
lessthanthree
|
ce3d863d32 |
Combine roundstart intercept and security level announcements (#80475)
## About The Pull Request At roundstart when the intercept report is sent, two announcements are created at the same time. It's loud and overlaps. This combines them into a single announcement. Before:  After:  ## Why It's Good For The Game Two Centcom or any other announcements playing at the same time (especially with two different sound files) can be annoying and the sounds distort each other. ## Changelog 🆑 LT3 qol: Roundstart intercept report and security level announcements are combined into a single announcement /🆑 |
||
|
Fikou
|
a3fa541e2e |
Bridge Assistant Station Trait (#80279)
## About The Pull Request adds a station trait which adds a new role, the bridge assistant he is designed to help commandeer the bridge and help out other heads when needed. he is armed with the mini energy gun (the one heads used to have on kilostation), a flash, a toolbelt (with an inducer), some cool shades and a swanky scarf. as he is a nerd he is weak and unable to twohand weapons, preventing him from wielding the fire axe. currently he does not have a mindshield but he cannot roll antag he currently has access to the bridge, announcement console, eva, teleporter, gateway, maint, and a weapon permit (somewhat (not really other than for nerds) interestingly this is the first job that isnt assistant that doesnt have access to any lathes, so he doesnt have orm access unlike all the other jobs (except assistant)) the trait also makes a coffee machine spawn on the bridge here is some useful art of your role  and ingame screenshots    ## Why It's Good For The Game Adds upon the station trait job system with a straight forward role that IS just a human (unlike the cargorilla), and is pretty basic with no custom assets or whatever other than hud icons Having the bridge assistant in some rounds seems like a neat way to protect it since it gets fucked up in like half the time, while also not having enough mechanical depth or gameplay as to warrant it as a permanent role ## Changelog 🆑 add: Bridge Assistant job accessible from a station trait. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
Mothblocks
|
714ff3ec54 |
Remove /datum/game_mode, we SSdynamic now [again] (#79965)
I don't remember what was hard about this last time it took me like 20 minutes this time so I'm scared. Removes dynamic simulations, only I have used them and it's a lot more complicated now with this. I plan on making Dynamic simulations a part of moth.fans anyway |