Now if you have a breath mask on your face, but lowered, and decide to start running on internals, you will automatically adjust the mask back on your face!
Add the incapacitated proc to mobs to check for stat, stun, weakened, paralysis, restrained. And replacing those checks by that new proc in some places.
Removed an unused client verb, changed a usr to src where they're the same mob, and changed a type == check to istype().
Allow turning on throw mode when clicking the UI button (hotkeys already allow you to do this).
Disallow throwing when not on a turf.
Fixes#4823
Make storage items close out the onscreen stuff when they get thrown.
Fixes#5296
Makes the sensor augmentation check for silicon instead of one for both
the AI and Borgs, since they are not actually different procs.
Reverts an accidental removal of the borg camera function, thinking it
came from NT's code.
- The AI can now access both Security and Medical HUDs via a new button
on its UI. The Medical HUD is exactly equal to all others. The AI's
Security HUD cannot detect implants.
- Cyborg HUD modules have been removed in favor of an inbuilt command,
to make it less of a hassle to access them.
- HUD code has been given its own file such that it can be used by any
mob. In addition, HUD users are placed into a list instead of searching
for only humans and checking them for a HUD item. This is to make it
easier to expand.
- Security HUD messages can now be received by any mob using a SecHUD.
This allows you to click which ever intent you want in the four-color
intent system humans have.
Other/simple mobs' still use the old single intent button.
F/G macros still work as well.
continued from: #4473
Fixes#4201 by adding a cancel button to the track mob list.
Fixes a runtime that pops up if you double click the "Track Mob" or "Show Camera List" buttons on the AI hud. Problem is that double clicking runs a proc that builds the datum of lists of trackable mobs twice, and then both procs sleep because of input(). When the first track completes it nulls the tracking datum, which causes problems for the second (or more) tracks which expect the tracking datum to not be null. Solution: Keep the datum around and simply rebuild the lists as-needed instead of creating and deleting the tracking datum datum pointlessly.
Conflicts:
code/modules/mob/living/carbon/monkey/monkey.dm - I don't know why it thought there was a conflict. Opening it in tortoisemerge showed no conflicts and automatically cleared the status. I reset to the repo's version just to be safe, then re-added my freakin 2 line function which has caused 2-3 "conflicts" so far.
MUTAGEN might be controversial I assume... The service borg has no spray bottle though.
Moves update_robot_modules_display() to fix a UI glitch where using the home to unequip a module wasn't making the module appear in the storage list until it was otherwise updated.
Robots no longer take fire damage from fire stacks, since they're otherwise immune to heat... also, fire stacks will gradually burn off and the borg will stop being on fire.
Service borg emag beer (beer2) was oldchloral instead of newchloral. Excellent argument against copy-paste. Fixed.
Removed the dumb "if this happened to be a borg's drink container, refill whatever it's currently holding the most of after a delay" which lead to an easy reagent duplication glitch, and was generally shit. Fixes issue #1673.
Uncapitalized some drink names which weren't proper nouns, and changed stuff like "Beer glass" to "glass of beer".
This still fixes#3401 too of course
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.
The garbage controller no longer bothers nulling out every variable on destroyed objects.
An object can opt to not be collected by returning true from Destroy(). Useful for pools or other edge cases.
Fixed boxes not being collected, along with a couple other things.
Turfs will not be monitored for collection.
generate_ion_law() is no longer a /datum proc, and I am an admin in the repo. Deal with it.
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.