IMM_OMOVE
Keywords: IMM_OMOVE, WIZ_OMOVE
=== STAFF MANUAL ===
Usage: omove <source vid> <destination vid>
omove <source vid> <destination vid> safe
Description:
Renumber an object prototype, moving it from one virtual ID to
another. Unlike ocopy, the source VID is vacated and the prototype
lives at the destination VID afterwards. The engine chases every
world-wide reference to the source in the same pass and rewrites
them to the new VID, so any lingering pointer that identified the
object by VID ends up pointing at the right place:
Mob start equip .. Every mob prototype's starting-equipment
entry with this VID is rewritten.
Room keys ........ Any room exit whose key VID is the moved
object is rewritten.
Zone resets ...... Any zone with a P / O / G / E / R
reset referencing this object is marked
for resave so the reset file picks up the
new VID. P also matches when the object
is the container argument.
Vehicles ......... Vehicle-subitem objects whose parent
vehicle VID is the source are rewritten.
Shops ........... Shops with the object in their producing
list are marked for resave.
Boards .......... If the object is an ITEM_BOARD, the
attached board is renumbered to the new
VID so its message file is saved under
the destination.
Houses .......... Any live instance of the object sitting
in a house room has that room's
ROOM_HOUSE_CRASH flag set so its crash
file will save.
Both source and destination zones are marked dirty for their
.obj files, and each cross-reference hit queues an additional
deferred save for the owning zone's matching file type. The full
set of deferred saves is executed at the end of the command.
Safe Mode:
By default, omove leaves a backup copy of the prototype at
the original VID. The backup is a fresh ObjectPrototype cloned
from the moved object, including its triggers, function,
shared variables, initial globals, and behavior sets, plus an
extra initial global named newVirtualID set to the new VID.
This makes it possible for player pfiles that still reference
the old VID to resolve -- the stub object can even be scripted
to forward to the new VID using newVirtualID.
Append the literal keyword safe as a third argument to
skip the backup. Use this only when you are certain that no
pfile or save file references the source VID -- for example,
when you are just renumbering a brand-new prototype during
zone construction.
Arguments:
<source vid> ..... Virtual ID of the object to move. Short
form :<number> inherits the current
room's zone.
<destination vid> Virtual ID to move it to. Short form
inherits the source VID's zone rather
than the current room's.
safe ............. Optional third token. Suppresses the
default backup copy.
Output:
On success the invoker sees:
Moved object <src> to <dst>.
Moved object <src> to <dst> (backup copy left behind).
The second form is used whenever safe was not specified.
The action is logged to the staff wiznet with the same
suffix.
Restrictions:
- Requires the OLC staff permission and build access to
both the source and destination zones.
- Both VID arguments are required. A missing destination
prints "Usage: omove <source> <destination>".
- The source must currently hold an object prototype
("Object not found.").
- The destination must be empty -- omove refuses to
overwrite: "The destination object already exists."
- Either the source or the destination being open in an
active oedit session blocks the command, with the game
reporting which staff member has it open.
Notes:
- Live instances of the object currently in the world are
not re-pointered; the prototype swap is handled through
obj_index.renumber and the existing ObjData* pointers
continue to resolve correctly against the renumbered
prototype.
- When in doubt about player pfile references, run
without safe. The backup stub is cheap and can be
removed later with delete obj <src> once you have
verified nothing still points at it.
Related Helpfiles: WIZ_MMOVE, WIZ_RMOVE, WIZ_SCRIPTMOVE
=== END MANUAL ===