View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000269 | LDMud | Efuns | public | 2004-11-26 23:21 | 2009-10-05 16:46 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000269: New efun copy_object() | ||||
| Description | Short: Efun copy_object() Date: Mon, 29 Oct 2001 11:44:36 +0100 (MET) From: Erik Meusel <emeusel@mail.CS.Uni-Magdeburg.De> Type: Feature State: new sag mal, wie waere es mit einer Efun der Art object copy_object(object ob)? Hier kurz ein Umriss, was die machen soll und wozu sie mE sinnvoll waere: Sie kopiert ein Objekt _komplett_ (vorzugsweise natuerlich nur Clones) und legt einen neuen Clone an, der in den gleichen Zustand versetzt wird wie das Quellobjekt. D.h. Variableninhalte, Symbolreferenzen, laufende call_out()s usw. usf. werden uebernommen. Sinn der Sache waere u.a. eine dramatische Vereinfachung des Renew-Vorganges, den viele Mudlibs implementiert haben, der jetzt noch auf dem Kopieren von Properties beruht und bei jeder Aenderung der Mudlib auf dem neuesten Stand gehalten werden muss. Ausserdem kann eine solche "Stueck-fuer-Stueck"-Kopie natuerlich nie komplett sein, private und statische Variablen des Quellobjektes kann man ja nicht auslesen. Vielleicht in Verbindung mit einer Applied-Funktion copy(object ob) oder so, damit komplexere Objekte die Moeglichkeit haben, sich ueber Dinge hinaus kopieren koennen, die Du von Driverseite sehen kannst, zB koennte dann ein Raum, der einen NPC beinhaltet, sich komplett kopieren, also auch eine eigene Kopie des Ursprungs-NPC herstellen und hineinstellen. Wichtig dafuer waeren vielleicht auch aus C++ bekannte Friend-Mechanismen (zumindest die automatischen fuer Instanzen der gleichen Klasse). Naja. Nur so als Anregung. Schreib mal Deine Meinung dazu, wenn Du magst. ----- How to handle inventories and changed programs? The copy() apply could be done via a simul_efun overloading this efun. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
Im inclined to leave it to the mudlib, even though certain entities can't directly be copied and must be deliberately exported e.g. by a query method. The mudlib knows usually much better, which entities of an object should be copied and which are better not. And sometime I really don't want to have an object the exact same data after renew than the old one, because I changed some behaviour and need some data to be different... A speed increase for renewing is IMHO not the issue here, because that is not a process, which takes place all time. To duplicate running callouts (with closures in the new object) is a complicated thing to do, granted. Lars argument about inventories and changed programs is also a very good point. |
|
|
I agree. Handling stuff like this in the driver would (at least) involve a callback hook into the mudlib to make the lib decide about what you mentioned. At this point, you can IMHO handle the whole process entirely in the mudlib. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:21 |
|
New Issue | |
| 2009-10-02 03:53 | zesstra | Note Added: 0001404 | |
| 2009-10-02 03:53 | zesstra | Status | new => feedback |
| 2009-10-02 04:41 | Largo | Note Added: 0001405 | |
| 2009-10-05 16:46 | zesstra | Status | feedback => closed |
| 2009-10-05 16:46 | zesstra | Resolution | open => won't fix |
