Invisible
unread,Nov 30, 2020, 6:47:20 AM11/30/20Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to ldmud...@googlegroups.com
Hello,
a quick question regarding clone_object and #pragma share_variables:
From what I have seen, #pragma share_variables creates a *shallow* copy
of the blueprint's variables. Actually this makes the name
"shared_variables" a bit misleading, as variables are _copied_ (i.e.
every clone gets its own value), but array/mapping variables hold a
reference (i.e. the contents are actually _shared_ between clones, like
the name suggests!).
I guess in most mudlibs, an object's properties are stored in
arrays/mappings, which are initialized on object creation (e.g. in a
create() or equivalent function call form the create_ob and create_clone
driver hooks). Now, is there a way to initialize the clone's variable
values to a *deep* copy of the current values from the blueprint? This
could dramatically speed up the creation of clones, because there would
e.g. be no need to re-initialize properties/attributes/details/etc in a
clone's create()-function, when they are (initially) equal for all new
clones anyways (but may be changed later, without affecting other clones).
example:
- /std/obj/item.c ---------------------
// suggestion for a less misleading pragma name
#pragma copy_variables
inherit "/std/obj.c";
void
create()
{
// if we are a clone we get all our initial values from the blueprint
if (clonep()) return;
// only run the initialisation in the blueprint
::create();
set_name("A beautiful item.");
add_adjective("beautiful");
add_detail("surface", "It's shiny!");
/* set a thousand other properties */
}
int
make_dirty()
{
// this should only update the property of this specific clone
update_detail("surface", "Someone made this item all sticky and
grimy.");
}
---------------------------------------
regards,
Invis