/obj and /mob objects are now handled by the garbage collector just like
other non-atomic data objects. Basically, this only affects you if you are
putting objects at loc=null, removing all references to the object in all
variables, and expecting that object to persist for future use such as in
for(obj/O) or the pseudo-list world.contents or something like that that does
not need an explicit reference to the object to be stored in a variable or
list. Objects are not deleted if they are the src of running/sleeping procs
or if they have contents, because that counts as a reference to the object.
Mobs with non-null key values are also not deleted, just in case you are using
a poor-man's saving system:)
You should make sure that all unwanted objects get deleted one way or another,
or your game will eventually run out of memory. This change makes your job
easier, because derivatives of /atom/movable now behave like other data
objects so that you can safely use them in temporary expressions and the like.
Example:
<![CDATA[
overlays += new/obj/MyOverlay(Icon,State) //no longer creates a permanent object
]]>
Another case where this may fix an unexpected leak is in assignment of a
contents list, where there are existing contents, since the items that were
there get shoved off to loc=null in the process. (Such an assignment can
happen during saving/loading when you create objects with default contents.)
If you have objects within objects (ie bags), you might want to define
Move(null) to delete such container objects if that always means that they are
unwanted. Otherwise, even the garbage collector is going to just let them sit
there. Same goes for any object with a ticker proc. Those are up to you.