Now to sting someone with active sting you alt+click them
In usual mode active sting do nothing
Clicking sting icon will deactivate the sting(hasnt removed the verb
however)
Now all monkifying will grant the monkeys what they can wear from their
previous form
Now all humanizing autoequips things from under you
(Done by Gia's suggestion, the quality is meh)
One more little change in icons
Prevents mech actions from acting on the user's inventory. Fixes#1487.
(Almost) fully prevents inventory use from within a mech, to be more consistent. The internals GUI button still works on the theory that it's emergency equipment.
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>
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.