HDTenEightyP/NetNews huggingface dataset:
From: guddt@uniwa.uwa.edu.au (David Bennett)
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Organization: University of Western Australia
Date: Thu, 3 Sep 1992 11:26:52 GMT

beeman@cats.ucsc.edu (Adam Beeman) writes:
>Notice all the set_* functions? what a waste... unless you like typing
>set_this_silly_variable(value) a lot.  I'm in the process of doing away
>with most of this.  In my system a single pair of functions, set() and query()
>can deal with quite a lot of this stuff.

>The virtual rooms can save us a lot of pain in this sort of situation.

On the single set/query idea...

I dont like it...

It is much easier to loose things.  One problem I had with changing
somethings to mappins in my code (and craig already outlined) was my
terrible spelling.  Using this method for setting and querying the
variables is very prone to this error.  The only useful reason for using
this syntax is the way that functions are done in lpmud creaing a large
table.  Fix this, don't hack your code.  There is nothing elegant aout
this style of programing.  In fact quite the reverse.  I would not
eagerly seek out people and tell them to loose this style of programing.
I feel it looses clarity and makes the code harder to read (as well as
makeing it more prone to silly errors).  In fact.  why have functions at
all?  Make them all done in one function called function with a huge
switch statement in lpc with mapping everywhere.  Uses much less
overhead for every object.

David.
[DDT] Pink fish forever.
-- 
  David Bennett,  guddt@uniwa.uwa.oz.au | University Computer Club
     Where Pink fish swim backwards.    | c/o Guild of Undergraduates
These words I am singing now mean nothing more than meow to an animal - TMBG
Disclaimer: Any spelling mistakes in this article are all entirly my fault.  Any grammer errors spotted in this article were put there because I could.
Newsgroups: rec.games.mud.lp
From: meetch@DIALix.oz.au (Mitchell Brandsma)
Subject: Re: Quests was Re: SW Quests
Organization: DIALix Services, Perth, Western Australia
Date: Thu, 03 Sep 92 03:52:13 GMT

baerrach@iagu.itd.adelaide.edu.au (Barrie Treloar) writes:

>How about people sharing clever ideas for quests
>or perhaps little parts of a quest that are quite 
>ingenious. No reference has to be made to the mud its on or 
>which quest it is. As a Wiz Talking over ideas with
>other people sounds cool

>Baerrach
>*8)

The quest that sticks out in my mind most of all was slapquest on Hero.  What
fun, running around like a madman, saying "SLAP ME!".  After fifty slaps your
quest was complete. :)  A real challenge to this would be if it was impossible
to say it in any form, thus forcing you to insult others or do something to
make them slap you.  :)

- Meetch (meetch@DIALix.oz.au :)
Newsgroups: rec.games.mud.lp
From: guddt@uniwa.uwa.edu.au (David Bennett)
Subject: Re: MudOS a ripoff?
Organization: University of Western Australia
Date: Thu, 27 Aug 1992 07:33:24 GMT

jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>When the name changed to MudOS, I was of the opinion that it was a
>bit premature.  As things stand now, though, I think it is undoubtedly
>a wholly different driver.  I doubt that CD has as many internal
>changes as MudOS.  Do you consider them to be a ripoff as well?

Personaly I do nt think the language is based on the internal things at
all.  It is based on how the language "looks and feels" to the
programer.  The language that MudOS is based on is still LPC.  for loops
looks the same, if statements havent changed.

Changeing efuns and how the driver deals with them does not change the
language.  Designing a language is not an easy task...

David.
[DDT] Pink fish forever.
-- 
  David Bennett,  guddt@uniwa.uwa.oz.au | University Computer Club
     Where Pink fish swim backwards.    | c/o Guild of Undergraduates
These words I am singing now mean nothing more than meow to an animal - TMBG
Disclaimer: Any spelling mistakes in this article are all entirly my fault.  Any grammer errors spotted in this article were put there because I could.
From: chena@crs.cl.msu.edu (Antony Chen)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 28 Aug 92 01:38:56 GMT
Organization: Michigan State University

oakley@contra.enet.dec.com (The Zeeker) writes:



>	Dosen't anyone want to at least TRY?  At least have a committee
>	to set up standard releases of game drivers, mudlibs, etc. 
>	I'm sure that if a committee was set up, many good ideas could
>	be incorporated into a single LP driver/mudlib without making it
>	too chaotic.  Nice tools could be made and distributed, etc.

Ugh...yeah, let's do that.  Sounds like a good idea.  Set up a committee
that will denounce changes that someone makes to a game driver or mudlib.
Hmm..this sounds kinda like...can't put my finger on it..communism?

Yeah..set up a board of people who will just quibble about what to do
and what not to do while people sit idly by waiting for them to make
a decision.  Or even worse, as you said in an earlier post about how
chaotic it is, what do you think will happen if you set up a committee?
People will go on and make changes as they see fit.  No one in the mud
world is gonna answer to a bunch of people who sit on this virrtual
committee.  BTW, do you think if I got on the committee, I could put it
on my next job app?  HAHAHAHAHA!!

****************************************************************************
MMMMM      MMMMM  Antony Chen aka MELVIN @ University of Michigan, Ann Arbor
 MMMM      MMMM   GO BLUE!!  THE FAB 5 RULES: Mama said knock you out! 
 MMM MM  MM MMM   Mud-related mail: tonychen@engin.umich.edu
 MMM  MMMM  MMM      Personal mail: Antony.Chen@um.cc.umich.edu
 MMM   MM   MMM          Misc mail: tchen@churchst.ccs.itd.umich.edu
MMMMM      MMMMM  ***********************************************************
From: d8andjo@dtek.chalmers.se (Johan Andersson)
Newsgroups: rec.games.mud.lp
Subject: Re: Accessing attributes (was: Re: Virtual Rooms and Objects)
Date: 4 Sep 92 12:05:07 GMT
	<KJETILHO.92Sep4023048@holmenkollen.ifi.uio.no> <37660@sdcc12.ucsd.edu>
Organization: Chalmers University of Technology, Sweden
In-reply-to: djohnson@cs.ucsd.edu's message of 4 Sep 92 02:07:39 GMT


[ On the difference between variables accessed by functions and properties
  stored in a mapping. ]

I dont think one solution only can be correct. Replacing all variable
access functions (set/query) with 'properties' stored in a mapping is IMHO
a bad idea, because as someone stated, some times you need to do something
more then just setting or querying the variable.

It might be so that in the 'standard mudlib' all you do is set/query, but
a wizard when inheriting the standard object might want to redefine the
access function so that it does something more.

By having set/query pairs you offer simple selectivity to the wizards.

If you have looked at CDlib you would know we use both functionalities, I
dont know if our compromise is very good, but I am convinced that a
compromise is necessary.

The main advantage of properties is that you need not change the standard
mudlib by adding variables and set/queries to allow new attributes of a
standard object.

In article <37660@sdcc12.ucsd.edu> djohnson@cs.ucsd.edu (Darin Johnson) writes:

>   It should be done from the driver anyway, since it is really
>   a language feature.
>
I think I agree. 

What we are talking here is an extension to the '->' operator to allow access
to variables.

>
>   The variables should define their own access.  (you wouldn't want
>   an external object defining if a variable is private or not,
>   so why do that for another variable attribute?)
>
Right, we could use 'public' to denote a read/write variable and 'protected'
to denote 'readonly', totally in conflict with C++ semantics :-)

We should probably allow 'wrapper' functions optionally, thereby allowing
an object to trap sets and queries of its variables. The syntax for
declaring such wrapper functions are left to the amusement of the reader.

/Johan
--
Johan Andersson           | "You don`t have conversations with microprocessors
Chalmers, Sweden          | you tell them what to do, and then you helplessly
Email:                    | watch the disaster when they take you literally."
d8andjo@dtek.chalmers.se  |	Sah`ot in David Brins "Startide Rising"
From: jwp@chem.ucsd.edu (John Pierce)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 28 Aug 1992 21:08:12 GMT
Organization: Chemistry Dept, UC San Diego
NNTP-Posting-Host: chedccf0.ucsd.edu

djohnson@cs.ucsd.edu (Darin Johnson) writes...
 > I'd try [to have an LP game driver committee].  Get much more done with all
 > the forces pointing in the same direction....

Damn!  Guess that means I'll have to try, too....  Can't let Darin loose on
his own that long. :-)

oakley@contra.enet.dec.com (The Zeeker) writes:
 > 	I'll try too....  We might just have an ANSI-LPC committee brewing....

Well, that rings the death knell on any sort of development that progresses
beyond 2.1.1 at the latest.  Have to have backward compatibility, you know,
or (heaven forfend!) "Approved Subsets" of the standard since people who had
to use them because they couldn't meet the real thing wouldn't be able to
give their stuff away (:returns from washing his mind with soap just for
thinking "approved subsets"), and we'll have to be sure that every
manufacturer who ever made more than an 8-bit box can meet the spec....

-- John Pierce, Chemistry, UC San Diego
   jpierce@ucsd.edu
   Horvendile, The Marches of Antan, chem.ucsd.edu (132.239.68.1) 3000
From: yappo@fy.chalmers.se (Sten D~ring)
Newsgroups: rec.games.mud.lp
Subject: Re: Hack'n'slash not for me
Date: 26 Aug 92 02:38:45 GMT
Organization: Chalmers Univ. of Technology, G|teborg, Sweden

Anyone considering ad&d a vivid system for roleplaying really should have no
opinions about any mud being a static world.

Yappo@Kingdoms mud.
Newsgroups: rec.games.mud.lp
From: jdahl@rchland.vnet.ibm.com (Jared Dahl)
Subject: Amud - is this what I need?
Date: Wed, 02 Sep 1992 13:14:32 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

A friend of mine and I are building a MUD(may not be) on an Amiga 3000
that has a 400 meg hard-disk.  This Amiga will be connected to several
modems via a multi-bus serial card, and people who call his bbs will
be able to play the mud.  Is this possible with the Amud code?  Or does
the Amiga need to be hooked into internet to work properly?  Can someone
give me a clue on this?


Jared "Clueless man in a Clueless land" Dahl
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Jared Dahl             | "My heart is human, my blood is boiling, | 
| Systems Programmer     |  my brain IBM"                           |
| IBM - Rochester, MN    |              -- STYX,  "Mr. Roboto"      |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Opinions expressed are mine, not IBM's.
From: wconsidi@orlith.bates.edu (William Considine)
Subject: Re: **** TOP 10 LPMUDs ****
Organization: Bates College, Lewiston, Maine
Date: Thu, 27 Aug 1992 16:54:29 GMT
From: uekleinf@mcs.Drexel.edu (Erik Kleinfelder)
Newsgroups: rec.games.mud.lp
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Date: 1 Sep 92 22:32:31 GMT
	<37330@sdcc12.ucsd.edu> <17jcmeINN21m@darkstar.UCSC.EDU>
	<UEKLEINF.92Aug31195626@queen.mcs.Drexel.edu>
	<1992Sep1.132741.8748@uniwa.uwa.edu.au>
Organization: Drexel University

>>>>> On 1 Sep 92 13:27:41 GMT, guddt@uniwa.uwa.edu.au (David Bennett) said:

David> uekleinf@mcs.Drexel.edu (Erik Kleinfelder) writes:

>     Very much, but now you got me wanting to develop ODLs with you.  One last
>thing, aren't we moving from LP to the MUSH type idea where objects are just
>stored variables(Granted they are saved, but you get the idea)???

David> Aren't all muds like this?  Aren't most rooms just colections of
David> variables?  On most muds every room doesnt do something spectacular so
David> in fact most rooms/objects are or could be like MUSH objects.  What is
David> wrong with that?

     I'm not saying anything is wrong with it, but stuff like this can move
from being single ".c" files to a database (*ack*).  This can cause more
problems when a newbie wizard starts coding and says ooh this is easy.  In
the long run, more and more Power LPC programers will dissappear and slowly,
LPC may take a back door on mudding instead of advancing into the future with
all types of MU*(and beyond...).

David> David.
David> [DDT] Pink fish forever.

Erik (Gunther God@Dragon's Den -- 129.25.7.111 2222)
Newsgroups: rec.games.mud.lp
From: guile@engin.umich.edu (Kenneth K Lee)
Subject: Re: sub-objects and MudOS virtual objects
Date: Fri, 28 Aug 92 14:53:05 EDT
Organization: University of Michigan Engineering, Ann Arbor

In article <escott.715018551@csuvax1> escott@csuvax1.csu.murdoch.edu.au (Evan Scott) writes:
>beeman@cats.ucsc.edu (Adam Beeman) writes:
>>MudOS is *years* ahead of its time, surely.
>
>Whether or not this was supposed to amuse us Buddha, you _have_
>been claiming this far and wide from the lofty heights of your ivory
>tower.  Thanx for in one statement demonstrating the ultimate
>in oxymoronical self-aggrandizing foolishness.
>
[lots of junk deleted]
Is it me, or did someone miss the punchline here?  Adam was being sarcastic,
poking fun at Geoff's and Mike's attitude that SW is years ahead of its time,
but the code's been released eons ago, so you can forget any repost of it...

   Seriously though, I think this silly flame war has gone on long enough. 
Something like the name of the driver is, to steal one of Geoff's favorite
words, trivial.  Why do you give a damn about the name of the driver, as long 
as they give the credit to Lars for being the original implementor?  I think
you guys have gotten all fired-up about something cosmetic....Sheesh..
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: MudOS a ripoff?
Date: 27 Aug 92 19:05:31 GMT
Organization: =CSE Dept., U.C. San Diego

>Have the Joneses released their code?

No, and boy, they seem pissed that people aren't bowing down to them :-)

>I notice you say nothing about the virtual objects.

Actually, what are virtual objects?  I've got virtual rooms on my
mud, but that's with plain 'ol generic 3.1.2.  (of course, virtual
can mean many things)

-- 
Darin Johnson
djohnson@ucsd.edu
  - Grad school - just say no.
From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: sub-objects and MudOS virtual objects
Date: 28 Aug 1992 07:55:34 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu
Summary: hit 'n' now. ;-)


In article <9208280657.AA01597@hebrew.cc.columbia.edu> jlw@HEBREW.CC.COLUMBIA.EDU (James Waldrop) writes:
>
 [ stuff deleted ]
>Even worse, how do you handle object pointers to things that haven't
>logged back in yet?  Or another problem, you say only cloned objects
>can be saved, so you have a pointer to /std/sword#345, but when you
>come back it's gonna be /std/sword#22 or somesuch confusion.  Possibly
>if you logged all the players back in, but linkdead, and you had some
>way of stamping objects, but then you're getting dangerously close to
>recreating the conditions that probably caused the crash in the first
>place.
>

	My guess is that each object gets a lifelong identity 
-- not file_name -- but related to it, and there can be only one such 
object with that identity, ever.  Of course, this was all done way before
you were born or reading news, and full source was posted then, but you
weren't paying attention then, and therefore can't possibly be helped by
a repost now. ;-)
	
>This is a useful thing, as far as it goes, but I think that comparing
>it to the MudOS virtual objects is a big stretch.

MudOS is *years* ahead of its time, surely.
(Except to hermits sitting on mountain tops who cure cancer.)

>Not that I'm saying
>one is better than the other, but it would be like comparing goats to
>horses.  I can always ride a goat if I work at it hard enough, but
>I'd much prefer to let the goat trim my lawn and ride the horse.
>

Does the goat go snicker-snack?

>Sulam, who is feeling particularly pastoral tonight.

Buddha, who isn't.
-- 
#include <std_disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
From: roarb@colargol.edb.tih.no (Roar Brekken)
Newsgroups: rec.games.mud.lp
Subject: Multi-inheritance problem.
Date: 26 Aug 92 02:13:04 GMT
Organization: Colargol, Trondheim College of Engineering
X-Newsreader: Tin 1.1 PL5



Hi.

The following holds true for at least these drivers: The 3.1.2 COMPAT_MODE
of VikingMud, and the CD.01.56 of Kingdoms.

I have the three objects, a.c, b.c and c.c. The first two are inherited by
the latter.

***** a.c *****

bingme()  {
  bing();
}

bing()  {
  write("BingAAA\n");
}

***** b.c *****

bingme()  {
  bing();
}

bing()  {
  write("BingBBB\n");
}

***** c.c *****

inherit "players/drevreck/obj/a";
inherit "players/drevreck/obj/b";

init()  {
  add_action("bingbing","bing");
}

bingbing()  {
  write("Binging a:\n");
  a::bingme();
  write("Binging b:\n");
  b::bingme();
  return 1;
}

Now here is what happens when I clone c.c and type 'bing':

Binging a:
BingAAA
Binging b:
BingAAA

In other words, when the function bingme() in a.c calls bing(), it calls
bing() in a.c. Which is very nice. But: When bingme() in b.c calls bing()
it ALSO calls bing() in a.c. Which is not nice at all!

If I reverse the two inherit lines in c.c, so that b.c is inherited before
a.c, then bing() in b.c will be called in both cases, so there is at least
some system to the madness... :-)

If I now write a function bing() in c.c as well, like this:

bing()  {
  write("BingCCC\n");
}

..the output turns out like this:

Binging a:
BingCCC
Binging b:
BingAAA

Which means that bing() in a.c is correctly masked by the one in c.c, but
that bing() in b.c STILL calls the one in a.c. *scream*

That two objects resting side by side in the inheritance chain are able to
call functions in each other strikes me as a BAAAD idea. That they do so
without even being asked to do it must be even worse. That I can't even STOP
them from doing so seems to be nothing short of ludicrous.

Another thing: If a.c and b.c both inherit some common base-object (which is 
a good idea, and even mandatory on some muds), and this base-object defines
a nomasked function, my object will not load, complaining about a 
'redeclaration of nomasked function' or something along those lines. That
is very understandable, but would it be too much to ask from a driver that
it discovered that both of the nomasked functions were defined in the same
object?

Are there any drivers / patches for drivers around that handle this in a better
way? Or are there some very good reasons for it being just like it is?
I can't help but viewing multi-inheritance as somewhat useless as long as it
behaves in the above described manner.

(Thanks to Pinkfish, whose influence caused my subconciousness to put the
 word 'bing' everywhere in those files... :-) )

--
Lars Syrstad aka Drevreck @ VikingMud, Kingdoms and others.
Email to: larss@edb.tih.no, NOT the above address (bugbugbug).

Those who live by prayers die by the sword. ( -Sabbat. )
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: Examples of shadow() in use?
Date: 26 Aug 92 00:37:50 GMT
Organization: =CSE Dept., U.C. San Diego

> Was wondering if anyone has some examples of shadow() being used
> which I could take a look at?  Any help is greatly appreciated!

Ok, here's something I have (a rare item by the way).
(some mud specific things, but the methods should be apparent)
You will also have to ensure that you can actually shadow
the object in particular.  Some mudlibs forbid shadowing players
be default, in which case this example won't ever work.  (at our
site, we just require all shadows to be in a secure place, so that
we get a chance to inspect them all first - more secure in my
humble opinion)


lifesaver.c:  /* not the shadow itself though */
--------
   misc. setup not included here.

   init() {
       if (environment() == this_player())
           check_shadow();
   }

   check_shadow() {
       object the_shadow;
       if (this_player()->shadow_query_lifesaver()) return;
       the_shadow = clone_object("secure-dir/lifesaver_shadow");
       if (the_shadow && !the_shadow->set_shadow(this_player()))
           destruct(the_shadow);
   }

lifesaver_shadow.c:
--------
    /*
     * Generally try to keep number of functions to a bare minimum.
     * Here there is a set, query, and the overwritten function only.
     */
     
    object myself;

    set_shadow(ob) { return (myself = shadow(ob,1)); }

    shadow_query_lifesaver() { return 1; }

    hit_player(wc_dam, sp_dam, wh_dam, amods) {
        if (wc_dam+sp_dam+wh_dam < myself->query_hp()) {
            return (myself->hit_player(wc_dam, sp_dam, wh_dam, amods));
        } else {
            object ob;
            write(some stupid message here, about how you didn't quite die);
            myself->move_player("X", RATHGOR(church));
            if (ob=present("amulet of life saving", myself))
                ob->destruct_object();
            destruct(this_object());
            return 0;
        }
    }
-- 
Darin Johnson
djohnson@ucsd.edu
    Where am I?  In the village...  What do you want?  Information...
From: wporter@dryer.ecn.purdue.edu (B.B. Wet)
Newsgroups: rec.games.mud.lp
Subject: Tsunami MUD
Keywords: Tsunami, What the Hell?
Date: 26 Aug 92 16:51:42 GMT
Organization: Purdue University Engineering Computer Network


What happened to Tsunami Mud?
i was just on it the other day, and today I can't connect.
If 'Black' is listening, mail me at:

wporter@plugflow.ecn.purdue.edu

-Barton Fink
From: djohnson@cs.ucsd.edu (Darin Johnson)
Newsgroups: rec.games.mud.lp
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Date: 4 Sep 92 00:32:50 GMT
Organization: =CSE Dept., U.C. San Diego

>Another problem with this idea is that sooner or later someone is going to
>use a property name that someone else already defined...

Start (and enforce) a convention.  Wizards who define properties should
prepend them with their name, as in "joebob:blah".  Leaves the problem
of synchronizing global properties - but if the people mucking with
the mudlib itself aren't communicating, there's not much hope left...
-- 
Darin Johnson
djohnson@ucsd.edu
    "I wonder what's taking Guybrush so long..."
From: uekleinf@mcs.Drexel.edu (Erik Kleinfelder)
Newsgroups: rec.games.mud.lp
Subject: Re: Driver additions
Date: 26 Aug 92 04:20:49 GMT
	<UEKLEINF.92Aug25152135@queen.mcs.Drexel.edu> <R1h-h##@engin.umich.edu>
	<37243@sdcc12.ucsd.edu>
Organization: Drexel University

djohnson@cs.ucsd.edu (Darin Johnson) said:

Darin> And again, if 3.1.2 is so HORRIBLY buggy as everyone says, why the
Darin> hell is everyone hiding the bug fixes???

     Now there is a damn good question!

Darin> -- 
Darin> Darin Johnson
Darin> djohnson@ucsd.edu
Darin>   - Brought to you by the 'Elvis in 92' committee.

Erik
Newsgroups: rec.games.mud.lp
From: oakley@contra.enet.dec.com (The Zeeker)
Subject: Re: Hack'n'slash not for me
Organisation: Treadstone Seventy-One
Organization: Digital Equipment Corporation, Maynard, MA.
Date: Wed, 26 Aug 1992 00:44:40 GMT


In article <XT.92Aug24004455@monet.math.chalmers.se>, xt@math.chalmers.se (Carl Hallen) writes...
>>In article <ANIPA.92Aug24001450@sotka.cs.tut.fi> anipa@cs.tut.fi (Niilo Neuvo) writes:
>>   Languages are a bad idea. You end up as genesis not being able to talk
>>   to anyone. 
> 
>On Genesis all players speak the same language if they use the 'say'
>command.

	Languages can be quite nice if implemented properly.  Sometimes
	it's necessary to actually make sure there is a LANGUAGE, words,
	vowels, syllables, etc.  Put a bit of effort and it turns out ok.
	
	Cheers

-----------------------------------------------------------------
Brought to you by Treadstone Seventy-One Corporation.
--- --- --- | /  "Come not between the dragon and his wroth!"
 /  |-  |-  |    		- Lear, King of England
--- --- --- | \
_________________________________________________________________