IMM_RMOVE
Keywords: IMM_RMOVE, WIZ_RMOVE
=== STAFF MANUAL ===
Usage: rmove <source vid> <destination vid>
Description:
Renumber a room, moving it from one virtual ID to another.
Unlike rcopy, this is a move -- the source VID is vacated and
the room lives at the destination VID afterwards, with all exits,
flags, and in-room contents still attached. Because the room is
renumbered in place through world.renumber, existing exit
pointers from neighbouring rooms stay valid automatically, but
every file that encodes the room's VID on disk is queued for
resave so the change survives a restart.
World Updates:
Room records ...... Both the source and destination .wld
files are marked dirty. Any other room
with an exit pointing at the moved room
also has its owning zone marked for
resave, so the new VID appears in its
exit block on disk.
Zone files ........ Both zones have their .zon files
marked dirty.
Zone resets ....... When the move crosses zones, the
full range of reset commands attached to
this room is moved from the source zone's
cmd list to the destination zone's.
Vehicle entries ... Every vehicle prototype whose
VEHICLE_ENTRY VID matches the source is
rewritten to the destination, and the
owning zone's .obj file is marked dirty.
Shops ............. Any shop whose in_room list
references the room gets its entry
rewritten, and the shop's zone is marked
for resave.
Houses ............ If the room is part of a player
house, the old room's crash file is
removed, world.renumber runs, and the
house is then told to save both its
contents and its record so the house
now tracks the room under its new VID.
The full set of deferred saves is executed at the end of the
command, so a single rmove can touch several files in one
stroke.
Arguments:
<source vid> ..... Virtual ID of the room 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, so moving within
a zone can be written as just
rmove :10 :99.
Output:
On success the invoker sees:
Moved room <src> to <dst>.
The action is logged to the staff wiznet as:
OLC: <name> moved room <src> to <dst>
Restrictions:
- Requires the OLC staff permission and build access
to both the source and destination zones.
- Both arguments are required. A missing destination
prints "Usage: rmove <source> <destination>".
- The destination VID must be well-formed and its zone
must exist: "Invalid destination VirtualID." or "The
destination zone does not exist." otherwise.
- The source must currently hold a room
("Room not found.").
- The destination must be empty -- rmove refuses to
overwrite: "The destination room already exists."
- Either the source or the destination being open in
an active redit session blocks the command, with the
game reporting which staff member has it open.
Notes:
- rmove has no "safe" mode -- unlike omove, it never
leaves a backup stub behind at the source VID. Plan
ahead if you need a rollback path.
- Players currently standing in the moved room are not
displaced -- the room they occupy is the same pointer,
just renumbered. They will see the new VID in any
command that prints a room VID.
- After the move, cross-zone reset transfers are
visible in the destination zone's reset list; a follow-
up zedit of the destination zone is the easiest way
to verify the new entries.
Related Helpfiles: WIZ_MMOVE, WIZ_OMOVE, WIZ_SCRIPTMOVE
=== END MANUAL ===