## About The Pull Request
This PR sort-of brings back old IEDs, albeit much more freeform compared
to their previous iteration. Using #94861's ``spark_act`` interactions
they can now be made by filling up a soda can with a variety of
chemicals (welding fuel being the easiest to obtain), dunking in a piece
of wire, taping it up (optional, required if using welding fuel or
plasma) and lighting it on fire with a lighter or welding tool (anything
that's hot enough works, really)
They have a random delay of 2-4 seconds, and can be disarmed by snipping
the fuse with wirecutters in time before they detonate (or don't,
depending on the mixture)
There's also a new, more "professional" improvised chemical explosive in
the form of beakerbombs. These can be assembled by putting a lid on a
beaker (alt-click, prevents the beaker from spilling its contents when
thrown) and attaching an assembly with an igniter or a condenser to it.
<img width="150" height="90" alt="dreamseeker_2OKpZeN7ay"
src="https://github.com/user-attachments/assets/599e75ea-9653-4db9-a915-b2ca6307635f"
/>
When triggered, igniters will heat the reagents up by a bit while
condensers will cool them down. However, you can also attach and wire up
a power cell, which will cause it to dump all of its power into the
beaker when the igniter fires off, triggering ``spark_act`` interactions
potentially causing a larger explosion.
<img width="534" height="447" alt="dreamseeker_k9Uzf18Eoa"
src="https://github.com/user-attachments/assets/4cfed5b4-3875-4522-9bfa-5f6a3c8e0864"
/>
Decently sized boom from The Contraption.
Plasma and welding fuel's potency inside of beakerbombs/soda cans is
significantly reduced compared to other riggable objects (strengthdiv is
3 times higher) as they're very easy to obtain and would make for very
powerful explosives, considering their very strong strengthdiv as most
rigging interactions use very little fuel/plasma to cause a large
explosion, which was carried over to the new system. (Don't worry, this
still leaves them at sensible values with welding fuel being about as
strong as old IEDs on average)
Closes#94990 via having plasma's electrical power modifier have a
decline past a certain point based on its volume
## Why It's Good For The Game
#81529 didn't justify IED removal whatsoever and I think with new
mechanics these can be used as easier (but weaker) to make improvised
bombs, being much less clunky to make and use than pipebombs.
Beakerbombs are essentially a somewhat weaker (even with metamat
beakers, you're still 20u short of a normal large beaker grenade at
200u) form of grenades, but have access to new interactions involving
charged up explosions, which could make for some variety among chemists'
weaponry.
## Changelog
🆑
add: Added back IEDs made by attaching some wire and tape to a soda can
filled with fuel, plasma, or any other explosive of your choice. They
need to be lit on fire with a lighter or a welding tool.
add: You can now attach a lid to beakers with alt-click, preventing them
from being spilled when thrown.
add: Added beakerbombs, made by attaching an assembly (with optional
power cell and wiring) to a lidded beaker.
balance: Rigged explosions now create flames.
balance: Plasma explosions now limit their explosion potency past a
certain point based on their volume
/🆑
## About The Pull Request
<img width="579" height="67" alt="image"
src="https://github.com/user-attachments/assets/d7a4427e-2a6e-44d3-94ba-c90a2d474984"
/>
Simple rotation components number in the 8-9k range per round, and each
contains a needless callback datum as well.
These do not need to hold any state and can be bespoke elements, and the
proc to do things post_rotation can just be a normal atom proc.
<details><summary>Still works as you'd expect, including items that have
flag requirements like the wrench</summary>
</details>
## Why It's Good For The Game
Makes a heavily used element much more lightweight, saves a few mb of
memory.
## Changelog
🆑
refactor: simple rotation component has been refactored into an element
Please report any bugs to github.
/🆑
## About The Pull Request
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).
## Changelog
🆑 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)
/🆑
## About The Pull Request
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.
## Why It's Good For The Game
Improving old code. And I want to be able to pet mobroaches while
holding them too.
## Changelog
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
## About The Pull Request
- Fixes#89242
- Fixes balloon alert runtime when the assembly is secured & the holder
cannot be attached
## Changelog
🆑
fix: fixes balloon alert runtimes with assembly holder
/🆑
## About The Pull Request
1. Having a broken arm will affect your accuracy when firing a weapon
with that arm, even potentially causing damage to you if it's a weapon
with recoil. This effect is not applied under the effects of a
painkiller.
2. The sister effect of this (punching someone with a broken arm) now
also has an interact with painkillers (it can no longer block your
attack).
3. Being drunk heavily affects ranged weapon accuracy, unless you're the
bartender
4. A lot of hand handling cleanup, using new macros to make it a lot
more readable at a glance
## Why It's Good For The Game
We have this system for modifying firearm accuracy but we don't really
use it commonly, and I feel like it slots in well with a lot of places
For broken arms, it adds some more depth to the wound system, in the
same way that trying to punch someone with a broken arm causes pain. (I
actually want to expand this to melee weapon accuracy and attacking with
melee weapons in general, but that's for a later time)
For drunkenness, it just adds to the drunk shenanigans. It also slightly
reduces the effectiveness of drinks as combat healing chemicals, such as
quadsec - makes it a bit more of a trade off.
## Changelog
🆑 Melbert
balance: Having a broken arm affects your accuracy with ranged weapons
fired with that arm. Utilizing a painkiller will nullify this effect,
however.
balance: Painkillers will prevent your punches from being cancelled due
to having a broken arm. You'll still take damage, though.
balance: Being drunk now affects your accuracy with ranged weapon. The
bartender is immune to this effect via their skillchip.
code: A lot of code involving left and right hand handling has been
cleaned up, easier to read. Report any oddities, like left and rights
being flipped
/🆑
## About The Pull Request
Rewrites how alt click works.
Based heavily on #82625. What a cool concept, it flows nicely with
#82533.
Fixes#81242
(tm bugs fixed)
Fixes#82668
<details><summary>More info for devs</summary>
Handy regex used for alt click s&r:
`AltClick\((.*).*\)(\n\t.*\.\.\(\))?`
`click_alt($1)` (yes I am aware this only copies the first arg. there
are no other args!)
### Obj reskins
No reason for obj reskin to check on every single alt click for every
object. It applies to only a few items.
- Moved to obj/item
- Made into signal
- Added screentips
### Ventcrawling
Every single atmospherics machine checked for ventcrawling capability on
alt click despite only 3 objects needing that functionality. This has
been moved down to those individual items.
</details>
## Why It's Good For The Game
For players:
- Alt clicking should work more logically, not causing double actions
like eject disk and open item window
- Added context menus for reskinnable items
- Removed adjacency restriction on loot panel
For devs:
- Makes alt click interactions easier to work with, no more click chain
nonsense and redundant guard clauses.
- OOP hell reduced
- Pascal Case reduced
- Glorious snake case
## Changelog
🆑
add: The lootpanel now works at range.
add: Screentips for reskinnable items.
fix: Alt click interactions have been refactored, which may lead to
unintentional changes to gameplay. Report any issues, please.
/🆑
## 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
🆑
/🆑
## 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™️
## About The Pull Request
I'm a bit sad about the state of trashbags.
They're very clunky to use, so they almost never get touched. S
depressing. Let's try and fix that.
Let's make em fit in the belt slot (again), but as a tradeoff we'll make
it harder to pull one thing from your bag.
We'll give it a say, 1.5 second delay, so you can't quickdraw from em.
If you try and dump them out into something else, we'll throw any
spillover on the ground below you
I'm also doing some general code cleanup here. Making procs more
readable, vars more direct, removing some old legacy stuff.
I've added a remove_single proc to hook into via subtype, which takes a
mob as input. this has required placing extra requirement on some helper
procs, but fortunately it's not something they're unable to meet.
My hope is this will make garbage bags usable without being stupid.
## Why It's Good For The Game
I don't see these get used at all, cause they're a pain to carry around.
They got gimped because people were using them as infinite storage for
shotgun shells and other small items.
I've made using them for this sort of thing hard and slow, so I think we
oughta be fine. If not I'll do some more touching, maybe give the
autodrop a delay.
## Changelog
🆑
balance: The janitor's trashbag now fits on his belt. In exchange,
taking something out of it sends a visible message, and has a delay.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Soft revert of #71224 , Fixes#71222
Fixes an exploit involving attachment of multiple igniters to one
assembly.
- Multiple igniters or condensers can no longer be attached to the same
assembly holder
- Assembly holders have a limit of 12 assemblies maximum
- I'm not sure if this is too low or limited, I picked it arbitrarily.
Please inform me if it could be upped a smidge.
- This lag exploit was born because of limitless assembly holders, which
is a little silly even with the exploit aside. All that uncapped holders
can bring are exploits or bugs, which I feel confident limited can
prevent. What use is there even for having so many?
- Cleans up / refactors some aspects of assemblies and assembly holders.
- Assemblies had a weird wire type flag that was only ever used by
signallers, but also used wrong by signallers. I did some scanning of
the code and realized that ... a lot of this was just straight up
unused, and not even assigned anywhere.
- Now, there is a flag assembly flag var, which everything is read off
of. Tested it and still seemed to all work fine.
## Why It's Good For The Game
Lag exploits are bad.
## Changelog
🆑 Melbert
fix: Fixed an exploit involving igniters attached to themselves.
Assembly holders are now limited to 12 assemblies maximum, and you
cannot attach multiple igniters to the same assembly.
refactor: Refactored some assembly jank, namely in how they pulse and
are pulsed.
/🆑
About The Pull Request
Fixes#69043 assemblies not providing a UI when part of a one-tank bomb. (This doesn't count voice analyzers, which don't have UI)
Fixes#68139 assemblies triggering themselves (and often turning themselves off).
Fixes timers ceasing to loop if the timer is set to less than the 3-second anti-spam threshold.
#69335, #68733 signalers occasionally runtiming due to qdel'd weak reference datums. Already addressed by another PR
Proximity sensors and mousetraps work on more wire datums, but proximity sensors are still buggy.
Igniter-sensor pairs can detonate fuel tanks properly, including plumbed fuel tanks. Fuel tank explosions scale with how much fuel is in them; this is slightly nerfed from existing values.
The fuel tank detonation code has been made generic, but other reagent dispensers have rigging turned off. If turned on with a varedit, you can rig and detonate water and other reagent tanks. Reagent tanks can theoretically both explode and spread reagents if it should happen to contain both welding fuel and other stuff. I have not actually tested this part of it, but I have detonated both water tanks and fuel tanks and each works correctly.
In making mousetraps work on wire datums, I had the opportunity to make it so that you could place a mousetrap in a door's wire and it would activate when someone passed through the door (useful to bolt a door open when someone authorized goes through, for example). This is a fun mechanic but does not make sense for a simple mousetrap to be so powerful, so it is disabled. Ideally, you could put the laser tripwire in a door's wires to do the same thing, but that would be a massive rework. Mousetraps still work in on-found mode for all wire datums, and will work on items with wiring datums (like C4 and chem bombs) when stepped on.
The signaler runtimes were a result of weak_ref datums being deleted, and the communications system not handling that. It's probably not ideal to run null checks in the post_signal loop, but I am not going to worry about it.
Many of the assemblies were not properly registering when the assembly holder was attached to an item. This was most important for proximity sensors, but that also has other problems that I haven't been able to track down.
The problem with UI not appearing was a result of the transition to TGUI however long ago that was; the proc that assures TGUI that you have the right item needed to be aware of one-tank bombs and similar, or else when you pass along an interact request it says "but you can't see it" and ignores you.
Why It's Good For The Game
Bugfixen.
The thing with the reagent dispensers only got this complicated when I realized that the plumbed fuel tank variant wasn't a subtype and therefore couldn't be rigged. And then... I basically just scaled it because the flat scale no matter the contents of the tank offended me. You could wrench open tanks, drain them entirely of fuel, rig them, and they would still go off like a pile of dynamite.
I used to have code in my branch that turned chem bombs into variants depending on the trigger, with mousetraps being mines for example. That's honestly the main reason I went out of my way to make mousetraps work better as assemblies. I could wish it were better supported, but mousetraps on grenade wiring will have to do for now.
Changelog
cl
balance: Welding fuel tank explosions have been scaled slightly down and require the fuel tanks to actually be full of welding fuel
fix: You can detonate welding fuel tanks with an igniter-sensor assembly
fix: You can reach your one-tank bomb's assembly controls by activating the item in your hand.
fix: Certain assemblies should no longer turn themselves off.
fix: Clumsy fools handling a mousetrap-based multi-part assembly may set it off by accident
/cl
This PR changes how assemblies and assembly holders work, and allows you to connect more than just a signaler and an igniter together. You could have a signaler, a repeating timer, and an igniter together to constantly produce sparks. Making the assembly holder is the same as before, but now you can add assemblies to it. This also allows signalers to be triggered via right clicking them while holding them in your active hand.
This adds some new defines and flags for the rotation component that lets us remove lots of c/p code chunks. I also added documentation to all the rotation defines that currently exist and in other spots that had weird behavior.
New rotation flags:
ROTATION_GHOSTS_ALLOWED - checks if ghosts are able to manipulate objects in config and lets them rotate the object
ROTATION_IGNORE_ANCHORED - this skips checking if an object is anchored (which normally prevents us from rotating) Used mainly for chairs.
ROTATION_NO_FLIPPING - this removes the flip verb from possible right click rotation options. Used for pipes that have custom flipping verbs instead
ROTATION_NEEDS_ROOM - this checks if an object needs to have an empty spot available in target direction. Used for windows and railings.
Objects can now be rotated in the direction based on which LMB or RMB you click with when you ALT click it. LMB is counter clockwise. RMB is clockwise. Before some objects could only be rotated clockwise. Now any object that inherits the rotation component can be rotated in either direction.
There was also a bug with wheelchairs that existed from when they were ported over from another codebase. The rotation logic was broken and never allowed anyone to rotate them. This has been fixed.
Rotation for IV_drips was enabled however Alt Click was being used for another proc and rotation was ignored because of this. I removed the rotation component due to this since I didn't want to change the hotkeys for IV drips since those have an actual effect on gameplay interactions while rotation does not.
Fingerprints are no longer added when something gets rotated. Only a few objects had this enabled but I believe this interaction was very spammy and unnecessary. I can readd this as a flag if needed but for now it's removed.
Alert balloons have replaced a lot of rotation to_chat() messages for the same reason as fingerprints. Rotating objects has almost no effect on gameplay and will only clutter a player's message log.
The hotkeys for pipe interactions had to be redone since Alt clicking was already being used in some situations. For regular pipes: Right clicking now changes the pipe layer. Alt clicking rotates the pipe. For Trinary pipes: Right clicking now flips the pipe device. Alt clicking rotates the device.
ComponentInitialize() is a deprecated function and the AddComponent proc was moved to Initialize for several objects.
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
Converts many proc overrides to properly use list/modifiers, fixes some spots where modifiers should have been passed, calls modifiers what it is, a lazy list, and cleans up some improper arg names like L, M, C, and N. Oh and I think there was a spot where someone was trying to pass M.name in as a string, but forgot to wrap it in []. I fixed that too.
About The Pull Request
This PR removes intents and replaces them with a combat mode. An explanation of what this means can be found below
Major changes:
Disarm and Grab intents have been removed.
Harm/Help is now combat mode, toggled by F or 4 by default
The context/verb/popup menu now only works when you do shift+right-click
Right click is now disarm, both in and out of combat mode.
Grabbing is now on ctrl-click.
If you're in combat mode, and are currently grabbing/pulling someone, and ctrl-click somewhere else, it will not release the grab (To prevent misclicks)
Minor interaction changes:
Right click to dissasemble tables, racks, filing cabinets (When holding the right tool to do so)
Left click to stunbaton, right click to harmbaton
Right click to tip cows
Right click to malpractice surgery
Right click to hold people at gunpoint (if youre holding a gun)
Why It's Good For The Game
Intents heavily cripple both the code and the UI design of interactions. While I understand that a lot of people will dislike this PR as they are used to intents, they are one of our weakest links in terms of explaining to players how to do specific things, and require a lot more keypresses to do compared to this.
As an example, martial arts can now be done without having to juggle 1 2 3 and 4 to switch intents quickly.
As some of you who saw the first combat mode PR, the context menu used to be disabled in combat mode. In this version it is instead on shift-right click ensuring that you can always use it in the same way.
In this version, combat mode also no longer prevents you from attacking with items when you would so before, as this was something that was commonly complained about.
The full intention of this shift in control scheme is that right click will become "secondary interaction" for items, which prevents some of the awkward juggling we have now with item modes etcetera.
Changelog
cl Qustinnus
add: Intents have been replaced with a combat mode. For more info find the PR here: #56601
/cl
* 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
AddComponent/AddElement now support named arguments. This requires passing around an argument list instead of using actual proc args which a bit gross but we can blame byond for forcing this.
InheritComponent uses mirrored init arguments instead of an argument list which means no more accessing it via index to get to the same arguments as in init.
As a small bonus I restructured dcs defines to be a bit more manageable. Mainly just splits them into separate files and gives them their own folder.
* wip
* wip2
* makes code actually compile on 511 + fixes
* versioning
* s
* adds python conversion script, schema change and removes 'force ' from item_used_for_combat
* fix to compile
* forgot to actually commit this
In cases where you're creating an image to use as an overlay, it makes more sense to use a mutable_appearance if you can. The image will create a static appearance for not just the image but also each intermediate step if you change vars along the way. The mutable appearance avoids this unnecessary and expensive process. The only situation that requires an image instead of a mutable_appearance is if the overlay is supposed to be directional. MA's ignore direction while images don't. I dunno why, probably another BYOND-ism.
I added a convenience function, mutable_appearance(), designed to emulate image(). Also went ahead and set the default plane of /mutable_appearance to FLOAT_PLANE because it's fucking 0 by default.
Several overlays that were image() calls were changed to just text strings when I could. overlays += "string" has the same result as overlays += image(icon, "string") and saves a proc call.
* Part1
* IT COMPILES!!!!
* Fuck wait this was missing from that last
* Update handlabeler.dm
* Update handlabeler.dm
* Fixes n shit
* Fix this
* Fixes#23310
* Fucking @RemieRichards was right
* Fixes devil unEquip
* WTF ARE BITFLAGS?
* THERES THE FUCKING PROBLEM
* Fixes
Added priority overlays to atoms, which will not be removed when overlays are cut and will always remain on top when new overlays are added. This requires everyone to use add_overlay() and cut_overlays() instead of overlays += and overlays.Cut(). These procs are found in __HELPERS/icons.dm, and the priority overlay list is found in game/atoms.dm. Everything else is replacing deprecated overlay manipulation.
SmArtKar