Subject: Re: Inspiring new approaches to quota

From: David Sanderman <[email-masked]>
Date: Fri, 28 May 1993 10:27:23 -0700

-> >what they do. Ideally exits should be entirely free. We're considering
-> >defining exits purely in a list defined on the room. One problem is 
allowing
-> >aliases for exits, which we are thinking of getting round by 
defining default
-> >exit names and aliases.
Some other benefits of object-exits that you lose when going
to verb exits (unless you hack in a lot of stuff):
1) ability to describe exits
2) exit locking
3) specialized exit:invoke code for more complex locking/actions
4) the ability to subclass exits in the case where you have lots of
   exits that should all behave in some special way
And so on.  It seems to make more sense to just have all the
exits on your MOO owned by a central exit-quota character, or
something along those lines, rather than going to verb exits.
  Dave/Zippy

---

From: "Jacqueline D. Hamilton" <[email-masked]>
Date: Fri, 28 May 1993 11:25:13 -0700

> 
> >what they do. Ideally exits should be entirely free. We're considering
> >defining exits purely in a list defined on the room. One problem is allowing
> >aliases for exits, which we are thinking of getting round by 
> >defining default exit names and aliases.

Just for those who might be interested, here's the specs on the "exitless
MOO" as implemented on Dragonsfire.

New room class #213 (this way the generic room #3 is preserved, and one
can still use it and create exits if you really want).

Added the following properties to #213:
  .links => stores a list in the form of {{room#,{exit-name,alias,alias}}.
            room# is where the exit goes to.
  .link_descs => exit descriptions
  .link_flags => Since DF is from a MUSE, we use flags for things like
                 "dark" and "transparent" exits.
  .link_keys => locks for exits.
  .link_msgs => a list containing standard exit messages for each exit -
                oleave, oarrive, leave, arrive, nogo, onogo.

There's a slew of new verbs added on #213 to handle all this, and several
core changes were made, most notably to @lock and @desc.  Among the primary
verbs on #213 are :match_link (similar to match_exit), a verb called 
:invoke (similar to $exit:invoke), and @onogo @nogo all that stuff defined
as a verb on the room.  Also :look was changed so you can look at exits,
and a new :here_huh to handle links instead of exit-objects.  There's 
various others that I dont recall off the top of my head.  #213 is pretty
well packed with stuff.

There's certainly pros and cons to such a system.   It's a real pain to 
dig from a "real" room, like the metarooms, to a linked room.  Links
sorta defeat the object-orientedness of MOO, but then so do metarooms. :)
But, I'd guess that close to 95% if not more of our users would never
want to do something strange with exits that'd require real objects with
inherited characteristics.

Meanwhile, we save considerable space doing it this way - as far as the MOO
goes, I believe we cut the size of our db from some 16-17 meg in memory to
around 12 meg.  It means a 20-quota goes a LONG way - 20 rooms, for instance,
is a large area, and you dont have to worry a whit how many exits you have.
And it sure as heck makes @audit less spammy. :)

If anyone cares to look at the code, #213 is readable, come to DF and ask
for a progbit.  DragonsFire is at netman.widener.edu 4444.

-j. (Jina@DF)