FUNKTION:
	varargs void GuardExit(string exit, mixed deny [, int force])

DEFINIERT IN:
	/std/npc/guard.c

ARGUMENTE:
	exit  - Ein Ausgang in dem Raum, in dem der NPC steht. z.B. "westen"
		oder "nordosten"
	deny  - 1. Entweder ein Integer:
		deny >  0 - es wird eine Standardmeldung ausgegeben.
		deny == 0 - Gibt den Ausgang wieder frei. Macht also ein
		vorheriges GuardExit() rueckgaengig.
	        2. Oder ein String:
		Der String wird an den Spieler ausgegeben, der versucht,
		den Ausgang zu benutzen.
	        3. Oder ein Array aus 2 Strings:
		Der erste String wird an den Spieler, der zweite String an
		den Raum ausgegeben.
	        4. Oder eine Closure:
		Die Closure wird aufgerufen, wenn der Spieler versucht, den
		Exit zu benutzen. Liefert die Closure 0, dann ist der Aus-
		gang frei, liefert sie 1, dann wird der Ausgang versperrt.
		Als Argument kann die Closure 2 Argumente erwarten:
		1. den Spieler als Objekt, der den Exit benutzen will.
		2. den Ausgang, den der Spieler benutzen will als String.
	force - Wenn angegeben wird der Ausgang immer versperrt bzw immer
		die Closure aufgerufen, unabhaengig davon, ob der Spieler 
		schleicht oder unsichtbar oder ein Magier ist. :-)

BESCHREIBUNG:
	Mit der Funktion kann man einen NPC anweisen einen Ausgang zu be-
	wachen. Er laesst dann keinen Spieler/NPC mehr diesen Exit durch-
	schreiten, solange er lebt. GuardExit basiert auf dem ET_GO-Event
	des Livings und bricht diesen ggf. ab. Sollte es ein Objekt geben,
	was sich anders 'bewegt', bitte einem Erzmagier Bescheid sagen.

	Normalerweise 'bemerkt' der NPC einen Spieler/NPC nicht, wenn die-
	ser unsichtbar ist und der NPC P_CANNOT_SEE_INVIS gesetzt hat ODER
	wenn der Spieler schleicht und der P_SENSE-Wert den NPCs nicht
	hoch genug ist (analog P_AGGRESSIVE) oder wenn der Spieler 
	IS_LEARNING ist. Wird 'force' gesetzt, wird der Ausgang immer
	versperrt, bzw. die Closure immer aufgerufen. Sinnvoll ist das bei
	Quest-NPCs, die Schleicher nicht durchlassen sollen oder aehn-
	lichem. Via Closure kann man das Versperren dann selbst regeln.

	WICHTIG: Da GuardExit intern als Event-Abbrecher implementiert ist,
	sind die dafuer geltenden Einschraenkungen zu beachten. Es duerfen
	keine Folgeevents durch Aufruf der closure ausgeloest werden.
	Dazu zaehlen unter anderem Move-Events (durch Aufruf von move() aus-
	geloest) und Todesevents (z.B. infolge von do_damage). Will man mehr,
	muss man einen eigenen Event-Abbruch-Reagierer fuer ET_GO bauen.

RÜCKGABEWERT:
	Keiner.

BEMERKUNG:
	Die Closure darf nur in dem NPC selbst liegen. Alles andere wird
	ein Bug! Der NPC meldet sich nur als Event-Lauscher an, wenn er
	auch einen Ausgang bewacht. Beendet man GuardExit mit deny==0 dann
	meldet sich der NPC ab, wenn er keinen Ausgang mehr bewacht. Der
	NPC meldet sich sowieso ab, wenn er zerstoert wird. Der NPC prueft
	NICHT, ob es den angegebenen Ausgang tatsaechlich gibt. Es ist ihm
	auch egal, wohin der Exit fuehrt. Er faengt jeden Exit (bzw. jedes
	Kommando) ab, was einen ET_GO-Event ausloest.

BEISPIEL:
	Im Waechter-NPC:

	int block(object player);

	void create()
	{
		...

		::create();

		...

	        GuardExit("westen", #'block);
	}

	int block(object player)
	{
		if(!objectp(player)) return 1;
		tell_object(player, "Der Raeuber laesst dich nicht durch!\n");
		tell_room(environment(), break_string("Der Raeuber lacht "
			"nur dreckig, als "+player->name(WER)+" versucht, "
			"nach Westen zu gehen."), ({player}) );
		return 1;
	}

SIEHE AUCH:
	AddExit(L), P_INVIS, P_HIDE, P_SENSE, P_CANNOT_SEE_INVIS, P_AGGRESSIVE