* atmos/fire alerts are now linked to an object and not its area, as intended
* simplified and full pathed the radio frequency datum
* made radio objects properly clean on del/qdel, instead of letting the radio controller remove nulls at each post_signal()
- ED-209's effective range has been reduced to 7, down from 12, to
prevent them attacking people off-screen.
- Ruthlessly nukes ".src" from the bot files, especially ed209bot.dm and
secbot.dm!
- Summoned bots now report on their department radio when summoned by
PDA.
- Bot radio frequencies now use the helpers instead!
- Officer Pingsky (On the MiniSat) is now set to declare his arrests on
the AI Private frequency, instead of Security.
- The remote_disabled var now prevents bots from being summoned or
controlled via PDA as well removing them from the AI's control panel.
- The AI can no longer re-activate a bot's remote control radio by
hacking it from the interface.
- The telescopic baton is now considered a safe weapon to carry and
wield by security bots.
- Added a small reminder to PDA users that bots can download access from
their ID to reach them.
*FIX: issue4487 (lasersound)
*Fix: repairing bot with weldingtool off. Gives warning msg.
*FIX: medbot fleeing one step when using weldtool/holosword.
*Fix: attacking silicon w/ holosword no longer gives spark.
*FIX: attacking bot w/ holosword is an assault.
*FIX: bots produce spark when damaged via attakby, similar to borgs.
*FIX: attacking ED209 with weldingtool on harm now triggers the bot response to the assault.
*FIX: bots can produce sparks when hit by projectile w/ damage>0. (to have some feedback b/c there's no msg otherwise)
*FIX: ED209 doesn't try to tase monkey despite wanting to arrest.
*FIX: LaserTAG ED209 points at monkey despite not shooting/hunting them.
*FIX: we don't check projectiletype and sound each time we fire. (Now only when using New() or emagging/hacking/emp'ing) (also
simplifying code)
*FIX: cannot access behavior mode to toggle patrol on lasertag ED209 (despite the fact that it should be able to patrol.
*FIX: ED209 tases cuffed target that are standing.
*FIX: ED209 can stun through a closet! And, it can cuff through windows and closet.
*FIX: the handcuffing problem. (issue2025)
*FIX: no message when trying to screwdriver panel of bots open but it's locked.
*FIX: added one audible message instead of for+show
*FIX: make 'detain' mean stun repeatedly. (issuenumber???)
*FIX: After finishing summon order, bot goes patrolling even if no auto_patrol.
*FIX: ED209 cannot be summoned or appear on the PDA securitron interlink cartridge.
FIX: autocustom names for lasertag ed209s doesn't work (if you don't give them a custom name, it gives them a custom one from a
list)
Removing maxstuns var in process() proc of both ED and beepsky. It doesn't do shit.
Lasertag ED no longer calls look_for_perp(), the loss in reaction speed is minimal. And it no longer calls for infraction
Adding myself as game master admin list.
RESULTS:
sorting 10 random lists of length 3 to 303 in increments of 3
(Meh, I forgot to refresh this one, there were only 338 trials rather than 1010, can't be bothered to recode the test)
Profile results (total time)
Proc Name Self CPU Total CPU Real Time Calls
------------------------------------------------- --------- --------- --------- ---------
/proc/sortList 0.672 16.141 16.243 171226 <--TG's current mergesort(recursive, hence the higher number of calls)
/proc/sortTim 0.008 3.278 3.274 338 <--TimSort
/proc/sortMerge 0.011 2.839 2.855 338 <--new mergesort
/proc/sortInsert 0.010 2.124 2.103 338 <--binary insertion
Sorting 10 presorted lists with 3 inversions (3 elements shuffled up), Lists of length 3 to 303 (increments of 3)
Profile results (total time)
Proc Name Self CPU Total CPU Real Time Calls
------------------------------------------------- --------- --------- --------- ---------
/proc/sortList 1.290 23.056 23.254 308050 <--rather cataclysmic
/proc/sortMerge 0.015 4.077 4.068 1010 <--
/proc/sortInsert 2.639 3.472 3.464 1010 <--
/proc/sortTim 0.014 1.567 1.576 1010 <--TimSort is faaar more effective in these cases,
Timsort can exploit runs effectively
sorting 10 presorted lists which have been reversed
Profile results (total time)
Proc Name Self CPU Total CPU Real Time Calls
------------------------------------------------- --------- --------- --------- ---------
/proc/sortList 1.234 23.193 23.295 308050
/proc/sortMerge 0.023 4.681 4.686 1010
/proc/sortInsert 2.875 3.750 3.765 1010
/proc/sortTim 0.020 3.294 3.284 1010 //This can be lower by using a different comparison method
*Corrected: /proc/sortTim 0.017 0.665 0.663 1010 //Using a non-strictly ascending comparison
sorting 10 presorted lists
Profile results (total time)
Proc Name Self CPU Total CPU Real Time Calls
------------------------------------------------- --------- --------- --------- ---------
/proc/sortList 1.199 21.391 21.517 308050
/proc/sortMerge 0.018 3.724 3.729 1010
/proc/sortInsert 2.497 3.302 3.309 1010
/proc/sortTim 0.024 0.586 0.584 1010
Summary, all the new procs are faster than the old ones. TimSort is ever so slightly slower than Insertion and Merging on random lists. But on lists with natural runs (partially sorted data) it is far faster than all others.
The old merge sort was removed and replaced with timSort. Other algorithms are provided as alternatives.
All algorithms use a central datum, so accept many of the same parameters. For instance, setting associative=1 will make them sort associative lists by their associated values, rather than keys.
They also accept a cmp argument. This allows sorting of lists of datums, text, numbers or whatever. The pre-existing helpers in lists.dm were rewritten as examples.
Works pretty well. If it can't GC something, it'll just del() it and be done.
Speed is amazing, holy shit.
New procs you should be aware of:
qdel(atom/movable) - sets up an object for garbage collection. Call this rather than del(atom/movable).
atom/movable/Destroy() - called right before the object is GC'd, so it still has a loc. Also called if the object is del()'d.
new controller - garbage.dm has all the details on this. Basically it nulls all references on GC'd objects and force del() them if necessary.
Generally speaking, objects should use Destroy() for behavior prior to deletion rather than Del(). You should also always call the parent so the object gets the right gc_destroyed var set.
ISSUES:
Tries to GC mobs atm. This actually works for new players, not so much for humans/monkies/simple_animals/anything. I'm guessing it needs to clear out their mind and HUD and maybe other things.
Gibbing is really bugged. It works, but the overlays just sit there for awhile and ugh. I'm very tempted just to del() mob/living and mob/camera and call it a day.
qdel() equipment doesn't unequip the item.
Pipes don't generally GC correctly. Debugging suggests they get referenced in many pipenets and that isn't cleared properly. However some do work fine. Need assistance here.
Bots don't GC, probably in the radio controller.
Lots of other shit doesn't GC but it's hard to find them because of the pipe spam.
I think I'm calling Destroy() twice by accident.
*TABLEPASS was already totally obsolete.
FPRINT was used, but it was on virtually everything anyway.
Removes those flags from every instance where they were used. Also assigned and removed other flags where it made sense.
If it is desired, I can revive the flag as NOFPRINT, which would retain the original functionality, though inverted. That way it would be be used only where it was intentional (holodeck items could use this for example).
Crossed() is a byond builtin which is called automatically when two movable atoms overlap (as a side effect of Move(), but not when loc or x/y/z is changed). Previously, turf/Entered() iterated through all objects in the turf in order to tell them an object had entered; with this change, HasEntered() becomes redundant and can be eliminated.
This may reduce lag when a large number of objects are moving in a small space (singularity, mining conveyors, etc) but should cause no changes to functionality at all.
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.
