Interacting with the wayfinding pinpointer dispenser recently after leaving it untouched basically since I added it I realised it has a bunch of bad design decisions that make it unpleasant to interact with so while this can never solve the lack of desirability of the pinpointers themselves hopefully it prevents the machine from contributing to the problem.
`/atom/movable/proc/mouse_buckle_handling(mob/living/M, mob/living/user)` has functionality that is too generic for `/mob/living/carbon/human/`
`/mob/living/carbon/human/MouseDrop_T(mob/living/target, mob/living/user)` contains code that is better suited for `mouse_buckle_handling()`
`/mob/living/carbon/human/MouseDrop_T()` results in a call stack that calls the generic `/atom/movable/proc/mouse_buckle_handling()` when the prerequisites for piggybacking or fireman carrying are not satisfied. But this makes no sense and means that when the game state is such that you should be inspecting the inventory, the game state is ALSO such that you are attempting to erroneously buckle a player to yourself.
In addition, `MouseDrop_T()` should really not be holding mouse buckling logic in this scenario. As a result, this proc override has been removed from /living/carbon/human entirely. All functionality has been shifted into an overriden `mouse_buckle_handling()` at the /living/carbon/human level.
Piggybacking and fireman carrying now actually return a value on success.
Finally, if we have successfully handled the MouseDrop_T event through a parent proc call chain, we no longer go on to show the mob's inventory.
All these tweaks combined mean that you can now click-drag to view inventories without a do_after and without attempting buckling, /mob/living/carbon/human buckling logic is now appropriately in `mouse_buckle_handling()` and no longer falls through to generic buckling checks, which is not relevant when trying to air quotes "buckle" a mob to a /mob/living/carbon/human. Successfully buckling a player to yourself (in this scenario through fireman carrying) no longer opens the inventory window.
I have tested the following behaviours and they work as intended.
- [x] Piggybacking
- [x] Fireman carrying
- [x] Inspecting inventory of /mob/living/carbon/human
- [x] Inspecting inventory of /mob/living/simple_animal/pet/dog/corgi/ian
- [x] Buckling /mob/living/carbon/human to a chair.
- [x] Buckling /mob/living/simple_animal/pet/dog/corgi/ian to a dog bed.
The emote CSS class was no longer in use, it has been unitalicized and made into the actual emote class, back into local.
A CSS class for info has been created which has no special CSS.
The who verb has been put into info. (infoplain CSS class)
PDA message receiving has been put into info (PDA message sending was already in info). (infoplain CSS class)
Supply radio has been properly placed into radio.
Service radio has been properly placed into radio.
Binary talk has been placed into radio.
A CSS class for minor announcements has been created.
Minor announcements (shuttle purchases, head of staff office announcements, silicon announcements, etc) have been placed into radio (major announcements are already in radio). (minorannounce CSS class)
I wanted to refactor how movetype flags are added and removed into traits to prevent multiple sources of specific movement types from conflicting one other. I ended up also having to refactor the floating animation loop (the one that bobs up and down) code in the process.
Why It's Good For The Game
A way to avoid conflict from multiple sources of movement types.
This also stops melee attacks, jitteriness and update_transform() from temporarily disabling the floating movetype bitflag altogether until the next life tick.
Tested, but i'm pretty sure improvements could be made.
Changelog
cl
fix: jitteriness, melee attack animations and resting/standing up should no longer momentarily remove the floating movement type.
/cl
This is an alternative to the PR Ryll made, it does some things similar e.g. the default limit of 1 interaction per target for a person, however, it refactors do_afters to support overrides for max interaction counts and unique sources.
For example, stripping uses the item being stripped as the source, allowing you to strip multiple items, but not the same item multiple times.
I've also fixed most other edge-cases this could cause where balance would be affected, but feel free to point out any I might've missed, this'll probably require some longer-term testmerging.
About The Pull Request
Honestly, I'm not sure this is the... Correct solution? But people more familiar with this will likely show me da wae.
Prohibits creating names that can't actually be spoken in-character due to chat filters by adding CHAT_FILTER_CHECKs to the procs that handle sanitising them.
For admin-utilised renaming procs, they'll be given a simple alert box to warn them their chosen name contains words prohibited by the IC chat filter and be allowed to confirm or cancel out.
Why It's Good For The Game
If you can't speak the name IC, chances are the name shouldn't be allowed at all. Players may occasionally be forced to ahelp certain names because they contain words prohibited in chat filters.
The PR aims to allow advanced tool users to be defined by traits rather than a hardcoded proc.
Also necessary for the CanUseTopic refactor I'm working on, which will be PRed separately for atomization purposes.
This PR also fixes an inconsistency with can_hold_items (since monkeys can actually hold items).
VV-related code cleanup
Added code to trigger the proper setters for several variables that have them.
Added some admin logging for var-edit teleports.
Cleaned-up some code all around.
* Self_attack for arms if the hand is empty
* Oops
* Light runtime fix
This is not my runtime, but I will fix it all the same
* return better good
* How about a variable name that actually fits
* asdf
Added / improved documentation for buckling procs and variables
Removed / moved some unused things (removed 'buckling' var on mob, moved can_unbuckle() and can_buckle() from mob to living, removed can_unbuckle() and can_buckle() from slimes because they were ignoring everywhere it was checked anyways)
Moved can_buckle() check to is_buckle_possible() with the rest of the checks
Allowed mobs to buckle other mobs to things on the same turf as them ( I don't see why this was blocked in the first place. We have mobs on the same turf as each other all the time)
Changed silicons to use user_buckle_mob() instead of their own do_after system - now slightly longer to buckle mobs from another turf but instant to buckle mobs from the same turf. This means that borgs can't combatspin people who are still standing but have a slight slowdown, but can load people even faster if they're stunned/incapacitated and lying down. (But honestly, I did it for consistency, not balance)
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
Splits the restrained() proc into component traits: TRAIT_HANDS_BLOCKED for the general inability to use hands and TRAIT_RESTRAINED for the more specific condition that permits arrests.
Code moved away from the update_mobility() proc so it doesn't have to wait for an update, instead changing based on events. The idea is to eventually kill that proc.
Wrapper proc added for setting the handcuffed value so we can react to the event of it changing.
Kills the RestrainedClickOn() proc. That is now just an UnarmedAttack(), in where the ability to use hands can be checked. Monkeys keep their bite attack and humans their self-examine.
- Backtick-escape code samples which contain `[]` syntax.
- Fix all crosslinks to nonexistent symbols.
- Somewhat improve docs for qdel defines, research defines, dynamic mode, and others.
- Remove unused bloodcrawling defines.
Some crosslinks to defined but undocumented symbols remain. For BYOND builtins, a future dmdoc version may link those symbols to their entries in the DM reference. Other symbols could be documented by a future PR.
New "file" crosslinks as used in `research.dm` are slated for release in a future dmdoc version.
Using the spin emote can no longer let you RNG your way out of new flash mechanics.
Mobs have a new flag that is set to when they start spinning and unset when they stop.
Flashes now use this new flag when calcing deviation.
Tactical combat spinning using the spin emote now results in a full deviation flash when it may previously have resulted in a failure or half-deviation flash.
Emotes should either not influence combat at all (spin on floor when both players share the same loc, this was already handled by same-loc code), or negatively influence combat for the emote user (spin in all other circumtances, which is what this PR addresses).
If you're doing emotes in full darkness right next to someone, then the person won't see them, despite seeing your mob, which is counter-intuitive. This fixes that issue
Allows blind people to examine things they're directly holding in their hands, so they don't need to swap hands back and forth between empty hands to check their ID or whatever
Slightly lowered the recent examine delay to make it easier to trigger examine_more
attack_hands that waited for input or slept (such as apiaries or airlocks) delayed the examination until after the attack_hand input or sleep was finished, so it is now called async to prevent the weird pause.
Blind people could previously examine things with disabled/detached limbs, that's fixed as well, and replaced a range check with adjacent, cause shoving your arm through windoors is bad.
-Mechs are a vehicle subtype
-Mech equipment half-rewritten
-Mech actions completely redone
-Cooldown macros
-New movement macros & replacing all var in GLOB.diagonals with ISDIAGONALDIR(var)
-New lazylist macro
-Support for lavaland only mechs
-Removed the tank because fuck off with that hacky shit
-Documentation
-Fuckton of fixes
Replaces like 70-80% of 0 and such, as a side effect cleaned up a bunch of returns
Edit: Most left out ones are in mecha which should be done in mecha refactor already
Oh my look how clean it is
Co-authored-by: TiviPlus <TiviPlus>
Co-authored-by: Couls <coul422@gmail.com>
Unequipping clothing via quickswap now properly calls dropped(), so you lose any traits you get for wearing them. This fixes being able to use the quickswap hotkey to keep traits and other properties like krav maga, sec/med/diagnostic hud's, and whatever else without actually wearing the clothing.
Fixes: #52788Fixes: #50798
Why It's Good For The Game
Honestly for my money, a quickswap hotkey is lame and overly gamey, which is funny because the kind of player who would be into that is exactly the kind of player I'd suspect of quietly abusing a bug like this bug for the last several months, but I digress.
Changelog
cl Ryll/Shaps
fix: Quickswapping clothing now properly unequips the swapped-out clothing, removing any traits they granted while worn
/cl
Adds SIGNAL_HANDLER, a macro that sets SHOULD_NOT_SLEEP(TRUE). This should ideally be required on all new signal callbacks.
Adds BLOCKING_SIGNAL_HANDLER, a macro that does nothing except symbolize "this is an older signal that didn't necessitate a code rewrite". It should not be allowed for new work.
This comes from discussion around #52735, which yields by calling input, and (though it sets the return type beforehand) will not properly return the flag to prevent attack from slapping.
To fix 60% of the yielding cases, WrapAdminProcCall no longer waits for another admin's proc call to finish. I'm not an admin, so I don't know how many behinds this has saved, but if this is problematic for admins I can just make it so that it lets you do it anyway. I'm not sure what the point of this babysitting was anyway.
Requested by @optimumtact.
Changelog
cl
admin: Calling a proc while another admin is calling one will no longer wait for the first to finish. You will simply just have to call it again.
/cl
Rolls TK checks into baseline mob can_interact_with code.
TK check code unashamedly stolen from /mob/living/carbon/human/shared_living_ui_distance
This change touches every single can_interact interaction involving a mob and an atom, except /obj/machine which overrides can_interact without calling the parent and thus is unaffected by this change.
It enables any functionality that would require a can_interact() check to return TRUE. It effectively works alongside the adjacency check and comes into play if the adjacency check would fail.
