* Adds SHOULD_NOT_SLEEP to Destroy. Why didn't we do this before. (#61943)
* Adds SHOULD_NOT_SLEEP to Destroy. Why didn't we do this before.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* small refactor to can_interact() so that borg range is fully respected (#60693)
Its a relatively small refactor that changes the previous machinery "can_interact()" proc that literally did a full override despite half of their checks already existing in not one, but TWO parent procs, so i removed the redundant checks, added callbacks to its parents and then added the cyborg range check on the can_interact_with() itself. in doing so i also moved the interaction range var from silicons only, to mobs as a whole and defaulted it to a single tile, silicons override it to 7 (so pAIs and borgs like before) but then set AI and AI.eye to "null", because i have a check in can_interact that if there is no range set, then the range is effectively unlimited. and i even added code for when AI is carded and their wireless transmission is disabled it sets their range to "0" aka, it has no range to do anything even if it could
this was really complicated for me so despite my extensive testing it probably would be a bad thing if any of you want to test my code yourself to ensure there isnt a bug with this (theres no runtimes ive come across)
note: i did a lot of searching and going through machinery to ensure i caught all the little snowflake overrides and added can_interact() checks to them, but i may have missed one or two things, especially maybe a altclick or ctrlclick somewhere, however i believe i caught most of them
one nice side effect of this refactor is that you can actually set another mobs range to something other than 1 tile and they can interact at range, rather than only silicons getting this ability, an admin could VV a human to have a 3 tile arm reach as a meme if they want
* small refactor to can_interact() so that borg range is fully respected
Co-authored-by: 小月猫 <alina.r.starkova@gmail.com>
Adds set_density()
Fixes one instance of a duplicate density assignment on an object.
Comments two hacky usages of density which will have to forgo using the setter for now.
Lets us append code to the event of density changing.
Pretty sure this is leading up to some multitile object thing -Lemon
Co-authored-by: Rohesie <rohesie@gmail.com>
* use SIGNAL_HANDLER REEEEEE (#59242)
makes as many procs as i can find use the SIGNAL_HANDLER define which i assumed they all already did
* USE SIGNAL_HANDLER REEEEEE
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Makes the explosive compressor and blastcannon actually use the TTVs they're given + the explosion changes to support that. (#58015)
* Adds explosion SFX to the blastcannon and explosive compressor
- Extracts the explosion SFX and screenshake proc from the SSexplosions explosion handling proc and lets the explosive compressor and blastcannon use it.
* Miscellaneous changes
- Adds defines for the internal explosion arglist keys
- Reverses the values of the explosion severity defines
- Changes almost everything that uses `/proc/explosion` to use named arguments
- Removes a whole bunch of argname = 0 in explosion calls.
* Removes named callback arguments.
* Changes the explosion signals to just use the arguments list
Adds a simple framework to let objects respond to explosions occurring inside of them.
Changes a whole bunch of explosions to use the object being exploded as the origin of the explosion rather than the turf the object is on.
Makes the explosive compressor and blastcannon actually use the TTVs they are given.
Adds support for things responding to internal explosions.
Less snowflake code for the explosive compressor and blastcannon calculating bomb range.*
Less confusing explosion severity defines.
Less opaque explosion arguments
*does not guarantee that the solution to letting them actually use the TTV is any less snowflake.
* Makes the explosive compressor and blastcannon actually use the TTVs they're given + the explosion changes to support that.
Co-authored-by: TemporalOroboros <TemporalOroboros@gmail.com>
* Fixes a bunch of invalid icon states. There's more, but my brain isn't fried enough for that. (#58608)
gibup1 and gibdown1 don't exist
items_and_weapons.dmi doesn't have an icon state called his_grace_ascended, in fact nothing does
items_cyborg.dmi doesn't have an icon state called laser, it does however have an icon state called
laser_cyborg
no porta_turret has an icon state with the _unpowered suffix, in fact I'm convinced none of them ever have
* Fixes a bunch of invalid icon states
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* fixes being unable to attach training toolboxes to training units (#56990)
* fixes being unable to attach training toolboxes to training units
Co-authored-by: Kylerace <kylerlumpkin1@gmail.com>
* Merge pull request #54798 from Ghommie/Ghommie-tg38
You can now unbuckle others from the toolbox training machine with altclick. (Lemon: Cleans up some issues with remote toolbox removal too)
* You can now unbuckle others from the toolbox training machine with altclick.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
