Guide: General XML Spawner Tutorial

XML Commands
.xmlhome <target> returns the coordinates of the spawner for the targeted object. Also takes arguments:

•go that teleports you to its spawner,
•gump that opens its spawner gump,
•send that sends the object back to the spawner location
Example: .xmlhome gump <target>
.xmlshow This command turns spawn crystals into ships masts making them much easier to spot. One thing to remember about those masts is that even though they are hidden to players, they will still block movement, so you dont want to leave them as masts.
.xmlhide hides the spawners, returning them to magic crystals from a ship's mast.
.xmlsave filename will save all of the spawners on the current map to the file
.xmlsaveall filename will save all spawners in the world to the file
.xmlspawnerrespawn forces a respawn of all xmlspawners in the region
.xmlspawnerrespawnall forces a respawn of all xmlspawners in all regions
.xmlunload deletes spawners that are contained in an xml file. Basically the reverse of the load command. This provides a quick way of adding and removing specific sets of spawners that would represent a logical group, such as a mini-quest, or a dungeon, without having to use common naming prefixes, and without risking unintended spawner wipes that might occur with the use of the .xmlspawnerwipe prefix, command. Because it is the complement of the .xmlspawnerload (.xmlload) command, the effects of using it can always be reversed by simply doing an [xmlload on the same file.

Setting a new Spawn
How to Set the spawn:
The first thing you need to do to create a spawn is creater the spawner bit. Type the command: .add xmlspawner (enter)
This will create a "magical crystal" - Double Click the crystal to access the spawner gump, which looks like this:
View attachment 2642

You can change the name of your spawn to whatever you wish at the top of the gump. You should try to use a name that includes what the spawn contains or a name you can remember for easy reference later. (Example: Haven-rats)
To add a spawn to the bit you can add the creature name directly into the top line of the spawner gump (ex. rat or cat), or if you do not know or are unsure of the mobiles (creatures) name you can select the arrow at the right of the entry line which will bring up a menu of available items and mobiles to select (see red circle below):
View attachment 2643
You can add up to 60 creatures/mobiles to one bit (though I doubt we will need to use that many on a single bit). Once you have the creatures listed that you wish to spawn, you can set the amount of each entry by clicking the Up/Down arrows to the left of that entry.
The COUNT and MAX entries on the right side will update as you go. The bit is active by default so as you raise the total number of creatures they will appear around the bit. The default range (wander distance) of 5 and spawn interval of 5-10 mins. will be set on the bit unless and until you change in it the spawner props menu. (Will tell you how to change this later)
Hitting the RESET button in this gump will remove all spawn in existence and turn off the bit. You can turn the spawn back on by clicking the red on/off button (changing it back to greeen) or by hitting the respawn button. The only difference here is RESPAWN will activate the bit and spawn all creatures listed for it, while turning the bit on only reactivates it and it will spawn based on the range and time intervals set rather then all at once. RightClick on the gump will close it and save the settings on the bit.
You have created a basic creature spawn. Congrats.

Spawn Creation Shorthand:
Once you have worked with the spawner and become familiar with how it works, you may wish to use the gumps less often, especially for basic spawns. THe spawner gives you this option with "constructables"
For example:

•.add xmlspawner creaturename,
•.add xmlspawner numberofcreatures mindelay maxdelay team homerange creaturename,
•.add xmlspawner numberofcreatures mindelay maxdelay team homerange spawnrange creaturename.
This simply matches the constructable calls available for the regular spawner through the gump itself.

Container Spawning:
placing a spawner in a container will allow items to be spawned in it (but not mobs). To get this to work properly you must create the spawner in one of two ways:

EASY WAY: You can .addtoPack xmlspawner and target the container you wish the item to spawn inside and then edit the spawner from there.
OR

LONG WAY You can .add xmlspawner and target a spot on the ground. Type .set movable true, target the spawner you made, pick up and place the spawner in the container you wish the spawn to be. Then type .set movable false, target the spawner, thereby locking it in place inside the container. The spawner is not visible by players.

Editing Individual creature or item spawns:
XML is geared to accept commandline-like spawn specification. This basically allows you to set properties of each spawn in the spawner using a /propertyname/value/ format, Multiple properties can be specified for each spawn allowing mob/item naming, unique property setting, etc. This works well in conjunction with the item-triggering feature since you can create items with specified names that match the trigger name of another spawner.

Creatures:
An example of the specification would be instead of just listing an ogre to be spawned you would list an ogre/name/The Butcher/str/190/damagemax/50/hue/500, which would create a blue ogre, named "The Butcher", with 190 strength, and maximum attack damage of 50.

Accessing the editing feature:
You can input these strings in the book feature on the spawner line in the main spawner gump. To access this feature you click on the scroll symbol to the right of the spawner entry line (circled in pink below).
View attachment 2644

Items:
You can also spawn items in the same way e.g. specifying a woodenchest/hue/300/movable/false would create a green locked down chest, or katana/name/Master of elements/slayer/elementalban/hue/200 would create a named light blue elemental super slayer. Note, the properties that you can set are basically the same as those that you can change with the .set command.
XMLspawner also supports setting nested attributes on items such as armorattributes. To access these attributes use dot notation e.g. to change luck on a weapon use the specification string: katana/attributes.luck/50 or platehelm/armorattributes.magearmor/1/skillbonuses.skill_1_name/anatomy/skillbonuses.skill_1_value/20 to set magearmor and add +20 anatomy. These are the same property names that appear in the props list.

Accessing the editing feature:
You can input these strings in the book feature on the spawner line in the main spawner gump. To access this feature you click on the scroll symbol to the right of the spawner entry line (circled in pink below).

As you can see in the red circle above, the line is inputted in a text format in the book shown in the upper right and applied to that spawners entry in the main spawner gump (lower right in image above). In this case we have created a cow named Benny (circled in purple) that is hued to 450 (beige in this case) and given hitpoints of 100. - Gotta check syntax on HITS in this case because I think I did it wrong in the example I screenshot--oops.

Weighted Probability spawning:
With multiple entries in an xmlspawner, if maxcount on the spawner is equal to the total of the individual mob counts (the default condition), then the spawner will behave exactly as the original xmlspawner, but by reducing maxcount you can produce a reduced number of total spawns in which an individual mobs spawning probability is based on the relative count ratio.
To implement a rare single mob spawn simply add multiple mobs to a single spawner in the ratio that you want them to spawn with, and then set the maxcount to 1. This will result in a single spawn that will produce any one of the multiple mobs with the probability of getting each determined by the count.For example:

1.add a balron, count = 1
2.add a gargoyle, count = 10
3.go to the xmlspawner props and set maxcount to 1
4.do a respawn and you are done.

This will result in a single spawn that will produce a balron roughly 10% of the time (actually 1 out of 11) and gargoyles the rest of the time.
I use this to put named spawns in as the rare with comparable basic spawns as the common, e.g. a named lich, that spawns rarely instead of a regular lich. Of course, you can also specify these parameters in your xml spawner files: Example (from XML file):
<MaxCount>1</MaxCount>
<Objects>ratman=15:ratmanarcher=15:barracoon=1</Objects>
This will give you a spawn that will produce a single ratman or ratman archer with equal probability about 48% of the time each and a named mob about 3% of the time (1 out of 31 times)

Understanding Spawner PROPS
Now that we know how to make a spawn, it is time to look at how to customize it. XmlSpawner allows for a wide array of customizations, from spawn intervals to player approach and speech triggers. To make adjustments to a spawner, you need to access the PROPS gump.
From the main spawner menu (DCLICK the spawner). Click the props button at the bottom right of the main menu (see image above). This will open the props gump (pictured below). It is important to understand that these settings are for the spawner NOT for the individual creatures on the spawn bit. Those can be edited more specifically (we will get into these later). The spawner props gump looks like this:
View attachment 2645

Important Spawner PROPSIn this section we will discuss the various prop settings in more detail. As we learn their uses this section will expand, so if a setting is missing at this point, I am not sure how to set or use it, or I have no idea what it does yet.
I have found some prop settings to be more helpful then others. Some that I think are really helpful and used more often are listed first:

MaxDelay
This sets the maximum time before the spawn triggers again until the MAX COUNT setting is reached for that creature in the spawn list. It only triggers ONE mob/item at a time for the range. So if you max count is 10 and your max and min delay are both 1 minute, and the entire spawn is wiped out, it would take 10 mins to completely respawn.

MinDelay
This sets the Minimum time the spawner will wait before triggering the next creature on the spawn.

ShowBounds
The default setting for this is FALSE, but when set to TRUE it gives you a white box that shows you the spawn range box that is current set on the spawner. This is the area in which the spawners will appear. They may or may not be set to stay in that box once spawned (see HomeRange). Turning this on is very helpful when working with a spawner. It can be turned on or off as needed.

NoTriggerOnCarried
This property blocks spawner triggering when the player is carrying the named item. This can be used to prevent a quest spawns (e.g. starting quest gump) from being triggered if a quest item (e.g. starting quest token) was already in the players possession.

TriggerOnCarried
This property has the opposite effect on the spawner. When set, the spawn will only fire if the trigger item is present.

X1_Y1
This prop changes the NW or Upper left corner of your spawner range box. When you select this prop you are then given the option to use your current location for the target, use a targeting cursor to choose the location, or finally you can enter the X,Y and Z coords manually.

X2_Y2
This prop works exactly like above, but set the SE or lower right corner of your spawner range box.

HomeRange
This is how many times the spawn will wander from the bit after they spawn. Basically their "home area".

SpawnRange
This setting reflects how far from the bit a spawn will appear when it is first spawned. If you set the SpawnRange outside or larger then the HomeRange, the creatures that spawn otuside the HomeRange will work their way back home over time.

Time of Day (TOD)
Set the TODStart and TODEnd to the times of day that you would like to limit spawning to. If they are set to the same value, that enables spawning at all times. If the Start value is greater that the end value, that indicates a time window that spans midnight. Proximity triggering will also be limited to the TOD window. Spawns that remain after the TOD window has passed will be removed. Note that timing of spawning is still governed by the spawn timer (can be seen as the NextSpawn property in the spawner property list). The TOD window simply determines whether a spawn will be allowed to be created once the spawn timer has elapsed. The TOD window is also applied to proximity triggering. It determines both whether the trigger can be set (must be triggered during the TOD window), as well as whether the spawn can be created (spawn must occur during the TOD window).

TODMode
The TODMode property that allows Time of Day (TOD)-dependent spawning to be in either Gametime or Realtime.

PlayerTriggerProp
By specifying a property test string in PlayerTriggerProp, you can trigger based upon the value of a property on a player within the proximity range of the spawner. For example setting PlayerTriggerProp to hits<50, would cause the spawner to trigger whenever a player within range fell below 50 health.
Other properties could be used to trigger when a player got hungry (hunger<5), or tired (stam<30), or was a criminal (criminal=true), or was fighting (combatant!(-null-)). Any property that is visible with the [props command, can be tested and the value to test against will be the value that appears there (or with the [get propname command)

MobTriggerName
Mob property triggered spawning is identical to player property triggering except that you specify a mob name in the MobTriggerName field, and then set the property test in MobTriggerProp. This will trigger whenever a player comes within proximity range of the spawner and the uniquely named mob is found and satisfies the property test specified in MobTriggerProp. Note that this mob can be anywhere in the world, it is the player that sets off the trigger and therefore has to be in range. These can be combined with any of the other triggering options so that, for example, a player holding a named quest item, could trigger a spawn based upon his fame or karma, (with different fame levels triggering different spawns), depending on the health of a named mob that he was doing combat with.

ProximityRange
When the proximityrange property is set to a value zero or greater, the spawner will become activated whenever a player comes within that range, and will be deactivated when a player leaves the range. Once the spawner has been triggered, it will run until the spawn timer elapses, even if the player that activated it leaves the proximity range, after spawning it will be shut off and will remain inactive until the next proximity triggered activation.
Note that when used in combination with the X1Y1 X2Y2 specification for spawning area, you can use this feature to sense players in one location and spawn mobs in another. You can also combine this with the duration parameter to have player triggered, but limited duration spawns, so that they will reset even if the player that triggered it doesnt kill the spawned mob - basically a one-shot spawner. Counselors and above will not trigger the sensor.

ProximityMsg
Allows setting a proximity trigger message that is displayed over the player when the spawner is triggered. Example: "You have the strange feeling that you are being watched."

ProximitySound
This allows you to set the sound played when a proximity triggered spawner is tripped by a player (a click and sparkle sound by default). If you are using the most recent version of inside UO to get the sounds, you need to subtract 1 from the number for it to play the proper sound.

SpeechTrigger
This property allows for speech triggering of spawns. Set the property SpeechTrigger with the string you want to trigger on.
This can be combined with the other proximity features for example, to allow spawns that are triggered when a player is within range, has an item, and, for instance sets a switch, or places gold in a container, and then says the key phrase.
Could also use it for implementing something like a guard zone in which calling out for guards would spawn for a specified duration. Or by combining it with the refractory option you could allow it to generate items on demand but only so frequently (e.g. guards, regs, drinks, etc. only once an hour, or once a day) or even only during certain times of the day.

TriggerOnCarried
Item-dependent triggering This is used in conjunction with proximity sensing. When a player with a specific named item in his pack comes within proximity range of the spawner, the spawn will be triggered.
TriggerOnCarried is used to specify the name of the trigger item. If it is set to null then items are not checked and it behaves like a normal proximity-triggered spawner. To prevent excessive pack searching, the item test is only conducted once upon crossing the proximity threshold, and the item must be in the top level of the backpack - no nested searching. Proximity sensing does not work inside containers.
The refractory settings can be used to limit the way in which the trigger is activated. By setting a short delaymin/delaymax you can have a spawn that appears almost immediately after triggering, but to prevent the spawner from being triggered right after that, setting the refractory period to something like 5 minutes will keep the proximity triggering from being activated for that period.

TriggerObject
TriggerOnProperty
This allows for the ability to make player-proximity triggered spawning also dependent upon a property of any targetable item. This allows spawn chaining by making one spawner dependent on the state of another spawner. It also allows spawners to be made dependent upon things such as switches, doors, number of items, weight, or amount of gold in containers, etc.
To use this feature, select the TriggerObject property in the props list, then target the object to trigger off of. Then set the TriggerObjectProperty field with the property and the value to test for.
For Example: maxgold=20, or killcount>10, or open=true. Where maxgold, killcount, and open are property names on the objects. Supports <, >, and = operators for testing the values. Supports, int, bool, string, and double value types.

TriggerProbability
This has the value of 1 by default which means the spawn will be triggered whenever the triggering conditions are met. Setting TriggerProbability to a value between 0 and 1 will reduce the chance that a spawn will be triggered even when the other triggering conditions are met. So, for example, having a spawn that is triggered by opening a door only 1 out of 10 times, or a rare that only spawns occasionally at a certain time of day.

Duration
The duration parameter enables spawns of limited duration. By default, spawners have a duration of zero, which means infinite duration (the standard case). The duration timer begins immediately after a spawn, and when the timer expires, all spawns on the spawner will be removed until the next respawn. Respawning will occur according to the min and max delay as usual. I like to use this to make rare spawns such as the common or doom rares, harder to get. Since on servers with a smaller player base there is not the competition to get rares, this feature can make them as infrequent as they would be on a more populated server, like only available for one second every 24 hours or more.
Note: when saving spawns to an xml file the duration parameter will be saved as seconds, not minutes.

DurationOver
As far as I can figure out, this doesnt do anything, it simply tells you when the duration amount above is about to happen. A count down field, so it were.

Other PROP settings:
AllowGhostTrig This prop can either be set to true or false. A true setting will allow ghost characters to trigger the spawner, while a false setting will set the spawner to only be triggered by living characters. Pretty self explainatory.

CurrentCount This is the number of creatures set to spawn from this bit. It reflects the cumulative total of all the spawns in the list added together. I can't think of a reason you would need to make adjustments to this.

ExternalTriggering This allows other objects to actively control the spawner. This feature is enabled by setting the ExternalTriggering property to true, then the spawner will add the state of the ExtTrigState property to its list of triggering conditions. This can be used in conjunction with any of the other triggering features, so that you could have a spawner that was dependent upon proximity triggering and activation of an object (like one of the levers or switches included) that would set the ExtTrigState. For example, to place a spawner under the control of a lever add a simplelever, set the TargetProperty prop of the lever to /exttrigstate/true, and the target1property to /exttrigstate/false. Then enable ExternalTriggering on the spawner. Switching the lever will then turn the spawner on and off. By enabling speech triggering as well, the spawner will only speech trigger when the lever is also in the correct position.

Quest Objectives:
The XMLspawner quests system supports the following objective types:
KILL, KILLNAMED, COLLECT, COLLECTNAMED, ESCORT, GIVE, GIVENAMED
Some examples are:

•KILL,mobtype,count,
•KILLNAMED,mobname,count,
•COLLECT,itemtype,count,
•COLLECTNAMED,itemname,count.

The quest items can now keep track of kills and collected items in their quest status, and quest tasks that require multiple mobs to be killed can be specified. To use this feature, spawn or create an XmlQuestToken class item such as the QuestNote, and set one or more of the Objective properties with the keywords.
For example to make a killtask type quest in which the player must kill 5 balrons, 5 lichlords, a named mob called "Bubba", and collect 20 diamonds, you could;Set the

•Objective1 property to "KILL,balron,5",
•Objective2 property to "KILL,lichlord,5",
•Objective3 property to "KILLNAMED,Bubba,1",
•Objective4 property to "COLLECT,diamond,20
A spawner can be then be set up to provide a reward when the objectives on the questnote are completed.

Spawning Conditions and Keywords
Special keywords can be used in spawning for control or effects. These will be explained in more detail below, but the keywords are listed below:
value keywords: RND, RNDBOOL, RNDLIST, RNDSTRLIST, RANDNAME, INC, MUL, MOB, SERIAL, SKILL
control keywords: WAITUNTIL, IF, WHILE, and GOTO
action keywords: ADD, ANIMATE, EQUIP, GIVE, TAKE, TAKEBYTYPE, CAST, SAY, MSG, SENDMSG, BCAST, RESURRECT, POISON, DAMAGE, MUSIC, EFFECT, SOUND, GUMP, DESPAWN, DELETE, UNEQUIP
loot keywords: ARMOR, WEAPON, JEWELRY, JARMOR, JWEAPON, SARMOR, SHIELD, LOOT, LOOTPACK, POTION, SCROLL, NECROSCROLL
access keywords: GET, GETONTHIS, GETONPARENT, GETFROMFILE, GETONSPAWN, GETONCARRIED, GETONMOB, GETONTRIGMOB, SET, SETONTHIS, SETONPARENT, SETONSPAWN, SETONSPAWNENTRY, SETONCARRIED, SETONMOB, SETONTRIGMOB, PLAYERSINRANGE, TRIGSKILL

Access Keywords:
SETONCARRIED
This allows you to set properties on a named item carried by the triggering player. The syntax is SETONCARRIED,itemname/prop/value/prop2/value... This can be used in conjunction with the TriggerOnCarried property and the XmlQuestToken items to detect and set quest objectives on quest token items.
With TriggerOnCarried, and NoTriggerOnCarried if the item is an XmlQuestToken item, then the status of objectives can also be specified as a requirement using the syntax "itemname,objective,objective,.." in the TriggerOnCarried or NoTriggerOnCarried string.
For example if you wish to trigger a spawner only when quest item "Blathers Quest" is carried and has objective 1 completed, then use the string "Blathers Quest,1" in the TriggerOnCarried property. If you would like to prevent triggering when objective 1 of that quest has already been completed then use the same string in the NoTriggerOnCarried property.

GETONPARENT and GETONTHIS
These are the GET counterparts to the SETONPARENT and SETONTHIS keywords. For attachments, the GETONPARENT keyword allows access to properties on the object that it is attached to. This is generally useful when trying to include properties in substitution strings, such as an XmlDialog where you could have a text string like this
Hello, my name is {GETONPARENT,name}
Value Keywords
MOB:
MOB keyword that can be used as a property value when setting properties that need a mobile id. e.g. the combatant property on a mobile. The mobile id of the named mob will be substituted for the MOB entry. The syntax is /MOB,name/ so for example to spawn a mob and have it attack another mob you could specify something like "ogre/combatant/MOB,The outcast", where a mob named "The outcast" had already been spawned somewhere. The two requirements for using this keyword are that the mob must exist and the mob name must be unique.

RND:
RND allows you to generate random values when specifying properties RND can be used anywhere that an integer value is normally specified. The syntax for RND is /RND,min,max/ For example ogre/hue/RND,1,500/ADD,0.1/<katana/hue/500/attributes.luck/RND,50,100> would spawn a randomly colored ogre with a 10% chance of dropping a blue katana with random luck values between 50 and 100.
To spawn a random range of statics from Inside UO, you need to be tricky. You need to ADD,.1/<static,4036/ItemID/RND,4036,4044> This will add a set of shells, static 4036 to a mob/chest, and then you set the ItemID with the RND option to vary the graphic between range 4036 and 4044 which are all shells.

SKILL
The SKILL,skillname keyword can be used both for setting skill values, as well as testing for them. The SKILL keyword can be placed anywhere that a valid property name could be used. For example to spawn a mob with certain skills use a spawn spec like ogre/SKILL,anatomy/100/SKILL,macing/100.
To set skills on players that triggered the spawner use a spec like SETONTRIGMOB/SKILL,meditation/120/SKILL,magery/120. This can be used to create skill-gate like behavior.
To test for a skill value for triggering for example, set PlayerTrigProp to SKILL,mining>100.

TRIGMOB:
The TRIGMOB keyword, which will substitute the mob who triggered the spawner as its value. Can be used to set any property that takes a mobile as its argument. So, for example, you could use it to spawn a mob that had the player who triggered it as the combatant, "ogre/combatant/TRIGMOB", or spawn pets that are controlled by the triggering player, for example ogre/name/Slave/controled/true/controlmaster/TRIGMOB

Action Keywords:
ADD:
ADD keyword allows you to add items to spawning mobs packs. The syntax for ADD is /ADD/itemtype, or /ADD,probability/itemtype, or /ADD,probability/<itemtype/prop1/value/prop2/value...> where probability is a drop probability between 0 and 1 and <itemspec> is an embedded item specification, so that you can put attributes on the added item as well. An example of this would be the specification string ogre/name/Lord Bleck/ADD,0.3/katana that would spawn an ogre named Lord Bleck with a 30% probability of dropping a katana.
As a further example, this can be combined with the note object for simple quest-like behavior using specification strings such as lich/name/Dark Master/ADD/<simplenote/notestring/My soul will not rest until you return with the Ring of the Elements found on my nemesis, the lich lord Artemis in the dungeons of Ilshenar. Take my sword to aid you./titlestring/The Return of Artemis/name/Quest of Artemis/size/2>/ADD/<longsword/maxdamage/RND,30,70> which will add the specified note and sword to a lich named Dark Master.

ANIMATE:
The ANIMATE,action[,framecount][,repeatcount][,forward true/false][,repeat true/false][delay] keyword to add animations to any mobile. For example,
SETONTRIGMOB/ANIMATE,32,5,1,true,false,0
would cause the triggering player to bow.
Or used in the Action field on an XmlDialog it could be used to make an npc bow, like:
SETONTHIS/ANIMATE,32,5,1,true,false,0

CAST:
The CAST keyword allows the spawner to cast spells on triggering players. The syntax is CAST,spellname[,arg] or CAST,spellnumber[,arg] where spellname and spellnumber are the registered spell names and numbers found in Scripts/Spells/Initializer.cs. This is used with triggering to allow the triggering mob/player to cause the spell to be cast with the triggering mob/player as the target. Both harmful and beneficial spells can be cast. Karma effects will also be applied. There are no casting delays, so multiple spells may be cast simultaneously. Some spells are are location targeted and can take an additional argument [,arg] which is a range value used to determine a random target location (+-range) relative to the caster. The default and mininum range value is 1. The Polymorph spell uses the 2nd argument as the bodyvalue.
For example, to set up a spawner to autoheal the triggering mob use the spawn spec CAST,greaterhealspell. To polymorph the triggering player into a bear use CAST,polymorphspell,212. To cast lightning on the triggering player CAST,lightningspell Not all spells will work automatically. Item targeted spells such as mark, recall, and sacredjourney will cast and bring up a targeting cursor.
NOTE: I will have to figure out if this can work with or be applied to our custom magic system. I dont see why not, but this has not yet been tested.

DELETE:
The DELETE keyword can be used to modify a standalone keyword and delete the object that it refers to (it will not allow you to delete players) For example, this spawn entry:
SET,Mystic Sword,longsword/DELETE
will delete the longsword named "Mystic Sword"
SETONMOB,SeeYouLater,Balron/DELETE
will delete the balron named "SeeYouLater"
SETONCARRIED,,Gold/DELETE
will delete gold that it finds being carried by the triggering mob
SETONSPAWN,TargetSpawner,2/DELETE
will delete all of the spawns of subgroup 2 on the spawner named TargetSpawner. This is basically the same as using the DESPAWN keyword but will delete all spawns regardless of their CLR flag setting.

GUMP
The GUMP keyword that will send a gump containing the designated text to the triggering player. Syntax is GUMP,title,number/text. A default set of gumps has been added, but these can be extended by the user. A sample script XmlQuestGumps.cs has been included showing the form of the default quest gumps. It is required to use the default GUMP features.
GUMP number 0 is a simple text display gump. GumpState is set to "done" after viewing.
GUMP number 1 displays a gump with yes/no selections. GumpState is set to either "yes" or "no" depending on the user selection.
GUMP number 2 displays a gump with a text entry area. GumpState is set to the text entered.
GUMP number 3 will send a quest gump with accept or decline options. GumpState is set to either "accept" or "decline" depending on the user input.

UNEQUIP:
The UNEQUIP,layer[,delete] keyword allows you strip a mobile of an equipped item on the specified layer. If the optional "delete" argument is specified, then the removed item will be destroyed, otherwise it will simply be dropped into the the mobiles pack. For example, you could disarm a one-handed weapon from a triggering player using:
SETONTRIGMOB/UNEQUIP,OneHanded or spawn a mobile, remove existing equipment, and replace it with new equipment with something like:
banker/UNEQUIP,pants/UNEQUIP,shoes,delete/EQUIP/sandals/SAY/Hey, where are my pants? This will create a banker, take off his pants and put them in his pack, take off his shoes and delete them, and then put on a pair of sandals in their place.

MSG:
The MSG keyword for the spawn specification strings that can be used to display messages over mobs or items when they are spawned. The syntax is /MSG/text/, with an optional probability factor specified using /MSG,probability/text/. So, for example, to spawn a lich that occasionally taunted you, you could use the spec string "lich/MSG,.5/All hope is lost/MSG,0.2/you feeble mortal/MSG/hahahahaa" to give you random combinations of messages such as "All hope is lost hahahahaa", or "feeble mortal hahahaha", or just "hahahahaa".
Or the string "ham/MSG/a tasty morsel" would place the message "a tasty morsel" above the ham when it was spawned.
Note, that because the switch/lever objects also use the same syntax for specifying properties on target items, you can use this keyword in conjunction with those items. So, for example, you could have a lever that opened a door, and also displayed a message over the door indicating it had opened using the string "/locked/false/MSG/the door magically opens" in the target item property description.

GIVE:
The GIVE keyword which is used as a spawn spec, and is "spawned" just like a regular mob/item. The syntax is the same as the ADD keyword, but the item is placed directly into the pack of the player that triggered the spawner,
GIVE/itemtype
GIVE,probability/itemtype
GIVE,probability/<itemtype/prop1/value/prop2/value...>

TAKE:
The TAKE keyword which is used as a spawn spec, and is "spawned" just like a regular mob/item. The syntax is TAKE/itemname or TAKE,probability/itemname. It will search the trigger players pack, and all containers in the pack for the first item that matches the name, and then delete it. It will not remove containers.
By combining the GIVE and TAKE keywords, you can have a spawner that takes one item and replaces it with another, for example a quest item can be replaced with a quest reward.
The TAKE keyword also allows for a partial removal of named stacked items. When called with the quantity argument, TAKE will attempt to remove the specified quantity of the stacked item. If less than the quantity is found, then whatever the amount found will be taken. If the item is not stackable, then the item will simply be taken.

TAKEBYTYPE
The syntax for this is TAKEBYTYPE,probability,quantity/itemtype. It is similar to the TAKE keyword but items are identified by type rather than name. For example, to take 1000 gold from a triggering player use the spawn spec TAKEBYTYPE,1,1000/gold.
Note, by default neither TAKE and TAKEBYTYPE will search a players bankbox. Adding the argument "true" added to TAKEBYTYPE and TAKE keywords allows bankboxes to be included in the searched items. The syntax is TAKE,probability,quantity,true/itemname and TAKEBYTYPE,probability,quantity,true/itemtype.

SET:
The SET keyword which is also used as a spawn spec and is "spawned" just like a regular mob/item. It sets properties on a target item that is specified in the SetItem property of the spawner. You target an item and when the spawner is triggered, it will apply the property changes contained in the SET specification string. For example, this can be used to open a door when certain trigger requirements are met, such as saying a keyword, or possessing an item, etc. using a spec string like:
SET/locked/false/MSG/the door is magically opened, and targeting a door from the SetItem property, or making a switch or lever or chest visible, when triggered with the spec line SET/visible/true.
Any property that can be written using the .set command, can be linked to spawner triggering using the SET keyword. Because the SET commands are "spawned" just as other mobs are spawned, they can be used to set properties of items at specified intervals by using spawners that are not triggered but are simply run on the normal timed schedule. For instance, using the time of day feature, you could have a set of doors that are locked during the day and opened at night, or are locked and unlocked occasionally on a 5-10 minute schedule (min/max delay).
Note, in order to have the target item properly saved to an xml file when using .xmlsave, the target item must have a unique name.

SETONTRIGMOB:
The SETONTRIGMOB keyword which is used as a spawn spec, and is "spawned" just like a regular mob/item, it is just that nothing is created but rather target properties are set on the mob that triggered a spawner. This could be used for example to drop mana or stamina when a player comes within range of a spawner, or kills a target number of mobs, or is carrying an item, etc. Or hide the player when a keyword is spoken and they possess a specific item. (e.g. spawn spec SETONTRIGMOB/stam/0/mana/0, or SETONTRIGMOB/hidden/true)
Also, by changing the x,y,z properties of the trigger player, it can be used to construct more sophisiticated teleporters, such as one that sends a player to a new location when they are carrying an item, and a target lever is in a specific position, or when a certain number of mobs are killed, or when their health reaches a certain level, etc. As well as the more straightforward type of triggering such as on a keyword.
Note, this is potentially a VERY powerful ability. Use of this feature should be made with care, since it can make changes to any writable players attributes. Of course, it cant do anything more than an admin could do normally by using the .set command on a player.

Attachments:
For a list of available attachments, type in game .availatt
Local variables are stored as XmlLocalVariable attachments on the spawner and can be viewed and modified using the .getatt command and targeting the spawner.
Supports the use of modifiers like global, multi, area, etc. with the .addatt and .delatt commands that add and delete attachments from objects (thanks to Vento Divino for the suggestion). So to add a particular attachment to all players you could do something like
.global addatt xmldata datavalue where playermobile
and to remove those attachments you could use
.global delatt xmldata where playermobile
Some of the stat and skill mod attachments are (will add syntax when I find it):

•XmlStr
•XmlDex
•XmlInt
•XmlSkill

and the fame, karma, and virtue attachments are:

•XmlAddFame
•XmlAddKarma
•XmlAddVirtue
•XmlStamDrain
•XmlManaDrain
•XmlLifeDrain
When attached to a mob or weapon, these will drain stam/mana/life from the defender on each hit and give it to the attacker. If attached to an item in the world, it will drain a random amount of stam/mana/life when a player moves near it. The random value will be between 0 and the argument to the attachment. The default refractory period between uses is 5 seconds. If a negative drain value is given, then the attachment will be reported as a curse when attached. For example, using the command
.addatt xmllifedrain 30 3 120
and targeting a mob, would give that player/mob 2 hours of lifedrain ability that would drain 0-30 hps on every hit, with a max rate of once every 3 seconds.

XmlSaveItem
This attachment that allows you to internalize an item and hold it on the attachment for later retrieval. This is used by xmlspawners and xmldialogs to keep track of taken items, but could be generally used to temporarily hold items. The SavedItem property can also be manually set and will internalize and maintain the targeted item on the attachment. When the attachment is deleted, the saved item is also deleted. By setting the RestoreItem property on the attachment to true, the saved item will be placed back into the world at the location of the object the attachment was attached to. If at any time the saved item is placed into the world (moved off of the internal map), XmlSaveItem will no longer keep track of it.

.xmledit
This utility is for editing XmlDialog specifications while ingame. This allows you to add or change npc dialog without having to create and load a .npc file. Just issue the command "[xmledit" and target an object with an XmlDialog attachment. If it does not have an attachment, you will be asked if you wish to add one.
The editing gump is divided into four sections.
The top section allows you to change the overall properties of the attachment, such as triggering range, triggering conditions, and reset time.
The middle section allows you to view and select a specific speech entry for editing. Press the button to the left of the entry to select it. The checkboxs on the right are used to select entries for deletion. Check the boxes of entries you wish to delete and then press the Delete button at the bottom of the gump. You will be prompted to confirm deletion. To add a new speech entry, just press the "Add" button at the bottom of the gump and a new empty entry will be added to the end of the entry list.
The lower section allows you to edit the selected entry. Enter in the new values. The changes will take effect the next time the gump is updated, either by selecting the "Refresh" button at the bottom of the gump, selecting another entry, or exiting the gump.
Currently, text entry is limited by the size of the text entry field. This will be updated with the book text entry interface in an upcoming version.
The bottom section contains buttons for Refreshing the XmlDialog, Adding a new speech entry, Deleting selected entries, Saving the XmlDialog specification to a .npc file, and paging through the speech entries.
The specification can be saved to a .npc file by entering in a filename in the "Save to file" text entry area and pressing the button next to it. The .npc extension will automatically be added. If the XmlDialog was loaded from an existing .npc file, that filename will be shown in the "Config:" field to the left of the Save option. There is currently no check for overwriting an existing file, so be careful (I will be adding this feature). This option is restricted to administrators.

TemporaryQuestObject
The syntax is: TemporaryQuestObject,questname[,expiration]
This attachment allows you to tag items/mobiles so that they are automatically deleted after some period of time, or whenever the quest they are associated with is completed (when the questholder associated with the quest deleted). (thanks to Eymerich for the idea).
To use this simply put the attachment on an object, and assign the questname, owner.
You can also use it to make temporary objects that are not associated with a quest by just specifying an expiration time. The way it works is When the attachment is deleted, the object it is attached to is also deleted. Typically you would probably create the object with the attachment using a spawn entry like this:
GIVE/<questholder/name/MyQuest/objective1/KILL,orc/autoreward/true/rewardstring/gold,100> GIVE/<longsword/name/Quest Sword/ATTACH/<temporaryquestobject,MyQuest/questowner/TRIGMOB>>
This would hand out a quest named MyQuest, and then give the triggering player a longsword named "Quest Sword" that was associated with MyQuest. Note that the mobile who is the questowner of the temporaryquestobject must be manually specified by setting the QuestOwner property on the attachment.
To make a general temporary object independent of any quests, just use the attachment with an expiration time like this
longsword/name/poof/ATTACH/temporaryquestobject,tempsword,3
which would make a sword that would autodelete after 3 minutes (the name "tempsword" could be anything since it it isnt really used for autodeletion and is just to identify the attachment).

XMLFreeze:
The XmlFreeze[,seconds] attachment that allows you to permanently or temporarily freeze a mobile in place. If attached with no duration argument, they will remain frozen until the attachment is removed. This can be used with the ANIMATE keyword to keep mobs from moving while animations are applied.
orc/ATTACH/xmlfreeze,10
would spawn the orc frozen for 10 seconds.
SETONTRIGMOB/ATTACH/xmlfreeze,10/MSG/You are frozen with fear!
would freeze the triggering player for 10 seconds and send them a message.

XmlMorph
This attachment changes the BodyMod property of target mobiles. When mobiles are deserialized, they automatically restore their default bodytype, so the OnReattach method can be used by the attachment to override this and restore the desired BodyMod assignment.

XmlWeaponAbility:
This attachment allows mobs to be given special attacks on the fly. You can add special attacks to a spawned mob with a spawn entry like:
orc/ATTACH/xmlweaponability,BleedAttack
or manually add it to any mob with
[addatt xmlweaponability BleedAttack
and then target the mob. Note, the attack name is case sensitive and can be any of the following:

•ArmorIgnore
•BleedAttack
•ConcussionBlow
•CrushingBlow
•Disarm
•Dismount
•DoubleStrike
•InfectiousStrike
•MortalStrike
•MovingShot
•ParalyzingBlow
•ShadowStrike
•WhirlwindAttack

Other Keywords:
ARMOR, WEAPON, POTION, that will create random magic items of the type specified.
ARMOR,min,max will drop a random piece of armor, shield, or jewelry with an attribute level randomly selected between min and max. min and max can range between 0 and 5 with 5 being the most powerful.
WEAPON,min,max does the same for weapons.
POTION drops a random potion,
Add these to the spec line in place of normal types, i.e. wherever you would use a typename like katana, or platehelm, just substitute these keywords. These can either be used as the basic entry in a spawn spec, therefore spawning them directly, or they can be used with the ADD keyword to add them to a spawned mobs pack. e.g. ogre/ADD,0.5/WEAPON,2,5 would spawn an ogre with a 0.5 probability of dropping a lev 2-5 magic weapon.
The spec line ARMOR,5,5/name/Bruiser/hue/300/durability/200 would spawn a random piece of magic armor of level 5, name it Bruiser, turn it blue, and set its durability to 200.
The spec line ogre/ADD,0.5/<ARMOR,5,5/name/Bruiser/hue/300/durability/200> would add that piece of armor to a spawned ogres pack with probability 0.5
The line GIVE/WEAPON,5,5 would give a level 5 magic weapon to the player that triggered the spawner.

Quest Items:
SimpleNote
There is a new SimpleNote object in the included script simplenote.cs which is an item that can be used independently, but is designed as added content for exercising spawner capabilities for more dynamic quest-like use. It is NOT needed for the spawner to function and is purely optional.
It allows construction of simple notes/messages that are designed to be read by players by opening into a scroll gump of variable size. The text of the note, its title, and text color can be specified by the user. The note can be defined in the spawner and can be used to pass trigger requirements etc. to the player. e.g. in the spawn specification string enter: simplenote/notestring/Seek out the Sword of Misery that is held by the ogre lord Blasphema in the forest north of Trinsic. Call out to him, and you will bring him forth./size/2/titlestring/The Quest for Blasphema/name/Blasphema's Quest.The triggering of the spawn could then be made dependent upon the player possessing the named note ("Blasphema's Quest").

QuestNote:
The quest item (QuestNote) and quest token item class (XmlQuestToken), that allows multi-part quests, with expiration time, and transfer restrictions. By placing quest information on these player carryable tokens, quests can be made without modification to playermobiles, or to any scripts at all, making them completely portable. XmlSpawners can modify or read multiple objectives on the items using the objective1-5 and completed1-5 properties.
The use of quest token items for mainenance of quest information also allows for multiple simultaneous quest simply by possessing the appropriate tokens. Quest item properties are public, so scripts can freely access them for constructing specific quest scenarios that can then be used to drive spawning.
Items that belong to the XmlQuestToken class lose their validity whenever they are transferred from the original owner, either to other players, to the world, or to containers not in the players pack. This prevents transferral of quests, and other exploits. These items are also blessed by default.
When an XmlQuestToken item is used as the target of carried-item triggering (TriggerOnCarried property), then it must be valid (never removed from the players pack), and satisfy specified subobjectives in order to trigger. (see TriggerOnCarried, and NoTriggerOnCarried multiple objectives. Objective status can be seen on the quest log status gump).
XmlQuestTokens can also be given limited lifetimes using the expiration property. Due to limitations in the way in which TimeSpan type variables are handled by .net, currently the maximum expiration time for a quest token is 24 hours.

Other Items:
•Added several new items for added content that are independent but enhance the use of the xmlspawners. They are a switch, a lever, and a combination lock.
The script SimpleSwitches.cs adds a 2or3-state lever, a 2 state switch with different facings determined by direction (not by flipping), and a combination lock. The states of the lever can be used to set properties on target items such as doors (locked/unlocked), or even to add items to containers. By setting the TargetItem and TargetProperty properties, you link the switch/lever states to certain item properties. So, for example to use a switch to open a door when the switch is in the 1 state, set Target1Item to the door and then set Target1Property to /locked/false (note, it uses the same syntax as the xmlspawner2 property specification strings. Since it shares the same syntax, you can also have it do things like change the color of an item, or add items to a container using the ADD/<spec> string.) SimpleCombinationLock simulates a multi-digit (max 8) combination lock. The state of each of the digits can be set using (for example) the lever or switch items. The combination is set in the Combination property. So the combination of 378, would correspond to digits 2,1,0 taking on values of 3,7, and 8 respectively. The Match property can be tested to determine when the target combination is matched by the combination of digits. Note that digit number corresponds to significance, from least to most. Each digit is a property (Digit0, Digit1, Digit2, ... Digit7) and can take on the values 0-9. You can set the property string to indicate either a property name on the target item (e.g. switchstate, or leverstate, or totalgold), or you can specify a test such as totalgold<100, or open=false, or locked=true. You could use this item to look for certain combinations of switches or levers, door states, etc. or even combinations of levers, and weight of a container, or number of kills on a spawn etc., and then open a door, or add items to a container, or change the color of a stone, trigger a spawn, etc.

•Added new items TimedSwitch, TimedLever, XmlLatch, and TimedSwitchableItem.
Similar to the SimpleSwitch and Simple lever, the TimedSwitch, TimedLever items add a reset timer to the switch/lever states with min/maxdelay properties and are derived from the XmlLatch which is a new class that supports resettable switching, and can be used as an item itself to implement a resettable latch (set the state externally and it will hold that state for some time and then reset). The item TimedSwitchableItem is a TimedSwitch that allows you to specify the Item statics that will be assigned to each state, allowing flexible user-defined visuals during switching, such as a torch or a stone, or a wall section, etc. Because it is a TimedSwitch you can assign actions that are associated with each state as well, such as opening a door when double-clicking a torch, or opening a secret passage when double-clicking on a wall section, etc. The current switching state of all of these items is contained in the State property, and the ResetState is the value that the State will be returned to after the reset timer expires.

Original Document by Paradyne - Modified for use on UO:Renaissance
Original Article - http://www.servuo.com/threads/xml-spawner-tutorial.98/