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