[MUD-Dev] C&C and Event Rescheduling

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Thu Jul 31 07:16:32 CEST 1997


[Shawn H:]
:For the record, object methods appear the same to the DB as object
:attributes.  This makes changing a method the same as changing an
:attribute--the C&C mechanism will take care of the contention where
:Bubba is opening a door and Boffo is changing the code for opening
:the door.  Only the VM cares if the contents of an attribute actually
:represent an attribute or a method.  None of this is gospel in my
:design yet, so I fully expect you to blast some holes in it :>

Is it really necessary to be this careful with code changes? To me, the
are outside of the scenario, in that they are not directly visible to
players, or to NPC's, etc. So, it doesn't really matter when code
changes actually take place. If an administrator is doing code changes
on a running system, it seems the desire is for those changes to take
effect "whenever they get there", otherwise that administrator would
have to take great care to put manual flags around everything, to block
out uses while the changes are being made. Often, changes to code will
need changes to more than one piece of code - do you want to add
provisions for manual locking?

For the record, when a wizard edits a piece of code in AmigaMUD, as
soon as the edited code is accepted by the server it becomes the one
official copy of that code, and further uses will use it. I've made
no provisions for delaying that switchover. Then again, my server is
single-threaded, but all the discussion of multi-threaded execution
didn't trigger any thoughts about protecting code changes.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA



More information about the mud-dev-archive mailing list