mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-07-15 10:04:30 +01:00
masterfixes
172 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Roxy
|
ba988f2230 |
Refactor split_stack to two separate procs, fixes a hard delete in the process (#91306)
## About The Pull Request I was trying to fix a hard delete and it became a whole thing - Reworks `/obj/item/stack/proc/split_stack` to no longer also try to put it in the user's hands, or take a user at all. The proc now purely splits the stack and returns the new one - Creates `/obj/item/stack/proc/split_n_take` which uses `split_stack` and does the other behaviors like fingerprint adding and putting in the user's hands - Update usages of `split_stack` to either properly use it and remove the code added to get around the put in hands behavior, or change them to use `split_n_take` instead - Fix a random bug in pipe bomb building I noticed while testing ## Why It's Good For The Game Ultimately this fixes a hard delete with goldgrubs eating a piece of ore while sitting on top of another piece of ore of the same type (the put in hands behavior of split stack would cause the ore being consumed to drop to the ground briefly, merge with the ore there, and then qdel while still being moved to the goldgrub contents), but also added bonus that it makes `split_stack` just split the stack and not some other stuff too. Also a pipe bomb bug fix ## Changelog 🆑 fix: fixed being able to add seemingly infinite refined bluespace crystals to pipe bombs refactor: /obj/item/stack/split_stack no longer tries to move the stack into the user's hands, use /obj/item/stack/split_n_take for that /🆑 |
||
|
MrMelbert
|
bc2215667f |
Re-refactors batons / Refactors attack chain force modifiers (#90809)
Melee attack chain now has a list passed along with it, `attack_modifiers`, which you can stick force modifiers to change the resulting attack This is basically a soft implementation of damage packets until a more definitive pr, but one that only applies to item attack chain, and not unarmed attacks. This change was done to facilitate a baton refactor - batons no longer hack together their own attack chain, and are now integrated straight into the real attack chain. This refactor itself was done because batons don't send any attack signals, which has been annoying in the past (for swing combat). 🆑 Melbert refactor: Batons have been refactored again. Baton stuns now properly count as an attack, when before it was a nothing. Report any oddities, particularly in regards to harmbatonning vs normal batonning. refactor: The method of adjusting item damage mid-attack has been refactored - some affected items include the Nullblade and knives. Report any strange happenings with damage numbers. refactor: A few objects have been moved to the new interaction chain - records consoles, mawed crucible, alien weeds and space vines, hedges, restaurant portals, and some mobs - to name a few. fix: Spears only deal bonus damage against secure lockers, not all closet types (including crates) /🆑 |
||
|
Ghom
|
11d82b7995 |
You can now interact with held mobs beside wearing them (feat: "minor" melee attack chain cleanup) (#90080)
People can now pet held mothroaches and pugs if they want to, or use items on them, hopefully without causing many issues. After all, it only took about a couple dozen lines of code to make... ...Oh, did the 527 files changed or the 850~ lines added/removed perhaps catch your eye? Made you wonder if I accidentally pushed the wrong branch? or skewed something up big time? Well, nuh uh. I just happen to be fed up with the melee attack chain still using stringized params instead of an array/list. It was frankly revolting to see how I'd have had to otherwise call `list2params` for what I'm trying to accomplish here, and make this PR another tessera to the immense stupidity of our attack chain procs calling `params2list` over and over and over instead of just using that one call instance from `ClickOn` as an argument. It's 2025, honey, wake up! I also tried to replace some of those single letter vars/args but there are just way too many of them. Improving old code. And I want to be able to pet mobroaches while holding them too. 🆑 qol: You can now interact with held mobs in more ways beside wearing them. /🆑 |
||
|
Waterpig
|
753d8e5ba4 | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-04a | ||
|
Waterpig
|
d3d3a12540 |
The big fix for pixel_x and pixel_y use cases. (#90124)
## About The Pull Request 516 requires float layered overlays to be using pixel_w and pixel_z instead of pixel_x and pixel_y respectively, unless we want visual/layering errors. This makes sense, as w,z are for visual effects only. Sadly seems we were not entirely consistent in this, and many things seem to have been using x,y incorrectly. This hopefully fixes that, and thus also fixes layering issues. Complete 1:1 compatibility not guaranteed. I did the lazy way suggested to me by SmArtKar to speed it up (Runtiming inside apply_overlays), and this is still included in the PR to flash out possible issues in a TM (Plus I will need someone to grep the runtimes for me after the TM period to make sure nothing was missed). After this is done I'll remove all these extra checks. Lints will probably be failing for a bit, got to wait for [this update](https://github.com/SpaceManiac/SpacemanDMM/commit/4b77cd487d0a7b6a069df20356b701af5b20489d) to them to make it into release. Or just unlint the lines, though that's probably gonna produce code debt ## Why It's Good For The Game Fixes this massive 516 mess, hopefully. closes #90281 ## Changelog 🆑 refactor: Changed many of our use cases for pixel_x and pixel_y correctly into pixel_w and pixel_z, fixing layering issues in the process. /🆑 --------- Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com> Co-authored-by: SmArtKar <master.of.bagets@gmail.com> |
||
|
Majkl-J
|
b6b8306fda | Merge branch 'master' of https://github.com/tgstation/tgstation into upstream-25-02a | ||
|
MrMelbert
|
239797a4ee |
Deletes misleading infinite define, adds defines for clearer status effect durations (#87842)
## About The Pull Request 1. Deletes `INFINTIE`, it is misleading and not at all a big number and causes bugs 2. Adds `STATUS_EFFECT_PERMANENT` and `STATUS_EFFECT_NO_TICK` to make it clearer what infinite status effects are |
||
|
Majkl-J
|
e59d8ba64b | Merge commit '179a607a90ad7ec62bdaff4e6fe72af60ee56442' of https://github.com/tgstation/tgstation into upstream-24-10b | ||
|
Waterpig
|
bb70889f6e |
TG Upstream Part 1
3591 individual conflicts Update build.js Update install_node.sh Update byond.js oh my fucking god hat slow huh holy shit we all fall down 2 more I missed 2900 individual conflicts 2700 Individual conflicts replaces yarn file with tg version, bumping us down to 2200-ish Down to 2000 individual conflicts 140 down mmm aaaaaaaaaaaaaaaaaaa not yt 575 soon 900 individual conflicts 600 individual conflicts, 121 file conflicts im not okay 160 across 19 files 29 in 4 files 0 conflicts, compiletime fix time some minor incap stuff missed ticks weird dupe definition stuff missed ticks 2 incap fixes undefs and pie fix Radio update and some extra minor stuff returns a single override no more dupe definitions, 175 compiletime errors Unticked file fix sound and emote stuff honk and more radio stuff |
||
|
grungussuss
|
58501dce77 |
Reorganizes the sound folder (#86726)
## About The Pull Request <details> - renamed ai folder to announcer -- announcer -- - moved vox_fem to announcer - moved approachingTG to announcer - separated the ambience folder into ambience and instrumental -- ambience -- - created holy folder moved all related sounds there - created engineering folder and moved all related sounds there - created security folder and moved ambidet there - created general folder and moved ambigen there - created icemoon folder and moved all icebox-related ambience there - created medical folder and moved all medbay-related ambi there - created ruin folder and moves all ruins ambi there - created beach folder and moved seag and shore there - created lavaland folder and moved related ambi there - created aurora_caelus folder and placed its ambi there - created misc folder and moved the rest of the files that don't have a specific category into it -- instrumental -- - moved traitor folder here - created lobby_music folder and placed our songs there (title0 not used anywhere? - server-side modification?) -- items -- - moved secdeath to hailer - moved surgery to handling -- effects -- - moved chemistry into effects - moved hallucinations into effects - moved health into effects - moved magic into effects -- vehicles -- - moved mecha into vehicles created mobs folder -- mobs -- - moved creatures folder into mobs - moved voice into mobs renamed creatures to non-humanoids renamed voice to humanoids -- non-humanoids-- created cyborg folder created hiss folder moved harmalarm.ogg to cyborg -- humanoids -- -- misc -- moved ghostwhisper to misc moved insane_low_laugh to misc I give up trying to document this. </details> - [X] ambience - [x] announcer - [x] effects - [X] instrumental - [x] items - [x] machines - [x] misc - [X] mobs - [X] runtime - [X] vehicles - [ ] attributions ## Why It's Good For The Game This folder is so disorganized that it's vomit inducing, will make it easier to find and add new sounds, providng a minor structure to the sound folder. ## Changelog 🆑 grungussuss refactor: the sound folder in the source code has been reorganized, please report any oddities with sounds playing or not playing server: lobby music has been repathed to sound/music/lobby_music /🆑 |
||
|
MrMelbert
|
66430e1147 |
Laser pointer has a 50% chance to fail when used on people wearing an eyepatch (#86693)
## About The Pull Request Laser pointer has a 50% chance to fail when used on people wearing an eyepatch ## Why It's Good For The Game  ## Changelog 🆑 Melbert balance: Laser pointers have a 50% chance to fail when used on people wearing eyepatches /🆑 |
||
|
MrMelbert
|
8486f2f7e2 |
Storage / table interactions at the bottom of the interaction chain (#85512)
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 #83742 Fixes #84434 Fixes #83982 Fixes #85516 Fixes #84990 Fixes #84890 Closes #85036 Closes #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. /🆑 |
||
|
Waterpig
|
4c4930c71d | Merge branch 'master' of https://github.com/tgstation/tgstation into pulls-tg-to-fix-shit | ||
|
Ben10Omintrix
|
91baa94ac5 |
event based incapicated and able_to_run (#86031)
## About The Pull Request this is a revival of #82635 . i got permission from potato to reopen this, he did almost all the work. i only just solved the conflicts and fixed all the bugs that were preventing the original from being merged (but it should be TMed first) ## Why It's Good For The Game slightly improves the performance of basic mob AI ## Changelog 🆑 LemonInTheDark refactor: able_to_run and incapacitated have been refactored to be event based /🆑 --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: ZephyrTFA <matthew@tfaluc.com> |
||
|
SkyratBot
|
dbcfb7bab9 |
[MIRROR] Laser pointers no longer make felinids phase through diagonal gaps (#29265)
* Laser pointers no longer make felinids phase through diagonal gaps * Update laserpointer.dm --------- Co-authored-by: Waterpig <49160555+Majkl-J@users.noreply.github.com> |
||
|
Waterpig
|
e7bfcac8bb |
Laser pointers no longer make felinids phase through diagonal gaps (#85755)
## About The Pull Request Someone forgot the dir argument, making it possible to phase through diagonal gaps. ## Why It's Good For The Game One less bug. I like my gbp ## Changelog 🆑 fix: Felinids no longer phase through diagonal gaps upon seeing a laser /🆑 |
||
|
Waterpig
|
5206cb4914 | Fixes felinid stuff and brings back laserpointing | ||
|
SkyratBot
|
53d3099582 |
[MIRROR] Moves tool use back higher in the chain, but makes it so tool acts are only called on non-combat-mode (#28457)
Moves tool use back higher in the chain, but makes it so tool acts are only called on non-combat-mode Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: SpaceLoveSs13 <68121607+SpaceLoveSs13@users.noreply.github.com> |
||
|
MrMelbert
|
4aa7bae77a |
Moves tool use back higher in the chain, but makes it so tool acts are only called on non-combat-mode (#84083)
## About The Pull Request ### Dilemma So we've been running into a dilemma recently as we move more and more items over (#84070, #83910) Some things like modsuits, tables, washing machines, storage items want to do their tool acts before their item interactions In the past this was perfectly fine, because it was `tool_act` -> `attack`, but now it's a problem, because it's `item_interaction` -> `tool_act` -> `attack`. Rather than resort to snowflaking, my idea is that we can move tools back up the chain so deconstruction and other similar effects are handled first, before anything else like putting the tool onto the table. ### So why does it require non-combat-mode? A large amount of tool acts early return if the user's on combat mode to allow the user to smack the thing instead of using the tool on it. So I've decided to walk back on what I said like a week ago and make this standardized behavior. ### Misc Reintroducing `tool_act` as a proc that exist means that atoms can easily hook certain interactions that must happen very high in the click chain, such as doing something that block storage insertion. Moves some of the behaviors I put on the (admittedly rather hacky) new proc to that. (Also cleaned up a bit of lockbox and medbot code) ## Changelog 🆑 Melbert fix: Fixed modsuit interactions slightly. No longer requires combat mode to use tools on it, plasma core works as intended as well. (Using combat mode, however, will make you insert the item) refactor: Refactored lockboxes refactor: Refactored medbot skin application /🆑 |
||
|
SkyratBot
|
b540aaf8ab |
[MIRROR] Afterattack is dead, long live Afterattack (#28128)
* Afterattack is dead, long live Afterattack * wew * fixes --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com> |
||
|
MrMelbert
|
ff6b41aa07 |
Afterattack is dead, long live Afterattack (#83818)
## About The Pull Request - Afterattack is a very simple proc now: All it does is this, and all it's used for is for having a convenient place to put effects an item does after a successful attack (IE, the attack was not blocked)  - An overwhelming majority of afterattack implementations have been moved to `interact_with_atom` or the new `ranged_interact_with_atom` I have manually tested many of the refactored procs but there was 200+ so it's kinda hard ## Why It's Good For The Game Afterattack is one of the worst parts of the attack chain, as it simultaneously serves as a way of doing random interactions NOT AT ALL related to attacks (despite the name) while ALSO serving as the defacto way to do a ranged interaction with an item This means careless coders (most of them) may throw stuff in afterattack without realizing how wide reaching it is, which causes bugs. By making two well defined, separate procs for handing adjacent vs ranged interactions, it becomes WAY WAY WAY more easy to develop for. If you want to do something when you click on something else and you're adjacent, use `interact_with_atom` If you want to do something when you click on something else and you're not adjacent, use 'ranged_interact_with_atom` This does result in some instances of boilerplate as shown here:  But I think it's acceptable, feel free to oppose if you don't I'm sure we can think of another solution ~~Additionally it makes it easier to implement swing combat. That's a bonus I guess~~ ## Changelog 🆑 Melbert refactor: Over 200 item interactions have been refactored to use a newer, easier-to-use system. Report any oddities with using items on other objects you may see (such as surgery, reagent containers like cups and spray bottles, or construction devices), especially using something at range (such as guns or chisels) refactor: Item-On-Modsuit interactions have changed slightly. While on combat mode, you will attempt to "use" the item on the suit instead of inserting it into the suit's storage. This means being on combat mode while the suit's panel is open will block you from inserting items entirely via click (but other methods such as hotkey, clicking on the storage boxes, and mousedrop will still work). refactor: The detective's scanner will now be inserted into storage items if clicked normally, and will scan the storage item if on combat mode /🆑 |
||
|
SkyratBot
|
5a3eb3e0fd |
[MIRROR] Fix laser_pointer/inifity_range having the wrong diode (#27524)
* Fix laser_pointer/inifity_range having the wrong diode (#82940) Fixes an issue where diode in infinity_range laser pointer was servo, not a micro-laser * Fix laser_pointer/inifity_range having the wrong diode --------- Co-authored-by: larentoun <31931237+larentoun@users.noreply.github.com> |
||
|
larentoun
|
1873d211d0 |
Fix laser_pointer/inifity_range having the wrong diode (#82940)
Fixes an issue where diode in infinity_range laser pointer was servo, not a micro-laser |
||
|
SpaceLoveSs13
|
ba5c112a86 |
Huge Mirror fixes (#27488)
* Fixes incorrect operator usage in mecha code (#82570)
## About The Pull Request
I completely screwed up and told the original PR author of #82415
(
|
||
|
MrMelbert
|
d280c9ccce | Makes it EVEN EASIER to work with atom item interactions ft. "Leaf and Branch" & "Death to Chains" (#82625) | ||
|
Useroth
|
2b60c77e55 |
Yet another mirror batch (#27314)
* A skub-related station trait. Reduced weight of annoyingly frequent neutral traits. (#81388)
## About The Pull Request
This PR introduces a new station trait that lets people choose if they
want to be pro-skub or anti-skub (or neither, really). It works the same
lobby buttons that job-related station traits also use. Depending on
whether you chose to be pro or anti skub, you'll spawn in with a special
box that contains the (bulky) skub and a pro-skub shirt, or an anti-skub
shirt. EDIT: Both also receive a number of stickers to propagate their
causes.
Kudos to @Fikou for coding the lobby buttons to be accessible by any
station trait rather than only job-related ones when you made the
Cargorilla station trait.
Another thing this PR also halves the exaggerated weight of low-cost
traits such as scarves, wallets and glitched PDAs, which I clearly
underestimated.
## Why It's Good For The Game
We've learned that low-cost, high weight traits are a bit of a design
mistake, because they tend to tip the scales toward themselves over and
over and over, leveling the diverseness of the feature and therefore
making it shallow and boring.
Beside, I've been thinking of the popular [skub comic
strip](https://pbfcomics.com/comics/skub/) lately.
## Changelog
🆑
add: Added a Skub-related station trait. You can now choose if you want
to be pro-skub or anti-skub, complete of shirt and stickers. Please
don't shank each other over it.
balance: Halved the weight of station traits such as scarves, wallets
and glitched PDAs.
/🆑
* Fix some slime species subtypes not having burn resistance (#82164)
## About The Pull Request
All slime species limb subtypes now inherent from the parent `/jelly`
subtype, giving them all their proper burn resistance.
## Changelog
🆑 Melbert
fix: Slimepeople and Luminescents are now 50% burn resistant like
Stargazers
/🆑
* There we go
* FIX: Makes Hatsune mi-go a (friendly) gold slime mob (#82251)
## About The Pull Request:
The hatsune mi-go is now a friendly gold slime mob. This means it won't
try and kill you. It also now doesn't make your ears hurt, and drops a
keyboard synth on death (you monster.)
## Why It's Good For The Game
So in making my resprited mi-go and subsequent speedmerge, I failed to
realize that there are only 10 possible migo spawnpoints - 5 in snowdin
gateway, 3 on ceres whiteship, and 2 on kilo whiteship. This means at
most eight can exist on anyround, with a decent likelyhood of 0. This,
combined with the fact the hatsune migo is banned from spawning outside
of roundstart locations, along with the fact people seem to love the
thing, made it feel _too_ rare, even for a shiny mob. You still have to
roll the random odds with the life chem or friendly gold slime pools,
but you should actually see them outside of two mutually exclusive space
ruins and a gateway now. Also, they don't try and kill you now, because
it would have been wrong to add a hostile creature to the friendly pool.
🆑
fix: Hatsune mi-go now is a friendly gold slime mob, and doesn't hurt
your ears.
add: Hatsune mi-go drops a keyboard synth on death (you monster.)
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* [THE QUIRKENING] Adds customization options to Organ Prosthetic, Junkie, Smoker, and Alcoholic! (#82051)
## About The Pull Request
Lets people pick:
- The shitty organ they spawn with (still has the restrictions of not
being possible to get heart when you are a plasmamen, for example)
- Their favorite alcohol to blackout with
- Their favorite brand of cigs
- Their favorite brand of drugs!
A lot of the code was taken from a downstream, made by @Floofies, i
already had my own implementation but it was buggy and not nearly as
clean, then i was made aware of theirs.
## Why It's Good For The Game
Character Customization is good and fun and lets people have more choice
in their roleplay.
## Changelog
🆑
add: Prosthetic organ users are now allowed to pick what they want to
start with.
add: Junkie of all kinds, including smokers and alcoholics, are also
able to pick their favorite type.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* [NO GBP] Fixes the "Drop Pod: Syndies" deathmatch modifier. (#82216)
## About The Pull Request
I've had false memories of `pick_weight` working with assoc-value-less
lists.
## Why It's Good For The Game
This will fix an issue with deathmatch modifiers.
## Changelog
🆑
fix: Fixed the "Drop Pod: Syndies" deathmatch modifier.
/🆑
* Fix robocontrol access runtime (#82242)
## About The Pull Request
`check_access` expects an item, such as an ID card, to... check access.
Not a mob.
We can circumvent this entirely by using `allowed`.
But this has an averse effect in that `allowed` will only check the
user's ID, not the ID in the mod PC.
So we need to run a separate check of `check_access` for the computer ID
card.
## Changelog
🆑 Melbert
fix: Robocontrol should work better.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
* Adds a photobooth (#82105)
## About The Pull Request
Adds a photobooth machine to the HoP line which can be used to update
your security records photo.
It updates the records of the person's name, which means hiding your
identity and wearing an ID will let you change other people's photos. If
you aren't hiding your identity and are wearing someone else's ID, it
won't update at all because it will be unable to find your record.
There's 2 variants of this machine, one at the HoP line that's tied
behind Law Office access (so Lawyers have an extra thing they can help
out with if no one's available, but maybe it would be better behind
Library access since Curators are our "photographer" role?), and the
Security one that requires Security access.
The Security one has a special feature that it adds a height chart
behind the player.
This machine is used by either right-clicking on it or by pressing a
button, so the HoP can do it remotely from their line (except on Tram
where it's in the library), and after a few delays it'll update your
records automatically to how you look like.
Emagging the machine will remove its access restrictions but every time
it updates your photos it will spam camera flashing and blind you.
Sprites
Open
Closed
Security version on the left, has a red tint on it
Video demonstration (old sprites):
https://github.com/tgstation/tgstation/assets/53777086/a2e59f08-2d58-4f5b-b081-e137c7606d35
## Why It's Good For The Game
Current security records has no way to change your photo ID, something
that was a feature before it was moved to TGUI. The only alternative is
to fully delete your record and make a new one with a photo and the same
name, but this shares a major issue with the HTML UI: You're immediately
sold out by the fact you have a background. No matter how well you try
to cover your tracks, any security officer looking at records will see
you are the only photo on the manifest that has a background and even a
camera in your hand, which makes it impossible to get away with it
unless security essentially takes pity on you.
This opens up the ability to fully mask yourself in records, finally.
This is also better even for non antagonists because you can now
properly update your photos to match what you look like in the event of
an appearance change or even just a job change, which makes it a benefit
for HoPs who likes to keep records as up-to-date as possible.
## Changelog
🆑 JohnFulpWillard, Twox
add: Added a new photobooth machine to the HoP's line.
fix: Things checking for access now checks your off hand, too.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Converts slimes to basic mobs (#82176)
After months of preparation, and further months of work, I am finally
done. Please bear with me, as this is a massive refactor, but I have
already atomized everything I could. This is now ready for review.
General
- The hilbert hotel slimes are now a subtype instead of a varedit.
- The `use_mob_ability` subtree now also accepts non cooldown abilities.
If set_behaviours is set up properly, mobs won't keep continously
triggering it as if it were a 0 second cooldown action. The alternative
would have been turning the slime abilities into cooldown abilities.
- Wrestling off a slime now signs up to the `COMSIG_ATOM_ATTACK_HAND`
signal, instead of being part of attack_hand.
- Adds datum/ai_controller/controller as a fourth, optional argument to
`/datum/ai_behavior/find_hunt_target/valid_dinner()` to make it possible
to access blackboard keys.
- Slimes no longer attack windows if they would accidentally move into
them (when the conditions are met), since random walk behaviour ignores
tiles they can't go in. It was also not worth to keep. Did you know this
was the sole override of `ObjBump()`?
- Examine was made less snowflaky/bespoke. Also added a new element:
`/datum/element/basic_health_examine`, which is a simple bespoke element
that prints out a custom message based on how damaged the basic mob it
is attached to is.
- Slimes only perform knockdown instead of paralysis, as they can attack
more often now, and paralysis is not that fun.
- LAssailant has been removed due being archaic code. To befriend a
slime, you have to spawn a monkey with the slime console, or feed them a
sheet of plasma. Simple grabbing the monkey or stuffing them in
disposals do not work anymore. Slime console spawned monkeys will have a
visible status effect, with pheromones coming off them to make this
clearer.
Actions
- Feeding, reproduction and evolution is no longer a verb.
- Slime feeding is no longer an action button. You have to use right
click, or as previously, mousedrop. Slimes can always unbuckle from mobs
they are attached to.
Hunger
- Instead randomly changing the starvation and max nutrition values
while growing up, evolution costs 200 nutrion. This makes the code more
readable, and behaviour more predictable, while still giving the
intended time between evolving and splitting. As a result, I could also
turn these into defines.
- Added a component that handles doing an effect over time while buckled
to a mob, until the mob dies or you get unbuckled.
- Slimes gained nutrition is no longer randomly multiplied by the damage
config value, but rather gain nutrition equal to twice the damage dealt.
You'll have to eat one monkey to evolve, just as before.
- Slimes do not heal passively. They only heal from eating. It was a
rather miniscule value that did not have much effect.
- Slimes generate electricity from hunger threshold, instead of the
random amount of hunger threshold + 100.
Environment
- Slimes take 15 damage from cold every second, instead of using a
complex formula (that also decreased the damage up to a point?).
- Slimes still heal from burn damage, but this is now set on the damage
coefficient list.
- Slimes instead of getting stunned by the cold, freeze in an ice cube.
BZ instead of setting them unconscious, calls the stasis status effect,
allowing you to safely stash your hungry slimes for later. They also no
longer slow down from the cold, as they are already slowed down by the
damage they get. Conversely they no longer get a speed up from a random
amount of temperature. I could be convinced to readd this either as part
of the basic sensitive component, or a similar one.
AI
- Removed the attacked_stacks system. Slimes will just perform regular
retaliation if you hit them in a harmful manner.
- Slimes now use the pet orders component. They will interrupt their
feeding when given a command by their master.
- Slimes have their own subtrees. I tried to replicate as much as I
could from the old code, dividing ancient code artifacts and intentional
stuff, so there might be some weirdness.
- Slime speech has been almost fully reduced to basic blorbing, as you
can not even understand them anymore, and most of them require the slime
to loop through all of their surroundings.
- Discipline does not have stacks either. Disciplined baby slimes have a
chance to clear their attack and hunt blackboard keys. All slimes will
stop feeding on the target otherwise.
- Since discipline is not a stack, rabidity instead gets removed at a
10% chance per disciplining.
- Slimes faces are a bit more randomly picked now.
- We want to convert all simple animals to basic mobs. Old slime code
was also very strange, and had some systems that have been replicated by
components.
- Slimes fully paralyzing you is not fun at all. Knockdown should give
you a fighting chance when a slime would like to eat you.
- Slimes slow down from the heavy damage they get from the cold, so I
don't think they need extra slowdown, nor do they need to speed up from
warmth, as they are already fast.
- Slimes turning into an icecube instead of becoming paralyzed from the
cold is more fun for the slimes, as they can break out for a few
moments. It is also funny.
- Slimes entering proper stasis from BZ is not just a visual indicator
of a slime that is safe to approach, but also keeps the slimes's hunger
value in check, allowing it to not starve while stopped. They can also
look around and blorble, instead of staring at a black screen, if player
controlled.
- The attack_stack and discipline_stack behaviours were rather
overcomplicated, and the xenobio mains I talked with didn't even know it
was a thing, so I argue it needed simplification.
- The bespoke friendship system of slimes was also too complicated.
Slimes slowly gained levels of trust, and at certain levels commands
costed friendship, and other levels, they did not. The binary friend/not
friend system that everything else in the game uses is much more
sensible.
- Using right click for feeding is much more sensible than using an
action, and then picking someone from a dropdown.
- Slime speech was very soulful but not only did it loop through
everything in sight, you couldn't even understand it unless you spoke
slime. Maybe it can be readded later in a different form.
- Slime's passive healing was miniscule, and having them rely on feeding
is more interesting.
also
fixes #81463
🆑
refactor: Slimes are now basic mobs. Please report any strange
behaviours!
balance: Slimes only stun you for two seconds when they shock you, the
rest of the duration is a knockdown.
balance: Slimes are not stunned from the cold, but rather, get frozen in
a freon icecube. BZ also puts them in complete stasis, instead of making
them unconscious. Their speed is likewise unchanged by temperatures.
balance: Slimes do not passively heal, they instead rely on feeding.
fix: Slimes can use the buckling screen alert to unbuckle and stop
feeding, along with clicking on the mob they are riding
/🆑
* Oh, right.
* Fixes AI verb Jump To Network (#70016)
* check for camera loc to not be a silicon
* check for z=0 instead
* Update code/modules/mob/living/silicon/ai/ai.dm
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* evil touch
* redundancy
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Removes camera assembly structures (#81656)
Removes the camera assembly structure middleman between the camera
wallframe and camera machine. All its behavior has been instead moved to
the camera, and I've tried to keep as much of the behavior the same as
before.
This also fixes the issue that camera assemblies had where, upon the
construction being finished, it would move itself into the newly
finished camera machine, therefore taking itself off a wall, therefore
deconstructing itself. This resulted in 2 piece of iron being in each
camera machine (except roundstart ones), and because camera machines
rely on the assembly inside of them for upgrades and such, upgrading
didn't work at all.
I've also made camera nets use defines (not in map) so it's easier to
find a list of them all, and tried to add autodoc comments to nearly
every var in camera code.
Removes copy paste and spaghetti code between structure and machine
camera, thus making it easier to work around with.
Closes https://github.com/tgstation/tgstation/issues/79019
🆑
fix: Cameras built in-round can be upgraded again.
fix: Deconstructing cameras now more consistently return to you the
upgrades inside of the camera.
fix: RD's telescreen can now properly see Ordnance cameras again.
fix: [Deltastation] Library art gallery no longer has an invisible
camera.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
* [MDB Ignore] Combines Cargobus consoles with Dept. Order Consoles, freeing all departments of 1 whole tile of space (#82210)
## About The Pull Request
- Departmental orders are now an NTOS app
- To download, they require `ACCESS_COMMAND`.
- To use, they require one access from the department.
- This means you cannot order things from not-your-department unless you
have an ID.
- When newly downloading the app, it will prompt a head of staff to
insert an ID, to determine which department to be linked to.
- Changes chat room overlay from the kind that AI uploads use to a new
icon.
- Minor refactors to department order in general.
## Why It's Good For The Game
These two computers are surprising waste spacers for two things which
are tied together.
So why not combine them?
The lesser used cargobus chat is still there, and departmental orders
are front and center.
This gives mappers a ton more leeway when mapping departments out and is
overall less clutter.
## Changelog
🆑 Melbert
qol: Cargobus chat console and Departmental Order console are now
combined into one.
qol: Mod PCs active on the "chat client" apps no longer look like AI
uploads (and now have their own sprite)
refactor: Departmental order consoles were refactored a bit, report any
oddities.
/🆑
* This should cut it.
* Was it really just skub?
* [No GBP] Fixes slow slime feed (#82284)
## About The Pull Request
Slimes were supposed to gain the same amount of nutrition as the damage
they dealt while feeding. However, I have accidentally multiplied this
again by `seconds_between_ticks` a second time. This meant that locally
slimes fed normally, but on the server they got about the third
nutrition they were supposed to, probably due to having more ticks per
second then my machine. This PR fixes that.
Also raised the nutrition gained by slimes by 20%, after careful
testing, one monkey wasn't always enough.
## Why It's Good For The Game
Fixes #82283
## Changelog
🆑
fix: Slimes now feed faster, and should only need one monkey to reach
their next lifestage.
/🆑
* [No GBP] Fixes a slime speed config and ai controller null error in slime nutrition handling (#82330)
## About The Pull Request
Someone has linked the runtimes logs of round 226376 to show off a
runtime, and I took a look, and found some unrelated runtimes in slime
code.
- The config file for slime slowdown was still using the simple_animal
path. This has been fixed.
- Somehow, a grey slime has lost its AI controller, and when it got
hungry, it runtimed. For now, a coalesce operator has been put in place.
Later, an investigation is needed to figure out where did its AI
controller go.
## Why It's Good For The Game
Runtimes bad.
## Changelog
🆑
fix: Slime properly load their slowdown values from the config files.
fix: Slimes who lose their AI controller will no longer runtime when
they get hungry.
/🆑
* [No GBP] Slime stasis fixes (#82304)
## About The Pull Request
`handle_environment` is never called when the target was in stasis, so
slimes stayed in stasis forever. This PR fixes that, albeit in an ugly
way.
It also makes slimes actually not get hungry while in stasis.
## Why It's Good For The Game
Fixes #82300
I also claimed slimes can be safely kept in stasis, but I didn't
actually put a stasis check before handle_nutrition. This is fixed now.
## Changelog
🆑
fix: Slimes stop being in stasis when taken out of a BZ filled
environment
fix: Slimes no longer become hungry while in stasis
/🆑
* Add a unit test to check that maploaded simple/basic mobs are in an environment they can survive in. (#82180)
I've recently noticed that the maploaded penguins from the snowdin away
mission were dying from unsafe atmos/temperature. This sparked the idea
of making a (focus only) unit test that would prevent this sort of
issues from happening.
This PR also implements the usage of the `atmos_requirements` and
`body_temp_sensitive` elements for simple animals too, cutting down the
copypaste.
More unit tests to make sure things are done correctly.
🆑
fix: Made sure that mapped critters (i.e. penguins on the snow cabin
away mission) can survive in the environment they're spawned in.
/🆑
* This all is going to suck.
* A step further
* Is this hell over?
* I hope it is.
* Autosort I suppose
* This should cut it for VoidRaptor
* And Blueshift
* Revert "Autosort I suppose"
This reverts commit 9100de67c30514fc25db3ba29df81d1b0ac54e24.
* Dear god, the chicken.
* I fucking hate mapping
* fixes gas analyzers (#82278)
## About The Pull Request
#82180 accidentally messed up air analyzers being able to read or send
readouts to the chat.
## Why It's Good For The Game
air analyzer good
## Changelog
🆑
fix: air analyzers work again
/🆑
* [NO GBP]Grind & juice fixes (#82272)
- Fixes #82266. Anything that has reagents can be either grinded or
juiced
- If something doesn't have reagents but has grind results it can still
be grinded but not juiced
🆑
fix: anything that has reagents can be either grinded or juiced
fix: stuff that does not have reagents but has grind results can still
be grinded but not juiced
/🆑
* Birdshot Engineering Retrofitting (#81840)
Warning: Nanotrasen Confidential Proprietary Information (NCPI) must
only be accessed and viewed within a Nanotrasen Virtual Environment
(NVE, vNTOS-3). Employees in violation of this information ordnance will
have their wages A) garnished, and B) sent to a labour camp up to a
maximum of ten (10y) years. Questions regarding policies related to NCPI
should be directed towards departmental heads or your sector Central
Command Information Authority (CCIA) personnel.
## About The Pull Request
Credentials Confirmed
The Birdshot Engineering Revitalization Plan (formerly proposal
Blindfold, now BERP) is a procurement effort to address growing
maintenance liabilities and costs on the Skitter-MDR Class Orbital
Station located in the Spinward Stellar Cluster (SSC, Sector 28-7b).
Over the course of the previous year, ongoing analysis data has provided
vital feedback since the station was once again brought into operation
after 17 years of abandonment; and using this data, 4 options were
outlined for the Blindfold Proposal.
1) Abandonment - No Cost. Operations on Birdshot will cease. 28-7b
operations will be moderately impacted.
2) Procurement - Medium Cost. Replace offending station sections
completely with low-cost, working alternatives. Operational gains in
28-7b expected.
3) Do Nothing - No Cost. Moderate long-term impacts to operations in
28-7b.
4) >>>_Was removed_
Option 2 was selected for BERP. Procurement efforts identified 3
solutions and later narrowed it down to 1. Following the selection
process architects were brought in to draft up low-impact refits to the
designated hulk. 5 selections made it past initial drafting, with 3
ultimately being selected for engineering board review. Penultimately
draft proposal 3 was selected for the project and now awaits engineering
certification. The draft plan is provided on the next page:
Following board certification, implementation of the plan will be
commenced by 28-7b Nanotrasen Enigneering Corps. (NECs). Construction
time-frame pending Project Foremans review.
## Why It's Good For The Game
Birdshot Engineering is where this whole station began. Back then,
things were going to look closer to Birdboat Station, but that became
looser and more ill-defined as progress was made on the overall station.
While I was satisfied of the decrepit feel of Birdshot Enigneering
initially, I knew that at some point, it would require modification to
better play into Birdshots strengths.
I've had a long laundry list of a roadmap that I've wanted to implement
since the station was added, and this was the top item. Tier Zero.
Problema Numero Uno. You get the idea. This has been a year of drafting,
redrafting, and redrafting everything until it fit Birdshot right. With
this, we're nearly there. I see this being the definitive Engineering
Department for this station for quite some time to come. However, this
is still a draft and some elements are subject to change as I begin to
work out some of the more minor kinks in the draft such as pipe
locations and transit tubes.
Presently Atmospherics is completely rebuilt from the bottom up. There
is more space, enough to do projects, but you'll have to tear down some
windows and walls to gain it. Nothing ventured, nothing gained. You also
have most of the gas distro line outside. I'm a firm believer in
enabling whatever antics ANY lunatic may have. Atmos techs can rest
assured that outside lines are completely reconfigurable (and powered)
enabling some... unique project prospects. You also gained an inside HFR
and Spare burn chamber. Enjoy.
The Engineering Common Areas are now inside the department proper
instead of the satellite treatment in the original implementation.
Security gets an actual outpost and engineers now have a proper office
to file engineering documentation. They say that office colleagues can
form tight bonds so let's see whose is stronger: Purples or Yellows?
The Supermatter Engine is more of an upgrade over the previous model
(Leaky SM is here to stay so deal with it). The room is larger with less
rock, allowing some manner of greater customization, but I believe
engineers will be more than happy to find that they now have a Burn
Chamber of their own. I have zero clue of what they'll do with it, but I
think any enterprising CE will be able to create something that even god
should fear.
Finally we have maint improvements. Nothing really to see here though
maybe there's the beginning of something for the future if you care to
speculate. I couldn't really keep the meandering maint of the previous
rock, so instead we now have some pseudo dead-ends. It's all connected
by transit tubes to the north (not shown) so you can slowly get around
if you will it. Of course there's plenty of cut-throughs,
not-so-finished sections, and opportunity for those who need it. Caution
to the blind, this whole rock is spicy.
Overall I'm happy with this and want to open it up in Draft Mode for
initial thoughts. I have a rough timeline on finishing this that
stretches out to the weekend, so the earlier comments are, the more
likely I'll be able to MAYBE do something about it. Thanks for the
patience and hopefully this is a doozy of an update for all our players.
Previous Engineering Provided for Point of Reference:
closes #75590
## Changelog
🆑
qol: Wholesale Revamp of Birdshots Engineering Department
fix: Some Birdshot Amtospherics Concerns
fix: Some Birdshot Engine Concerns
/🆑
* Bumps `dependencies.sh` to 515.1633 Stable (#82138)
## About The Pull Request
Two reasons for this.
1. It's the stable branch, so let's move it up. This PR will detect any
issues that we might have with the latest 515.1633 as far as the
codebase is concerned (the servers have been running 1633 for at least a
week now).
2. ~~I'm fucking sick of seeing the Lua Scripting Notice in CI even
though it was fixed a few days ago in #82074
(
|
||
|
SkyratBot
|
031e483e4d |
[MIRROR] New station trait job: Human AI (#26823)
* New station trait job: Human AI (#81681) 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 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. https://github.com/tgstation/tgstation/assets/53777086/e16509f8-8bed-42b5-9fbf-7e37165a11e8 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. 🆑 JohnFulpWillard, Tattax add: Adds a new station trait job: The Human AI. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> * Oh right * so this works * whoooops --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com> |
||
|
John Willard
|
0417e090cc |
Removes camera assembly structures (#81656)
## About The Pull Request Removes the camera assembly structure middleman between the camera wallframe and camera machine. All its behavior has been instead moved to the camera, and I've tried to keep as much of the behavior the same as before. This also fixes the issue that camera assemblies had where, upon the construction being finished, it would move itself into the newly finished camera machine, therefore taking itself off a wall, therefore deconstructing itself. This resulted in 2 piece of iron being in each camera machine (except roundstart ones), and because camera machines rely on the assembly inside of them for upgrades and such, upgrading didn't work at all. I've also made camera nets use defines (not in map) so it's easier to find a list of them all, and tried to add autodoc comments to nearly every var in camera code. ## Why It's Good For The Game Removes copy paste and spaghetti code between structure and machine camera, thus making it easier to work around with. Closes https://github.com/tgstation/tgstation/issues/79019 ## Changelog 🆑 fix: Cameras built in-round can be upgraded again. fix: Deconstructing cameras now more consistently return to you the upgrades inside of the camera. fix: RD's telescreen can now properly see Ordnance cameras again. fix: [Deltastation] Library art gallery no longer has an invisible camera. /🆑 --------- Co-authored-by: san7890 <the@san7890.com> |
||
|
John Willard
|
9ac81e1a64 |
New station trait job: Human AI (#81681)
## About The Pull Request This PR does many things, I'll try to explain the basic/background stuff to the main thing first: 1. Adds a new remote that allows a human to function like an AI. It controls a fly that will fly around the station slowly, and when it reaches a machine then the person can interact with it as if they were an AI. This required changing a lot of silicon/AI checks with one that also checks for this remote, and some messing with shared ui state. 2. Moves req_access from the obj and bot to ``/atom/movable`` which lets it be shared between the two, no more copy-paste and one side lacking features/checks/signals the other has. 3. Adds a check for AI config for AI-related station traits, which was lacking prior Now for the good part... Adds a new station trait that replaces the AI with a Human. This person is equipped with an AI headset (including Binary), an advanced camera console, an omni door wand, the machine controller, and their laws. They are immune to the SAT's turrets (even if set to target borgs) and are slow outside of the SAT, mimicing the actions of the AI. They interact with the world through their advanced camera console, which allows them to do most AI stuff needed, and the holopad they can connect to without having to ring first (like Command can). They are given a paper with the laws they must follow, but since they are human they are able to bend it. Cyborgs that run the default lawset are "slaved" to them via an unremovable law 0, so the Human AI can bend the laws if they really need to (for their own survival n such), and make the cyborgs obey their commands above laws, but in general this shouldn't be a frequent occurrence. This does take into account the unique AI trait, so it's not guaranteed Asimov. When this station trait rolls, all Intellicards, AI uploads, and AI core boards are destroyed and are unresearchable. They can be spawned by admins in-game if necessary. Maybe in the future we can also exclude Oldstation from this but I haven't really decided. Extra perks: Human AI spawns with a Robotic voicebox (unless they are a body purist) and teleport blocking implant, so they can't use teleporters to bypass their on-station slowdown. They also have an infinite laser pointer that can be used to blind through their camera console. This is unfortunately nerfed from the recent borg balance PR that removed its stun. This was meant to be the alternative to no longer being able to permanently lock borgs down like AIs can (or more than one, for that matter). They aren't affected by Roburgers, Acid, and Fuel's toxicity. Bots salute them like they do Beepsky (which is now a trait) They spawn with SyndEye to replace the AI's tracking ability They do not have a bank account ### The machine remote The machine remote has a little fly in it that flies to the machines it is pointed to, working as the arms and legs of the Human AI. It scans the machine and punches in the action the AI does, and is how the AI accesses basically anything. This fly slowly moves from one machine to the next, and can be recalled with Alt Click. It works on machines and bots. ### Video (Low quality to fit Github) https://github.com/tgstation/tgstation/assets/53777086/e16509f8-8bed-42b5-9fbf-7e37165a11e8 ## Why It's Good For The Game I've seen a funny screenshot one day of a person replacing the AI by using a bunch of door remotes, camera console, crew monitoring console, and a few other things. I've been thinking about that for a few years and really wanted to make it official if not easier to make possible, because it is an incredibly funny interaction. This makes it a reality, and while they aren't as powerful as regular AIs, I think it makes for better and funnier in-game moments. With the same weight as Cargorilla (1), I hope this wouldn't be rolling too often and ruin rounds, but instead show off the different capabilities that Humans and AIs can do, to do the job of an AI. You win some you lose some. ## Changelog 🆑 JohnFulpWillard, Tattax add: Adds a new station trait job: The Human AI. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> |
||
|
Ephemeralis
|
bc6a4d993b |
I See Clearly Now: Laser pointer balance adjustments (#25588)
* Laser pointer fixes: remove felinid forced movement, chat notifications, add limited laser pointer type * Comment formatting fixes Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> * Trailing formatting fix Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> * Modularise * Make GCF vendor sell limited laserpointers * Apply suggestions from code review --------- Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
SkyratBot
|
3658c80e57 |
[MIRROR] Explodes device.dmi [MDB IGNORE] (#25523)
* Explodes device.dmi * Demodularize these * Update traitordevices.dm * Update traitordevices.dm * Modularizes hypnotic flash * Modular dmi repath * Modular dmi repath --------- Co-authored-by: YesterdaysPromise <122572637+YesterdaysPromise@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
SkyratBot
|
b15b16976a |
[MIRROR] Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom [MDB IGNORE] (#25516)
* Attack chain refactoring: Broadening `tool_act` into `item_interact`, moving some item interactions to... `atom/item_interact` / `item/interact_with_atom`
* Patches up merge skew (#80197)
## About The Pull Request
Yeah #79968 (
|
||
|
YesterdaysPromise
|
71a1fee2f1 |
Explodes device.dmi (#80025)
## About The Pull Request I woke up today and thought 'what would be easy thing to do today so I can say I've done something?'. Then I remembered I saw several gangtool usages the time I split radio up, and I could remedy those. 7 hours later, device.dmi is split in a folder of its own, and I've also given unique sprites to door remotes and landing desginators. ## Why It's Good For The Game The device.dmi was kind of a mess. ## Changelog 🆑 /🆑 |
||
|
MrMelbert
|
1e76fd70b4 |
Attack chain refactoring: Broadening tool_act into item_interact, moving some item interactions to... atom/item_interact / item/interact_with_atom (#79968)
## About The Pull Request Implements half of this (with some minor changes):  The ultimate goal of this is to split our attack chain in two: - One for non-combat item interactions - Health analyzer scanning - using tools on stuff - surgery - Niche other interactions - One for combat attacking - Item hit thing, item deal damage. - Special effects on attack would go here. This PR begins this by broadining tool act into item interact. Item interact is a catch-all proc ran at the beginning of attack chain, before `pre_attack` and such, that handles the first part of the chain. This allows us to easily catch item interaction and cancel the attack part of the chain by using deliberate bitflag return values, rather than `TRUE` / `FALSE`*. *Because right now, `TRUE` = `cancel attack`, no matter what, which is unclear to people. Instead of moving as much as possible to the new proc in this PR, I started by doing some easy, obvious things. More things can be moved in the future, or technically they don't even need to move in a lot of cases. ## Changelog 🆑 Melbert refactor: Refactored some methods of items interacting with other objects or mobs, such as surgery and health analzyers. Report if anything seems wrong /🆑 |
||
|
SkyratBot
|
4c01e3f805 |
[MIRROR] Demotes the "electrical conductivity" flag from flags_1 to obj_flags [MDB IGNORE] (#25381)
* Demotes the "electrical conductivity" flag from `flags_1` to `obj_flags` (#80033) ## About The Pull Request Code to handle this flag only ever existed on the `/obj` sublevel, so there's no need for it to be on the `/atom` level `flags_1`. There was probably a point in time in which mobs or turfs conducted electricity but there's zero code for it anymore so we truly just live in a society now. ## Why It's Good For The Game Frees up a slot on `flags_1` (which is really nice actually), proper scoping of certain bitflag stuff, etc. ## Changelog Not relevant to players. I may have screwed something up, will be doing a few passes on this myself to ensure all the search and replaces went alright but we should be good™️ * Demotes the "electrical conductivity" flag from `flags_1` to `obj_flags` * Modular * Update misc.dm --------- Co-authored-by: san7890 <the@san7890.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
SkyratBot
|
7dd661f342 |
[MIRROR] basic cats and mini kitchen helpers [MDB IGNORE] (#25330)
* basic cats and mini kitchen helpers (#79800) ## About The Pull Request this pr transforms cats into basic pets! cats now have some new behavior. they can carry fish and hunted mice in their mouths to deliver it to kittens, and kittens will eat them.   if a kitten sees you holding food, it will point at you and meow loudly until u give it the food. becareful when putting male cats near each other, there is a small chance they get into a heated argument and meow loudly at each other until one of them flees. also added a new small cat house for cats. cats will use these homes if u build one near them (using 5 wood planks)  Chefs can craft the cake cat and breadcat. these are useful cats because they can help the chef around in the kitchen. they will turn stoves and grills off when food is ready, so they dont burn. and the cake cat will help the chef decorate his donuts ## Why It's Good For The Game refactors cats into basic mobs and gives them a deeper ai ## Changelog 🆑 refactor: cats are now basic pets. please report any bugs. add: the cake cat and bread cat can now help the chef around in the kitchen /🆑 * basic cats and mini kitchen helpers * Modular --------- Co-authored-by: Ben10Omintrix <138636438+Ben10Omintrix@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
san7890
|
7f7688b60a |
Demotes the "electrical conductivity" flag from flags_1 to obj_flags (#80033)
## About The Pull Request
Code to handle this flag only ever existed on the `/obj` sublevel, so
there's no need for it to be on the `/atom` level `flags_1`. There was
probably a point in time in which mobs or turfs conducted electricity
but there's zero code for it anymore so we truly just live in a society
now.
## Why It's Good For The Game
Frees up a slot on `flags_1` (which is really nice actually), proper
scoping of certain bitflag stuff, etc.
## Changelog
Not relevant to players.
I may have screwed something up, will be doing a few passes on this
myself to ensure all the search and replaces went alright but we should
be good™️
|
||
|
Ben10Omintrix
|
ce6f2724cd |
basic cats and mini kitchen helpers (#79800)
## About The Pull Request this pr transforms cats into basic pets! cats now have some new behavior. they can carry fish and hunted mice in their mouths to deliver it to kittens, and kittens will eat them.   if a kitten sees you holding food, it will point at you and meow loudly until u give it the food. becareful when putting male cats near each other, there is a small chance they get into a heated argument and meow loudly at each other until one of them flees. also added a new small cat house for cats. cats will use these homes if u build one near them (using 5 wood planks)  Chefs can craft the cake cat and breadcat. these are useful cats because they can help the chef around in the kitchen. they will turn stoves and grills off when food is ready, so they dont burn. and the cake cat will help the chef decorate his donuts ## Why It's Good For The Game refactors cats into basic mobs and gives them a deeper ai ## Changelog 🆑 refactor: cats are now basic pets. please report any bugs. add: the cake cat and bread cat can now help the chef around in the kitchen /🆑 |
||
|
SkyratBot
|
af9ed1ee04 |
[MIRROR] Basic Space Dragon [MDB IGNORE] (#24340)
* Basic Space Dragon (#78979) * Basic Space Dragon --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
Jacquerel
|
cf5c1fa08c | Basic Space Dragon (#78979) | ||
|
SkyratBot
|
d45b0e5fc0 |
[MIRROR] Laser pointer update: Shining Through Walls Edition (feat. fixes!) [MDB IGNORE] (#23044)
* Laser pointer update: Shining Through Walls Edition (feat. fixes!) * Update laserpointer.dm --------- Co-authored-by: Sealed101 <cool.bullseye@yandex.ru> Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com> |
||
|
Sealed101
|
b22ff1a4eb |
Laser pointer update: Shining Through Walls Edition (feat. fixes!) (#77007)
# _PR PSA_  ## About The Pull Request Cleans up code for laser pointers, fixing some bugs like the forever-charging state or affecting dead cats along the way. Remaining charge is now available upon examine. Canonizes #45834 by implementing an upgrade to the laser pointers: installing a bluespace crystal into a laser with tier 3 or higher laser diode lets it shine through walls. Using an upgraded laser uses twice the charge of a normal one. Of course, you can only shine it on something if you can see the target behind the wall, like via x-ray or thermals. Mesons don't count, however. If one tries to jam a crystal into a pointer with a tier 1/2 laser (or a tier 1/2 laser in a pointer with an installed crystal), _something_ will get teleported, crushing the crystal. You can uninstall the crystal with wirecutters or a hemostat. The pointer will _hint_ on closer examination (`examine_more`) at a possibility of a crystal being installed if you upgrade the laser (different messages for tier 1/2/3,4). Removes one stupid 1% increase for a recharge chance per process tick if your laser was in a full recharge state because it was insignificant and irrelevant. i've had a branch for this for almost 9 months and i was always laying it off for some day later. today i just completely fucked the branch. whoops. i'm not even sure at this point what else did i fix while here, double whoops ## Why It's Good For The Game Closes #45834 - Canonizes a bug into a feature. Fixes #77003 - lol Cleaner code, possibly more robust even. Seeing the remaining charge was not available at all and the only hint was when you tried shining the pointer on something. That sucks. ## Changelog 🆑 add: you can upgrade laser pointers with a bluespace crystal to let them shine through walls at double the power cost, if the laser in the pointer is of tier 3 or higher. qol: laser pointer charge can be seen by examining it fix: fixed laser pointers luring dead cats when shone upon code: laser pointer code cleaned up a tad /🆑 --------- Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
SkyratBot
|
c0799c48c0 |
[MIRROR] A small pile of borg combat changes [MDB IGNORE] (#22704)
* A small pile of borg combat changes (#75819) ## About The Pull Request This PR rebalances borg combat. It is first part of broader set of changes that I talked about with armhullen, which was then discussed in discord player project channel. Ultimately arm decided to rewrite the complete rebalance and grab combat, but to help with testing, and to measure reaction to that changes, I wrote this much smaller change, that should be usable as a TMd test. Main points that changed: - Flashing cyborgs for the first time blinds them, and scrambles their movement. Flashing them while they are blinded immobilizes them as it used to, but still allows them to talk, and use radio. - Emping cyborgs still turns them completely off, but the code behind is _slightly_ changed, because of how utterly incomprehensible cyborg code is - Borg stunarm deals 60 stamina damage, costs 200 energy (SUBJECT TO CHANGE AS SOON AS I DECIDE ON HOW TO), and applies confusion, stuttering, and jittering. - Robot consoles used by humans can now lock down only one borg at a time, they exhibit increased power draw while doing so. The borg is also informed of the location of the console. If left alone, the borg will unlock itself in 10 minutes, to avoid leaving it permanently locked down in some faraway place. If the console gets destroyed (or depowered), the borg will get unlocked - laser pointer only blinds borgs, without the paralyze component. If you flash a borg blinded this way it will paralyze it, so comboing it is possible. - Throwing things at borgs slows them down Not planned, but possible if testing shows its required: - Changing borg health to malfunctions - Whatever people convince me to add - Portable lockdown solution for sec, or a way for them to do basic check on borg. - Usage of bucket/something else to restrict radio usage of cyborg If you have ideas what would make this change better please use [discord channel](https://discord.com/channels/326822144233439242/1113145741788065924), or comments. Almost everything that I wrote here is subject to change, as requested or suggested. ### DISCLAIMER I had to change few functions in background of how borgs work. This WILL have changes I couldn't predict, since some of them aren't linked in any obvious way in code. I am aware of that, and will try fixing what needs fixing when pointed out. PS: Borg code is a nightmare ## Why It's Good For The Game Borg combat sucks. It is absolutely binary, there is 0 capacity for talking, because both sides fear losing in one click. Sec can't really feasibly ask the borg to state laws while flashed, so their only solution is to kill it and revive it. - Turning most instastun solutions into less lethal versions should lessen the pressure, since it reduces the chance that person that reacts first survives. - It causes minor reduction in traitor's capacity to emag borgs with only a flash, but EMPs still hardstun, and they are plentiful both in uplink, and in ghetto form, so that shouldn't be a problem. - Since it allows borgs to scream for help while being flashed, it also increases the potential of AI helping it, or at least noticing its death. - Lockdown console changes reduce its capability in completely turning off malf ai, and leave it still highly capable of being an useful tool in stopping emagged cyborgs. ## Changelog 🆑 balance: Flashing borgs requires two consecutive flashes to fully immobilize balance: Flashed borgs can speak balance: Remote lockdown on cyborgs lasts 180 seconds balance: Cyborg stun arm works like normal baton, and costs less energy /🆑 --------- Co-authored-by: ATH1909 <42606352+ATH1909@ users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@ gmail.com> * A small pile of borg combat changes --------- Co-authored-by: Kubisopplay <38842052+Kubisopplay@users.noreply.github.com> Co-authored-by: ATH1909 <42606352+ATH1909@ users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@ gmail.com> |
||
|
Kubisopplay
|
b3ac4e1c7d |
A small pile of borg combat changes (#75819)
## About The Pull Request This PR rebalances borg combat. It is first part of broader set of changes that I talked about with armhullen, which was then discussed in discord player project channel. Ultimately arm decided to rewrite the complete rebalance and grab combat, but to help with testing, and to measure reaction to that changes, I wrote this much smaller change, that should be usable as a TMd test. Main points that changed: - Flashing cyborgs for the first time blinds them, and scrambles their movement. Flashing them while they are blinded immobilizes them as it used to, but still allows them to talk, and use radio. - Emping cyborgs still turns them completely off, but the code behind is _slightly_ changed, because of how utterly incomprehensible cyborg code is - Borg stunarm deals 60 stamina damage, costs 200 energy (SUBJECT TO CHANGE AS SOON AS I DECIDE ON HOW TO), and applies confusion, stuttering, and jittering. - Robot consoles used by humans can now lock down only one borg at a time, they exhibit increased power draw while doing so. The borg is also informed of the location of the console. If left alone, the borg will unlock itself in 10 minutes, to avoid leaving it permanently locked down in some faraway place. If the console gets destroyed (or depowered), the borg will get unlocked - laser pointer only blinds borgs, without the paralyze component. If you flash a borg blinded this way it will paralyze it, so comboing it is possible. - Throwing things at borgs slows them down Not planned, but possible if testing shows its required: - Changing borg health to malfunctions - Whatever people convince me to add - Portable lockdown solution for sec, or a way for them to do basic check on borg. - Usage of bucket/something else to restrict radio usage of cyborg If you have ideas what would make this change better please use [discord channel](https://discord.com/channels/326822144233439242/1113145741788065924), or comments. Almost everything that I wrote here is subject to change, as requested or suggested. ### DISCLAIMER I had to change few functions in background of how borgs work. This WILL have changes I couldn't predict, since some of them aren't linked in any obvious way in code. I am aware of that, and will try fixing what needs fixing when pointed out. PS: Borg code is a nightmare ## Why It's Good For The Game Borg combat sucks. It is absolutely binary, there is 0 capacity for talking, because both sides fear losing in one click. Sec can't really feasibly ask the borg to state laws while flashed, so their only solution is to kill it and revive it. - Turning most instastun solutions into less lethal versions should lessen the pressure, since it reduces the chance that person that reacts first survives. - It causes minor reduction in traitor's capacity to emag borgs with only a flash, but EMPs still hardstun, and they are plentiful both in uplink, and in ghetto form, so that shouldn't be a problem. - Since it allows borgs to scream for help while being flashed, it also increases the potential of AI helping it, or at least noticing its death. - Lockdown console changes reduce its capability in completely turning off malf ai, and leave it still highly capable of being an useful tool in stopping emagged cyborgs. ## Changelog 🆑 balance: Flashing borgs requires two consecutive flashes to fully immobilize balance: Flashed borgs can speak balance: Remote lockdown on cyborgs lasts 180 seconds balance: Cyborg stun arm works like normal baton, and costs less energy /🆑 --------- Co-authored-by: ATH1909 <42606352+ATH1909@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com> |
||
|
SkyratBot
|
8782f19258 |
[MIRROR] Stabilizes code that flicks overlays to view/all clients [MDB IGNORE] (#22601)
* Stabilizes code that flicks overlays to view/all clients (#76937) ## About The Pull Request Rather then using images and displaying them with client.images, we can instead simply make an object, give it the passed in image/MA's appearance, and then vis_contents it where we want. If you want to animate things, you can just use the atom we return from the proc call. This ends up costing about 25% of the best case scenario (one guy online) It will save more time with more users, but it also allows us to avoid the hypersuffering that is passing GLOB.clients into the flick proc. So I think I'm happy enough with this. For context, here's average per call cost for flick_overlay_view() right now. It winds between 5e-5 and 1e-4. With these changes we should pretty consistently hit the low end of this, because none of our work really varies all that much.  (I was using sswardrobe for this, but it ends up being a lot slower so like, why yaknow) ``` /atom/movable/flick_visual New: 3.65625ms Provide: 7.4375ms Qdel: 9.4375ms Stash: 9.46875ms ``` ## Why It's Good For The Game Using our tools should not make your code eat cpu time for no reason. Hearers is expensive, iterating clients is expensive, let's not be expensive. * Stabilizes code that flicks overlays to view/all clients * Not every client needs to see this * and these could be using SECONDS * grr DM * Convert these modular files to seconds too * Update dance_machine.dm --------- Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com> Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com> |
||
|
LemonInTheDark
|
68184a2e50 |
Stabilizes code that flicks overlays to view/all clients (#76937)
## About The Pull Request Rather then using images and displaying them with client.images, we can instead simply make an object, give it the passed in image/MA's appearance, and then vis_contents it where we want. If you want to animate things, you can just use the atom we return from the proc call. This ends up costing about 25% of the best case scenario (one guy online) It will save more time with more users, but it also allows us to avoid the hypersuffering that is passing GLOB.clients into the flick proc. So I think I'm happy enough with this. For context, here's average per call cost for flick_overlay_view() right now. It winds between 5e-5 and 1e-4. With these changes we should pretty consistently hit the low end of this, because none of our work really varies all that much.  (I was using sswardrobe for this, but it ends up being a lot slower so like, why yaknow) ``` /atom/movable/flick_visual New: 3.65625ms Provide: 7.4375ms Qdel: 9.4375ms Stash: 9.46875ms ``` ## Why It's Good For The Game Using our tools should not make your code eat cpu time for no reason. Hearers is expensive, iterating clients is expensive, let's not be expensive. |
||
|
SkyratBot
|
c4d4e1da63 |
[MIRROR] Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. [MDB IGNORE] (#20916)
* Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. * AI GEN RUN ONE --------- Co-authored-by: ArcaneMusic <41715314+ArcaneMusic@users.noreply.github.com> Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com> |
||
|
ArcaneMusic
|
f2fd69a49a |
Minerals have been refactored so costs and minerals in items are now in terms of mineral defines. (#75052)
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you all here (through the automatic reviewer request system). So, mineral balance! Mineral balance is less a balance and more of a nervous white dude juggling spinning plates on a high-wire on his first day. The fact it hasn't failed after going on this long is a miracle in and of itself. This PR does not change mineral balance. What this does is moves over every individual cost, both in crafting recipes attached to an object over to a define based system. We have 3 defines: `sheet_material_amount=2000` . Stock standard mineral sheet. This being our central mineral unit, this is used for all costs 2000+. `half_sheet_material_amount=1000` . Same as above, but using iron rods as our inbetween for costs of 1000-1999. `small_material_amount=100` . This hits 1-999. This covers... a startlingly large amount of the codebase. It's feast or famine out here in terms of mineral costs as a result, items are either sheets upon sheets, or some fraction of small mats. Shout out to riot darts for being the worst material cost in the game. I will not elaborate. Regardless, this has no functional change, but it sets the groundwork for making future changes to material costs much, MUCH easier, and moves over to a single, standardized set of units to help enforce coding standards on new items, and will bring up lots of uncomfortable balance questions down the line. For now though, this serves as some rough boundaries on how items costs are related, and will make adjusting these values easier going forward. Except for foam darts. I did round up foam darts. Adjusting mineral balance on the macro scale will be as simple as changing the aforementioned mineral defines, where the alternative is a rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~ Items individual numbers have not been adjusted yet, but we can standardize how the conversation can be held and actually GET SOMEWHERE on material balance as opposed to throwing our hands up or ignoring it for another 10 years. |
||
|
SkyratBot
|
c325783977 |
[MIRROR] a borg who's somehow immune to flashes will no longer still be disabled by laser pointers [MDB IGNORE] (#20622)
* a borg who's somehow immune to flashes will no longer still be disabled by laser pointers (#74596) ## About The Pull Request Resolves an extreme edge case where if (via adminbus or a downstream's changes) a borg is somehow immune to being flashed, a laser pointer would still be able to blind them. ## Why It's Good For The Game Aerial rodent made its ninja cyborgs flashproof, but they're not laser pointer-proof due to this bug. I figured that fixing this bug upstream would be best, in case some insane /tg/ admin (or coder 😳) attempts to flashproof a borg at some point in the distant future. ## Changelog 🆑 ATHATH fix: Laser pointers will no longer disable borgs that have somehow been made immune to flashes. /🆑 --------- Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com> * a borg who's somehow immune to flashes will no longer still be disabled by laser pointers --------- Co-authored-by: ATH1909 <42606352+ATH1909@users.noreply.github.com> Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com> |
||
|
ATH1909
|
04ae3281c5 |
a borg who's somehow immune to flashes will no longer still be disabled by laser pointers (#74596)
## About The Pull Request Resolves an extreme edge case where if (via adminbus or a downstream's changes) a borg is somehow immune to being flashed, a laser pointer would still be able to blind them. ## Why It's Good For The Game Aerial rodent made its ninja cyborgs flashproof, but they're not laser pointer-proof due to this bug. I figured that fixing this bug upstream would be best, in case some insane /tg/ admin (or coder 😳) attempts to flashproof a borg at some point in the distant future. ## Changelog 🆑 ATHATH fix: Laser pointers will no longer disable borgs that have somehow been made immune to flashes. /🆑 --------- Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com> |