Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 1 | |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 2 | clean_up() |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 3 | ********** |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 4 | |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 5 | |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 6 | FUNKTION |
| 7 | ======== |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 8 | |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 9 | int clean_up(int ref); |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 10 | |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 11 | |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 12 | DEFINIERT IN |
| 13 | ============ |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 14 | |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 15 | * /std/room.c |
| 16 | |
| 17 | * man kann die Funktion jedoch auch in beliebigen Objekten selbst |
| 18 | definieren. |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 19 | |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 20 | |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 21 | ARGUMENTE |
| 22 | ========= |
| 23 | |
| 24 | ref |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 25 | Ein Referenzzaehler (s.u.) |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 26 | |
| 27 | |
| 28 | BESCHREIBUNG |
| 29 | ============ |
| 30 | |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 31 | Wenn ein Objekt seit langer Zeit nicht mehr benutzt wurde (d.h. es |
| 32 | wurde keine lfun *von aussen* in ihm gerufen), ruft der Driver |
| 33 | diese Funktion auf. Es kann es sich hier selbst zerstoeren, um |
| 34 | Speicher freizugeben (und ggf. spaeter mit aktuellem Sourcecode neu |
| 35 | erzeugt werden, was auch eine Art einfacher Updatemechanismus ist). |
| 36 | |
| 37 | Der Referenzzaehler <ref> gibt an, wie oft das Objekt als Vorlage |
| 38 | fuer Clones oder erbende Programme dient. Folgende Faelle sind |
| 39 | damit unterscheidbar: |
| 40 | |
| 41 | ref==0: |
| 42 | Das Objekt ist ein Clone (oder eine Blueprint mit ersetztem |
| 43 | Programm) |
| 44 | |
| 45 | ref==1: |
| 46 | Das Objekt ist eine Blueprint (kein Clone), von welcher zur |
| 47 | Zeit keine Clones oder erbenden Programme existieren. |
| 48 | |
| 49 | ref > 1: |
| 50 | Das Objekt dient als Vorlage / Blueprint fuer Clones oder |
| 51 | erbende Programme. |
| 52 | |
| 53 | Das Objekt im clean_up zu zerstoeren, ist in der Regel ist daher |
| 54 | nur sinnvoll, wenn ref kleiner oder gleich 1 ist. |
| 55 | |
| 56 | Sollte man einem Objekt ein clean_up geben, was als Clone im Umlauf |
| 57 | ist und dieses im Falle von ref==0 zerstoeren, bedeutet dies |
| 58 | letztendlich, dass sich ungenutzte Clones aufraeumen. |
| 59 | |
| 60 | In einem Spezialfall kann ref auch < 0 sein: wenn clean_up *nicht* |
| 61 | vom Driver gerufen wird, sondern (manuell) von irgendwo aus der |
| 62 | Mudlib, ist die *Konvention*, einen Wert < 0 zu uebergeben. |
| 63 | |
| 64 | Standardmaessig definieren nur Raeume clean_up(). Hierbei gilt die |
| 65 | Besonderheit, dass Raeume sich erst beim *zweiten* Aufruf von |
| 66 | clean_up() wegraeumen, wenn in ihnen Objekte liegen, die der Raum |
| 67 | *nicht* selbst mittels AddItem() erzeugt hat. D.h. laesst jemand |
| 68 | etwas im Raum rumliegen, erhoeht sich effektiv die Cleanup-Zeit auf |
| 69 | das doppelte. Und hat irgendjemand sich auf einen Hook des Raums |
| 70 | registriert, raeumt der Raum sich nicht im clean_up() auf. |
| 71 | |
| 72 | Soll ein Raum sich niemals per clean_up() selber aufraeumen, kann |
| 73 | die Property P_NEVER_CLEAN gesetzt werden. Aber bitte seid hiermit |
| 74 | *sehr sparsam* und benutzt das nur in Raeumen, die es wirklich |
| 75 | benoetigen. Fast alle Raeume kommen super klar, wenn sie bei Bedarf |
| 76 | neu erzeugt werden. |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 77 | |
| 78 | |
| 79 | RUeCKGABEWERT |
| 80 | ============= |
| 81 | |
| 82 | Der Rueckgabewert hat nur dann eine Bedeutung, wenn sich das Objekt |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 83 | nicht selbst zerstoert hat. |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 84 | |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 85 | Wird 0 zurueckgegeben, so wird clean_up() *nicht erneut* gerufen. |
| 86 | Ein Rueckgabewert ungleich 0 zeigt hingegen an, dass das Objekt |
| 87 | sich moeglicherweise beim naechsten Aufruf von clean_up() |
| 88 | zerstoeren koennte, d.h. der Driver wird es nach Ablauf der |
| 89 | Cleanup-Zeit erneut versuchen. |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 90 | |
| 91 | |
| 92 | BEMERKUNGEN |
| 93 | =========== |
| 94 | |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 95 | Die Cleanup-Zeit, die ein Objekt nicht benutzt werden darf, bevor |
| 96 | clean_up() aufgerufen wird, betraegt momentan 18h (64800 Sekunden). |
Zesstra | 953f997 | 2017-02-18 15:37:36 +0100 | [diff] [blame] | 97 | |
| 98 | |
| 99 | SIEHE AUCH |
| 100 | ========== |
| 101 | |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 102 | lfuns: |
| 103 | reset() |
MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame] | 104 | |
Zesstra | 70ea424 | 2019-06-27 20:51:52 +0200 | [diff] [blame] | 105 | Properties: |
| 106 | P_NEVER_CLEAN |
| 107 | |
| 108 | 18.02.2019, Zesstra |