* Adds some user feedback to borgs using modules while buckled to things (#52459)
* user feedback
* c
* Adds some user feedback to borgs using modules while buckled to things
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Aiming to implement the framework oranges has detailed in https://tgstation13.org/phpBB/viewtopic.php?f=10&t=19102
Moves canmove to a bitflag in a new variable called mobility_flags, that will allow finer grain control of what someone can do codewise, for example, letting them move but not stand up, or stand up but not move.
Adds Immobilize()d status effect that freezes movement but does not prevent anything else.
Adds Paralyze()d which is oldstun "You can't do anything at all and knock down).
Stun() will now prevent any item/UI usage and movement (which is similar to before).
Knockdown() will now only knockdown without preventing item usage/movement.
People knocked down will be able to crawl at softcrit-speeds
Refactors some /mob variables and procs to /mob/living.
update_canmove() refactored to update_mobility() and will handle mobility_flags instead of the removed canmove
cl
rscadd: Crawling is now possible if you are down but not stunned. Obviously, you will be slower.
/cl
Refactors are done. I'd rather get this merged faster than try to fine tune stuff like slips. The most obvious gameplay effect this pr has will be crawling, and I believe I made tiny tweaks but I can't find it Anything I missed or weird behavior should be reported.
Gives the ability to take and view photo to Cyborgs
AI's share their photo album with connected Cyborgs, and connected Cyborgs have the pictures they take saved to the AI's album. If a Cyborg is not connected to an AI, photos are saved to the Cyborg's camera object. If a Cyborg has photos in it's album while not connected to an AI, but is subsequently connected to an AI, the photos are added to the AI's album. This is initiated by pulsing the appropriate wire on the borg.
Cyborgs can attach images to newscaster feeds, from the active album available to it (the AI's, or its own if disconnected)
Cyborgs cannot interact with photocopiers, but however have become a moving printer. They are every inefficent at printing, and thus can only print two color pictures before needing to be refilled with toner (simply click on them with toner in active hand).
Added some span classes to the previous AI photography work.
One minor bug fix to photocopier which could result in a photo object ending up in the 'hand' of an AI or cyborg.
Ranged weapons and laser eyes have a cooldown of 0.4.
Grilles, windows, windoors, walls and blobs have a cooldown of 0.8.
Hitting mobs will also have a cooldown of 0.8.
Removes the unused USEDELAY flag.
Gives cyborgs existing AI control/alt/shift click shortcuts while
allowing for them to be used on non-doors/apc normally. (shift still
inspects, control still drags, etc)
Fixes#2382
GODDAMN ARAN WHY YOU FIXED AIS SO FAST I ALREADY NAMED A BRANCH
APPROPRIATELY AND THEN SUGGENLY I NOTICED YOUR PR YOU RUINED EVERYTHING
ARAN OH GOD WHY YOU DO THIS TO ME ARAN WHY WHY WHY
New procs:
* module_selected(module) - Checks whether the module slot specified by "module" is currently selected.
* module_active(module) - Checks whether there is a module active in the slot specified by "module".
* get_selected_module() - Returns the slot number of the currently selected module. Returns 0 if no modules are selected.
* select_module(module) - Selects the module slot specified by "module"
* deselect_module(module) - Deselects the module slot specified by "module"
* toggle_module(module) - Toggles the selection of the module slot specified by "module".
* cycle_modules() - Cycles through the list of selected modules.
Signed-off-by: Mloc-Argent <colmohici@gmail.com>
Adjusts the click code to not use client/Click(). The code is largely unchanged, except that it allows the compiler default behaviour of calling atom/Click(), and then forwards the call to mob/ClickOn(). I had some reports that melee combat mixed with movement was behaving oddly, and I believe it may be due to the use of client/Click; the byond documentation says that redefining client/Click() causes additional overhead, and it isn't strictly necessary.
Alters the way double clicks are handled, in an attempt to better handle clickspam, as often occurs during pitched combat. This may also be responsible for the above, but I don't know.
Inserts proximity (aka flag) checks in all afterattack() procs. The old assumption was that unless an item used the USEDELAY flag, afterattack() was only called when adjacent, but this is no longer true. This led to beakers, soap, crayons, etc, all being usable at all ranges.
Removes the NODELAY flag, which was unused. Removes all existing uses of the USEDELAY flag so that it can be readded to things that need extra delay.
Removes the hand_* procs, previously used by restrained actions. Instead, the mob helper mob/RestrainedClickOn() has abosrbed basically all the functionality they were used for, which is really only monkeys with jungle fever.
Adds a special case of the Adjacency() proc for doors. This fixes#136, airlocks being unreachable due to border fire doors. However, this only takes us back to the unpleasant position where you have to open-hand the door, switch to a crowbar, and pry open the firedoor; it still needs a better fix.
attack_self use should be somewhat more standard; previously the activate object verb (and pagedown) had no delay at all.
Lowers the time taken when interacting with things on your person or in your square.
Fixes#646, #579, #863
Completely redoes the click code. Moves all click related code into code/_onclick for reference. Also moves hud datum code and all the screen object code I could find into code/_onclick/hud, as it is related. Item attack(), attackby(), afterattack(), and attack_self() have been moved into item_attack.dm for consistency.
Completely removes dummy objects and adds atom.Adjacent(user). This proc checks for border items and anything marked with throwpass for determining whether or not you can reach a given square. A turf helper, ClickCross(), was added to facilitate this.
Removes the monolithic Atom.Click() proc in favor of an overridable click handler attached to mobs. Click code no longer uses the : path operator as a consequence, and mob/lastDblClick has been moved to Client/next_click. A few end arounds were necessary (screen objects, buildmode, and spells), but this has been handled by repurposing Atom.Click(); if you have special click code, insert it in the object's Click() function and return 1 to prevent normal processing.
This update adds support for attack_ghost(); the previous "new" click handler had support for it but was never finished. I have taken the liberty of letting ghosts click portals, the gateway, and the teleporter to jump to the intended target square, and kept the previous default action of examine()ing every damn thing you click. It is to be suggested that you could do more with this proc when ghost interactions are enabled.
This update also adds support for double clicking. It is currently only used for ghosts and AIs, because the original (first) click still registers normally. For both of these, double clicking a square will jump you to it, and double clicking a mob will follow it. In the case of ghosts, double clicking bots and the singularity will also set you following it; if you double click your own corpse, you will re-enter it; this also works if your body is in a closet, sleeper, DNA scanner, etc. Default mobs ignore double clicks as normal.
-- NOTE --
There are two flags which were previously unused or misused by click code: USEDELAY and NODELAY. Ostensibly, USEDELAY would double the normal 1sec delay, and NODELAY would remove it.
Using either of these flags as intended would significantly affect the timing of the game. In particular, USEDELAY is currently applied to guns and about everything else that acts at range. I am adding USEDELAY as a half-second increase for now, but I have not put a significant amount of thought into it. I considered lowering the normal 1sec delay to .8sec to balance it, but the consequences of that on combat involve more calculations than I care to make.
NODELAY seems to never have been used, and I did not implement it, but I could do so trivially.
