A
          / \      _             Play Now                         Nemesis on 
          | |     | |  _______   _        _   _______    _______   _    _______
          | |\    | | |   ____| |  \    /  | |   ____|  /   ____| | |  /   ____|
 /-------/-------------------------------------------------------------------,
O= Home <=XX|  About  News  Pics  Adventurers  Wizards  Download  Connect     >
 \-------\-------------------------------------------------------------------'
          | |   \   | |  |____  | |      | | |  |____   ___ \  \  | |  ___ \  \
          | |     \_| |_______| |_|      |_| |_______| |_______/  |_| |_______/
          \ /
           V  

Documentation Area

Document Path: /doc/object/set_data

Lfun:	set_data - setup the variables in a cloned or inherited generic object

Synopsis:
	int set_data(...)

Description:
	This manual has to be re-written! This below is old stuff! For the
	persistence of players' inventory, there is a new syntax of set_data
	that will also support the old stuff below but is much easier to
	handle! Documentation will come ...

	Generic objects should provide an implementation of set_data(). The
	number and meaning of arguments changes, but they have one thing in
	common: Important data comes first, optional data last, so you can
	leave fields that you don't care for, out. For instance let's look
	at the comment I wrote into /obj/armour.c right in front of set_data:

	/* -> set_data(name, type, value, weight, ac, short, alias, long);
	 *      only first 4 parameters are absolutely necessary.  -lynx
	 */

	So you can clone /obj/armour.c and call set_data("ring of leather",
	"ring", 17, 1) and that's all. You have an ugly worthless ring made out
	of leather. Now forget this bad example. ;)

	Using set_data instead of several small set_something calls is more
	efficient, that's why set_data should be used mostly. Especially with
	system generic objects.

	The order and meaning of arguments for a set_data function should be
	kept once defined. You can rely on that, it won't be changed.
	Should you be a coder of generic (object class) objects, you must
	take special care in choosing a good strategy of argument order!
	Once wizards use your objects you are not supposed to change the order!

Return value:
	... to be ignored, but should be true!

Examples:
	This is somewhat old stuff - new will come:
	/* from armour.c */
	set_data(n, t, v, w, c, s, a, l, i) {
		name = n; type = t; value = v; weight = w; alias = a;
		if (c) ac = c;
		if (s) short_desc = s;
		else short_desc = a_or_an(n)+" "+n;
		if (l) long_desc = l;
		else long_desc = capitalize(short_desc)+".\n";
		info = i;
	}

Note:
	This is almost all old stuff!

See also:
object/show_data