On Wed, 5 Sep 2001, Del wrote:
>Please correct me if I am wrong. If a player, mob or room has an object,
>does it not have an actual copy of the prototype? The question Caniffe
>asked seems to be a good one. Why have a copy of the object? Why not have
>a single variable or small struct to point to the prototype for every
>copy of that object? All references to that object should just get the
>information from the prototype.
Let's see:
struct obj_flag_data {
int value[4];
Can't stay in prototype: changes for various objects. Once I've
finished my little work on object stacking you should be able to
make this global and split off copies of objects.
int timer;
Needs a local copy.
byte type_flag;
int /*bitvector_t*/ wear_flags;
int /*bitvector_t*/ extra_flags;
int weight;
int cost;
int cost_per_day;
long /*bitvector_t*/ bitvector;
Prototypable, unless you 'enchant weapon', which changes
'extra_flags': SET_BIT(GET_OBJ_EXTRA(obj), ITEM_ANTI_EVIL);
};
struct obj_data {
obj_vnum item_number;
Object global.
room_rnum in_room;
Object local.
struct obj_flag_data obj_flags;
See above.
struct obj_affected_type affected[MAX_OBJ_AFFECT];
Object global, but can change: see 'enchant weapon' again.
char *name;
char *description;
char *short_description;
char *action_description;
Object global, though people often 'string' objects.
struct extra_descr_data *ex_description;
Object global. Doesn't change often but can.
struct char_data *carried_by;
struct char_data *worn_by;
sh_int worn_on;
struct obj_data *in_obj;
struct obj_data *contains;
struct obj_data *next_content;
struct obj_data *next;
All object local.
};
So our structures become (being generous and assuming copy-on-write for
the global-yet-changes-sometimes items):
struct obj_shared_data {
int value[4];
byte type_flag;
int /*bitvector_t*/ wear_flags;
int /*bitvector_t*/ extra_flags;
int weight;
int cost;
int cost_per_day;
long /*bitvector_t*/ bitvector;
obj_vnum item_number;
struct obj_affected_type affected[MAX_OBJ_AFFECT];
char *name;
char *description;
char *short_description;
char *action_description;
struct extra_descr_data *ex_description;
}
and:
struct obj_local_data {
int timer;
room_rnum in_room;
struct char_data *carried_by;
struct char_data *worn_by;
sh_int worn_on;
struct obj_data *in_obj;
struct obj_data *contains;
struct obj_data *next_content;
struct obj_data *next;
}
>If there is an object that get's changed, a new prototype can be made?
Not generally an option. What VNUM do you assign your new object? Then you
have to adjust the entire array as well. What about 600 different corpses?
Sure they don't take any more room in the prototype array than having 600
individual objects but do you really want to make the contortions OasisOLC
has to go through to make an object the norm?
>Effectively the player just has a list of vnum's of the objects that they
>have vice a copy of the object. Or is this what you are planning with
>this new stacking idea? Would this idea not cut down on memory usage
>considerably?
The major failing with trying to split the objects up is a non-prototyped
object. Corpses and mail messages do not have prototypes, which is also
why they don't save in the object files without PjD's object code. You
can't just invent a prototype for a transient object.
I will admit to not liking 'next_content' and 'next' in obj_data, but
that's due to wanting to separate the list from the datum.
struct list_item { void *data; struct list_item *next; }
list_item -> list_item -> list_item -> NULL
\_obj_dat \_obj_data \_obj_data
Makes the list primitives non-object-specific.
--
George Greer
greerga@circlemud.org
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST