Deliantra
view release on metacpan or search on metacpan
res/types.xml view on Meta::CPAN
<attribute arch="damned" editor="damnation" type="bool">
A damned piece of equipment cannot be unwielded unless the curse
is removed. Removing damnations is a tick harder than removing curses.
</attribute>
<attribute arch="cursed" editor="curse" type="bool">
A cursed piece of equipment cannot be unwielded
unless the curse is removed.
</attribute>
<attribute arch="lifesave" editor="save life" type="bool">
An item with this flag enabled will save the players life
for one time: When the player is wearing this item and his
health points reach zero, the item disappears, replenishing
half of the player's health.
An item with <save life> should not have
any decent additional bonuses!
</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.
</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="applied" editor="is applied" type="bool">
If you put this item into the inventory of a monster, and
you want the monster to use/wear the item - you must set
<is applied>.
Enabling this flag doesn't make any sense if the item
is NOT in a monster's inventory.
</attribute>
&player_stat_resist_sections;
<section name="misc">
<attribute arch="luck" editor="luck bonus" type="int">
With positive luck bonus, the player is more likely to
succeed in all sorts of things (spellcasting, praying,...).
Unless the <luck bonus> is very high, the effect will be
barely visible in-game. Luck bonus on one piece of equipment
should never exceed 3, and such bonus should not be too
frequently available.
</attribute>
<attribute arch="hp" editor="health regen." type="int">
Positive <health regen.> bonus speeds up the
player's healing process. Negative values slow it down.
</attribute>
<attribute arch="sp" editor="mana regen." type="int">
Positive <mana regen.> bonus speeds up the
player's mana regeneration. Negative values slow it down.
</attribute>
<attribute arch="grace" editor="grace regen." type="int">
Positive <grace regen.> bonus speeds up the
player's grace regeneration. Negative values slow it down.
Since grace can be regenerated rather easy with praying,
additional <grace regen.> bonus should be VERY RARE!!
</attribute>
<attribute arch="food" editor="food bonus" type="int">
Positive <food bonus> slows down the player's digestion,
thus he consumes less food. Negative values speed it up.
Note that food is consumed not only for "being alive", but
also for healing and mana-regeneration.
<food bonus> only affects the amount of food consumed
for "being alive". Hence, even with high <food bonus>,
during a fight a player can run out of food quickly.
</attribute>
<attribute arch="xrays" editor="xray vision" type="bool">
Xray vision allows the player to see through obstacles
in a two-square-wide radius. This is extremely helpful and
desirable, so don't give it away for cheap on equipment.
</attribute>
<attribute arch="stealth" editor="stealth" type="bool">
Stealth allows the player to move silently.
This comes to effect if a player turns himself
invisible and tries to sneak around monsters.
(At least that was the idea behind it)
</attribute>
<attribute arch="reflect_spell" editor="reflect spells" type="bool">
If a player is wearing any piece of equipment with
the ability to <reflect spells>, all kinds of
spell-bullets and -beams will bounce off him.
This works only about 90% of all times, to
avoid players being completely immune to certain
types of attacks.
This is a very powerful ability and it
shouldn't be handed out cheap!
</attribute>
<attribute arch="reflect_missile" editor="reflect missiles" type="bool">
If a player is wearing any piece of equipment with
the ability to <reflect missiles>, all kinds of
projectiles (e.g. arrows, bolts, boulders) will
bounce off him. This works only about 90% of all
times, to avoid players being completely immune to
certain types of attacks.
</attribute>
&move_type;
<attribute arch="path_attuned" editor="attuned paths" type="bitmask_spellpath">
Click on the <attuned paths> button to select spellpaths.
The player will get attuned to the specified spellpaths
while wearing this item.
</attribute>
<attribute arch="path_repelled" editor="repelled paths" type="bitmask_spellpath">
Click on the <repelled paths> button to select spellpaths.
The player will get repelled to the specified spellpaths
while wearing this item.
</attribute>
<attribute arch="path_denied" editor="denied paths" type="bitmask_spellpath">
Click on the <denied paths> button to select spellpaths.
The specified spellpaths will be denied to the player
while wearing this item.
</attribute>
</section>
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This text describes the item's "story". Every decent artifact
should have such a description.
</attribute>
</type>
<!--####################################################################-->
<type number="58" name="Battleground">
<ignore>
<ignore_list name="non_pickable" />
</ignore>
res/types.xml view on Meta::CPAN
reduced by the value of <food depletion>.
For negative values, a %-based amount is taken.
</attribute>
<attribute arch="hp" editor="health regen." type="int">
This value increases the player's healing rate.
Negative values decrease it.
</attribute>
<attribute arch="sp" editor="mana regen." type="int">
This value increases the player's rate of mana regeneration.
Negative values decrease it.
</attribute>
</section>
<section name="disability">
<attribute arch="Str" editor="strength" type="int">
The player's strength will rise by the given value
while being infected. (Negative values make strength fall)
</attribute>
<attribute arch="Dex" editor="dexterity" type="int">
The player's dexterity will rise by the given value
while being infected. (Negative values make dexterity fall)
</attribute>
<attribute arch="Con" editor="constitution" type="int">
The player's constitution will rise by the given value
while being infected. (Negative values make constitution fall)
</attribute>
<attribute arch="Int" editor="intelligence" type="int">
The player's intelligence will rise by the given value
while being infected. (Negative values make intelligence fall)
</attribute>
<attribute arch="Pow" editor="power" type="int">
The player's power will rise by the given value
while being infected. (Negative values make power fall)
</attribute>
<attribute arch="Wis" editor="wisdom" type="int">
The player's wisdom will rise by the given value
while being infected. (Negative values make wisdom fall)
</attribute>
<attribute arch="Cha" editor="charisma" type="int">
The player's charisma will rise by the given value
while being infected. (Negative values make charisma fall)
</attribute>
</section>
<attribute arch_begin="msg" arch_end="endmsg" editor="message" type="text">
This text is displayed to the player every time the
symptoms strike.
</attribute>
</type>
<!--####################################################################-->
<type number="23" name="Door">
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
A door can be opened with any normal key. It also can be broken by attacking
it, and it can be defeated with the lockpicking skill. If a door is
defeated, horizontally and vertically adjacent doors are automatically
removed.]]>
</description>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="alive" value="1" type="fixed" />
&movement_types_terrain;
<attribute arch="hp" editor="hitpoints" type="int">
The more <hitpoints> the door has, the longer it takes to be broken.
</attribute>
<attribute arch="ac" editor="armour class" type="int">
Doors of high <armour class> are less likely to get hit.
<armour class> can be considered the "counterpiece" to
<weapon class>.
</attribute>
<attribute arch="other_arch" editor="drop arch" type="string">
This string defines the object that will be created when the door was
defeated.
</attribute>
<attribute arch="randomitems" editor="treasurelist" type="treasurelist">
This entry determines what kind of traps will appear in the door.
</attribute>
<attribute arch="treasure_env" editor="treasure in env" type="bool">
Set this flag to move treasure items created into the environment (map)
instead of putting them into the object.
</attribute>
</type>
<!--####################################################################-->
<type number="83" name="Duplicator">
<ignore>
<ignore_list name="system_object" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
When activated, a duplicator can duplicate, multiply or destroy a pile of
objects which lies somewhere on top of the duplicator.
The duplicator has one arch name specified as <target arch>,
and only objects of this archetype can be affected.<br>
It will multiply the number of items in the pile, by the <multiply factor>.
If the latter is set to zero, it will destroy objects.]]>
</description>
<use><![CDATA[
I hope it is clear that one must be very cautious when inserting a duplicator
anywhere with <multiply factor> greater than one.
It is designed to be used for betting mechanisms only (bet -> win/loose).
It is <b>not acceptable</b> to allow duplication of anything other than
coins, gold and jewels. Besides, it is very important that the chance to
loose the input matches the chance to earn winnings.<br>
A duplicator with <multiply factor> 3 for example should have a
loosing rate of 2/3 = 67%.]]>
</use>
<attribute arch="other_arch" editor="target arch" type="string">
Only objects of matching archtype, lying ontop of the duplicator will be
duplicated, multiplied or removed. All other objects will be ignored.
</attribute>
<attribute arch="level" editor="multiply factor" type="int">
The number of items in the target pile will be multiplied by the
<multiply factor>. If it is set to zero, all target objects
will be destroyed.
</attribute>
<attribute arch="connected" editor="connection" type="string">
An activator (lever, altar, button, etc) with matching connection value
is able to trigger this duplicator. Be very careful that players cannot
abuse it to create endless amounts of money or other valuable stuff!
</attribute>
res/types.xml view on Meta::CPAN
<attribute arch_begin="msg" arch_end="endmsg" editor="exit message" type="text">
If set, this message will be displayed to the player when he applies the exit.
This is quite useful to throw in some "role-play feeling": "As you enter the
dark cave you hear the sound of rustling dragonscales...". Well, my english
is poor, but you get the point. =)
</attribute>
<attribute arch="damned" editor="set savebed" type="bool">
If set, then players using this exit will have their savebed position
set to the destination of the exit when passing through.
</attribute>
</type>
<!--####################################################################-->
<type number="72" name="Flesh">
<description><![CDATA[
Just like with food, the player can fill his stomache and gain a
little health by eating flesh-objects. <br>
For dragon players, flesh plays a very special role though: If the
flesh has resistances set, a dragon player has a chance to gain resistance in
those categories. The only constraint to this process is the <flesh level>.
Don't forget that flesh items with resistances have to be balanced
according to map/monster difficulty.]]>
</description>
<use><![CDATA[
For dragon players, flesh items can be highly valuable. Note that many
standard monsters carry flesh items from their <treasurelist>.
These flesh items "inherit" resistances and level from the monster they belong to.
When you add special flesh items to the inventory of a monster, this is
not the case - so you have to set it manually.
<br><br>
Generally adding special flesh-treaties for dragon players is a great thing
to do. Always consider that dragon players might really not be interested
in that special piece of weapon or armour, so don't let the dragon-fellows miss
out on the reward completely.]]>
</use>
<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="level" editor="flesh level" type="int">
The <flesh level> is not visible to the players and it affects only
dragon players. Normally this value reflects the level of the monster
from which the flesh item originates.
Dragon players always search for flesh of highest level possible,
because it bears the best chance to gain high resistances.
</attribute>
<attribute arch="startequip" editor="godgiven item" type="bool">
A godgiven item vanishes as soon as the player
drops it to the ground.
</attribute>
&resistances_flesh_section;
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This text may describe the item.
</attribute>
</type>
<!--####################################################################-->
<type number="0" name="Floor">
<required>
<attribute arch="is_floor" value="1" />
<attribute arch="alive" value="0" />
</required>
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
Floor is a very basic thing whithout too much
functionality. It's a floor - you stand on it.]]>
</description>
<attribute arch="is_floor" value="1" type="fixed" />
<attribute arch="no_pick" value="1" type="fixed" />
<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="67" name="Floor (Encounter)">
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
Encounter-Floor is pretty much the same as normal floor.
Most outdoor floor/ground-arches are set to be "encounters".
That is kind of a relict from former code: When walking over
encounter-floor, players sometimes got beamed to little maps
with monsters on them. Nowadays this feature is disabled -
Hence encounter floor is not different from normal floor.]]>
</description>
<attribute arch="is_floor" value="1" type="fixed" />
<attribute arch="no_pick" value="1" type="fixed" />
<section name="terrain">
res/types.xml view on Meta::CPAN
</ignore>
<description><![CDATA[
Magic walls fire spells in a given direction, in regular intervals.
Magic walls can contain any spell. However, some spells do not
operate very successfully in them. The only way to know is to test
the spell you want to use with a wall.
<br><br>
Several types of magical walls are predefined for you in the
archetypes, and can be found on the "connected" Pickmap.]]>
</description>
<use><![CDATA[
Spellcasting walls pose an interesting alternative to monsters.
Usually they are set to be undestroyable. Thus, while monsters
in a map can be cleared out, the magic walls remain. Low level
characters for example will not be able to pass through their
spell-area, hence they cannot loot a map that a high level character
might have cleared out.
<br><br>
Another point of magic walls is that if the player dies, he has to face
them all again. Magic walls can add a kind of "permanent thrill" to
your maps.
<br><br>
Be careful that your magic walls don't kill the monsters on a map. If
placing monsters, eventually take ones that are immune to the
walls' spell(s).
<br><br>
It is possible to make walls rotate when triggered. But that is so
confusing (and useless IMHO) that I did not mention it above. You
can find a working example on the map
"/pup_land/castle_eureca/castle_eureca8".]]>
</use>
<attribute arch="dam" editor="spell" type="spell">
The magic wall will cast this <spell>.
</attribute>
<attribute arch="level" editor="spell level" type="int">
The wall will cast it's spells at level <spell level>. "level 1"
walls cast spells at minimal strength. "level 100" walls cast deadly
spells. Arch default is level 1 - you should always set this value
to meet the overall difficulty of your map.
</attribute>
<attribute arch="connected" editor="connection" type="string">
Every time the <connection> value is triggered, the wall will cast
it's spell. You should set <casting speed> to zero, or this won't
have much visible effect.
</attribute>
&activate_on;
<attribute arch="speed" editor="casting speed" type="float">
The <casting speed> defines the spellcasting speed of the wall.
You can fine-tune how long the duration between two casts shall
be. If you want to create a wall that can be activated (cast per
trigger) via connected lever/button/etc, you must set "speed 0".
</attribute>
&speed_left;
<attribute arch="sp" editor="direction" type="list_direction">
The magic wall will cast it's spells always in the specified
<direction>. A magic wall with direction set to <none> will
always fire in a random direction.
</attribute>
&movement_types_terrain;
<section name="destroyable">
<attribute arch="alive" editor="is destroyable" type="bool">
Walls with <is destroyable> enabled can be attacked and (eventually)
destroyed by the player. If disabled, all other attributes on
this tab, as well as resistances, are meaningless.
</attribute>
<attribute arch="hp" editor="hitpoints" type="int">
The more <hitpoints> the wall has, the longer
it takes to be destroyed.
</attribute>
<attribute arch="maxhp" editor="max hitpoints" type="int">
<max hitpoints> are the maximum amount of hitpoints the wall
can have. This only makes sense if the wall can regain health.
</attribute>
<attribute arch="ac" editor="armour class" type="int">
A magic wall of high <armour class> is less likely to get hit from
an opponent. <armour class> can be considered the "counterpiece"
to <weapon class>.
</attribute>
</section>
&resistances_basic;
</type>
<!--####################################################################-->
<type number="55" name="Marker">
<ignore>
<ignore_list name="system_object" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
A marker is an object that inserts an invisible force (a mark) into a
player stepping on it. This force does nothing except containing a
<key string> which can be discovered by detectors or inventory
checkers. It is also possible to use markers for removing marks again
(by setting the "name" slot to the name of the marker to be removed).
<br><br>
Note that the player has no possibility to "see" his own marks,
except by the effect that they cause on the maps.]]>
</description>
<use><![CDATA[
Markers hold real cool possibilities for map-making. I encourage
you to use them frequently. However there is one negative point
about markers: Players don't "see" what's going on with them. It is
your task, as map-creator, to make sure the player is always well
informed and never confused.
<br><br>
Please avoid infinite markers when they aren't needed. They're
using a little space in the player file after all, so if there
is no real purpose, set an expire time.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="slaying" editor="key string" type="string">
The <key string> can be detected by inv. checkers/detectors.
If the player already has a force with that <key string>,
there won't be inserted a second one.
</attribute>
<attribute arch="connected" editor="connection" type="string">
When the detector is triggered, all objects with the same
connection value get activated.
</attribute>
<attribute arch="speed" editor="marking speed" type="float">
The <marking speed> defines how quickly it will mark something
standing on the marker. Set this value rather high to make
sure the player really gets his mark. I think <marking speed> 1.0
should do fine.
</attribute>
&speed_left;
<attribute arch="food" editor="mark duration" type="int">
This value defines the duration of the force it inserts.
If nonzero, the duration of the player's mark is finite:
about 1 food per 10 seconds. <mark duration> zero/unset
means the mark will stay on the player forever.
</attribute>
<attribute arch="name" editor="delete mark" type="string">
When the player steps onto the marker, all existing forces in
the players inventory with a <key string> matching <delete mark>
will be removed. If you don't want to remove any marks, leave
this textfield empty.
Note that the string <delete mark> is set as the name of
this marker. So don't be confused, and remember changing the
name will take effect on the marker's functionality.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="marking message" type="text">
In the moment when the player gets marked, this text is displayed
to him. You should really set a message in any marker you create,
because it's the only way for the player to notice what's going on.
</attribute>
</type>
<!--####################################################################-->
<type number="36" name="Money">
<ignore>
<attribute arch="unpaid" />
</ignore>
<description><![CDATA[
Items of the type Money are handled as currency.
Money cannot be sold/bought in shops. When money is dropped
in a shop, it stays the same.<br>
When a player picks an item from a shop and attempts to
walk over the shop mat, the item's selling-price is automatically
subtracted from the player's money.
<br><br>
For money, always use the default arches.
Don't modify them.]]>
</description>
<attribute arch="race" value="gold and jewels" type="fixed" />
</type>
<!--####################################################################-->
<type number="0" name="Monster & NPC">
<required>
<attribute arch="is_floor" value="0" />
<attribute arch="alive" value="1" />
<attribute arch="tear_down" value="0" />
</required>
<ignore>
<attribute arch="material" />
<attribute arch="name_pl" />
<attribute arch="nrof" />
<attribute arch="value" />
<attribute arch="unpaid" />
</ignore>
<description><![CDATA[
Monsters can behave in various kinds of ways.
They can be aggressive, attacking the player. Or peaceful,
helping the player - maybe joining him as pet.
The unagressive creatures who communicate with players are
usually called "NPCs" (Non Player Character), a well-known
term in role-play environments.]]>
</description>
<use><![CDATA[
Monsters play a central role in most maps. Choosing the right
combination of monsters for your map is vital:
<UL>
<LI> Place only monsters of slightly varying (increasing) strength.
It's no fun to play for two hours just to find out the last
monster is unbeatable. Similar, it's not exciting to fight orcs
after passing a room of dragons.<br>
This rule applies only for linear maps (one room after the other),
with treasure at the end. You can sprinkle the treasure around,
or make non-linear maps - That is often more entertaining.
<LI> Places with high level monsters must not be easy to reach.
Balrogs, Dragonmen and the likes should be at the end of a quest,
not at the beginning.
<LI> Don't stick monsters together that tend to kill each other.
Fire- and cold dragons in one room for example is a bad idea.
By weakening and killing each other they are easy prey for players,
not worth the experience they hold.
<LI> Create your own monsters, especially for "boss"-type monsters.
Having stage-bosses guarding treasure is a lot of fun when done right.
Avoid to create monsters with completely non-intuitive abilities:
Don't give ice-spells to firedragons or vice versa. Don't add
draining attack to trolls, etc. Additionally, you should inform the
player before he bumps right into some very special/unusual monster.
<LI> Last but not least: Always keep an eye on the experience your monsters
hold. Design your maps in a way that high experience
is always well-defended. Don't make large rooms full with only one kind
of monster. Keep in mind the different abilities/techniques players
can use.
</UL>
I know it's impossible to make the perfectly balanced map. There's always
some part which is found too easy or too hard for a certain kind of player.
Just give it your best shot. And listen to feedback from players if you
receive some. :-)]]>
</use>
<attribute arch="alive" value="1" type="fixed" />
<attribute arch="randomitems" editor="treasurelist" type="treasurelist">
When the monster is killed, items from the treasurelist will
drop to the ground. This is a common way to reward players
for killing (masses of) monsters.
Note that you can always put items into the monster's
inventory. Those will drop-at-kill just like the stuff
from the <treasurelist>.
</attribute>
<attribute arch="treasure_env" editor="treasure in env" type="bool">
Set this flag to move treasure items created into the environment (map)
instead of putting them into the object.
</attribute>
<attribute arch="level" editor="level" type="int">
A monster's <level> is the most important attribute.
<level> affects the power of a monster in various ways.
</attribute>
<attribute arch="race" editor="race" type="string">
Every monster should have a race set to categorize it.
The monster's <race> can have different effects:
Slaying weapons inflict tripple damage against enemy races
and holy word kills only enemy races of the god.
</attribute>
<attribute arch="exp" editor="experience" type="int">
When a player kills this monster, he will get exactly this
amount of <experience>. The experience will flow into
the skill-category the player used for the kill.
If you create special monsters of tweaked strenght/abilities,
always make sure that the <experience> is set to a
reasonable value. Compare with existing arches to get a feeling
what reasonable means. Keep in mind that spellcasting monsters
are a lot harder to kill than non-spellcasters!
</attribute>
<attribute arch="speed" editor="speed" type="float">
The <speed> determines how fast a monster will both move
and fight. High <speed> makes a monster considerably stronger.
</attribute>
&speed_left;
<attribute arch="other_arch" editor="breed monster" type="string">
This only takes effect if <multiply> is enabled. The monster will
create a <breed monster> every once in a while. <breed monster>
can be set to any valid arch-name of a monster. Multipart monster
should not be used.
</attribute>
<attribute arch="generator" editor="multiply" type="bool">
Monsters with <generator> enabled will create a <breed monster>
every once in a while. Mice are a good example for this effect.
If enabled, you must also set <breed monster> or check
<template generation> and put other monsters in the inventory.
</attribute>
<attribute arch="use_content_on_gen" editor="template generation" type="bool">
This only takes effect if <multiply> is enabled. The monster
will create a new monster every once in a while by duplicating it's inventory.
In this case, the <breed monster> value is never used and can be forgotten.
Each time the monster need to generate an object, it will be
a randomly chosen item from the inventory. When generator is destroyed,
inventory is destroyed.
</attribute>
&move_type;
res/types.xml view on Meta::CPAN
<ignore_list name="system_object" />
<attribute arch="connected"/>
</ignore>
<description><![CDATA[
A trigger marker is an object that inserts an invisible force (a mark) into a
player stepping on it WHEN TRIGGERED. This force does nothing except containing a
<key string> which can be discovered by detectors or inventory
checkers. It is also possible to use markers for removing marks again.
(by setting the "name" slot to the name of the marker to be removed).
<br><br>
Note that the player has no possibility to "see" his own marks,
except by the effect that they cause on the maps.]]>
</description>
<use><![CDATA[
Markers hold real cool possibilities for map-making. I encourage
you to use them frequently. However there is one negative point
about markers: Players don't "see" what's going on with them. It is
your task, as map-creator, to make sure the player is always well
informed and never confused.
<br><br>
Please avoid infinite markers when they aren't needed. They're
using a little space in the player file after all, so if there
is no real purpose, set an expire time.]]>
</use>
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="slaying" editor="key string" type="string">
The <key string> can be detected by inv. checkers/detectors.
If the player already has a force with that <key string>,
there won't be inserted a second one.
</attribute>
<attribute arch="connected" editor="connection" type="string">
Unlike a regular marker this is the connection that triggers this marker to activate.
</attribute>
<attribute arch="food" editor="mark duration" type="int">
This value defines the duration of the force it inserts.
If nonzero, the duration of the player's mark is finite:
about 1 food per 10 seconds. <mark duration> zero/unset
means the mark will stay on the player forever.
</attribute>
<attribute arch="name" editor="delete mark" type="string">
When the player steps onto the marker, all existing forces in
the players inventory with a <key string> matching <delete mark>
will be removed. If you don't want to remove any marks, leave
this textfield empty.
Note that the string <delete mark> is set as the name of
this marker. So don't be confused, and remember changing the
name will take effect on the marker's functionality.
</attribute>
<attribute arch_begin="msg" arch_end="endmsg" editor="marking message" type="text">
In the moment when the player gets marked, this text is displayed
to him. You should really set a message in any marker you create,
because it's the only way for the player to notice what's going on.
</attribute>
</type>
<!--####################################################################-->
<type number="0" name="Wall">
<required>
<attribute arch="is_floor" value="0" />
<attribute arch="alive" value="0" />
<attribute arch="no_pass" value="1" />
</required>
<ignore>
<attribute arch="nrof" />
<attribute arch="title" />
<attribute arch="name_pl" />
<attribute arch="value" />
<attribute arch="unpaid" />
</ignore>
<description><![CDATA[
Walls usually block passage and sight.]]>
</description>
&movement_types_terrain;
<attribute arch="can_roll" editor="moveable" type="bool">
If set, the object is able to "roll", so it can be pushed around.
This setting is used for boulders and barrels.
</attribute>
<attribute arch="no_magic" editor="restrict spells" type="bool">
This takes effect only with <blocksview> disabled.
Restricting the use of spells to pass this wall.
</attribute>
<attribute arch="damned" editor="restrict prayers" type="bool">
This takes effect only with <blocksview> disabled.
Restricting the use of spells to pass this wall.
</attribute>
</type>
<!--####################################################################-->
<type number="109" name="Wand & Staff">
<description><![CDATA[
Wands contain a certain spell. The player can apply (ready) and
fire the wand. After a defined number of casts, the wand is
"used up". It is possible to recharge a wand with scrolls of
charging, but usually that isn't worth the cost.]]>
</description>
<use><![CDATA[
Wands are quite seldomly used. The reason prolly is that they're
generally not cost-efficient. Handing out high-level wands with
powerful special spells isn't a good idea either, because of
the recharge ability.
<br><br>
For low levels, staffs of healing/cure and word of recall are
quite desirable though. Ideal rewards for low level quests.]]>
</use>
<attribute arch="sp" editor="spell" type="spell">
The <spell> specifies the contained spell.
</attribute>
<attribute arch="level" editor="casting level" type="int">
The <casting level> of the wand determines it's power.
An average level for wands in shops is about 10.
</attribute>
<attribute arch="food" editor="number of charges" type="int">
The wand can be used <number of charges> times before it is
used up. It can be recharged with scrolls of charging.
</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 wand.
</attribute>
</type>
<!--####################################################################-->
<type number="0" name="Weak Wall">
<required>
<attribute arch="is_floor" value="0" />
<attribute arch="alive" value="1" />
<attribute arch="tear_down" value="1" />
</required>
<ignore>
<ignore_list name="non_pickable" />
</ignore>
<description><![CDATA[
A weak wall is a breakable spot amidsts a solid wall. Typically
these weak walls look similar to their solid "relatives" except
for a small crack or little chunks of wall on the ground.]]>
</description>
<use><![CDATA[
If you want to create hidden rooms, using weak walls is alot
better than completely indiscernible passages in a wall.<br>
Anyways, there can be a lot more to weak walls than just finding
them: Rising their defensive stats, weak walls can become a
serious obstacle. An ice wall might only be torn down by a fire
attack for example. A granite wall for instance might be very
hard to destroy.]]>
</use>
<attribute arch="alive" value="1" type="fixed" />
<attribute arch="no_pick" value="1" type="fixed" />
<attribute arch="tear_down" value="1" type="fixed" />
<attribute arch="race" editor="race" type="string">
For weak walls, <race> should always be set to "wall",
unless you create something fancy like a building which
is in fact meant to be a huge animal.
Note that shovels slay walls, so they do tripple damage
against weak walls.
</attribute>
<attribute arch="level" editor="level" type="int">
The <level> of a weak wall works similar to monster levels.
Due to the fact that weak walls cannot attack, the level
is much less important though.
</attribute>
<attribute arch="hp" editor="health points" type="int">
The <health points> of a weak wall define how long it takes to
tear it down. With every successful hit from an opponent,
<health points> get drained.
</attribute>
<attribute arch="maxhp" editor="max health" type="int">
<max health> is the maximum amount of <health points> this
weak wall can have. Since walls generally don't heal, I doubt
this has much real effect.
</attribute>
<attribute arch="ac" editor="armour class" type="int">
Weak walls of high <armour class> are less likely to get hit.
<armour class> can be considered the "counterpiece" to <weapon class>.
</attribute>
&resistances_basic;
</type>
<!--####################################################################-->
<type number="15" name="Weapon">
<description><![CDATA[
Wielding a weapon, the object's stats will directly be inherited to the
player. Usually enhancing his fighting-abilities. Non-magical weapons can
be improved with scrolls.]]>
</description>
<use><![CDATA[
If you create artifacts (equipment) with stats- or resistance-bonus:
Keep playbalance in mind! Such items mustn't be reachable without hard
fighting AND questing.]]>
</use>
<attribute arch="attacktype" editor="attacktype" type="bitmask_attacktype">
This number is a bitmask, specifying the weapon's attacktypes.
Attacktypes are: physical, magical, fire, cold.. etc. Most artifact weapons
have no more than one or two attacktypes. Keep in mind that all weapons
can be blessed by the player's diety, thus adding an additional attacktype.
When a player hits a monster with a weapon that has more than one attacktype,
then he will do as much damage as the "best" of his attacktypes does. So,
the more attacktypes you've got, the better your chance to take advantage
of a monster's vulnerabilities. (Btw: Same rule applies for monster vs.
player.). Attacktypes "magic" and "chaos" are somehow exceptions.
</attribute>
<attribute arch="weapontype" editor="weapontype" type="list_weapon_type">
The <weapontype> characterizes the weapon's type of physical
attack. It could best be considered a "subclassification"
of the physical attacktype. For now, this is only used for
attack messages!
res/types.xml view on Meta::CPAN
It is very important to adjust the <item power> value carefully
for every artifact you create! If zero/unset, the Deliantra server will
calculate a provisional value at runtime, but this is never
going to be an accurate measurement of <item power>.
</attribute>
<attribute arch="damned" editor="damnation" type="bool">
A damned weapon cannot be unwielded unless
the curse is removed. Removing damnations is
a tick harder than removing curses.
</attribute>
<attribute arch="cursed" editor="curse" type="bool">
A cursed weapon cannot be unwielded unless
the curse is removed.
</attribute>
<attribute arch="lifesave" editor="save life" type="bool">
An item with this flag enabled will save the players life
for one time: When the player is wearing this item and his
health points reach zero, the item disappears, replenishing
half of the player's health.
An item with <save life> should not have
any decent additional bonuses!
</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.
</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;
<section name="misc">
<attribute arch="luck" editor="luck bonus" type="int">
With positive luck bonus, the player is more likely to
succeed in all sorts of things (spellcasting, praying,...).
Unless the <luck bonus> is very high, the effect will be
barely visible in-game. Luck bonus on one piece of equipment
should never exceed 3, and such bonus should not be too
frequently available.
</attribute>
<attribute arch="hp" editor="health regen." type="int">
Positive <health regen.> bonus speeds up the
player's healing process. Negative values slow it down.
</attribute>
<attribute arch="sp" editor="mana regen." type="int">
Positive <mana regen.> bonus speeds up the
player's mana regeneration. Negative values slow it down.
</attribute>
<attribute arch="grace" editor="grace regen." type="int">
Positive <grace regen.> bonus speeds up the
player's grace regeneration. Negative values slow it down.
Since grace can be regenerated rather easy with praying,
additional <grace regen.> bonus should be VERY RARE!!
</attribute>
<attribute arch="food" editor="food bonus" type="int">
Positive <food bonus> slows down the player's digestion,
thus he consumes less food. Negative values speed it up.
Note that food is consumed not only for "being alive", but
also for healing and mana-regeneration.
<food bonus> only affects the amount of food consumed
for "being alive". Hence, even with high <food bonus>,
during a fight a player can run out of food quickly.
</attribute>
<attribute arch="xrays" editor="xray vision" type="bool">
Xray vision allows the player to see through obstacles
in a two-square-wide radius. This is extremely helpful and
desirable, so don't give it away for cheap on equipment.
</attribute>
<attribute arch="stealth" editor="stealth" type="bool">
Stealth allows the player to move silently.
This comes to effect if a player turns himself
invisible and tries to sneak around monsters.
(At least that was the idea behind it)
</attribute>
<attribute arch="reflect_spell" editor="reflect spells" type="bool">
If a player is wearing any piece of equipment with
the ability to <reflect spells>, all kinds of
spell-bullets and -beams will bounce off him.
This works only about 90% of all times, to
avoid players being completely immune to certain
types of attacks.
This is a very powerful ability and it
shouldn't be handed out cheap!
</attribute>
<attribute arch="reflect_missile" editor="reflect missiles" type="bool">
If a player is wearing any piece of equipment with
the ability to <reflect missiles>, all kinds of
projectiles (e.g. arrows, bolts, boulders) will
bounce off him. This works only about 90% of all
times, to avoid players being completely immune to
certain types of attacks.
</attribute>
<attribute arch="path_attuned" editor="attuned paths" type="bitmask_spellpath">
Click on the <attuned paths> button to select spellpaths.
The player will get attuned to the specified spellpaths
while wearing this weapon.
</attribute>
<attribute arch="path_repelled" editor="repelled paths" type="bitmask_spellpath">
Click on the <repelled paths> button to select spellpaths.
The player will get repelled to the specified spellpaths
while wearing this weapon.
</attribute>
<attribute arch="path_denied" editor="denied paths" type="bitmask_spellpath">
Click on the <denied paths> button to select spellpaths.
The specified spellpaths will be denied to the player
while wearing this weapon.
</attribute>
</section>
<attribute arch_begin="msg" arch_end="endmsg" editor="description" type="text">
This text describes the weapons's "story". Every decent artifact weapon
should have such a description.
</attribute>
</type>
<type number="116" name="Event Connector">
<description><![CDATA[
Event connectors link specific events that happen to objects to
a crossfire plug-in. They are not used at all in Deliantra.]]>
</description>
</type>
( run in 1.086 second using v1.01-cache-2.11-cpan-39bf76dae61 )