While I was writing about caravans yesterday, and mentioned templates, it occurred to me that a lot of people have probably never seen the code behind an Astaria object, and that I could use one as a very basic guide to what wizards see as opposed to what players see.
This, then, is the template I used for weapons for that caravan. This is the glowing green Matrix text waterfalling down my screen.
// Caravan weapon based on the gold autoloads found in Astaria shops
// Custom made for x at a cost of y
// Bale@Astaria 22 Sep 2008
#include <mudlib.h>
inherit WEAPON ;
void create()
{
::create();
set("id", ({ "weapon" "another weapon", "more weapon" }) );
set("short", "a weapon");
set("long", "The description of the weapon goes here.");
set("weapon", 1);
set("damage", ({ 1, 1 }) );
set("type", "dagger");
set("name", "Weapon");
set_verbs( ({ "stab", "slice" }) );
set_verbs2( ({ "stabs", "slices" }) );
set("second", 1);
set("nosecond", 0);
set("mass", 1);
set("bulk", 1);
set("value", ({ 1, "copper" }) );
set("autoload", 1);
set("autowear", 1);
set("no_detonate", 1);
// Options
set("light", 0);
set("no_steal", 0);
set("no_corrode", 0);
set("wield_func", "wield_message");
set("unwield_func", "unwield_message");
}
int wield_message()
{
message("", "Some text goes here", TP);
message("", "Some text goes here", ETP, ({ TP}) );
return 1;
}
int unwield_message()
{
message("", "Some text goes here", TP);
message("", "Some text goes here", ETP, ({ TP}) );
return 1;
}
People familiar with C-family languages will notice a lot of similarities. LPC is said to be a specialized variant of a combination of C and C++.
All of the “set” statements above create a property, somewhat similar to a variable though with fairly significant differences. The statement ‘set(“autoload”, 1)’ creates a property called “autoload”, which is set to 1 or true — it is the line that tells the mud that a piece of gear should be saved to your player file and thus, automatically reloaded the next time your player file is. (I.e. upon your next login.
The main block of code is encapsulated within the create() function. Create() is executed one time, when an object is created, and not thereafter unless specifically called somewhere else in the code.
The wield_message() and unwield_message() functions are optional, but commonly added. They’re used to do things like wield and unwield spam (as the name suggests), but also applying and removing wield bonuses. The functions are called above from the wield_func() and unwield_func() statements at the end of create(). Special attacks would be handled similarly:
void create()
{
...
set ("hit_func", "special_attack");
...
}
int special_attack()
{
(all the code for the special goes here)
}
Many of the properties which are set… autoload, light, id, short, long… are specific bits of data which the MUD reads and expects to be present by default. In this very basic example, most are required. Weapon and Damage are, where Light is not; a lot of weapons aren’t light sources. Any theoretical arbitrary property can be created with any theoretical arbitrary value assigned to it. Unless that property is accessed somewhere else in the code (whether on the weapon itself or elsewhere in the mudlib) that property will simply be ignored.
This is a very simple, very basic weapon, but would actually compile and load on the current driver (albeit with horrifically cheesy placeholder descriptions.) It’s just over 1 kilobyte of text — 1070 bytes, to be specific. By comparison, my personal wizweapon (the original Soulthief) weighs in at 25 times as much code, at roughly 27 kilobytes.
kizayaen's devblog 