Deliantra
view release on metacpan or search on metacpan
res/types.xml view on Meta::CPAN
<!ELEMENT bitmask (entry*)>
<!ATTLIST bitmask name CDATA #REQUIRED>
<!ELEMENT list (entry*)>
<!ATTLIST list name CDATA #REQUIRED>
<!ELEMENT entry EMPTY>
<!ATTLIST entry bit CDATA #IMPLIED
value CDATA #IMPLIED
name CDATA #REQUIRED>
<!ELEMENT ignore_list (attribute* | EMPTY)>
<!ATTLIST ignore_list name CDATA #REQUIRED>
<!ELEMENT default_type (attribute*)>
<!ELEMENT type (import_type?,required?,ignore?,description?,use?,(section | attribute)*)>
<!ATTLIST type name CDATA #REQUIRED
number CDATA #REQUIRED>
<!ELEMENT description (#PCDATA)>
<!ELEMENT use (#PCDATA)>
<!ELEMENT import_type EMPTY>
<!ATTLIST import_type name CDATA #REQUIRED>
<!ELEMENT required (attribute+)>
<!ELEMENT ignore (attribute*,ignore_list*)>
<!ELEMENT section (attribute+)>
<!ATTLIST section name CDATA #REQUIRED>
<!ELEMENT attribute (#PCDATA)>
<!ATTLIST attribute type CDATA #IMPLIED
arch CDATA #IMPLIED
arch_begin CDATA #IMPLIED
arch_end CDATA #IMPLIED
editor CDATA #IMPLIED
value CDATA #IMPLIED
length CDATA #IMPLIED
true CDATA #IMPLIED
false CDATA #IMPLIED>
<!ENTITY move_on "
<attribute arch='move_on' editor='movement on' type='movement_type'>
Which movement types automatically (as opposed to manually) activate this object.
</attribute>
">
<!ENTITY move_off "
<attribute arch='move_off' editor='movement off' type='movement_type'>
Which movement types deactivate this object (e.g. button).
</attribute>
">
<!ENTITY move_type "
<attribute arch='move_type' editor='movement type' type='movement_type'>
Determines which kinds of movement this object can use (e.g. for monsters)
or grants (e.g. for amulets).
</attribute>
">
<!ENTITY move_block "
<attribute arch='move_block' editor='blocked movement' type='movement_type'>
Objects using these movement types cannot move over this space.
</attribute>
">
<!ENTITY movement_types_terrain "
&move_block;
<attribute arch='move_allow' editor='allowed movement' type='movement_type'>
Objects using these movement types are allowed to move over this space. Takes
precedence over 'blocked movements'.
</attribute>
<attribute arch='move_slow' editor='slowed movement' type='movement_type'>
The types of movement that should by slowed down by the 'slow movement penalty'.
</attribute>
<attribute arch='move_slow_penalty' editor='slow movement penalty' type='int'>
If <slow movement> is set to a value greater zero, all
creatures matching 'slow move' will be slower than normal on this spot.
<slow movement> 1 - rough terrain
<slow movement> 2 - very rough terrain
...
<slow movement> 5 - default for deep swamp
...
<slow movement> 7 - spider web (sticky as hell)
</attribute>
">
<!ENTITY speed_left "
<attribute arch='speed_left' editor='speed left' type='float'>
The speed left to the object. On every tick, if this value is higher
than 0, the object acts/triggers/moves etc. and the value gets
decremented by 1. Otherwise, it is incremented by <speed> on
every tick.
</attribute>
">
<!ENTITY activate_on "
<attribute arch='activate_on_push' editor='activate on push' type='bool'>
Whether the teleporter should only be activated on push.
</attribute>
<attribute arch='activate_on_release' editor='activate on release' type='bool'>
Whether the teleporter should only be activated on release.
</attribute>
">
<!ENTITY resistances_flesh_desc "
Resistances on flesh items make them more durable against spellcraft
of the appropriate kind. It also allows dragon players to eventually gain
resistance by eating it. Usually resistance should only be set for flesh
items in a monster's inventory.
">
<!ENTITY resistances_flesh_section "
<section name='resistance'>
<attribute arch='resist_physical' editor='resist physical %' length='15' type='int'>
&resistances_flesh_desc;
</attribute>
<attribute arch='resist_magic' editor='resist magic %' length='15' type='int'>
&resistances_flesh_desc;
</attribute>
<attribute arch='resist_fire' editor='resist fire %' length='15' type='int'>
&resistances_flesh_desc;
</attribute>
<attribute arch='resist_electricity' editor='resist electricity %' length='15' type='int'>
&resistances_flesh_desc;
</attribute>
<attribute arch='resist_cold' editor='resist cold %' length='15' type='int'>
&resistances_flesh_desc;
</attribute>
<attribute arch='resist_confusion' editor='resist confusion %' length='15' type='int'>
&resistances_flesh_desc;
</attribute>
res/types.xml view on Meta::CPAN
<section name="terrain">
&movement_types_terrain;
<attribute arch="is_wooded" editor="wooded terrain" type="bool">
This flag indicates this spot contains wood or high grass.
Players with activated woodsman skill can move faster here.
</attribute>
<attribute arch="is_hilly" editor="hilly terrain" type="bool">
This flag indicates this spot contains hills or large rocks.
Players with activated mountaineer skill can move faster here.
</attribute>
</section>
<attribute arch="no_magic" editor="no spells" type="bool">
If enabled, it is impossible for players to use (wizard-)
spells on that spot.
</attribute>
<attribute arch="damned" editor="no prayers" type="bool">
If enabled, it is impossible for players to use prayers
on that spot. It also prevents players from saving.
</attribute>
<attribute arch="unique" editor="unique map" type="bool">
Unique floor means that any items dropped on that spot
will be saved beyond map reset. For permanent apartments,
all floor tiles must be set <unique map>.
</attribute>
<attribute arch="is_buildable" editor="buildable" type="bool">
A buildable can be built upon. This is usually used in combination with
the unique attribute for player apartments or guild storages. But it's
use is not limited to private maps.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This text may describe the object.
</attribute>
</type>
<!--####################################################################-->
<type number="6" name="Food">
<description><![CDATA[
By eating/drinking food-objects, the player can fill his
stomache and gain a little health.]]>
</description>
<attribute arch="food" editor="foodpoints" type="int">
The player's stomache will get filled with this amount of foodpoints.
The player's health will increase by <foodpoints>/50 hp.
</attribute>
<attribute arch="startequip" editor="godgiven item" type="bool">
A godgiven item vanishes as soon as the player
drops it to the ground.
</attribute>
</type>
<!--####################################################################-->
<type number="91" name="Gate">
<ignore>
<ignore_list name="non_pickable" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Gates play an important role in Deliantra. Gates can be opened
by activating a button/trigger, by speaking passwords (-> magic_ear)
or carrying special key-objects (-> inventory checker).
Unlike locked doors, gates can get shut again after a player has
passed, which makes them more practical in many cases.]]>
</description>
<use><![CDATA[
Use gates to divide your maps into seperated areas. After solving
area A, the player gains access to area B, and so on. Make your
maps more complex than "one-way".]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="speed" value="1" type="float">
The speed of the gate affects how fast it is closing/opening.
</attribute>
<attribute arch="connected" editor="connection" type="string">
Whenever the inventory checker is triggered, all objects with identical
<connection> value get activated. This only makes sense together with
<blocking passage> disabled.
</attribute>
<attribute arch="wc" editor="position state" type="int">
The <position state> defines the position of the gate:
Zero means completely open/down, the "number of animation-steps" (usually
about 6 or 7) means completely closed/up state. I suggest you don't
mess with this value - Leave the default in place.
</attribute>
&movement_types_terrain;
<attribute arch="no_magic" editor="restrict spells" type="bool">
Restricting the use of spells to pass this gate. This has
an effect only if <block view> is disabled.
</attribute>
<attribute arch="damned" editor="restrict prayers" type="bool">
Restricting the use of prayers to pass this door. This has
an effect only if <block view> is disabled.
</attribute>
</type>
<!--####################################################################-->
<type number="113" name="Girdle">
<import_type name="Amulet" />
<description><![CDATA[
Wearing a girdle, the object's stats will directly be inherited to
the player. Girdles usually provide stats- or damage bonuses and no
defense.]]>
</description>
<use><![CDATA[
Feel free to create your own special artifacts. However, it is very
important that you keep your artifact in balance with existing maps.]]>
</use>
<attribute arch="magic" editor="magic bonus" type="int">
<magic bonus> works just like ac, except that it can be improved by
"scrolls of Enchant Armour" or reduced by acid. It is less useful
than direct armour-class bonus on the helmet.
Important: <magic bonus> on girdles has no effect if there is no
<armour class> set. Girdles shouldn't have <armour class>, thus
<magic bonus> is pointless here.
</attribute>
</type>
<!--####################################################################-->
<type number="100" name="Gloves">
<import_type name="Amulet" />
<description><![CDATA[
res/types.xml view on Meta::CPAN
<!--####################################################################-->
<type number="64" name="Inventory Checker">
<ignore>
<ignore_list name="system_object" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Inventory checkers passively check the players inventory for a
specific object. You can set a connected value that is triggered
either if that object is present or missing (-> "last_sp") when a
player walks over the inv. checker. A valid option is to remove the
matching object (usually not recommended, see "last_heal").
<br><br>
Alternatively, you can set your inv. checker to block all players
that do/don't carry the matching object.
<br><br>
As you can see, inv. checkers are quite powerful, holding a
great variety of possibilities.]]>
</description>
<use><![CDATA[
Putting a check_inventory space in front of a gate (one below) and
one on the opposite side works reasonably well as a control mechanism.
Unlike the key/door-combo, this one works infinite since it is
independant from map reset. Use it to put a "structure" into your
maps: Player must solve area A to gain access to area B. This concept
can be found in nearly every RPG - simple but effective.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="slaying" editor="match key string" type="string">
This string specifies the object we are looking for: We have a match
if the player does/don't carry a key object or a mark with identical
<key string>. Note that key objects usually appear as "passports" in
this context. A typical example is the city gate mechanism of scorn.
</attribute>
<attribute arch="race" editor="match arch name" type="string">
This string specifies the object we are looking for: We have a match
if the player does/don't carry an object of archtype <match arch name>.
</attribute>
<attribute arch="hp" editor="match type" type="int">
This value specifies the object we are looking for: We have a match
if the player does/don't carry an object that is of type <match type>.
Example: Set <match type> 15 (type 15 => weapon) and <blocking passage>
enabled. Now you have an inv. checker blocking all players that carry any
kind of melee weapon. To pass, a player is forced to leave behind all
his weaponry... bad news for a warrior. ;)
</attribute>
<attribute arch="last_sp" editor="match = having" type="bool">
Enabled means having that object is a match.
Disabled means not having that object is a match.
</attribute>
<attribute arch="connected" editor="connection" type="string">
Whenever the inventory checker is triggered, all objects with identical
<connection> value get activated. This only makes sense together with
<blocking passage> disabled.
</attribute>
&movement_types_terrain;
<attribute arch="last_heal" editor="remove match" type="bool">
<remove match> means remove object if found. Setting this is usually not
recommended because inv. checkers are in general invisible. So, unlike
for altars/ locked doors, the player won't expect to lose an object when
walking over that square. And he doesn't even get a message either.
So, *if* you enable <remove match>, make sure
to inform the player what's going on!
</attribute>
</type>
<!--####################################################################-->
<type number="163" name="Item Transformer">
<description><![CDATA[
An item transformer is simply applied, after having marked a 'victim'
item. If the victim is suitable, it will be transformed into something
else.]]>
</description>
<use><![CDATA[
To make an item transformable, you just have to fill the 'slaying' field.
The syntax is:
<br>
<pre>slaying slayer:[yield ]new_item[;slayer:[yield ]new_item]*</pre>
<br>
with [] denoting optional part, and * any number of preceding [].
'new_item' must be the name of an existing archetype.
<br><br>
Example, for object apple: slaying knife:2 half_apple
<br><br>
This means that, when applying a knife (should be an Item Transformer),
one 'apple' will be transformed into 2 'half_apple'.]]>
</use>
<attribute arch="food" editor="number of uses" type="int">
<number of uses> controls how many times the item transformer can
be used. The value 0 means "unlimited"
</attribute>
<attribute arch="slaying" editor="verb" type="string">
Contains the verb that is used to construct a message to the player
applying the item transformer.
</attribute>
<attribute arch="startequip" editor="godgiven item" type="bool">
A godgiven item vanishes as soon as the player
drops it to the ground.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This text may contain a description of the item transformer.
</attribute>
</type>
<!--####################################################################-->
<type number="60" name="Jewel">
<description><![CDATA[
Items of the type Gold & Jewels are handled like a currency.
Unlike for any other type of item, in shops, the buy- and selling
prices differ only marginally.]]>
</description>
<attribute arch="race" value="gold and jewels" type="fixed" />
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This text may describe the object.
</attribute>
</type>
<!--####################################################################-->
<type number="24" name="Key">
<description><![CDATA[
When carrying a key, a normal door can be opened. The key will
disappear.]]>
</description>
<attribute arch="startequip" editor="godgiven item" type="bool">
A godgiven item vanishes as soon as the player
drops it to the ground.
</attribute>
<attribute arch="no_steal" editor="not stealable" type="bool">
This item can't be stolen if the flag is set.
</attribute>
</type>
<!--####################################################################-->
<type number="20" name="Locked Door">
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
A locked door can be opened only when carrying
the appropriate special key.]]>
</description>
<use><![CDATA[
If you want to create a locked door that cannot be opened (no key),
set a <key string> like "no_key_available". This will clearify things
and only a fool would create a key matching that string.
Door-objects can not only be used for "doors". In many maps these
are used with all kinds of faces/names, especially often as
"magic force". A good example is the map "Lake_Country/ebony/masterlev".
There you have magic forces (door objects) put under certain artifact
items. To get your hands on the artifacts, you need to bring up the
appropriate quest items (key objects).]]>
</use>
<attribute arch="move_type" value="0" type="fixed" />
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="slaying" editor="key string" type="string">
The <key string> in the door must be identical with the
<key string> in the special key, then the door is unlocked.
It is VERY important to set the <key string> to something that
is unique among the Deliantra mapset.
DONT EVER USE the default string "set_individual_value".
When the key string starts with "match ", then it is expected to
be a match expression, which will be applied to the player, so
you can use e.g. (match type=POTION in inv). Note that the matched
object will be removed.
</attribute>
<attribute arch="no_magic" editor="restrict spells" type="bool">
Restricting the use of spells to pass this door.
This should be set in most cases.
(Don't forget that the spell "dimension door" is easily
available at about wisdom level 10).
</attribute>
<attribute arch="damned" editor="restrict prayers" type="bool">
Restricting the use of prayers to pass this door.
This should be set in most cases.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="lock message" type="text">
When a player is trying to open the door without carrying the
appropriate key, this text is displayed to the player. This is
a good opportunity to place hints about the special key needed
to unlock the door.
</attribute>
</type>
<!--####################################################################-->
<type number="29" name="Magic Ear">
<ignore>
<ignore_list name="system_object" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Magic_ears trigger a connected value
when the player speaks a specific keyword.]]>
</description>
<use><![CDATA[
Whenever you put magic_ears on your maps, make sure there are
CLEAR and RELYABLE hints about the keywords somewhere. Don't make
something like a gate that is opened by speaking "open" or
"sesame", expecting the player to figure this out all by himself.
<br><br>
Magic_ears are typically used for interaction with NPCs. You
can create the impression that the NPC actually *does* something
according to his conversation with a player. Mostly this means
opening a gate or handing out some item, but you could be quite
creative here.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="connected" editor="connection" type="string">
The Magic_ear will trigger all objects with the
same connection value, every time it is activated.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="keyword-matching" type="text">
This textfield contains the keyword-matching-syntax. The text should
have the following format: "@match <keyword1>|<keyword2>|... ".
Any number of keywords from one to infinite is allowed. Make sure
they are seperated by a '|'.
res/types.xml view on Meta::CPAN
<ignore>
<ignore_list name="non_pickable" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Pedestals are designed to detect certain types of living objects.
When a predefined type of living creature steps on the pedestal, the
connected value is triggered.]]>
</description>
<use><![CDATA[
If you want to create a place where only players of a certain race
can enter, put a teleporter over your pedestal. So the teleporter is
only activated for players of the matching race. Do not use gates,
because many other players could sneak in. If you put powerful
artifacts into such places, generally set "startequip 1", so that
they are preserved for that one race and can't be traded to others.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="slaying" editor="match race" type="string">
the <match race> defines the object we're looking for. If <match race>
matches the monster's or the player's race, we have a match.
Yes, pedestals can detect a player's race! E.g. you could create a
place where only fireborns can enter, by setting "slaying unnatural".
If it is set to "player", any player stepping on the pedestal
is a match. Very useful if you want to open a gate for players
but not for monsters.
&match_compat;
</attribute>
<attribute arch="connected" editor="connection" type="string">
When the pedestal is triggered, all objects with the same
connection value get activated.
</attribute>
&move_on;
</type>
<!--####################################################################-->
<type number="32" name="Pedestal Trigger">
<import_type name="Pedestal" />
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
Pedestal triggers are pedestals which reset after a short period
of time. Every time it is either applied or reset, the
<connection> value is triggered.]]>
</description>
</type>
<!--####################################################################-->
<type number="19" name="Item Match">
<ignore>
<ignore_list name="non_pickable" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Match objects use the deliantra matching language
(http://pod.tst.eu/http://cvs.schmorp.de/deliantra/server/lib/cf/match.pm)
to match items on the same mapspace (if move_on/off are unset) or
items trying to enter (if move_blocked is set).
If a connected value is given, then it is triggered if the first object
matching the expression is put on it, and the last is removed.]]>
</description>
<use><![CDATA[
If you want to trigger something else (e.g. a gate) when an item is above this object,
use the move_on/move_off settings.
If you want to keep something from entering if it has (or lacks) a specific item,
use the move_blocked setting.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="slaying" editor="match expression" type="string">
&match_compat;
Optionally you can leave out the "match " prefix.
</attribute>
<attribute arch="connected" editor="connection" type="string">
When the match is triggered, all objects with the same
connection value get activated.
</attribute>
&move_on;
&move_off;
&move_block;
</type>
<!--####################################################################-->
<type number="94" name="Pit">
<ignore>
<ignore_list name="non_pickable" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Pits are holes, transporting the player when he walks (and falls) into them.
A speciality about pits is that they don't transport the player to
the exact destination, but within a configurable radius of the destination
(never on blocked squares).<br>
Optionally, pits can get closed and opened, similar to gates.<br><br>
Monsters and items are affected by pits just as well as players.
Even multipart monsters can fall through them, given enough space.]]>
</description>
<use><![CDATA[
Pits can add interesting effects to your map. When using them, make
sure to use them in a "logical way": Pits should always drop the
player to some kind of lower level. They should not be used to
randomly interconnect maps like teleporters do.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="range" editor="spread radius" type="int">
The radius of the square area that the pit will randomly put the player into (0 to 3, default 1).
</attribute>
<attribute arch="connected" editor="connection" type="string">
When a <connection> value is set, the pit can be opened/closed
by activating the connection.
</attribute>
&activate_on;
<attribute arch="hp" editor="destination X" type="int">
The pit will transport creatures (and items) randomly into a two-square
radius of the destination coordinates.
If the destination square becomes blocked, the pit will act like
being filled up and not work anymore!
</attribute>
<attribute arch="sp" editor="destination Y" type="int">
The pit will transport creatures (and items) randomly into a two-square
radius of the destination coordinates.
If the destination square becomes blocked, the pit will act like
being filled up and not work anymore!
</attribute>
<attribute arch="wc" editor="position state" type="int">
The <position state> defines the position of the gate:
Zero means completely open/down, the "number of animation-steps" (usually
about 6 or 7) means completely closed/up state. I suggest you don't
mess with this value - Leave the default in place.
</attribute>
&move_on;
</type>
<!--####################################################################-->
<type number="7" name="Poison Food">
<description><![CDATA[
When eating, the player's stomache is drained by 1/4 of food.
If his food drops to zero, the player might even die.]]>
</description>
</type>
<!--####################################################################-->
<type number="5" name="Potion">
<description><![CDATA[
The player can drink these and gain various kinds of benefits
(/penalties) by doing so.]]>
</description>
<use><![CDATA[
One potion should never give multiple benefits at once.]]>
</use>
<attribute arch="level" editor="potion level" type="int">
If the potion contains a spell, the spell is cast at this level.
For other potions it should be set at least to 1.
</attribute>
<attribute arch="sp" editor="spell" type="spell">
When a player drinks this potion, the selected spell
will be casted (once). This should work for any given spell.
E.g. heal is "sp 35", magic power is "sp 67".
</attribute>
<attribute arch="attacktype" editor="special effect" type="list_potion_effect">
There are two types of special effects for potions:
'life restoration' - restore the player's stats lost by death or draining
(this has nothing in common with the restoration spell!)
'improvement' - increase the player's maximum health/mana/grace
by a very small amount.
</attribute>
<attribute arch="cursed" editor="cursed" type="bool">
If a potion is cursed, benefits generally turn into penalties.
Note that potions can be "uncursed" by praying over an altar,
with relative ease. *But* the potion must be identified to notice
that it is cursed >:)
</attribute>
<attribute arch="startequip" editor="godgiven item" type="bool">
A godgiven item vanishes as soon as the player
drops it to the ground.
</attribute>
&player_stat_resist_sections;
</type>
<!--####################################################################-->
<type number="156" name="Power Crystal">
<description><![CDATA[
res/types.xml view on Meta::CPAN
unrelated to any predefined skill archtype.</p>]]>
</use>
<attribute arch="invisible" value="1" type="fixed" />
<attribute arch="no_drop" value="1" type="fixed" />
<attribute arch="skill" editor="skill name" type="string">
The <skill name> is used for matchings. When a usable
object has an identical <skill name>, players
(or monsters) will need this skill to apply/use the object.
</attribute>
<attribute arch="expmul" editor="exp multiplier" type="float">
This is the ratio of experience the players total should increase by
when this skill is used. If this is zero, then experience only goes to
to the skill. Values higher than 1 are allowed. Note that experience
rewarded to the players total is in addition to that given to the
skill. Eg, if player should get 500 exp for using a skill, and
expmul is 1, the player will get 500 added to that skill as well as
500 to their total.
</attribute>
<attribute arch="subtype" editor="skill type" type="list_skill_type">
The <skill type> defines the base functionality of the skill.
Skill types are hardcoded in the Deliantra server. It isn't hard to
create new skill types, but it requires a bit of server-coding.
</attribute>
<attribute arch="level" editor="level" type="int">
</attribute>
<attribute arch="exp" editor="experience" type="int">
</attribute>
<attribute arch="can_use_skill" editor="is native skill" type="bool">
The <is native skill> flag has an effect only when this
skill object is placed in the inventory of a monster (or player).
If it is set, the monster or player knows the skill natively, which
means he does not need a skill tool to use it.
</attribute>
</type>
<!--####################################################################-->
<type number="130" name="Skill Scroll">
<description><![CDATA[
By reading a skill scroll, a player has a chance to learn the
contained skill.]]>
</description>
<use><![CDATA[
Skill scrolls are very much sought for by players. Currently,
all skill scrolls are sold in shops randomly, which is in fact not
a good system. It would be nice to have some cool quests with
skill scrolls rewarded at the end.]]>
</use>
<attribute arch="race" value="scrolls" type="fixed" />
<attribute arch="skill" editor="skill name" type="string">
The <skill name> matches the skill object that can
be learned from this scroll.
</attribute>
</type>
<!--####################################################################-->
<type number="21" name="Special Key">
<ignore>
<attribute arch="material" />
</ignore>
<description><![CDATA[
When carrying the appropriate special key, a locked door can
be opened. The key will dissapear.
<br><br>
This object-type can also be used for "passport"-like items:
When walking onto an invetory checker, a gate for example might
get opened. The "passport" will stay in the player's inventory.]]>
</description>
<use><![CDATA[
How to make a "passport": You take the special key arch
(archetype name is "key2"), set the face to something like
card.111 and the name to "passport" - that's all. The <key string>
certainly must match with the appropiate inventory checker.
<br><br>
Of course you can be creative with names and faces of
key-objects. A "mysterious crystal" or a "big dragon claw"
(with appropriate faces) appear more interesting than just
a "strange key", or "passport".]]>
</use>
<attribute arch="slaying" editor="key string" type="string">
This string must be identical with the <key string> in the
locked door, then it can be unlocked. It can also be used
to trigger inventory checkers.
</attribute>
<attribute arch="material" editor="material" type="bitmask_material">
For Special Keys, material should always be unset or set
to Adamantite. This prevents the key from getting
burned or otherwise destroyed.
</attribute>
<attribute arch="unique" editor="unique item" type="bool">
Unique items exist only one time on a server. If the item
is taken, lost or destroyed - it's gone for good.
This can be used if you want to sell apartments on your
map: Simply sell a unique passport/key, and place
an inventory checker at the entrance of your apartment.
</attribute>
<attribute arch="startequip" editor="godgiven item" type="bool">
A godgiven item vanishes as soon as the player
drops it to the ground.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This will add a description to the object. The player can read
this text by clicking on the item in his inventory. Use this
message to describe what the key/passport is good for. A player
might have 50 different keys on his key-ring. Don't expect
players to recall their purpose just by their names.
</attribute>
<attribute arch="no_steal" editor="not stealable" type="bool">
This item can't be stolen if the flag is set.
</attribute>
</type>
<!--####################################################################-->
<type number="101" name="Spell">
<ignore>
<ignore_list name="system_object" />
</ignore>
<description><![CDATA[
Spell objects define a spell. When a spell is put in a spellbook,
players can learn it by reading the book. Once learned, players
can use the spell as often as they like. With increasing skill level
of the player, spells may gain power but also increase cost.<br>
Monsters can use spells which are put in their inventory (provided
that certain "enabling" settings are correct). The monster's
<treasurelist> can also be used to provide it with spells.]]>
</description>
<use><![CDATA[
A lot of the spells' settings can be tuned and customized.
When creating new spells which are accessible to players, it is
important to think about balance. A single spell which is too
powerful and/or too easy to use can eventually toss the whole skill
and magic school system out of whack. Testing new spells is
quite important therefore.]]>
</use>
<attribute arch="no_drop" value="1" type="fixed" />
<attribute arch="invisible" value="1" type="fixed" />
<attribute arch="skill" editor="skill name" type="string">
The <skill name> matches the skill which is needed
to cast this spell. This should be one out of "sorcery",
"pyromancy", "evocation", "summoning" or "praying".
If you want to fiddle with these, please take care not
res/types.xml view on Meta::CPAN
</attribute>
<attribute arch="hp" editor="destination X" type="int">
The exit destinations define the (x, y)-coordinates where the exit
leads to.
If both are set to zero and <exit path> is empty, the player will
get teleported to another, randomly chosen teleporter on the same
map (Slightly confusing for the player though). Make sure there
actually *is* a second one in that case.
If both are set to zero and <exit path> is set, the player will
be transferred to the "default enter location" of the destined map.
The latter can be set in the map-properties as "Enter X/Y". Though,
please DO NOT use that. It turned out to be a source for numerous
map-bugs.
</attribute>
<attribute arch="sp" editor="destination Y" type="int">
The exit destinations define the (x, y)-coordinates where the exit
leads to.
If both are set to zero and <exit path> is empty, the player will
get teleported to another, randomly chosen teleporter on the same
map (Slightly confusing for the player though). Make sure there
actually *is* a second one in that case.
If both are set to zero and <exit path> is set, the player will
be transferred to the "default enter location" of the destined map.
The latter can be set in the map-properties as "Enter X/Y". Though,
please DO NOT use that. It turned out to be a source for numerous
map-bugs.
</attribute>
<attribute arch="connected" editor="connection" type="string">
If a connection value is set, the teleporter will be activated
whenever the connection is triggered. To use this properly,
<activation speed> must be zero.
</attribute>
&activate_on;
<attribute arch="speed" editor="activation speed" type="float">
If the <activation speed> is nonzero, the teleporter will
automatically be activated in regular time-intervals. Hence, the
player can just step on it and gets teleported sooner or later.
The duration between two activates depends on the given value.
Default in the teleporter arch is <activation speed> 0.1.
VERY IMPORTANT: If you want to have your teleporter activated via
button/handle/magic_ear/etc, you must set <activation speed> to zero!
</attribute>
&speed_left;
</type>
<!--####################################################################-->
<type number="26" name="Timed Gate">
<ignore>
<ignore_list name="non_pickable" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
Gates play an important role in Deliantra. Gates can be opened
by activating a button/trigger, by speaking passwords (-> magic_ear)
or carrying special key-objects (-> inventory checker).
Unlike locked doors, gates can get shut again after a player has
passed, which makes them more practical in many cases. Unlike normal
gates, timed gates open when triggered but automatically close again
after some time.]]>
</description>
<use><![CDATA[
Use gates to divide your maps into separated areas. After solving
area A, the player gains access to area B, and so on. Make your
maps more complex than "one-way".]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="connected" editor="connection" type="string">
Whenever the inventory checker is triggered, all objects with identical
<connection> value get activated. This only makes sense together with
<blocking passage> disabled. If unset, the gate opens automatically
after some time.
</attribute>
&activate_on;
<attribute arch="wc" editor="position state" type="int">
The <position state> defines the position of the gate:
Zero means completely open/down, the "number of animation-steps" (usually
about 6 or 7) means completely closed/up state. I suggest you don't
mess with this value - Leave the default in place.
</attribute>
&movement_types_terrain;
<attribute arch="no_magic" editor="restrict spells" type="bool">
Restricting the use of spells to pass this gate. This has
an effect only if <block view> is disabled.
</attribute>
<attribute arch="damned" editor="restrict prayers" type="bool">
Restricting the use of prayers to pass this door. This has
an effect only if <block view> is disabled.
</attribute>
<attribute arch="hp" editor="open duration" type="int">
Defines the duration the gate remains closed. This only takes effect
if the gate is not connected.
</attribute>
</type>
<!--####################################################################-->
<type number="155" name="Trap">
<ignore>
<attribute arch="no_pick" />
<attribute arch="title" />
<attribute arch="name_pl" />
<attribute arch="weight" />
<attribute arch="value" />
<attribute arch="material" />
<attribute arch="unpaid" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
A trap is a object that can either do damage or trigger another connected object
when detonated. Traps are like runes except they are not magical in nature,
and generally have either a physical attack or trigger a reaction.
<br><br>
Traps hit any monster or person who steps on them for 'dam' damage in
'attacktype' attacktype and/or trigger a reaction.
<br><br>
Many traps are already defined in the archetypes.]]>
</description>
res/types.xml view on Meta::CPAN
how much experience the player gets for doing so. Beware: High level
traps can be quite a cheap source of experience! So either make them
tough, or keep the level low.
</attribute>
<attribute arch="Cha" editor="visibility" type="int">
This value determines what fraction of the time the trap is visible:
It'll be randomly visible 1/<visibility> of the time. Also effects
how easily the trap may be found.
</attribute>
<attribute arch="hp" editor="number of charges" type="int">
The trap will detonate <number of charges> times before disappearing.
</attribute>
<attribute arch="dam" editor="direct damage" type="int">
<direct damage> specifies how much damage is done by the trap.
This should be set in reasonable relation to the trap's level.
</attribute>
<attribute arch="attacktype" editor="attacktype" type="bitmask_attacktype">
This attribute defines what attacktype to use for direct damage when
the trap detonates.
</attribute>
<attribute arch="connected" editor="connection" type="string">
When the trap is detonated, all objects with the same
connection value get activated.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="detonation text" type="text">
When the trap detonates, this text is displayed to the
victim. For especially powerful or complex traps, create an appropriate
and thrilling description. ;)
</attribute>
</type>
<!--####################################################################-->
<type number="95" name="Trapdoor">
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
Trapdoors are very similar to pits. The difference is that they
can not be closed. Instead, the weight of the object on the
trapdoor determines weither it slams the trapdoor open and falls through
or not.<br>
Once a trapdoor has been opened (by a creature or items of sufficient
weight,) it remains open, acting like an opened pit.]]>
</description>
<use><![CDATA[
Trapdoors should be used in the same fashion as pits:
They should always drop the victims to some kind of lower level. They
are not supposed to be used to randomly interconnect maps like teleporters.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
&move_on;
<attribute arch="weight" editor="hold weight" type="int">
This value defines how much weight the trapdoor can hold.
Once items or creatures are gathered on the trapdoor, with
a total weight surpassing this value, then the trapdoor will
open and things start falling through.
</attribute>
<attribute arch="hp" editor="destination X" type="int">
The trapdoor will transport creatures (and items) randomly into
a two-square radius of the destination coordinates.
If the destination square becomes blocked, the trapdoor will act like
being filled up and not work anymore!
</attribute>
<attribute arch="sp" editor="destination Y" type="int">
The trapdoor will transport creatures (and items) randomly into
a two-square radius of the destination coordinates.
If the destination square becomes blocked, the trapdoor will act like
being filled up and not work anymore!
</attribute>
</type>
<!--####################################################################-->
<type number="4" name="Treasure">
<ignore>
<attribute arch="nrof" />
<attribute arch="title" />
<attribute arch="name_pl" />
<attribute arch="weight" />
<attribute arch="value" />
<attribute arch="material" />
</ignore>
<description><![CDATA[
A treasure-object turns into certain randomitems when the map is loaded
into the game.]]>
</description>
<use><![CDATA[
About usage of the "random-artifact" treasurelist:
This will generate powerful stuff like girdles, xray helmets, special
swords etc. If you put this as reward to your quest, players might be
motivated to do it more than once. BUT, by doing so they will get a huge
number of different artifacts! Besides, players will always seek the place
with the most easy-to-get random artifact and ignore all others.
My advice: Don't use it! Attract players with good fighting experience
(from monsters), potions, spellbooks, money, and non-random artifacts. ]]>
</use>
<attribute arch="randomitems" editor="treasurelist" type="treasurelist">
This entry determines what kind of treasure will appear. Look into
/crossfire/share/crossfire/treasures for details about existing
treasurelists.
</attribute>
<attribute arch="auto_apply" editor="auto-generate" type="bool">
"Auto-generate" must be set in order to have the treasure be created
when the map is loaded.
If you want to create a random treasure chest, you unset this flag.
That way, the player has to apply the object (the chest), then the
treasure is generated.
</attribute>
<attribute arch="hp" editor="create number" type="int">
"Create number" specifies how many pieces of the given treasurelist
will appear. Note that for every piece there is a chance that nothing is
generated. Also, sometimes there can be stacks of items generated, like
for gems/money.
</attribute>
<attribute arch="exp" editor="quality level" type="int">
The <quality level> will be used for the quality of the generated
treasure instead of the map difficulty (as was done with shops).
If zero/unset, the map difficulty will instead be used.
(Example for comparison: Shop floors generate treasure of
<quality level> 5 per default).
</attribute>
</type>
<!--####################################################################-->
<type number="52" name="Trigger Marker">
<ignore>
<ignore_list name="system_object" />
<attribute arch="connected"/>
( run in 0.560 second using v1.01-cache-2.11-cpan-39bf76dae61 )