## About The Pull Request
Extends the part of the crafting unit test that ensures consistency
between the total mats of the components of a recipe (or rather, the
result of said recipe) and a generic instance of the same type as its
result, previously only implemented on food recipes.
## Why It's Good For The Game
This ensures a degree of consistency with the material composition of
various objects in the game. I couldn't do it in the original PR as that
one was too big already and it took months to get it merged, and have
the relative bugs fixed.
Currently a WIP as I slowly deal with the unit test reports.
## Changelog
🆑
refactor: Follow-up to the crafting/material refactor from months ago.
All objects crafted with stacks now inherit their mat composition (not
necessarily the effects and color) by default, while previously only a
few things like chair, sinks and toilets did. Report any object looking
or behaving weirdly as a result.
fix: The material composition of ammo boxes is no longer a 1/10 of what
it's supposed to be. It was a shitty hack to make it harder to recycle
empty ammo boxes. Instead, they lose materials as they're emptied now.
/🆑
## About The Pull Request
It's just a partial cleanup of
anti-[STYLE](https://github.com/tgstation/tgstation/blob/master/.github/guides/STYLE.md)
code from /tg/'s ancient history. I compiled & tested with my helpful
assistant and damage is still working.
<img width="1920" height="1040" alt="image"
src="https://github.com/user-attachments/assets/26dabc17-088f-4008-b299-3ff4c27142c3"
/>
I'll upload the .cs script I used to do it shortly.
## Why It's Good For The Game
Just minor code cleanup.
Script used is located at https://metek.tech/camelTo-Snake.7z
EDIT 11/23/25: Updated the script to use multithreading and sequential
scan so it works a hell of a lot faster
```
/*
//
Copyright 2025 Joshua 'Joan Metekillot' Kidder
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
//
*/
using System.Text.RegularExpressions;
class Program
{
static async Task Main(string[] args)
{
var readFile = new FileStreamOptions
{
Access = FileAccess.Read,
Share = FileShare.ReadWrite,
Options = FileOptions.Asynchronous | FileOptions.SequentialScan
};
FileStreamOptions writeFile = new FileStreamOptions
{
Share = FileShare.ReadWrite,
Access = FileAccess.ReadWrite,
Mode = FileMode.Truncate,
Options = FileOptions.Asynchronous
};
RegexOptions regexOptions = RegexOptions.Multiline | RegexOptions.Compiled;
Dictionary<string, int> changedProcs = new();
string regexPattern = @"(?<=\P{L})([a-z]+)([A-Z]{1,2}[a-z]+)*(Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss)([A-Z]{1,2}[a-z]+)*";
Regex camelCaseProcRegex = new(regexPattern, regexOptions);
string snakeify(Match matchingRegex)
{
var vals =
matchingRegex.Groups.Cast<Group>().SelectMany(_ => _.Captures).Select(_ => _.Value).ToArray();
var newVal = string.Join("_", vals.Skip(1).ToArray()).ToLower();
string logString = $"{vals[0]} => {newVal}";
if (changedProcs.TryGetValue(logString, out int value))
{
changedProcs[logString] = value + 1;
}
else
{
changedProcs.Add(logString, 1);
}
return newVal;
}
var dmFiles = Directory.EnumerateFiles(".", "*.dm", SearchOption.AllDirectories).ToAsyncEnumerable<string>();
// uses default ParallelOptions
// https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.paralleloptions?view=net-10.0#main
await Parallel.ForEachAsync(dmFiles, async (filePath, UnusedCancellationToken) =>
{
var reader = new StreamReader(filePath, readFile);
string oldContent = await reader.ReadToEndAsync();
string newContent = camelCaseProcRegex.Replace(oldContent, new MatchEvaluator((Func<Match, string>)snakeify));
if (oldContent != newContent)
{
var writer = new StreamWriter(filePath, writeFile);
await writer.WriteAsync(newContent);
await writer.DisposeAsync();
}
reader.Dispose();
});
var logToList = changedProcs.Cast<KeyValuePair<string, int>>().ToList();
foreach (var pair in logToList)
{
Console.WriteLine($"{pair.Key}: {pair.Value} locations");
}
}
}
```
## Changelog
🆑 Bisar
code: All (Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss) procs now use
snake_case, in-line with the STYLE guide. Underscores rule!
/🆑
## About The Pull Request
This PR adds the ability to install a B.O.R.I.S. in a circuit that
contains an MMI component. These circuits can then be remotely connected
to by an AI by clicking on them or anything they are inside of. To
indicate that a circuit allows remote AI connection, an indicator is
given to the circuit and anything containing it.
Additionally:
- Refactors the MMI component to use `item_interaction`, since it was
pertinent.
- You cannot insert an MMI/B.O.R.I.S. into a locked circuit.
- You can no longer hotswap MMIs/B.O.R.I.S.es - you must manually eject
the inserted one.
Let me know what changelog labels I should use for the hotswap removal
and the prevention of insertion into locked circuits.
## Why It's Good For The Game
If you can put an MMI or posibrain in a circuit, why not allow an AI to
use it using a B.O.R.I.S.?
## Changelog
🆑
add: B.O.R.I.S.es can be installed inside of integrated circuits with
MMI components, allowing an AI to remotely interface with them the same
way an MMI or posibrain could.
refactor: The MMI component now uses item interaction behavior for
inserting MMIs/B.O.R.I.S.es.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
My original plan was to just implement materials into crafting so that
items would inherit the materials of their components, allowing for some
interesting stuff if the material flags of the item allow it. However to
my dismay crafting is a pile of old tech debt, starting from the old
`del_reqs` and `CheckParts` which still contain lines about old janky
bandaids that are no longer in use nor reachable, up to the
`customizable_reagent_holder` component which has some harddel issues
when your custom food is sliced, and items used in food recipes not
being deleted and instead stored inside the result with no purpose as
well as other inconsistencies like stack recipes that transfer materials
having counterparts in the UI that don't do that.
EDIT: Several things have come up while working on this, so I apologise
that it ended up changing over 100+ files. I managed to atomize some of
the changes, but it's a bit tedious.
EDIT: TLDR because I was told this section is too vague and there's too
much going on. This PR:
- Improves the dated crafting code (not the UI).
- replaced `atom/CheckParts` and `crafting_recipe/on_craft_completion`
with `atom/on_craft_completion`.
- Reqs used in food recipes are now deleted by default and not stored
inside the result (they did nothing).
- Renames the customizable_reagent_holder comp and improves it (No
harddels/ref issues).
- Adds a unit test that tries to craft all recipes to see what's wrong
(it skips some of the much more specific reqs for now).
- In the unit test is also the code to make sure materials of the
crafted item and a non-crafted item of the same type are roughly the
same, so far only applied to food.
- Some mild material/food refactoring around the fact that food item
code has been changed to support materials.
## Why It's Good For The Game
Improving the backbone of the crafting system. Also materials and food
code.
## Changelog
🆑
refactor: Refactored crafting backend. Report possible pesky bugs.
balance: the MEAT backpack (from the MEAT cargo pack) may be a smidge
different because of code standardization.
/🆑
Because the wings were in fact made of wax
## About The Pull Request
Storage goes to the very bottom of the interaction chain, hardcoded in
on `/atom`.
This is not preferred, obviously, but it ends up being a lot less
snowflaking overall.
Tables also go at the very bottom by extending `base_item_interaction`.
Fixes#83742Fixes#84434Fixes#83982Fixes#85516Fixes#84990Fixes#84890Closes#85036Closes#84025 (RMB places it on the table.)
Closes#86616
Other changes:
Refactored pod storage to be less jank. Patches some exploits around it.
## Why It's Good For The Game
Should make a lot more interactions a lot more reliable... hopefully
## Changelog
🆑 Melbert
refactor: Storage and Tables are now a lower priority action, meaning
some uses of items on storage should work... better, now. Here's hoping
at least, report any oddities.
refactor: Note: For an overwhelming majority of items, **combat mode**
will attempt to attack/insert into the target, while **non-combat-mode**
will attempt to use on a target. This means screwdrivering or emagging a
MODsuit must be done on non-combat-mode, as combat mode will simply put
the screwdriver or emag into its storage. Same applies to tables, though
when in doubt, RMB may help (for things which are also weapons, like
mops).
refactor: Refactored escape pod storage, now they actually properly show
as unlocked on red alert and above.
/🆑
Hello everybuddy, your number three rated coder-failure here to clean up
some mess. This PR accomplishes some of the more major structural clean
up changes I wanted to do with /obj/ folder, but decided to wait on
until wallening gets merged, and so, time has come. Several things to
still be done, although I know these cleaning PR's are quite a load, so
will wait for this one to get done with first.
## Why It's Good For The Game
Saner spriters, better sprites, less annoyance. Also deleted a whole
load of redundancy this time around, a lot of sprites which existed
simultaniously in two places now got exit their quantum superposition.
## 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>
## About The Pull Request
This item was supposed to allow the purchaser to put an AI into their
mod suit, however as written nothing except available ghost count
stopped you from using it over and over again so that every op on the
team had an AI suit.
Now we just destroy the item if you successfully transfer the AI into
anything so you can't reuse it.
Also I moved it to its own file rather than having the definition of
this item be above every other proc definition in the file, including
some it was using.
## Changelog
🆑
fix: The Nuke Op MODsuit AI downloader only works once per purchase, as
intended.
/🆑
## About The Pull Request
Fixes#78455
Syndicate AI's is now granted the codespeak language on spawning.
## Why It's Good For The Game
fixes.... le good?
## Changelog
🆑
fix: Syndicate Modsuit AI's now downloads the current codespeak book
upon being downloaded.
/🆑
## About The Pull Request
Fixes#78058
This did a couple of weird things and I am not totally sure it ever
worked, but now it does.
Firstly, I moved the creation of the AI Eye to before we attach the
client, as it would make a stack trace if it did not exist on client
login.
Secondly, I changed a call to `pre_attack` to a call to the actual proc
we wanted, `capture_ai`.
Thirdly, I removed a reundant line which set the key of the AI core a
second time from the candidate, which we had already done when
initialising the AI. Because we had already done it, we were instead
setting the key to null (because the observer's key had already been
nulled and moved to the AI) and kicking the player by removing their key
from all mobs.
Finally, I passed `src` as a list into `log_silicon` when logging
transferring the AI into the card, because it stack traces when not sent
a list.
I also did a fair amount of housekeeping to improve the experience of
using this device.
## Changelog
🆑
fix: The nuclear operative MODsuit intellicard now actually downloads an
AI rather than simply kicking candidates from the game.
/🆑
## About The Pull Request
Adds a syndicate AI card for nuke ops. Costs 12 TC, can be refunded.
Activating it in-hand opens up a ghost poll like normal reinforcements.
## Why It's Good For The Game
> Adds a syndicate AI card for nuke ops. Costs 12 TC, can be refunded.
Activating it in-hand opens up a ghost poll.
It'll be fun to have a lil modsuit pal with you who can maybe help if
you get stunned, in critical condition, or else. With an injector module
they can even save your life, if it's loaded with medicine! Unless they
can't actually inject, but oh well, out of scope.
12 TC seems fair to me, not so expensive that nobody's going to bother
with something that's not really useful in the vast majority of
circumstances, but not so cheap that everyone will get one.
There are also doubtless a huge amount of gimmicks that savvy nukies can
get up to, having a pocket AI.
**Since this needs two players to be fully tested, I wasn't able to do
so. Please testmerge this before merging so we can confirm it works
ingame!**
## Changelog
🆑
add: Adds a syndicate AI card for nuke ops. Costs 12 TC, can be
refunded. Activating it in-hand opens up a ghost poll like normal
reinforcements. Base interaction range for syndicate AIs is one, which
means they can handle electronics only in proximity.
add: Adds a syndicate AI interaction range upgrade for nuke ops, costs 4
TC and can be applied onto a syndicate AI (inside any container) to
increase its interaction range by two per. (Three purchases are
recommended for seven tiles of range!)
/🆑
## About The Pull Request
Spiritual successor to #76716
- Some spells can now be cast while the mob is within the contents of
certain atoms.
- PAIs can now cast if within a PAI card
- AIs can now cast if within an AI card
- People within vehicles (mechas and cars) can now cast their spells
- Repulse and Knock now have unique interactions for being cast within a
locker
## Why It's Good For The Game
Carlac's PR gave me an idea for how to tackle this in a relatively clean
way so I went ahead and adapted the suggestion to something that works
for the cast chain.
This isn't perfect, some spells will need to be updated, but they can be
done piecemeal.
This is something that, IN THEORY, should have already been wholesale
supported by the spell refactor - any atom you pass into the cast chain
should "just work ™️ ", either rejecting if it fails the valid target
check or doing the spell effects as if the atom passed was the caster.
## Changelog
🆑 Melbert
add: PAIs can now cast wizard spells should they have any.
add: AIs located in intellicards can now cast wizard spells should they
have any.
add: Some spells, such as AoE or conjure spells, are now castable from
within Mechas or Clown Cars. To varying degrees of success.
add: Knock will now unlock and open closets you are hiding within.
add: Repulse will now throw open closets you are hiding within.
/🆑
first things first, back when LemonInTheDark changed the interact_range code he did a slight modification that broke the AI cards, namely, he did this (not saying its a bad change, it is actually a good change, just mentioning what change caused the issue im fixing now):
now, his change does make sense, since he changed the range default to 0 instead of 1, however "null" is also used as a range, specifically for AIs, now this normally isnt an issue for the AI itself, as the AI generally gets a TRUE in its interaction checks before it gets down this deep (machines have a bypass specifically for AI), but there is one situation in which it does go this deep: AI Cards, when in an AI card the AIs interaction range is set to 0 and their interaction is disabled, thereby making it impossible for them to interact with anything, now when a player opens the card UI and enables the AIs ability to interact, this sets their range back to null, aka unlimited, the issue now however, is that since "null" is treated the same as "0", and AIs in cards dont hit the same bypasses an AI core does, Lemons change to submit a false return for 0, is also submitting false for null, meaning the AI card cannot interact with anything except the tile its on, despite having null/unlimited range....
fixed by changing the null value to infinity where it is used
additionally my fix of can_interact() code apparently had the unintended side effect of not allowing rotations of machines if theres no power, i missed this entirely because thats such a specific situation, since you try rotating with APC power in most cases, it also didnt affect most machines, that said the fix was simple, just changed the proc being called to only check distance, not power. fixes#61852
and last but not least, fixes some code with the syndie bombs interactability, namely removes a redudant section, and adds a check for range, turns out there were no checks for range so you could in theory open the UI and walk away and then activate it from another location, so added a quick check to ensure you actually CAN interact with it before letting you push buttons in the UI
Its a relatively small refactor that changes the previous machinery "can_interact()" proc that literally did a full override despite half of their checks already existing in not one, but TWO parent procs, so i removed the redundant checks, added callbacks to its parents and then added the cyborg range check on the can_interact_with() itself. in doing so i also moved the interaction range var from silicons only, to mobs as a whole and defaulted it to a single tile, silicons override it to 7 (so pAIs and borgs like before) but then set AI and AI.eye to "null", because i have a check in can_interact that if there is no range set, then the range is effectively unlimited. and i even added code for when AI is carded and their wireless transmission is disabled it sets their range to "0" aka, it has no range to do anything even if it could
this was really complicated for me so despite my extensive testing it probably would be a bad thing if any of you want to test my code yourself to ensure there isnt a bug with this (theres no runtimes ive come across)
note: i did a lot of searching and going through machinery to ensure i caught all the little snowflake overrides and added can_interact() checks to them, but i may have missed one or two things, especially maybe a altclick or ctrlclick somewhere, however i believe i caught most of them
one nice side effect of this refactor is that you can actually set another mobs range to something other than 1 tile and they can interact at range, rather than only silicons getting this ability, an admin could VV a human to have a 3 tile arm reach as a meme if they want
Converts most spans into span procs. Mostly used regex for this and sorted out any compile time errors afterwards so there could be some bugs.
Was initially going to do defines, but ninja said to make it into a proc, and if there's any overhead, they can easily be changed to defines.
Makes it easier to control the formatting and prevents typos when creating spans as it'll runtime if you misspell instead of silently failing.
Reduces the code you need to write when writing spans, as you don't need to close the span as that's automatically handled by the proc.
(Note from Lemon: This should be converted to defines once we update the minimum version to 514. Didn't do it now because byond pain and such)
Creates update_name and update_desc
Creates the wrapper proc update_appearance to batch update_name, update_desc, and update_icon together
Less non-icon handling code in update_icon and friends
Signal hooks for things that want to change names and descriptions
99%+ of the changes in this are just from switching everything over to update_appearance from update_icon
All ui_act procs should call parent by default. All procs should preserve the value of the parent proc when it's TRUTHY and pass it down the call stack. No UI should be interactible when its flags or state indicate it should not be, except when explicity overriden by child procs intentionally disregarding parent return values to achieve a specific goal.
* Renames a few variables. Also reorders fallback order again.
Renames item_state to inhand_icon_state
Renames mob_overlay_icon to worn_icon
Renames mob_overlay_state to worn_icon_state
worn_icon_state/mob_overlay_state now never gets used for inhands.
* Fixes some comments
* Fixes map issue
* Restart lints
* Properly resolves conflicts
* Refactor several log lines to use datum_info_line and atom_loc_line
* Add default return strings from datum_info_line and atom_loc_line
* Add parentheses around atom_loc_line data
* Change more logs to use atom_loc_line
* Add check in atom_loc_line for turfs to avoid calling get_turf on them
* Re-add removed 'at'
* Replace datum_info_line with key_name and atom_loc_line with loc_name
* Refactor logging functions
* Avoid double-logging self-interactions
* Fallback to simple stringification if all else fails in key_name()
* Rewrite muscle spasm logging to use log_message
* Standardize logging of martial arts
* Tweak individual logging panel look
* Fix individual logging panel source
* When I typed || I really meant &&
* Fix Telecomms logging always showing client logs in the panel
* Reverts addition of buggy ownership log to panel
* Remove colon
* Fix missing log_directed_talk tag
* Add warning for missing type in log_direted_talk
* Change warnings to stack_traces
* Add square brackets around fallthrough key_name() case to help parsing
* Allow atom arguments/src in log_*() functions
* Change log_combat call with null argument to log_message
* Change mecha types' log_message() arguments to match atom and mob version
* Add key_name() case for atoms
* Fix resist_grab() unsetting pulledby before log_combat gets a chance to use it
* Fix log_globally logic
* Add logging for hitting objects with items
* Move log_combat() to atoms.dm
* Use utility functions for object stringification in log_combat()
* Use utility functions for object stringification in log_combat()
* Add missing logs for interacting with display cases
* Rewrite log_combat() comment
* Add missing space in log_combat()
* Add logging for hitting grilles barehanded
* Add missing ..()
* adds signal and modifies each call of afterattack to call it's inherited proc
* uses new macro for sendsignal()
* map fuck
* skip precommithooks
* combine and negate 2 ifs
Alexis