mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-08-22 04:30:44 +01:00
ok-behavior-trees
624
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
df7832aa43 |
Replaced our NPC AI with Behavior Trees. (#96628)
This PR replaces our current NPC AI with a [behavior tree system](https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control)). Behavior trees are a common way of creating AI in which you place nodes in a tree structure to define what actions an AI should take. AI controllers defined a list of /datum/ai_planning_subtree types in behavior_nodes. Each subtree was a self-contained unit that could call queue_behavior() to fire off /datum/ai_behavior actions. The controller iterated subtrees in order, each one deciding independently whether to queue something and deciding whether the next subtree would run. This has a few issues: 1. There's no real structure; you are just defining a list of things to try in order. 2. There was a loooot of subtrees that were basically the same as another but with some slight modification 3. It was hard to understand. Controllers now define a single json file describing a tree of nodes. The tree is composed of structural composites: Sequence - do A, then B, then C (and so on) Selector - try A, if it fails try B, then C (and so on) Parallel - run A and B simultaneously, with configurable failure/success policies and or looping behavior Subplan - loop a child continiously Along that we also have "Decorators". These are nodes that basically check a condition (E.g.; do we have a combat target). These decorators can be used to gate behavior and are re-useable across behavior trees. They also have a concept known as "Observers". Which lets them cancel lower priority behavior in case their condition changes (Which we check whenever a signal fires that fits that specific decorator). This makes the AI much more responsive to change in environment. For behaviors, we still use the ai_behavior datums. These are the actual behaviors such as "Move to X", "Attack X". The only major change is that these can no longer sleep() since they now run in the ai_controller. Lastly, we now also have subtrees, except now they are essentially pieces of behavior tree that can be re-used, or even overriden at runtime or as a variable. Allowing for making modular AI made out of several smaller trees. You can set variables on these nodes directly via the extension (see below), which should reduce the need to make subtypes of behaviors by a lot. All of these vars are saved on the JSON and will be applied at runtime. If you are using subtrees, you can also assign "bindings" to these variables, which will allow instances of the subtree to override those variables. Since a tree structure with variables becomes hard to parse in a JSON, I've made a VSCode extension to edit these JSONs: https://marketplace.visualstudio.com/items?itemName=BehaviorTreeG.behaviortreeg https://github.com/CabinetOnFire/BehaviorTreeG <img width="1795" height="1268" alt="image" src="https://github.com/user-attachments/assets/56aa2f0b-3cf9-449f-bca4-8281fca82db6" /> This extension allows you to edit the behavior tree JSONs, and browse through all the behaviors/decorators/subtrees we have If you'd like more info on how to build these AI check out the learn_ai.md. I will also make a tutorial to go over more depth on what the system offers because I kind of suck at doing technical write-ups. Targetting has been changed to. I've made a new acquire_targets behavior that takes a target_source (what am I targetting) and targetting_strategy (what does the candidate need to fulfill to be considered a target). This allows us to make composites targetting combinations to reduce the amount of specific find_and_set esque behaviors we had before. Not everything is ported to this system but that would be a longer term goal. I've added a new build_bt script that converts all the behavior tree JSONs into compiled versions. Why is this needed? Because I wanted to keep using defines in behavior trees, so we need a way to convert this into literal values before we send it to DM. This script runs on compile and should also run in CI (If I didn't fuck that up!). This saves to a new build/ folder. I've ported every single AI in the game to this system (except raptors, Kobsa is working on those so should be in soon!), so I do expect some bugs to come out of this. But I also fixed some issues that have probably been in the game for a long time such as: - Fixed penguins being unable to fish - Fixed bileworms not being able to devour people - Fixes goldgrubs not grubbing gold (they could not mine!) - Lizards actually eat food they find Either way, I'd reccomend a long TM on this. 1. (Hopefully) a better development experience for making AI 2. Less copy-paste for behaviors, we should be able to re-use more pieces to make behavior 3. Behavior trees is a more common pattern in making AI, so it should be easier to find resources to find out how to do things. 🆑 CabinetOnFire, Iamgoofball, SmartKar, Ben10omintrix refactor: Replaces our AI system with behavior trees, porting all datum/ai to it /🆑 I will add this PR with more details down the line. I think I got the big picture but its a big PR, so sorry if I missed something important. --------- Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com> Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com> |
||
|
|
ff006aa4a5 |
verb macro system (pr 1/3) (#96720)
## About The Pull Request just macro-izes all the usages of verbs in the codebase as a pre-requisite to my follow up pr that serializes all the verbs arguments so we can tgui-ify the command bar, so we can then put it on the onscreen map. this also basically does the same as #94487 so can easily be integrated into the verb queueing stuff... but does not actually do any verb queueing by itself. basically im just trying to be https://github.com/tgstation/tgstation/labels/Atomic ## Why It's Good For The Game it doesn't really do anything by itself but it does let us do more stuff ## Changelog 🆑 code: the backend to all verbs in the game has been played with, please report any issues to github /🆑 --------- Co-authored-by: harryob <55142896+harryob@users.noreply.github.com> |
||
|
|
af8f69da13 |
Adds "Event Logging", or EVLogging, A new debug system that allows us to track individual datums and log events on a timeline (#96035)
## About The Pull Request This Pull Request adds a new logging system that uses a timeline to track and visualize important events for specific datums. This is done via a new window in which you can select a datum for tracking, which adds it to the timeline. If this datum implements the EVLOGGING macros, it can track important events onto this timeline. As an example, we can log whenever an AI is deciding to make a new path, if it decides to generate a new decisionmaking plan, it finishes an action, or it decides to target someone/something. We can select these events to see more information, and optionally get a snapshot of important variables at the time this event was logged (like the blackboard and current plan for AI controllers). You can also filter out specific events / track info, which is done via categories. Each event / piece of track info is given a category and if you disable a category all events / track info in that category is hidden. This lets you filter out things you might not care about. <img width="2346" height="1209" alt="image" src="https://github.com/user-attachments/assets/0763077c-e349-4c7c-b017-23d29e1d089b" /> _whoever thinks we didnt need advanced cleanbot logging is a noob_ In the video below I showcase how this works; https://file.house/7nsOiqdvmSTxlsk3fs-e8g==.mp4 A cleanbot is roaming the halls, I turn on the event logger, click the "pick target" button and click on the datum I'd like to track (the cleanbot). This results in the cleanbot now tracking its events. I spawn some dirt and the cleanbot decides to clean it, and I go through the events; You can see theres different events being listed, such as when the cleanbot starts targetting the dirt, when it cleans plan, when it makes it JPS path and every time it moves over it. The macros I've currently implemented are as follows: **EVLOG_TEXT(DATUM, CATEGORY, INFO)** Only adds text to the event logger window, no world-visuals EVLOG_LOCATION(DATUM, CATEGORY, INFO, TURF) Adds text to the event logger and adds an image to where that turf is. EVLOG_TURFS(DATUM, CATEGORY, INFO, TURFS) Adds text to the event logger and adds an image to each turf in the TURFS list EVLOG_LINES(DATUM, CATEGORY, INFO, TURF_A, TURF_B) Adds text to the event logger and adds a line from turf_a to turf_B EVLOG_PATH(DATUM, CATEGORY, INFO, TURFS) Adds text to the event logger and visualizes a path from A to B (same way as the pathfinding debugger, of which I moved the visualization before to SSPathfinder) In terms of performance, the logger is a singleton, and events are ONLY logged if 1. The logger is running 2. The datum has the DF_EVLOGGING flag. This means most of the time, logging an event is a single var lookup (Since the runner is off by default). The DF_EVLOGGING flag is off by default as well and has to be enabled by the event logger, or set temporarily by a dev in code. This system can easily be extended with more event types / visualization types as well. (I'm thinking of datumizing the ones I have now) The TGUI is still a bit of a mess, I would love some pointers because I'm not really good at react so I just kind of hit it with a hammer until it did what I wanted 😎 Also, all of this is based on VisLogging from Unreal Engine, so it will have some likeness https://unreal-garden.com/tutorials/visual-logger/ ## Why It's Good For The Game This system allows us to debug more complex systems (like basic AI) in an understandable and clear way. While the implementation cases are not super common right now, extending this system could make debugging these systems much more comprehensible, and hopefully lets more developers help us with improving these systems. (plus, we LOVE timelines) ## Changelog 🆑 CabinetOnFire refactor: Implements "Event Logging" an improved way for programmers to debug specific datums. /🆑 --------- Co-authored-by: Lucy <lucy@absolucy.moe> |
||
|
BloopandGitHub
|
b3770614c1 | Makes invisimins actually invisible to regular ghosts, plus qol improvements (#95856) | ||
|
ArcaneMusicandGitHub
|
57be83952e |
Fixes for black market creation verb. (#95619)
## About The Pull Request The "Create Black Market Item" verb now needs an input so that it doesn't try and crash the client. The verb also has a few extra bits of cleanup. Successful completion of the verb will now alert admins that it's been added to the market. ~~This also adds an additonal admin verb, "View Blackmarket", which will allows you to view a blackmarket UI with all the currently loaded items. (I HAVE YET TO MAKE THIS WORK WITH MY CURRENT STRATEGY, HENCE THIS PR BEING A DRAFT).~~ Removed due to taking too long. ## Why It's Good For The Game Better admin ui/ux, fewer ways to accidently crash your game from viewing all `/obj`s in the game, and allows for more admin interaction with the black market which the original PR intended to do. ## Changelog 🆑 fix: More safeguards were added to the admin "Create Black Market Item" verb. /🆑 |
||
|
mrmanlikesbtandGitHub
|
928df286a6 |
Kills /datum/asset/var/_abstract, uses abstract_type instead (#95756)
## About The Pull Request It's all in the title ## Why It's Good For The Game Forgotten in #92909 ## Changelog no player facing changes |
||
|
SmArtKarandGitHub
|
11fbb59049 | TGUIfies some VV actions, replaces the actions dropdown with a searchable one (#95480) | ||
|
ArcaneMusicandGitHub
|
fb58e99934 |
Admins can add new custom blackmarket listings, and tweaks the "Launch" shipping option. (#95191)
## About The Pull Request Two main items: 1: Admins can now use the new "Create new Blackmarket Item" verb, which prompts them about the item, price, quantity, name and description of the item they'd like to list. If successful, the item will be listed to the black market, available to purchase by the crew. Prices can be set very, very high, though I've limited the available quantity to 100 per listing as a nice middle-ground value. The verb can be used any number of times, allowing for admins to use the black market to run events, as such. Of note, this verb will spawn a fresh typepath of the object listed, so it cannot be used to list var-edited objects as-is, but it's still quite useful for offering unique or rare items to the crew based on the needs of the round. 2: This PR does a few tweaks to the "launch" shipping option on the black market. The text displayed when having an object launched to the station has been adjusted to reduce some ambiguity on if the item is potentially deleted when launched. The launch behavior has not been modified in this way, as the object is still launched at the station using similar logic as before. **However**, the item is now launched to the station in a faux-energy bubble, which destroys itself and empties it's contents when it makes thrown impact or is opened by hand. In practice, this is only noticeable if you were outside when the order is launched at the station, or if the crate makes impact with you. This allows for black market objects that create spawners to arrive at the station harmlessly, which also potentially reducing some of the randomness of an object being thrown at the station, and then leaving the z-level immediately based on the extra collision involved. Additionally, I've lowered the **shipping cost to 0** of launched items. Misc: Did some code cleanup by adding defines for each of the categories of black market items, and a list-define for every category together. ## Why It's Good For The Game I've wanted to have the option for admins to be able to list things for the crew to buy for quite awhile now, without requiring them to barter by hand or through a reliable means that can't be bypassed by 3 assistants with baseball bats. This offers that option, while also having some flavor of being offered on the black market, if that's desirable. Otherwise, it's no impact on the average round as it's admin-only. Regarding the launch options, this started as a grammar tweak as I was talking with Arm on discord and the lack of clarity raised the whole shipping option to our attention. After confirming that launching things to the station was NOT, in fact a literal noob trap, just an awful choice, I started work on the shield-bubble idea in an attempt to see if I could try and reduce some of the randomness involved with that shipping option. It already sucks due to the risk of going out into space, there's no need to make it suck worse by potentially losing any of the cooler items available on the black market at the same time. So, price down and a mild consistency up. I also ran into #95183 while I was testing all of this, so this should fix #95183. Lastly, code cleanup. Made a few things look 3% nicer. |
||
|
itsmeowandGitHub
|
cc335e7e9e |
IconForge: rust-g Spritesheet Generation (#89478)
## About The Pull Request Replaces the asset subsystem's spritesheet generator with a rust-based implementation (https://github.com/tgstation/rust-g/pull/160). This is a rough port of https://github.com/BeeStation/BeeStation-Hornet/pull/10404, but it includes fixes for some cases I didn't catch that apply on TG. (FWIW we've been using this system on prod for over a year and encountered no major issues.) ### TG MAINTAINER NOTE  ### Batched Spritesheets `/datum/asset/spritesheet_batched`: A version of the spritesheet system that collects a list of `/datum/universal_icon`s and sends them off to rustg asynchronously, and the generation also runs on another thread, so the game doesn't block during realize_spritesheet. The rust generation is about 10x faster when it comes to actual icon generation, but the biggest perk of the batched spritesheets is the caching system. This PR notably does not convert a few things to the new spritesheet generator. - Species and antagonist icons in the preferences view because they use getFlatIcon ~~which can't be converted to universal icons~~. - Yes, this is still a *massive* cost to init, unfortunately. On Bee, I actually enabled the 'legacy' cache on prod and development, which you can see in my PR. That's why I added the 'clear cache' verb and the `unregister()` procs, because it can force a regeneration at runtime. I decided not to port this, since I think it would be detrimental to the large amount of contributors here. - It is *technically* possible to port parts of this to the uni_icon system by making a uni_icon version of getFlatIcon. However, some overlays use runtime-generated icons which are ~~completely unparseable to IconForge, since they're stored in the RSC and don't exist as files anywhere~~. This is most noticeable with things like hair (which blend additively with the hair mask on the server, thus making them invisible to `get_flat_uni_icon`). It also doesn't help that species and antag icons will still need to generate a bunch of dummies and delete them to even verify cache validity. - It is actually possible to write the RSC icons to the filesystem (using fcopy) and reference them in IconForge. However, I'm going to wait on doing this until I port my GAGS implementation because it requires GAGS to exist on the filesystem as well. #### Caching IconForge generates a cache based on the set of icons used, all transform operations applied, and the source DMIs of each icon used within the spritesheet. It can compare the hashes and invalidate the cache automatically if any of these change. This means we can enable caching on development, and have absolutely no downsides, because if anything changes, the cache invalidates itself. The caching has a mean cost of ~5ms and saves a lot of time compared to generating the spritesheet, even with rust's faster generation. The main downside is that the cache still requires building the list of icons and their transforms, then json encoding it to send to rustg. Here's an abbreviated example of a cache JSON. All of these need to match for the cache to be valid. `input_hash` contains the transform definitions for all the sprites in the spritesheet, so if the input to iconforge changes, that hash catches it. The `sizes` and `sprites` are loaded into DM. ```json { "input_hash": "99f1bc67d590e000", "dmi_hashes": { "icons/ui/achievements/achievements.dmi": "771200c75da11c62" }, "sizes": [ "76x76" ], "sprites": { "achievement-rustascend": { "size_id": "76x76", "position": 1 } }, "rustg_version": "3.6.0", "dm_version": 1 } ``` ### Universal Icons Universal icons are just a collection of DMI, Icon State, and any icon transformation procs you apply (blends, crops, scales). They can be convered to DM icons via `to_icon()`. I've included an implementation of GAGS that produces universal icons, allowing GAGS items to be converted into them. IconForge can read universal icons and add them to spritesheets. It's basically just a wrapper that reimplements BYOND icon procs. ### Other Stuff Converts some uses of md5asfile within legacy spritesheets to use rustg_hash_file instead, improving the performance of their generation. Fixes lizard body markings not showing in previews, and re-adds eyes to the ethereal color preview. This is a side effect of IconForge having *much* better error handling than DM icon procs. Invalid stuff that gets passed around will error instead of silently doing nothing. Changes the CSS used in legacy spritesheet generation to split `background: url(...) no-repeat` into separate props. This is necessary for WebView2, as IE treats these properties differently - adding `background-color` to an icon object (as seen in the R&D console) won't work if you don't split these out. Deletes unused spritesheets and their associated icons (condiments spritesheet, old PDA spritesheet) ## Why It's Good For The Game If you press "Character Setup", the 10-13sec of lag is now approximately 0.5-2 seconds. Tracy profile showing the time spent on get_asset_datum. I pressed the preferences button during init on both branches. Do note that this was ran with a smart cache HIT, so no generation occurred.  Much lower worst-case for /datum/asset/New (which includes `create_spritesheets()` and `register()`)  Here's a look at the internal costs from rustg - as you can see `generate_spritesheet()` is very fast:  ### Comparison for a single spritesheet - chat spritesheet: **Before**  **After**  ## Changelog 🆑 fix: Fixed lizard body markings and ethereal feature previews in the preference menu missing some overlays. refactor: Optimized spritesheet asset generation greatly using rustg IconForge, greatly reducing post-initialization lag as well as reducing init times and saving server computation. config: Added 'smart' asset caching, for batched rustg IconForge spritesheets. It is persistent and suitable for use on local, with automatic invalidation. add: Added admin verbs - Debug -> Clear Smart/Legacy Asset Cache for spritesheets. fix: Fixed R&D console icons breaking on WebView2/516 /🆑 |
||
|
SmArtKarandGitHub
|
cf27074ee5 |
Fixes runtimes in Spawn Debug Full Crew, makes the warning clearer (#89601)
## About The Pull Request Mobs without clients or prefs now get default values instead of informed default values, preventing runtimes in Spawn Debug Full Crew. Also made the ***second*** warning much clearer and only appear when the user isn't localhost, similarly to Start Now. Totally not related to a recent incident on live servers, nope. Surely not. ## Changelog 🆑 fix: Spawn Debug Full Crew no longer runtimes admin: Spawn Debug Full Crew now explicitly warns you a second time if you're attempting to use it as a non-localhost user. /🆑 |
||
|
JacquerelandGitHub
|
d7264ce0f3 |
Admin verb to apply mob random speech behaviour (#89382)
## About The Pull Request Separate verb and PR from #89375 because this is something you'd apply on top of a mob with existing behaviour, or one you've used the other verb on. This will probably conflict with my other PR but that's my problem. This adds a shortcut for making mobs say/emote stuff randomly on a timer from a list of things you have specified. Doing this via VV is possible but sufficiently complicated that I don't think anyone would ever bother. As with the other PR you can optionally do this to mobs who already have a client if you want them to randomly burp every so often or something. I briefly flirted with the idea of replacing all `/datum/ai_planning_subtree/random_speech` subtypes with blackboard ones but... I think probably actually we save some memory _and_ sanity by not doing that. A bunch of mobs on totally different typepaths use the `/insect` subtype for instance, and I don't think it would be an improvement to paste the same four vars into all of their blackboards. ## Why It's Good For The Game This one is frankly more niche than the other PR probably but it is plausibly useful if you are setting up some kind of VV creature. |
||
|
JacquerelandGitHub
|
f1d3994c95 |
Apply AI Controller Admin Verb (#89375)
## About The Pull Request Melbert asked me to make this and I thought it'd be relatively easy and plausibly useful so I did. This PR adds a feature to the VV menu for mobs which allows you to apply and configure an AI controller from a list of templates. It's not as versatile as coding one would be, but it should be able to accomodate a lot of generic scenarios. Some examples of basic stuff you can set it up to do: - Give Ian a machine gun he will fire at nearby people while staying within a specified min/max range. - Have Poly fire brimstone beams on cooldown at whoever is nearby (although she won't bother trying to line up cardinally). - Assign a gorilla to be someone's personal bodyguard which will follow them around and attack anyone who hurts them. I have also made an executive decision to remove the restriction that basic ai controllers can only be placed on basic mobs. We've removed _most_ non-basic simple mobs from the game, and also have more recently updated most AI behaviours to work agnostically of whether they are assigned to a basic mob or not... which means that they'll largely work on carbons. Coincidentally, this feature makes sure to ask if you want an AI controller to remain active on a mob which already has a client. Assigning an active AI controller to a live player which forces their character to automatically attempt to run away from whoever the last person to attack them was is ~~not recommended behaviour because it's largely untested~~ highly recommended behaviour because I think it's very funny (makes it very hard to play though). I'm gonna do another PR some time which cleans up `random_speech` so it's configurable and then let you slap that on whoever as well. ## Why It's Good For The Game Enables a greater level of admin abuse. ## Changelog 🆑 admin: Added easier tooling for admins to add or change the AI controllers on mobs /🆑 |
||
|
The SharkeningandGitHub
|
7e20627406 | Fixes things being statistically weighted to drop in security (#88788) | ||
|
carlarctgandGitHub
|
55a07d99b8 |
Fixed being unable to aghost while corpselocked (#87594)
## About The Pull Request Fixed being unable to aghost while corpselocked, via adding another parameter to ghostize that checks if it's an aghost or not ## Why It's Good For The Game i wana leave my body when testing as ethereal ## Changelog 🆑 fix: Fixed being unable to aghost while corpselocked /🆑 |
||
|
san7890andGitHub
|
a4328ae1f9 |
Audits tgui_input_text() for length issues (#86741)
Fixes #86784
## About The Pull Request
Although some of the issues found were a direct result from #86692
(
|
||
|
TimberpoesandGitHub
|
6808a082eb |
Assorted changes to job assignment code and logging. Runtime free, guaranteed or your money back. Price: $£0. (#85947)
## About The Previous Pull Request #85308 reverted by #85929  ~~Causes the round to not start when a player isn't eligible for any jobs at a specific priority level due to runtimes trying to `pick()` from an empty list aborting the entire job assignment stack.~~ (Fixed???? by https://github.com/tgstation/tgstation/pull/85947/commits/e0e9f2f430079d4ab7097abe12e75f934131a638) Maybe we should test merge this for a mo just to make sure no more cheeky runtimes pop up before merging. ## About The Pull Request This PR does a couple of minor things: Makes the job debug logging a bit easier to follow. Minorly brings some SSjob code up to code standards, converting proc names to snake_case and doing some otherm is cleanup. Refactored some stuff into different procs, updated some comments. And some major things: Changes the job assignment logic. Old behaviour > Assign dynamic priority roles > Force one Head of Staff (if possible) > Assign all AIs > Assign overflow roles (bugged in 2 ways) > Shuffle the available jobs list once, at the start of the random job assignment loop > Pick and assign random jobs for random players from High prefs down, with a priority on Head of Staff roles > Handle everyone that couldn't be assigned a random job New behaviour > Assign dynamic priority roles > Assign all Head of Staff roles to players with High prefs > If no Head of Staff was made in the above way, force one Head of Staff (if possible) > Assign all AIs > Assign overflow roles (fixed) > Prioritise and fill unfilled head roles at each job priority pref level, from High prefs down. > Build a list of all jobs that each unassigned player could be eligible for at the above pref level. > Pick a job from that list at random and assign it to the player. > Handle everyone that couldn't be assigned a random job. In reality there should be little impact on overall job assignment, the code changes read more as semantics. For example, the priority check for filling Head slots will have the same candidate pool in both old and new versions, but in the new version we're more clearly saying that Heads are important and we want to prioritise filling them for the sake of round progression even though the outcome in new and old is the same. A key change will lead to an increase in assistants - Overflow fixes. Currently the code block to do early assignments to the Overflow role doesn't work - or works but not as you'd expect. The idea was is that because enabling the Overflow role in the prefs menu is an On/Off toggle that sets the job to High priority when enabled and prevents any other High priority pref, players that have the Overflow role enabled will **always** get it. It's their highest priority job with infinite slots. So we do a pass right at the start to give everyone with the Overflow role enabled that role and save us wasting time later on in random job code giving them that same role but with more work. The problem is the code for this only assigns the Overflow role to people with it set to Low priority in their prefs, resulting in log readouts like: ``` [2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1 [2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority [2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority [2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0 ``` Where nobody gets pre-assigned the overflow role because their prefs are all set to the High priority from being toggled... Except wait a second, some people have it at Medium priority when it should just be a No Role/High Priority Role toggle? And herein we meet a problem. My hypothesis is that traits and stuff that change the overflow have allowed players to set the "ordinary" overflow role of Assistant to Medium and/or Low priority. This still shows as enabled in the prefs menu, but leads to an outcome where a player with assistant enabled is assigned Cook instead. ``` [2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1 [2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority ... [2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority ... [2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0 ``` So players with the Overflow job pref set to Low (an unexpected state, should be disabled or High) would be guaranteed to get that role if none of the higher priority Head of Staff/AI/Dynamic roles took over via the bugged "force overflow for people with the pref enabled" proc. Players with the Overflow job pref set to High would be guaranteed to get that role if none of the higher priority Head of Staff/AI/Dynamic roles took over via the random job assignment code giving them their Highest priority role thanks to the infinite job slots of the Overflow. And players with the Overflow job pref set to Medium (an unexpected state, should be disabled or High) would get Assistant if the shuffle step of the available jobs list put Assisstant before any of the other jobs they had prefs enabled for at Medium that weren't already filled, otherwise they'd get another random job. This code is now changed to ignore the priority the player has set when looking for people to fill the overflow role. As long as it **is** enabled, the player will get it unless they're forced into a dynamic ruleset role (AI when malf rolls) or a Head of Staff role due to their other prefs (they have RD set to med or low, and no other player has a Head of Staff at high so they get randomly picked and miss the overflow role). This will increase the number of assistants in shifts where their pref state has Assisstant in the bugged Medium priority, but doesn't change it for bugged Low and not-bugged High/On priority. On the other side of the coin, we have how the random jobs are picked. They're kinda not random, and I noticed this reading the logs then reading the code. The list of available jobs to pick from is randomly shuffled - but only **once**. All players pull from a list of jobs in the same order. So you end up with a log block like this: ``` [2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist [2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0 [2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2 [2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist [2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0 [2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2 [2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2 [2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2 [2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook [2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0 [2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1 [2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz [2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1 ``` The list is shuffled into an order of something like `list("Scientist", "Botanist", "Cook", "Sec Officer", ...)` then iterated over for each player. So every random job selection goes: > "Does Player1 have Scientist enabled and at the right priority? No? Okay, Botanist? Yes? You get botanist." > "Does Player2 have Scientist enabled and at the right priority? No? Okay, Botanist? Yes? You get botanist." > "Does Player3 have Scientist enabled and at the right priority? No? Okay, Botanist has no slots left so we'll remove it from the list. Okay, Cook? Yes? You get cook." > "Does Player4 have Scientist enabled and at the right priority? No? Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec Officer? ..." This can lead to stacked individual departments if it gets randomly rolled to the start of the list in the shuffle, and completely empty departments if they end up at the end. On high pop shifts this is probably less of an issue. Player prefs add noise to this and as departments at the front fill up, those at the back pick up some of the lower pref players. But have you ever had a shift where there's just like... No fucking sec even though there's tons of players? The logging (before I made changes in this PR) was a bit ass, but my hypothesis there is that sec officer was shuffled right at the end of the random job list, so every other department was filled up before sec officers were picked. To mitigate this, I made the list shuffle every single time the game picks a random available job for the player. This should lead to a more balanced selection of available jobs by avoiding situations where the code is biased towards packing some departments by accident. ## Why It's Good For The Game Overflow fixes mean people who go to their prefs and see the Overflow Role is On will all have the same experience - They will be the Overflow role. More random random job selection should prevent individual departments having a jobs be stacked when it would have otherwise been possible for a more balanced selection but the code unintentially biased random departments to be overstaffed and understaffed each shift. ## Changelog 🆑 fix: Having the Overflow Role set to On will properly ensure you get that role at a High priority as intended by the game code. fix: Job selection is now a little bit more random. Fixes an unintentional bias in random job assignment that could lead to feast-or-famine for roles where everyone is assigned one job and nobody is assigned another job. /🆑 |
||
|
John WillardandGitHub
|
1880003270 |
Reworks silicon/ai access checking & fixes some ui_act's (#84964)
## About The Pull Request Currently to check for Silicon access, we do: ``if is silicon or is admin ghost or has unlimited silicon privileges or has machine remote in hand`` What has unlimited silicon privileges? Bots, Drones, and admin ghosts. To check for AI access, it just checks for AI instead of silicon, and doesnt check for unlimited silicon privileges. This was kinda silly, so I thought I should make this a little easier to understand. Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or ``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost, since now instead of being a var on the client, we moved it to using the same trait but giving it to the client instead, but since we have to keep parity with previous functionality (admins can spawn in and not have this on, it only works while as a ghost), I kept previous checks as well. No more type checks, removes a silly var on the mob level and another on the client. Now while I was doing this, I found a lot of tgui's ``ui_act`` still uses ``usr`` and the wrong args, so I fixed those wherever I saw them, and used a mass replace for the args. Other changes: - machinery's ``ui_act`` from https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin ghosts no longer get kicked off things not on cameras. This was my fault, I overlooked this when adding Human AI. - Human AI's wand gives AI control as long as it's in your hand, you can swap to your offhand. I hope this doesn't end up going horribly, otherwise I'll revert this part. It should let human AIs not have their UI closed on them when swapping to eat food or use their door wand or whatnot. - Bots previously had special checks to scan reagents and be unobservant, I replaced this with giving them the trait. I also fixed an instance of unobservant not being used, so now statues don't affect the basic creature, whatever that is. ## Why It's Good For The Game This is an easier to understand way of handling silicon access and makes these mobs more consistent between eachother. Other than what I've mentioned above, this should have no impact on gameplay itself. ## Changelog 🆑 fix: Statues don't count as eyes to creatures. fix: Human AIs and Admin ghosts no longer get kicked off of machines that aren't on cameranets. /🆑 |
||
|
Kyle Spier-SwensonandGitHub
|
4d1639b04c |
Revert "Assorted changes to job assignment code and logging." (#85929)
Reverts tgstation/tgstation#85308  |
||
|
|
1eef540054 |
Assorted changes to job assignment code and logging. (#85308)
## About The Pull Request
This PR does a couple of minor things:
Makes the job debug logging a bit easier to follow.
Minorly brings some SSjob code up to code standards, converting proc
names to snake_case and doing some otherm is cleanup.
Refactored some stuff into different procs, updated some comments.
And some major things:
Changes the job assignment logic.
Old behaviour
> Assign dynamic priority roles
> Force one Head of Staff (if possible)
> Assign all AIs
> Assign overflow roles (bugged in 2 ways)
> Shuffle the available jobs list once, at the start of the random job
assignment loop
> Pick and assign random jobs for random players from High prefs down,
with a priority on Head of Staff roles
> Handle everyone that couldn't be assigned a random job
New behaviour
> Assign dynamic priority roles
> Assign all Head of Staff roles to players with High prefs
> If no Head of Staff was made in the above way, force one Head of Staff
(if possible)
> Assign all AIs
> Assign overflow roles (fixed)
> Prioritise and fill unfilled head roles at each job priority pref
level, from High prefs down.
> Build a list of all jobs that each unassigned player could be eligible
for at the above pref level.
> Pick a job from that list at random and assign it to the player.
> Handle everyone that couldn't be assigned a random job.
In reality there should be little impact on overall job assignment, the
code changes read more as semantics. For example, the priority check for
filling Head slots will have the same candidate pool in both old and new
versions, but in the new version we're more clearly saying that Heads
are important and we want to prioritise filling them for the sake of
round progression even though the outcome in new and old is the same.
A key change will lead to an increase in assistants - Overflow fixes.
Currently the code block to do early assignments to the Overflow role
doesn't work - or works but not as you'd expect. The idea was is that
because enabling the Overflow role in the prefs menu is an On/Off toggle
that sets the job to High priority when enabled and prevents any other
High priority pref, players that have the Overflow role enabled will
**always** get it. It's their highest priority job with infinite slots.
So we do a pass right at the start to give everyone with the Overflow
role enabled that role and save us wasting time later on in random job
code giving them that same role but with more work.
The problem is the code for this only assigns the Overflow role to
people with it set to Low priority in their prefs, resulting in log
readouts like:
```
[2024-07-27 09:49:43.469] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:43.469] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Radioprague, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.472] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caluan, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Caractaser, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.473] DEBUG-JOB: FOC player job enabled at wrong level, Player: Apsua, TheirLevel: High Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
[2024-07-27 09:49:43.475] DEBUG-JOB: AC1, Candidates: 0
```
Where nobody gets pre-assigned the overflow role because their prefs are
all set to the High priority from being toggled... Except wait a second,
some people have it at Medium priority when it should just be a No
Role/High Priority Role toggle?
And herein we meet a problem. My hypothesis is that traits and stuff
that change the overflow have allowed players to set the "ordinary"
overflow role of Assistant to Medium and/or Low priority.
This still shows as enabled in the prefs menu, but leads to an outcome
where a player with assistant enabled is assigned Cook instead.
```
[2024-07-27 09:49:47.775] DEBUG-JOB: DO, Running Overflow Check 1
[2024-07-27 09:49:47.775] DEBUG-JOB: Running FOC, Job: /datum/job/assistant, Level: Low Priority
...
[2024-07-27 09:49:43.475] DEBUG-JOB: FOC player job enabled at wrong level, Player: Bebrus2, TheirLevel: Medium Priority, ReqLevel: Low Priority
...
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
```
So players with the Overflow job pref set to Low (an unexpected state,
should be disabled or High) would be guaranteed to get that role if none
of the higher priority Head of Staff/AI/Dynamic roles took over via the
bugged "force overflow for people with the pref enabled" proc.
Players with the Overflow job pref set to High would be guaranteed to
get that role if none of the higher priority Head of Staff/AI/Dynamic
roles took over via the random job assignment code giving them their
Highest priority role thanks to the infinite job slots of the Overflow.
And players with the Overflow job pref set to Medium (an unexpected
state, should be disabled or High) would get Assistant if the shuffle
step of the available jobs list put Assisstant before any of the other
jobs they had prefs enabled for at Medium that weren't already filled,
otherwise they'd get another random job.
This code is now changed to ignore the priority the player has set when
looking for people to fill the overflow role. As long as it **is**
enabled, the player will get it unless they're forced into a dynamic
ruleset role (AI when malf rolls) or a Head of Staff role due to their
other prefs (they have RD set to med or low, and no other player has a
Head of Staff at high so they get randomly picked and miss the overflow
role).
This will increase the number of assistants in shifts where their pref
state has Assisstant in the bugged Medium priority, but doesn't change
it for bugged Low and not-bugged High/On priority.
On the other side of the coin, we have how the random jobs are picked.
They're kinda not random, and I noticed this reading the logs then
reading the code.
The list of available jobs to pick from is randomly shuffled - but only
**once**. All players pull from a list of jobs in the same order. So you
end up with a log block like this:
```
[2024-07-27 09:49:47.985] DEBUG-JOB: DO pass, Player: Pierow, Level:3, Job:Botanist
[2024-07-27 09:49:47.985] DEBUG-JOB: Running AR, Player: Pierow, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.985] DEBUG-JOB: Player: Pierow is now Rank: Botanist, JCP:0, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: DO pass, Player: Daddos, Level:3, Job:Botanist
[2024-07-27 09:49:47.986] DEBUG-JOB: Running AR, Player: Daddos, Job: /datum/job/botanist, LateJoin: 0
[2024-07-27 09:49:47.986] DEBUG-JOB: Player: Daddos is now Rank: Botanist, JCP:1, JPL:2
[2024-07-27 09:49:47.986] DEBUG-JOB: FOC job filled and not overflow, Player: Bebrus2, Job: /datum/job/botanist, Current: 2, Limit: 2
[2024-07-27 09:49:47.987] DEBUG-JOB: FOC player job not enabled, Player: Bebrus2
[2024-07-27 09:49:47.987] DEBUG-JOB: DO pass, Player: Bebrus2, Level:3, Job:Cook
[2024-07-27 09:49:47.987] DEBUG-JOB: Running AR, Player: Bebrus2, Job: /datum/job/cook, LateJoin: 0
[2024-07-27 09:49:47.988] DEBUG-JOB: Player: Bebrus2 is now Rank: Cook, JCP:0, JPL:1
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC player job not enabled, Player: Redwizz
[2024-07-27 09:49:47.988] DEBUG-JOB: FOC job filled and not overflow, Player: Redwizz, Job: /datum/job/cook, Current: 1, Limit: 1
```
The list is shuffled into an order of something like `list("Scientist",
"Botanist", "Cook", "Sec Officer", ...)` then iterated over for each
player. So every random job selection goes:
> "Does Player1 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player2 have Scientist enabled and at the right priority? No?
Okay, Botanist? Yes? You get botanist."
> "Does Player3 have Scientist enabled and at the right priority? No?
Okay, Botanist has no slots left so we'll remove it from the list. Okay,
Cook? Yes? You get cook."
> "Does Player4 have Scientist enabled and at the right priority? No?
Okay, Cook has no slots left so we'll remove it from the list. Okay, Sec
Officer? ..."
This can lead to stacked individual departments if it gets randomly
rolled to the start of the list in the shuffle, and completely empty
departments if they end up at the end.
On high pop shifts this is probably less of an issue. Player prefs add
noise to this and as departments at the front fill up, those at the back
pick up some of the lower pref players.
But have you ever had a shift where there's just like... No fucking sec
even though there's tons of players? The logging (before I made changes
in this PR) was a bit ass, but my hypothesis there is that sec officer
was shuffled right at the end of the random job list, so every other
department was filled up before sec officers were picked.
To mitigate this, I made the list shuffle every single time the game
picks a random available job for the player. This should lead to a more
balanced selection of available jobs by avoiding situations where the
code is biased towards packing some departments by accident.
## Why It's Good For The Game
Overflow fixes mean people who go to their prefs and see the Overflow
Role is On will all have the same experience - They will be the Overflow
role.
More random random job selection should prevent individual departments
having a jobs be stacked when it would have otherwise been possible for
a more balanced selection but the code unintentially biased random
departments to be overstaffed and understaffed each shift.
## Changelog
🆑
fix: Having the Overflow Role set to On will properly ensure you get
that role at a High priority as intended by the game code.
fix: Job selection is now a little bit more random. Fixes an
unintentional bias in random job assignment that could lead to
feast-or-famine for roles where everyone is assigned one job and nobody
is assigned another job.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
|
||
|
RhialsandGitHub
|
1ca7a03a00 |
Lazy load templates now have a prompt for whether or not to send you to the template area upon loading (#82902)
## About The Pull Request Generating a lazy load template map now gives you a choice for whether or not you want to be ghosted/teleported to the template you are loading. ## Why It's Good For The Game This has always annoyed me, especially when testing stuff related to the nukie base (since it needs to be manually loaded before creating a nukie team to avoid runtime spam). It might be a minor gripe, but I don't think it should be forced. ## Changelog 🆑 Rhials admin: Lazy loading map templates now gives you the option to not ghost/teleport to the loaded area upon completion. /🆑 |
||
|
chelandGitHub
|
fa28207f6b |
Fixes a minor spelling mistake on the admin panel/verb list (#82747)
## About The Pull Request Corrects `inisimin` to `invisimin`. This addresses #82728, but only fixes one of the two issues mentioned ## Why It's Good For The Game -1 spelling mistake ## Changelog 🆑 spellcheck: 'inisimin' verb corrected to 'invisimin' /🆑 |
||
|
ZephyrandGitHub
|
7f8752be14 | Admin Verb Datums MkIII | Now with functional command bar (#82511) | ||
|
MrMelbertandGitHub
|
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. |
||
|
LemonInTheDarkandGitHub
|
0a496f180c |
Refactors fancy type generation (#81259)
## About The Pull Request [Refactors fancy type generation](https://github.com/tgstation/tgstation/commit/3f218ac7b714a87477d3bd96425df709c6e7fa27) Ok so we have this proc that generates concatenated names for types so admins have a nice list to sort through. The trouble is this is done by, for each type, iterating all possible replacements, and seeing which ones apply (with expensive string operations) A clean run of this applied to all datums takes about 3.5 seconds on my pc. This sucks. Ok so can we do better. Well, yes, pretty easily. Rather then, for each potential type, iterating all the options, let's build a zebra typecache (a lookup list of type -> string to use), and use that. Then we can use a list of replacement -> the bit to tear out to figure out what to remove. This works quite well. It does mean that we're doing it based off the type tree and not type paths, so if we didn't have a replacement for like, mob, it'd look weird, but we don't have cases like that so it's fine. Or well we sorta did, didn't have anything for atom movables or areas, but I fixed that so sall good. Anyway, we only need to do this work once. It takes about 0.3 seconds on my machine, so we can cache it. Just this on its own would technically slow init, since we have a some code that's running this proc off static, but we can just not, that's fine (technically saves init time too since we don't have to burn 0.1 seconds on it anymore). This brings the cost of generating this list for all datums from 3 seconds to 0.16, assuming we have the static pre generated. We could in theory pre-generate just like, all the strings? But I don't think the cached cost is high enough for that to be a real problem. IDK open to other thoughts Oh also I had to reorder the strings in that list, cause zebra_typecacheof has reverse priority. s life [Updates stat tracking macro to work at world start](https://github.com/tgstation/tgstation/commit/1fbfb701a16e6df7170ee642bef66b16652281d3) It for some reason doesn't actually get anything this early, but now at least the logging would in theory function ## Why It's Good For The Game Better response times for admins, faster code, more better |
||
|
ArcaneMusicandGitHub
|
006b61f08b |
Adds a Debug command to stop all weather. (#80848)
Atomizing out of #78524 as a result of that PR being too big and this was quite easy to do. ## About The Pull Request This adds a debug (admin) command that allows you to stop all weather effects that are going on across the map in a given instance. This is useful for when you are testing something on lavaland and need the storm to stop, or if you otherwise had some other kind of weather effect interfering with testing something. It's worth noting this directly calls end() on the active weather effect, meaning that for more complicated weather that may have different side effects, it may need some extra finess, but as of current writing no weather does anything interesting in their wind_down() procs. ## Why It's Good For The Game God weather is so annoying while testing lavaland, plus this is just straight admin and testing tooling so there's no harm. ## Changelog 🆑 admin: Added a new admin verb that ends all active weather within the weather subsystem. /🆑 |
||
|
Yaroslav NurkovandGitHub
|
98f489a33d |
Map export admin verb/buildmode (#80326)
## About The Pull Request The base for the PR was taken from https://github.com/shiptest-ss13/Shiptest/pull/206 and thank them for that. The point of this verb is to save pieces of the map to your computer for further use. It's not that necessary, but rarely, it can be useful. [Video](https://i.imgur.com/M6mdDTC.mp4) ## Why It's Good For The Game Transferring buildings from one round to another, preserving the decor made in the game. ## Changelog 🆑 Vishenka0704 admin: The ability to export a part(or z-level) of the map has been added. /🆑 |
||
|
san7890andGitHub
|
b0be5d4c8a |
Reworks invisimin variable to a trait (#80121)
## About The Pull Request This was a variable that existed on the `/mob` level despite only ever being altered in one place. Perfect to just make a trait since it's all managed in one spot anyways (and no other code is really reliant on this flag being flipped, it's just for the code to know to add/remove invisimin status). I also tweaked some messages so they could be more consistent, lmk if that should be changed ## Why It's Good For The Game Less not-useful stuff to scroll through in View Variables, better scoping of a variable to an intended location. ## Changelog Not necessary |
||
|
TimberpoesandGitHub
|
835ca92007 |
Moves the new "Turn Target into MMI" verb into a VV dropdown option and rewrites the code around it. (#80097)
## About The Pull Request Removes the Turn Target into MMI verb and re-adds it as a VV dropdown option. Rewrites the code around this to support what is effectively an admin-forced action, which MMI code previously didn't support cleanly. ## Why It's Good For The Game #79896 added a new debug verb, unfortunately because of how that debug verb was defined (it has args for a target mob in the proc params) it automatically gets added to the right click context menu instead...  Which is not ideal for admins as they're one misclick away from just deleting a mob. This moves it to the VV dropdown menu for humans and rewrites the code behind it, which previously relied on the MMI attackby proc which expects a user and thus has side effects as a result. This new code is more suited to an admin force-insertion than the old code which removed the brain and forced the now brainless mob to insert its former brain into the MMI (with the potential to fail on user input for the now brainless mob).  ## Changelog 🆑 admin: Removed the "Turn Target into MMI" right click context menu verb entirely, and instead added the same command as a VV dropdown on human mobs. /🆑 |
||
|
MothblocksandGitHub
|
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 |
||
|
|
f187c5229d |
Fix bug where MMI's cannot open doors (#79896)
## About The Pull Request While #69556 did fix it for posi brains. it did not account for MMI's meaning only posi brains got fixed as a bonus, im throwing in a shitty debug command because MMI's put all there logic in attackby ## Why It's Good For The Game bugs bad ## Changelog 🆑 admin: A new debug verb to turn yourself into an MMI(almost the funniest thing) fix: MMI's inside mechs can now properly open doors like there posibrain counterparts /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
MrMelbertandGitHub
|
566c7ba9c2 |
Removes some code soul (IF YOU ARE COPY PASTING THIS...), replaces it with a macro (#79935)
## About The Pull Request
Replaces all instances of `SSblackbox.record_feedback\("tally",
"admin_verb", 1, (.+)\)` with `BLACKBOX_LOG_ADMIN_VERB($1)`
This makes so the funny comment isn't necessary.
It also reveals one location which someone did not heed the comment, the
`debug_controller` proc copy+pasted the line but did not change the
fourth argument. PEOPLE DON'T READ!
|
||
|
TwistedCicrularConvexLensandGitHub
|
c228b95a78 |
Fixes Invisimin to not show up on HUDs (#79605)
## About The Pull Request Adds _**2 lines of code**_ that enables and disables being able to be spotted with sec/med huds. ## Why It's Good For The Game Fixes https://github.com/tgstation/tgstation/issues/72198 and https://github.com/tgstation/tgstation/issues/36709 since they're the same issue. This has been around for almost a year now which suggets that maybe this verb wasn't being used much anyways. But fixes are fixes and fixed code is healthy code. ## Changelog 🆑 TwistedSilicon fix: invisimin verb now makes you invisible to all HUDs too! No more floating healthbars or job identifiers giving you away while you sneak around. /🆑 <details> <summary>Before</summary> https://github.com/tgstation/tgstation/assets/106436013/02b7999b-ae7b-4f79-bd0e-d353d0026db2 </details> <details> <summary>After</summary> ### MedHuds https://github.com/tgstation/tgstation/assets/106436013/0845c623-8ea1-4c95-825b-008d0be1a428 ### SecHuds https://github.com/tgstation/tgstation/assets/106436013/8af5cd9d-ad6a-4758-8efd-1cce9ca7a643 </details> No more of this:  (So for the love of GOD do not invismin next to a chasm or SM shard, since not even you know where you are anymore.) |
||
|
MrMelbertandGitHub
|
8d69710d52 |
Fix admins without R_POLL getting (an unusable) poll verb (#79461)
## About The Pull Request Copy paste error, I assume. `admin_verbs_poll` only contains `/client/proc/poll_panel` which requires `R_POLL` to use. ## Changelog 🆑 Melbert admin: Admins without `R_POLL` no longer have access to "Server Poll Management", not that they could have used it anyways. /🆑 |
||
|
Emmett GainesandGitHub
|
96d7e9c690 |
Invisibility refactor (#78908)
This adds a tracker for sources of invisibility and a priority system. I needed this for another thing so I'm doing this first since it touches a lot of code. As for the bugs fixed in the changelog, it's only what I noticed while going through everything and there's likely a few more things fixed with this. This should be testmerged for a while, I'll bring this out of draft when it feels safe. 🆑 admin: Invisimin can now be used on mobs that are already invisible, whether through temporary or permanent effects. fix: Monkeyize/Humanize mob transformations no longer permanently reveal invisible mobs if they had effects making them invisible otherwise. fix: Objects with the undertile element that have been made invisible through other means are no longer revealed by being uncovered. /🆑 |
||
|
|
7626c3bd6c |
Tram v6/Transport Subsystem (#78230)
Co-authored-by: Unit0016 <50649185+unit0016@users.noreply.github.com> Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: Kylerace <kylerlumpkin1@gmail.com> |
||
|
Emmett GainesandGitHub
|
4be51f846d |
Pipe gas visuals (#78217)
## About The Pull Request Primarily this pr is all about getting pipes to have a visual display for the gas within them. A couple other things of note have been done to make that easier though: - A sprite generator that outputs to a dmi has been made for all pipe variants and the layers. This is because I didn't want to work with hundreds of pipe sprites just to do minor changes. In the future I would like to generate things like this during a github action but for the moment this is just a helper you can use for generating the pipe dmi files. - Some minor reorganization of the code in the pipe dm file. - Some doc comments on things that bothered me ## Why It's Good For The Game Gives a bit of visual feedback when working with pipes that should hopefully make people more comfortable around them if they can easily see if the pipes are empty or are filled with an unknown gas mixture. Can also serve as a warning to those keeping an eye out for things like plasma floods. 🆑 ninjanomnom add: Pipes now have a colored visual display that shows their contents at a glance. /🆑 ~~The colors for gases could stand to be better, if anyone wants to suggest alternatives to what I've used please do as I put only a bare minimum of thought into each choice.~~ I've switched to using the gas colors defined in tgui constants.  |
||
|
JacquerelandGitHub
|
3ed187e86b |
Basic Mob Flesh Worm (#78744)
## About The Pull Request Fixes #68614 Converts the Flesh Worm (Armsy) into a Basic Mob. Most of its behaviour has been moved into a component which we can use to make arbitrary mobs into linked lists of mobs. To accomplish this I added a signal which is sent when you call any `adjustXLoss` proc, let me know if my implementation is "calling the same signal from several places" by a backdoor, I wanted to avoid registering to 6 signals but I'll change it if I must. While I was here I killed the unused "lesser" variant because we stopped using it. Resultingly, Ascended Armsy doesn't need to distinguish itself by inflating the sprite, so it doesn't. This means that now flesh worms are using their sprites as intended to be displayed, but if people really miss all of its segments being poorly scaled by the byond engine then I guess I can restore it. ## Why It's Good For The Game  ## Changelog 🆑 refactor: Flesh Worms are now basic mobs. Please report any unexpected behaviour. sprite: Flesh Worms are a little bit slimmer. /🆑 |
||
|
JacquerelandGitHub
|
7d7f55ee53 |
Heretic Ascension Tweaks (#78472)
## About The Pull Request Some changes to Cosmic and Knock heretic ascensions, in response to feedback. - Cosmic Heretics can no longer control their summon while jaunted. - Additionally the death link element the Star Gazer used... wouldn't work if there was more than one cosmic heretic. I refactored it into a component, so that it would. Frankly there are probably a lot of _other_ abilities which shouldn't be usable while jaunted but are, but I have been burned in the past by adding defaults which were applied too widely so we'll leave it case-by-case for now. - The Knock rift can no longer summon Flesh Worms of any kind. - But it _can_ summon fire sharks (we really need to reflavour these...) and any future "basic mob" heretic mobs (or ones which are converted). - Additionally the rift can't be clicked by ghosts while it's polling ghosts automatically because that would create funky empty-minded mobs. - Finally it goes away when the heretic dies. ## Why It's Good For The Game For Cosmic Heretics, controlling the Star Gazer in conjunction with Space Jaunt essentially meant that the heretic was playing an RTS as an invincible observer with an invulnerable unit, now they have to actually be present and killable in order to sic The Beast on you. For Knock Heretics, Minor Flesh Worms are a proof of concept which was never meant to be used except by admins. They're _barely_ weaker than a normal flesh worm, extraordinarily tanky, delete walls, and generally devalue the Flesh path ascension. Vanishing upon heretic death is because every _other_ ascension is at least theoretically stoppable except this one. Now this one is too. It's still _very hard_ to kill the heretic because every _10 seconds_ they can transform into a heretic mob which acts as an extra health pool. ## Changelog 🆑 fix: If two cosmic heretics ascend in the same round, their star gazer survival will be linked to each individual heretic and not shared by just one of them. fix: You can't click the Knock heretic portal to join as a mob while already signed up to become a mob. balance: Cosmic heretics can't order the Star Gazer around while jaunting. balance: The Knock Heretic portal cannot summon Flesh Worms, but can summon Fire Sharks. balance: The Knock Heretic portal will disperse if its creator is killed. /🆑 |
||
|
JacquerelandGitHub
|
f5aa244939 |
Adds add/remove mob ability to VV dropdown menu (#78652)
## About The Pull Request You add spells to mobs via a dropdown in VV but mob abilities via marking the mob and pressing a button in the admin status panel. I like opening the VV menu more than I like marking mobs (I am usually going to need to open it anyway) so I added an alternate route in the VV dropdown. ## Why It's Good For The Game It's better for my personal workflow. ## Changelog 🆑 admin: Mob abilities can be granted to arbitrary mobs via the VV menu in a similar way to spells. /🆑 |
||
|
JacquerelandGitHub
|
ad81ca6f4c |
Allows admins to overrule God (#78429)
## About The Pull Request Adds a "manage religious sect" verb to the "game" menu of the admin panel. It can be used to assign the chaplain's sect if they haven't picked one yet, or reassign it (to a different one, or to nothing) if they already have. This is likely mostly going to be used for ahelps where someone misclicks or suddenly logs off and wants to be replaced by a different chaplain with different ideas. ## Why It's Good For The Game Admins asked me to make it ## Changelog 🆑 admin: Admins can now reset or modify the chaplain's sect from a UI panel /🆑 |
||
|
|
1b96345e44 |
Multi-Z Support for Lazy Templates | Cleans up some turf flag misuse (#77786)
## About The Pull Request Adds multi-z support for lazy templates Also fixes some improper use and placement for turf flags ## Why It's Good For The Game Shadow needs/wants this for bit runner maps. Turf flags are also why lava has been generating in places it shouldnt. (inside of ruins) ## Changelog 🆑 fix: Lava can no longer occasionally generate inside of previously loaded templates and breach and/or destroy shit /🆑 --------- Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com> Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> |
||
|
MrMelbertandGitHub
|
26a0e3cb79 |
Don't do eligibility checks for debug spawn crew (#76374)
## About The Pull Request Fixes #76372 Just Don't do eligibility checks for assigning the roles to the debug crew. ## Changelog 🆑 Melbert fix: Fix Debug verb "Spawn full crew" /🆑 |
||
|
|
8788e48378 |
Shuttle events (#76008)
## About The Pull Request https://github.com/tgstation/tgstation/assets/7501474/a2d83ce8-eba1-42d9-a1f8-9d73f7c40b21 Adds shuttle events! Stuff can now start to happen outside the shuttle, either benign or spicy (but usually just fun to watch)! ## Why It's Good For The Game The shuttle escape sequence is an important part of the game, uniting about every player surviving player. Recently, #71906 has made the escape sequence more forgiving as well as more interesting by conditionally doubling the playing field. The area outside the shuttle is still mostly empty though, except for the few people being spaced, daredevils and the occasional epic space fight. This PR adds adds some space events to spice up the outside of the shuttle! This both gives people something too look at, making the escape sequence feel less static and more lively, as well as give people a reason to go outside and get the full experience of ~being decapitated by a meteor~ swimming with the fishes! <details> <summary>Shuttle Events</summary> **Friendly carp swarm** Spawns a group of carp that flies past the shuttle, completely friendly unless provoked. **Friendly meteors** Spawns a lot of strong meteors, but they all miss the shuttle. Completely safe as long as you don't go EVA **Maintenance debris** Picks random stuff from the maintenance spawn pool and throws it at the shuttle. Completely benign, unless you get hit in the head by a toolbox. Could get you some cool stuff though! **Dust storm** Spawns a bunch of dust meteors. Has a rare chance to hit the shuttle, doing minimal damage but can damage windows and might need inflight maintenance **Alien queen** One in every 250 escapes. Spawns a player controlled alien queen and a ripley mech. RIP AND TEAR!! Really not that dangerous when you realize the entire crew is on the shuttle and the queen is fat as fuck, but can still be fun to throw people around a bit before being torn to shreds. **ANGRY CARP** Once in every 500 escapes. Spawns 12 normal carp and 3 big carps, who may just decide to go through the shuttle or try and bust through the window if you look at them wrong. Somewhat dangerous, you could stay away from the windows and try to hide, or more likely shoot at them and weld the windows **Fake TTV** Lol **Italian Storm** Once in every 2000 rounds. Throws pasta, pizza and meatballs at the shuttle. Definitely not me going off the rails with a testing event **Player controlled carp trio** Once in every 100 escapes. Spawns three player controlled carp to harass the shuttle. May rarely be a magicarp, megacarp or chaos carp. I can't honestly see them do anything other than be annoying for 3 seconds and die There are some other admin only ones: a group of passive carps going directly through the shuttle and just being little shits, and a magic carp swarm </details> Events are selected seperately, there isn't a crazy weighting system, each just has a chance to run, and multiple could run at once. They also don't immediately trigger, so people can get settled a bit, and to make sure just waiting out the more dangerous ones is still a valid strategy. ## Changelog 🆑 add: Adds shuttle events! If shuttle escapes weren't exciting before (doubtful), they definitely are now! I'm joking it's mostly an atmosphere thing. admin: Adds an admin panel to interact with shuttle events, under the Events tab: Change Shuttle Events fix: Objects spawned in hyperspace will properly catch hyperspace drift /🆑 There's a few things I'd like to do later (another PR) (honestly anyone can do them because I suck at follow-ups), because this is too big as is: - Hijack triggered shuttle events - More events (got a lot of cool suggestions, but I'm putting most of them on hold) - Maybe stration announcements if some more dangerous ones get added - Structures appearing next to the escape shuttle??? --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
ZephyrandGitHub
|
89f5992a4c |
Player Ticket History - A Synopsis At A Glance (#75830)
## About The Pull Request Adds a new front-end for viewing player ticket history stored in the connected database. Also adds a button to directly query for previous tickets from the ticket panel. ## Pictures     ## Why It's Good For The Game Gives admins the ability to look at a players behaviour in-game without the need for external tooling, (statbus) ## Changelog 🆑 admin: Player Ticket History - view a player's ticket history without the need to use external tooling. /🆑 |
||
|
LemonInTheDarkandGitHub
|
57ef596898 |
Admin Library Moderation (in-game edition) (#75645)
For the longest time, the only way admins could moderate the library was by using statbus's external tool. But a few months back statbus went down, and ever since then they've been sitting lost. Shit sucks. The whole external thing has been bugging me for a while, so let's fix all that yeah? This pr adds a new verb to the admin tab that allows admins to ban/restore books from the library. It includes expanded (ckey) search, faster response times, in tool book viewing with and without markdown rendering, and viewing of deleted books. This is accomplished with a special subtype of library consoles, stored on the admin datum. It shouldn't let you do anything without +BAN, rip my live debugging or whatever. I've also hooked into (and fixed) Ned's existing library actions log, and added viewing support to the ban/restore pages. This logs banning admin, ban time, ban reason, etc. As a part of this, I've fixed/expanded on the existing UIs. I've added ID search to all existing consoles, and fixed an existing bug with the visitor console not supporting category search (shows how many people actually use the thing) Changes to the library_action table were pretty minor. The ckey column was too small, so longer keys just caused it to fail on ban. Bad. That and the ip address column was signed, which wasted space and was non standard with other tables. |
||
|
|
c6205dd063 |
Adds a new front end for viewing logs | fixes the manifest log message too (#75617)
## About The Pull Request   ## Why It's Good For The Game I promised I would add it; and while it's not as nice as my previous iteration it is faster and more streamlined. ## Changelog 🆑 admin: new log viewer, try it out. (View Round Logs) /🆑 Fixes #75605 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
|
569d8f5a72 |
Refactored the TTS subsystem to more properly handle message garbling. Added a volume preference for TTS. (#75559)
TTS subsystem refactor. --------- Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com> Co-authored-by: Iamgoofball <iamgoofball@gmail.com> Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com> |
||
|
ZandarioandGitHub
|
77db52dc6b |
Corrects record_feedback()'s copy/paste comment (#74962)
## About The Pull Request
Corrects `record_feedback()`'s copy/paste comment.
## Pointless history
Originally being added in
|
||
|
MrMelbertandGitHub
|
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. |
||
|
ZephyrandGitHub
|
5122fb07cb |
Refactor SPELL_REQUIRES_OFF_CENTCOM to SPELL_REQUIRES_STATION (#73348)
When I refactored stuff to use lazy templates it broke a few needed checks, this is one of those checks. Although there is no reason this shouldn't have been checking for station level over not CC |