Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 1 | |
| 2 | NotifyDestruct() |
| 3 | **************** |
| 4 | |
| 5 | |
| 6 | FUNKTION |
| 7 | ======== |
| 8 | |
| 9 | public int|string NotifyRemove(object zerstoerer); |
| 10 | |
| 11 | |
| 12 | ARGUMENTE |
| 13 | ========= |
| 14 | |
| 15 | zerstoerer |
| 16 | Das Objekt, welches destruct() auf dieses Objekt anwendet. |
| 17 | |
| 18 | |
| 19 | BESCHREIBUNG |
| 20 | ============ |
| 21 | |
| 22 | Diese Funktion wird vom Master der Mudlib in jedem Objekt gerufen, |
| 23 | welches zerstoert wird, um Objekten eine letzte Chance zu geben, sich |
| 24 | aufzuraeumen. |
| 25 | Wenn ihr diese Funktion selber definiert, achtet bittet darauf, dass sie |
| 26 | in keinem Fall Fehler ausloesen sollte, d.h. testet entsprechend |
| 27 | gruendlich. |
| 28 | Wenn ihr aus /std/ erbt und diese Funktion ueberschreibt,, _muesst_ ihr |
| 29 | die geerbte NotifyDestruct() aufrufen, da sonst das Lichtsystem nicht |
| 30 | aktualisiert wird. |
| 31 | |
| 32 | Privilegierte Objekte (z.B. Root-Objekte, spezielle Ausnahmen wie der |
| 33 | Netztotenraum, Armageddon) koennen die Zerstoerung in letzter Sekunde |
| 34 | verhindern, indem sie hier einen Wert != 0 zurueckliefern. Wird ein |
| 35 | string zurueckgeliefert, wird dieser die Fehlermeldung des |
| 36 | prepare_destruct() im Master sein. |
| 37 | Bei nicht-privilegierten Objekten (also fast alle) ist an dieser Stelle |
| 38 | _kein_ Abbruch der Zerstoerung moeglich! |
| 39 | |
| 40 | |
| 41 | RUeCKGABEWERT |
| 42 | ============= |
| 43 | |
| 44 | Der Rueckgabewert muss ein string oder ein int sein. Allerdings wird der |
| 45 | Master den Rueckgabewert nur fuer privilegierte Objekte auswerten. |
| 46 | |
| 47 | |
| 48 | BEMERKUNGEN |
| 49 | =========== |
| 50 | |
| 51 | Wie gesagt, bitte keine Fehler ausloesen (auch wenn der Master |
| 52 | grundsaetzlich damit klar kommt). Speziell ist ein raise_error() zur |
| 53 | Verhinderung eines destructs nutzlos. |
| 54 | Bitte macht in dieser Funkion nur das, was _unbedingt_ notwendig ist. |
| 55 | Wenn jemand ein destruct() anwendet statt ein remove() zu rufen, hat das |
| 56 | in der Regel einen Grund (z.B. um buggende remove() zu umgehen). Insb. |
| 57 | ist ein save_object() in remove() und NotifyDestruct() vollstaendig |
| 58 | ueberfluessig. |
| 59 | |
| 60 | |
| 61 | SIEHE AUCH |
| 62 | ========== |
| 63 | |
| 64 | NotifyLeave(), NotifyInsert(), NotifyRemove() |
| 65 | |
| 66 | Last modified: 25.02.2009, Zesstra |