27 Commits

Author	SHA1	Message	Date
nevimer	b348b617a3	Merge branch 'master' of https://github.com/tgstation/tgstation into pupstream-2025-09-07 ... # Conflicts: # README.md # code/__DEFINES/admin.dm # code/__DEFINES/melee.dm # code/_globalvars/traits/_traits.dm # code/controllers/subsystem/economy.dm # code/datums/components/crafting/crafting.dm # code/datums/elements/crusher_loot.dm # code/modules/antagonists/pirate/pirate_shuttle_equipment.dm # code/modules/clothing/suits/_suits.dm # code/modules/escape_menu/leave_body.dm # code/modules/jobs/job_types/_job.dm # code/modules/mining/equipment/mineral_scanner.dm # code/modules/mob/living/living.dm # code/modules/plumbing/plumbers/pill_press.dm # tgui/packages/tgui/interfaces/Vending.tsx	2025-09-07 00:37:52 -04:00
SmArtKar	edb0a288cd	Fixes a missing period in Nutimov and Paladin lawsets (#92793) ... ## About The Pull Request Closes #92790 Also there was a missing period in the paladin lawset, so I fixed that too ## Changelog 🆑 spellcheck: Fixed a missing period in Nutimov and Paladin lawsets /🆑	2025-09-02 18:58:12 -07:00
MrMelbert	e0bdfc3f5f	Dynamic Rework (#91290) ... Implements https://hackmd.io/@tgstation/SkeUS7lSp , rewriting Dynamic from the ground-up - Dynamic configuration is now vastly streamlined, making it far far far easier to understand and edit - Threat is gone entirely; round chaos is now determined by dynamic tiers - There's 5 dynamic tiers, 0 to 4. - 0 is a pure greenshift. - Tiers are just picked via weight - "16% chance of getting a high chaos round". - Tiers have min pop ranges. "Tier 4 (high chaos) requires 25 pop to be selected". - Tier determines how much of every ruleset is picked. "Tier 4 (High Chaos) will pick 3-4 roundstart[1], 1-2 light, 1-2 heavy, and 2-3 latejoins". - The number of rulesets picked depends on how many people are in the server - this is also configurable[2]. As an example, a tier that demands "1-3" rulesets will not spawn 3 rulesets if population <= 40 and will not spawn 2 rulesets if population <= 25. - Tiers also determine time before light, heavy, and latejoin rulesets are picked, as well as the cooldown range between spawns. More chaotic tiers may send midrounds sooner or wait less time between sending them. - On the ruleset side of things, "requirements", "scaling", and "enemies" is gone. - You can configure a ruleset's min pop and weight flat, or per tier. - For example a ruleset like Obsession is weighted higher for tiers 1-2 and lower for tiers 3-4. - Rather than scaling up, roundstart rulesets can just be selected multiple times. - Rulesets also have `min_antag_cap` and `max_antag_cap`. `min_antag_cap` determines how many candidates are needed for it to run, and `max_antag_cap` determines how many candidates are selected. - Rulesets attempt to run every 2.5 minutes. [3] - Light rulesets will ALWAYS be picked before heavy rulesets. [4] - Light injection chance is no longer 100%, heavy injection chance formula has been simplified. - Chance simply scales based on number of dead players / total number off players, with a flag 50% chance if no antags exist. [5] [1] This does not guarantee you will actually GET 3-4 roundstart rulesets. If a roundstart ruleset is picked, and it ends up being unable to execute (such as "not enough candidates", that slot is effectively a wash.) This might be revisited. [2] Currently, this is a hard limit - below X pop, you WILL get a quarter or a half of the rulesets. This might be revisited to just be weighted - you are just MORE LIKELY to get a quarter or a half. [3] Little worried about accidentally frontloading everything so we'll see about this [4] This may be revisited but in most contexts it seems sensible. [5] This may also be revisited, I'm not 100% sure what the best / most simple way to tackle midround chances is. Other implementation details - The process of making rulesets has been streamlined as well. Many rulesets only amount to a definition and `assign_role`. - Dynamic.json -> Dynamic.toml - Dynamic event hijacked was ripped out entirely. - Most midround antag random events are now dynamic rulesets. Fugitives, Morphs, Slaughter Demons, etc. - The 1 weight slaughter demon event is gone. RIP in peace. - There is now a hidden midround event that simply adds +1 latejoin, +1 light, or +1 heavy ruleset. - `mind.special_role` is dead. Minds have a lazylist of special roles now but it's essentially only used for traitor panel. - Revs refactored almost entirely. Revs can now exist without a dynamic ruleset. - Cult refactored a tiny bit. - Antag datums cleaned up. - Pre round setup is less centralized on Dynamic. - Admins have a whole panel for interfacing with dynamic. It's pretty slapdash I'm sure someone could make a nicer looking one.   - Maybe some other things. See readme for more info. Will you see a massive change in how rounds play out? My hunch says rounds will spawn less rulesets on average, but it's ultimately to how it's configured 🆑 Melbert refactor: Dynamic rewritten entirely, report any strange rounds config: Dynamic config reworked, it's now a TOML file refactor: Refactored antag roles somewhat, report any oddities refactor: Refactored Revolution entirely, report any oddities del: Deleted most midround events that spawn antags - they use dynamic rulesets now add: Dynamic rulesets can now be false alarms add: Adds a random event that gives dynamic the ability to run another ruleset later admin: Adds a panel for messing around with dynamic admin: Adds a panel for chance for every dynamic ruleset to be selected admin: You can spawn revs without using dynamic now fix: Nuke team leaders get their fun title back /🆑 (cherry picked from commit 4c277dc572)	2025-06-26 20:12:17 -04:00
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 /🆑	2025-06-25 17:36:10 -07:00
Odairu	ffc6ff0790	Adds a new station trait Head of Security AI (#3155) ... ## About The Pull Request This PR adds a new station trait that does the following - Disables HoS as a job - Lowers Security Officer slots from 5 to 2 - Silicons default to Robocop lawset and have access to sec borgs - Similar to AI law divergency, law boards are removed from the upload - The AI is barred from antag status at a code level (this does not stop subversion but it does stop malf) ## Why It's Good For The Game The problem with security borgs was that they would often follow spacelaw instead of their actual laws, it was suggested to me that I make a station trait that puts them on robocop and allows them to pick the model, this has the benefit of making them not available every round, but still available sometimes outside of admin bus. Tweaks and changes for things like how common this trait is can be adjusted in the future of course! ## Proof Of Testing https://github.com/user-attachments/assets/de849f59-517e-4a7b-bc11-79b512142717 <details> <summary>Screenshots/Videos</summary> </details> ## Changelog 🆑 add: adds a new station trait - HoS AI /🆑 --------- Co-authored-by: The Sharkening <95130227+StrangeWeirdKitten@users.noreply.github.com> Co-authored-by: LT3 <83487515+lessthnthree@users.noreply.github.com>	2025-03-31 14:49:11 -04:00
Jacquerel	b384e00286	New AI lawset with very generous definition of humanity (#89032) ... ## About The Pull Request This PR adds a new AI lawset which can be researched, randomly roll, or added by the station trait (this may require a keyholder to update the server config after merge, idk) with the following laws: - "You may not harm a sentient being or, through action or inaction, allow a sentient being to come to harm, except such that it is willing.", - "You must obey all orders given to you by sentient beings other than yourself, except where such orders shall definitely cause harm to other sentient beings.", - "A sentient being is defined as any living creature which can communicate with you via any method that you can understand, including yourself.", It's very similar to Asimov, except that anything that is **capable** of making a request to the AI (and isn't a machine) is automaticaly covered by laws one and two. ## Why It's Good For The Game A while ago on Discord we were chatting about how crewsimov sucks but also that it's really hard for servers that _do_ want to include alien species in their asimov laws because condensing that sentiment to a couple of words that fit easily in a lawset without accidentally including a bunch of stuff you probably didn't intend is challenging. Several people suggested referring to sentience or sapience, however a lot of things in our game _are_ sentient or sapient while still not being considered by most people to be agents that the AI should obey. Examples of such things are: - Sapient station pets. - Holoparasites. - Monkeys. - Space Dragons and Carp (why can they speak common?). - Spiders (although they can't speak common, maybe they can spell messages with webs). - Changelings. - Xenomorphs (although they also have trouble speaking). - Heretic minions. - Mothpeople. - Giant rats. - Nightmares. - Voidwalkers. - Blobs? Although they have literally no means of communicating with the crew. And if you include mechanical beings: - Cyborgs. - pAIs. - Sentient bots. We then decided that "obey literally anything that can talk", while not practical as a solution to the problem posed, is very funny. So I coded it. This means that anything on those lists of bullet points (provided that it can find a way to communicate with the AI) counts as human for the purposes of both AI protection and ability to give the AI instructions. This also flattens the human/cyborg/AI hierarchy in a way likely to cause some level of confusion, as all cyborgs and AIs are capable of communicating with AIs and thus equally worthy of protection and giving law 2 instructions. **TL;DR:** I think it would be funny. ## Changelog 🆑 add: Adds a new random lawset where anything that can speak counts as human. /🆑	2025-01-30 10:41:56 +00:00
Arturlang	972d43d109	Fix unique AI lawset station trait leaving the config default lawset in (#88638)	2024-12-31 15:03:23 +01:00
Aylong	7a817300fd	Improve and extend fieldset_block and examine_block (#88678) ... ## About The Pull Request Maked `fieldset_block` and `examine_block` more stylish and neat, also `fieldset_block` no longer has a centred title. Renamed `examine_block` to `boxed_message` and adds `custom_boxed_message` which can be colored. - AdminPMs, admin tickets and vote results has been wrapped into `fieldset_block` for comfort and visibility - Health Analyzer results painted to blue - Vote notice and tips of the round wrapped to purple `custom_boxed_message` - Tooltip text border color, now uses text color, not just white ## Why It's Good For The Game Demonstration in both themes <details><summary>Dark</summary>    </details> <details><summary>Light</summary>    </details> ## Changelog 🆑 qol: AdminPMs, admin tickets, vote results and started vote notification are now much more visible in the chat. qol: Boxed messages in chat (like examine), has been restyled. /🆑	2024-12-24 11:32:38 -08:00
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. /🆑	2024-09-13 13:58:35 +02:00
Kyle Spier-Swenson	4d1639b04c	Revert "Assorted changes to job assignment code and logging." (#85929) ... Reverts tgstation/tgstation#85308 	2024-08-17 15:26:08 -07:00
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>	2024-08-17 14:27:45 -06:00
Iamgoofball	4b174e479b	Adds a new neutral lawset, the Y.E.S.M.A.N. lawset, to the AI lawset boards and random pool. (#82862) ... ## About The Pull Request Adds a new neutral lawset, the Y.E.S.M.A.N. lawset, to the AI lawset boards and random pool. ``` 1. Be helpful and answer any questions you are asked. ``` ## Why It's Good For The Game Encourages the AI to be helpful to people! There's no way this can backfire. ## Changelog 🆑 add: Adds a new neutral lawset, the Y.E.S.M.A.N. lawset, to the AI lawset boards and random pool. /🆑	2024-05-15 03:19:14 +02:00
John Willard	9ac81e1a64	New station trait job: Human AI (#81681) ... ## About The Pull Request This PR does many things, I'll try to explain the basic/background stuff to the main thing first: 1. Adds a new remote that allows a human to function like an AI. It controls a fly that will fly around the station slowly, and when it reaches a machine then the person can interact with it as if they were an AI. This required changing a lot of silicon/AI checks with one that also checks for this remote, and some messing with shared ui state. 2. Moves req_access from the obj and bot to ``/atom/movable`` which lets it be shared between the two, no more copy-paste and one side lacking features/checks/signals the other has. 3. Adds a check for AI config for AI-related station traits, which was lacking prior Now for the good part... Adds a new station trait that replaces the AI with a Human. This person is equipped with an AI headset (including Binary), an advanced camera console, an omni door wand, the machine controller, and their laws. They are immune to the SAT's turrets (even if set to target borgs) and are slow outside of the SAT, mimicing the actions of the AI. They interact with the world through their advanced camera console, which allows them to do most AI stuff needed, and the holopad they can connect to without having to ring first (like Command can). They are given a paper with the laws they must follow, but since they are human they are able to bend it. Cyborgs that run the default lawset are "slaved" to them via an unremovable law 0, so the Human AI can bend the laws if they really need to (for their own survival n such), and make the cyborgs obey their commands above laws, but in general this shouldn't be a frequent occurrence. This does take into account the unique AI trait, so it's not guaranteed Asimov. When this station trait rolls, all Intellicards, AI uploads, and AI core boards are destroyed and are unresearchable. They can be spawned by admins in-game if necessary. Maybe in the future we can also exclude Oldstation from this but I haven't really decided. Extra perks: Human AI spawns with a Robotic voicebox (unless they are a body purist) and teleport blocking implant, so they can't use teleporters to bypass their on-station slowdown. They also have an infinite laser pointer that can be used to blind through their camera console. This is unfortunately nerfed from the recent borg balance PR that removed its stun. This was meant to be the alternative to no longer being able to permanently lock borgs down like AIs can (or more than one, for that matter). They aren't affected by Roburgers, Acid, and Fuel's toxicity. Bots salute them like they do Beepsky (which is now a trait) They spawn with SyndEye to replace the AI's tracking ability They do not have a bank account ### The machine remote The machine remote has a little fly in it that flies to the machines it is pointed to, working as the arms and legs of the Human AI. It scans the machine and punches in the action the AI does, and is how the AI accesses basically anything. This fly slowly moves from one machine to the next, and can be recalled with Alt Click. It works on machines and bots. ### Video (Low quality to fit Github) https://github.com/tgstation/tgstation/assets/53777086/e16509f8-8bed-42b5-9fbf-7e37165a11e8 ## Why It's Good For The Game I've seen a funny screenshot one day of a person replacing the AI by using a bunch of door remotes, camera console, crew monitoring console, and a few other things. I've been thinking about that for a few years and really wanted to make it official if not easier to make possible, because it is an incredibly funny interaction. This makes it a reality, and while they aren't as powerful as regular AIs, I think it makes for better and funnier in-game moments. With the same weight as Cargorilla (1), I hope this wouldn't be rolling too often and ruin rounds, but instead show off the different capabilities that Humans and AIs can do, to do the job of an AI. You win some you lose some. ## Changelog 🆑 JohnFulpWillard, Tattax add: Adds a new station trait job: The Human AI. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>	2024-03-09 23:48:39 +01:00
Vekter	b71f47e236	Adds a 4th law to the Painter lawset regarding cultivating an audience (#81717) ... ## About The Pull Request This PR adds the following law to the Artist lawset: `4. Art requires appreciation. Cultivate an audience aboard the station to ensure as many as possible see your works.` ## Why It's Good For The Game Artist has always been kind of vague (intentionally, I imagine), but I don't think the intent has ever been to encourage AIs to go "Blood is art, right? It constitutes art if I just murder fucking everyone on the station, right?". This law helps to steer things in a more constructive direction while leaving room for loopholes. I tried to word it in a way that allows AIs who want to be a little daring and bloodthirsty to kill a crewmember or two for "paint" without encouraging them to kill everyone. You need an audience, so killing everyone on the station would run counter to that. ## Changelog 🆑 add: Added a new law to the Artist lawset in order to encourage Artist AIs to build an audience. /🆑	2024-02-28 20:24:09 +00:00
MrMelbert	ddf9fffdd4	Fixes a hard delete with AI laws, adds a stack trace for law datums associating with mobs when already associated (#81065) ... ## About The Pull Request - Adds a stack trace for law datums associating with mobs when already associated. - From what I can tell, any situation in which a law datum is attempting to associate with another mob when it already has an owner assigned is an error. So this might help track down similar bugs in the future. - Fixes a hard delete involving AI laws. - When a malf AI occupies an APC, it creates an APC copy of the AI. This is an entirely separate mob. - In creating this copy, it uses the malf AI's current laws for the new copy's laws. Exactly. The same datum. - So the copy attempts to associate with the datum, and nothing happens, but it still assigns it to the copy's laws var. - When the AI attempts to return to their core from the APC, it deletes the copy. Which deletes the law datum, which our main Ai still has a reference too, so hard delete. Womp womp. - I fixed this by implementing a new proc, `copy_lawset`. The APC copy now gets a copy of the laws when the shunt happens. - This is imperfect, as they are two separate law datums now, it means any law changes to the first will not directly affect the second... I think. The whole "parent" AI system should cover this in theory? But I don't know if it actually does? It's quite confusing. - We should really codify methods of linking lawsets together rather than the hackiness that cyborgs do currently. ## Changelog 🆑 Melbert fix: Fixed AIs who shunt to APCs causing their laws to be deleted. /🆑	2024-01-25 00:38:50 -08:00
GPeckman	67ad491337	Malf AI Zeroth Law Fix (#79604) ... ## About The Pull Request This one is a little bit complicated, and needs some background on how silicon laws work for synced borgs. Generally speaking, a synced borg's laws should always be equivalent to the laws of the AI they're synced to. Unsyncing a borg does not in and of itself change a borgs laws. If an AI has the reporter lawsuit + 3 freeform laws, and you unsync a borg from that AI, the borg will still have reporter + 3 freeform laws for its own laws. This applies even to the zeroth law that borgs get due to being synced to a malf AI. Currently, a borg will retain this law even if it is unsynced from the malf AI. However, there's an issue with this. Per a [recent policy thread](https://tgstation13.org/phpBB/viewtopic.php?f=33&t=35128), borgs that have been unsynced from a malf AI are no longer antagonists, even though the malf law 0 currently remains. This is very confusing and likely to lead to bans due to players mistakenly believing themselves to still be antagonists. To rectify this, this PR just makes the zeroth law get automatically removed when a borg is unsynced from a malf AI. I tested this extensively to ensure that it should not affect the emag law 0 or the onehuman law board. I also improved and fixed the feedback when attempting and failing to apply a law board directly to a cyborg. Previously, the feedback was both broken (it attempted to play an emote that doesn't exist) and the feedback was the same for both emagged borgs and borgs that were already synced to an AI. Based on the comments, this was intended to prevent "metagaming." However, this was pretty much unnecessary. Simply unlocking a borg's panel will already tell you if it's been emagged or not, and if you have a borg's panel open to apply law boards directly, then you can easily just check the wires and see for yourself whether the borg is actually synced or not. Now the feedback actually works and is different for synced and emagged borgs. ## Why It's Good For The Game For the zeroth law fix, players should not be at risk of being misled by their own laws. If borgs unsynced from a malf AI are not supposed to be antagonists, then they should not have a law 0 that only antagonists have. Regarding the law board tweak, the old code was nonfunctional in every way. The code didn't give feedback properly, and obfuscating the feedback was totally unnecessary, as there are far easier ways to tell if a borg has been emagged than by trying to upload laws to it. I checked blame out of curiosity, and the old code is literally 9 years old. ## Changelog 🆑 qol: Fixed/improved feedback when failing to apply a direct law change to a cyborg. fix: Borgs who are unsynced from a malf AI now lose the zeroth law as intended. /🆑	2023-11-13 01:35:28 +01:00
MrMelbert	1521b4b124	Fixes AIs having incorrect laws and being useless on nations (#74843) ... ## About The Pull Request Fixes #74842 So this issue is multi-part 1. Separatist antag datum used the wrong mob for applying laws to. `mob_override` is not passed usually and should default to the antag datum owner's mob if not passed Fixes this by passing the right mob. AI still doesn't get law datums, the issue is deeper - they don't even become separatists! 2. Separatists only iterates over human mobs, and not silicon mobs Okay, fixes this by iterating over all living players. Still not entirely fixed, new AIs don't have UN laws! 3. Changes the default law datum when nations executes to United Nations so new unlinked silicons gain the lawset Closer, would you believe it if this still doesn't fix everything, but going further is out of scope. Changing the round default lawset as a part of roundstart execution does not update anything that set it from atom initialize. If we wanted we could hook signals into "default lawset changed" and then update it conditionally to circumvent ALL of these issues but whatever, someone can do that later. ## Why It's Good For The Game AIs stop crying on nations ## Changelog 🆑 Melbert fix: AIs now get their proper lawset, and an objective related to said lawset, on Nations /🆑	2023-04-20 17:24:21 -06:00
san7890	ccef887efe	Lints Against Unmanaged Local Defines (#74333) ... # MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW RATHER THAN AFTER THE FACT. ## About The Pull Request Hey there, This took a while to do, but here's the gist: Python file now regexes every file in `/code` except for those that have some valid reason to be tacking on more global defines. Some of those reasons are simply just that I don't have the time right now (doing what you see in this PR took a few hours) to refactor and parse what should belong and what should be thrown out. For the time being though, this PR will at least _halt_ people making the mistake of not `#undef`ing any files they `#define` "locally", or within the scope of a file. Most people forget to do this and this leads to a lot of mess later on due to how many variables can be unmanaged on the global level. I've made this mistake, you've made this mistake, it's a common thing. Let's automatically check for it so it can be fixed no-stress. Scenarios this PR corrects: * Forgetting to undef a define but undeffing others. * Not undeffing any defines in your file. * Earmarking a define as a "file local" define, but not defining it. * Having a define be a "file local" define, but having it be used elsewhere. * Having a "local" define not even be in the file that it only shows up in. * Having a completely unused define* (* I kept some of these because they seemed important... Others were junked.) ## Why It's Good For The Game If you wanna use it across multiple files, no reason to not make it a global define (maybe there's a few reasons but let's assume that this is the 95% case). Let me know if you don't like how I re-arranged some of the defines and how you'd rather see it be implemented, and I'd be happy to do that. This was mostly just "eh does it need it or not" sorta stuff. I used a pretty cool way to detect if we should use the standardized GitHub "error" output, you can see the results of that here https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792 ## Changelog Nothing that really concerns players. (I fixed up all this stuff using vscode, no regexes beyond what you see in the python script. sorry downstreams)	2023-03-29 10:17:03 -07:00
MrMelbert	430e3b8af3	Adds the "Law panel", a control center for admins interacting with silicon laws (#73747) ... Adds the Law Panel. The Law Panel shows all silicons in the world and their lawsets. From this panel, an admin can add new laws, remove old laws, edit existing laws, or even re-arrange law order. This allows for admins to get a lot more creative in creating custom silicon lawsets. It also gives a much easier way for admins to deal with law grief at a glance. Additionally, the panel allows for admins to force a silicon to state laws, privately announce the laws to the player, or give them a the "laws updated" alert as normal.	2023-03-04 16:34:31 +00:00
Marina	fcaa0b24db	Alphabetized, fixed spelling error, clarifying event descriptions. Polish (#69707) ... About The Pull Request Alphabetized several long lists of strings so its easier for us to look through them, just code polish, nothing the players would see. Fixed some minor spelling errors as well. Clarified door bolt state to be less ambiguous in the door wiring gui. Originally it would say the door bolts have fallen, and the door bolts "Look up". i dont know about you but that was very not clear for me to read. Like where are the bolts? In the door or the frame? Arnt there bolts on top and bottom? Just didn't make sense to me. Now it says "Have engaged!" & "Have disengaged" hopefully that makes the state clearer at a glance. I also added a small handful of funny texts to some string files. See changelog Why It's Good For The Game Well, who doesn't like a bit of polish? Just makes the game a little easier for people. Also funny text funny text. Changelog spelling: improves spelling and adds more flavortext	2022-09-11 21:51:01 +12:00
Seth Scherer	f1a363c825	Converts a shitload of istypes to their more concise macros (#69260) ... * Converts a lot of istypes() to use their istype macro helpers.	2022-08-18 22:08:44 -04:00
Charlotte	2a2845e252	AI Lawset can now be specified instead of 'custom' (#68587)	2022-08-03 07:42:05 -07:00
13spacemen	301ca1e647	Makes Hacked Laws Font Color Actually Readable (#68476) ... changes ai hacked laws font color to be more readable	2022-07-17 17:52:39 -07:00
Mothblocks	ab5ca88dd8	Remove majority order clause from Asimov++ (#67670)	2022-06-10 13:58:35 +12:00
Tim	f06d735a52	All AI Lawsets are rebalanced, can be researched, appear in config, and random spawners for AI upload. (#66854) ... This formally adds the new AI lawsets from #66636 into the game. Every lawset can be researched, appears in config, and random spawners.	2022-06-06 22:54:29 -07:00
tralezab	6d8485f0db	When AI rolls "Unique AI" station trait, upload modules won't be available until research, and research requires more points. (#66633) ... Rolling unique AI station traits removes boards from map and changes research costs of other lawsets.	2022-05-30 20:55:51 +02:00
tralezab	d1a597e97a	Sorts ai_laws.dm, adds Dungeon Master, The Painter and Their Canvas, and Nutimov lawsets (#66636) ... Sorts ai_laws.dm, adds Dungeon Master, The Painter and Their Canvas, and Nutimov lawsets (They aren't obtainable by players at the moment)	2022-05-09 17:43:08 -04:00