XmlSpawner2 v4.0

--------------------
updated 22/04/2014
Fwiffo

Moved some files to allow a user to remove certain unneeded portion of XmlSpawner (siege, mobfactions, etc) without too much hassle and no errors by compiler is such cases.

Updated this file to match actual stage of changes.

--------------------
updated 19/04/2014
Fwiffo

this is an update for backward compatibility with official google code RunUO - for compatibility with ServUO and the checks for GitHUB RunUO by msturgil

Please, always refer to the correct TXT files that match your case.

--------------------
updated 17/04/2014
Fwiffo

- fix in custom area reload error, if the area is a square, during load it's size would be halved and so on in each reload, to prevent this we check actual central point and we also check if the area is square or of irregular size.
- by using the flag "ServUO" at compile time, (as defined in the original project found on servuo) you instruct to use the things found in there, so you don't have to edit almost anything inside...(Thanks to tindo on runuo for the additions and fix for ServUO)

--------------------
updated 21/11/2013
Fwiffo

BaseXmlSpawner.cs - Total conversion to generic Type
Added TAKEGIVE and SETVALUE
Added Disable TickReset to Xmlspawner, so at every tickm, if you choose so, the killcount won't decrement.
Updated the XmlSpawnerGump so that every new added commands are viewable there (in the xmlspawner gump click HELP!
Minor Fixes to other systems.

Please, always rever to the HELP Gump in XmlSpawner for reviews on how a command can work, I have no time for examples

--------------------
updated 09/08/2013
Fwiffo

bugfix in autoreward with RewardAction!=null

--------------------
updated 07/08/2013
Fwiffo

Generic/Strongly typed List<T> conversion from arraylists in all XmlQuest/*

Another joucy addon is the RewardAction in "XmlQuestHolder", in this string an action could be done to the player when completing the quest with "AutoReward" to true, playing a song, damage, teleporting, changes. all with the same XmlSpawner syntax, considering the invoker/trigger mobile as the owner of the questbook.

Also a bugfix occurred during the screening of the code, questpoints where not correctly calculated for taking rewards and even if you remove the "CanSeeReward" from XmlQuestHolder, if the player had registered the macro or tried to sent a crafted packet with the correct button number, he could open the bag.
The bag under the same XmlQuestHolder now is more secure, it doesn't allow item stacking, thus preventing to the player to stack gold with the gold present, or put other items, that will anyway vanish when completed, in the same bag.

--------------------
updated 21/07/2013
Fwiffo

Completely converted attachment system to use strongly typed List instead of ArrayList and Dictionary instead of Hashtable.

Tried a conversion of XmlMobFactions/XmlDynamicFaction with the use of the same as above.

Generic List<T> and Dictionary are better in those situation, were the gain in speed is way better than the old methods.

Fix to a Cast exception in GetClientsInRange, since this call returns Netstate Type, not Mobile, also an original bug was found in PlayMusic, considering that netstate were directly casted as mobile, it could cause a server crash.

--------------------
updated 18/07/2013
Fwiffo

Fixed the use of name proptest, in case you want to allow a search and don't want to specify a name in property test, you can use the wildcard "*" (FOREACH - AMOUNTCARRIED and many others that will allow to input a name among other things):

Example:
FOREACH,PlayerMobile,*,3/DAMAGE,100

Will do 100 damage to all playermobiles in a range of three, the * will match any name
FOREACH,Item,,3/Name/New Name
Will get any Item in a range of three whose name is "null" in the property test, and will rename them to "New Name".


Modified and fixed a bug in SETONPETS:

Before:
SETONPETS,range/prop/value/prop/value...
but it wouldn't work, since the checkname, with a value of null, wasn't valid (and you couldn't modify it!)

Now:
SETONPETS,range[,name]/prop/value/prop/value...
If you don't specify a name, any name will match, if you input a *, also, any name will match, an empty name will match only pets with "null" name in property.


Modified the PLAYERSINRANGE, so instead of searching for any mobile and checking if they are players, it will search for any active client (logged in player, that's it).

--------------------
updated 13/07/2013
Fwiffo

Changed QuestLogGump in XMLQuestLogGump because of name conflicts with RunUO source from SVN.

In XmlSpawner2.cs fixed the SpawnerBounds, that returned a smaller area than the real one of the spawner, this only affected FOREACH command.

Fixed an old bug in XmlDialog, where an NPC with LockedConversation selected, if it starts a conversation and then waits for input from the user, another user giving speech for that input could obtain, in case of successful eventual checks, the control of the subsequent input, now this is checked, so LockedConversation makes more sense.

Added some extras found in the web, they were not checked for any bugs, so, if you plan on using them, be warned that they may cause server instability, TEST THEM at your own risk!

-------------------
updated 11/7/2013
Fwiffo

FIX
null reference in XmlFind fix;
Major update, removing references to object types and using generic type when possible, fixed possible stack overflows in a case as this:
Spawner1 Entry1 : SPAWN,Spawner2,1
Spawner2 Entry1 : SPAWN,Spawner1,1

this is an absurd case, but if you're making LARGE use of IF/SPAWN/WHILE it CAN happen since the primary call always continues to run without returning a value, in some cases, making excessive use of recursive call, if that generally happens, I've put in a check that allows a max of 10 recursive calls, and then throws the error in the spawner/activator object, specifyng who caused the error, without a server crash.

Other bugfixes where made in the meantime, some required major changes in the structure, but compatibility with older xmlspawner system was always the first thing in mind, so no changes are required on the user side.

MODIFICATIONS
The GET Keyword, used inside an XMLSPAWNER, can get the property of the SETITEM, if that is set, in a way like this:

GET,SETITEM,property by using SETITEM capitalized, if you use Setitem or setitem, it will work like in the old way, will search for the item name. This is to speedup uses of the setitem in conditional/complicated spawners that make use of the SETITEM, allowing to get properties on them easily.

OLD command AMOUNTCARRIED,itemtype -- NEW is AMOUNTCARRIED,itemtype[[,banksearch],itemname] (it can check for name, in bank, and always counts even amount of equal unstackable items carried or in bank)

OLD command SETONTHIS/prop/value/prop2/value2/prop3/value3/.. -- NEW is SETONTHIS[,proptest=value]/prop/value/prop2/value2/prop3/value3/.. doing a proptest for speed in execution of a check before set inside spawner or elsewhere.

SUMMARY
Most of us, at least the ones that try to use the xmlspawner with most of it's functionality, have faced the truth when they found that there isn't any way to set a long string with slashes and special chars without getting into trouble, not counting that maybe you need to continue to set other properties (spawning a lever that does many actions, a custom text, a spawner that spawns a spawner that spawns a spawner...well the last is kinda absurd...but anyway...).
The Literal terminator is defined in BaseXmlSpawner.cs via a static char, and is the char '§', you can change it to whatever you want.

Example of literal termination:

in spawner book:
simplelever/target1property/@this/is/a/long/string/with/slashes§target2property/simplestring

remember not to put a / right after the §, there is no need for that!
-----
Added modifier FACETO usable in conjunction with mobiles, to make turn easily in a direction or other mob or item
Syntax is FACETO,x,y
Example: FACETO,{GETONTRIGMOB,x},{GETONTRIGMOB,y}
will turn to the mobile that trigged the event. Very useful in conjunction with xmlquesters or with proximity activated spawns or in conjunction with the use of FOREACH (see below).
-----
Added FOREACH usable in spawner as well as other items that use this system.
Syntax is FOREACH,objecttype[,name][,range]/action OR /prop/value/prop/value

objecttype is the type of the object that you're searching, for example if you're searching only Horse, and don't really care for the name, in a range of three from the activator, that could be the spawner or something else, then the syntax would be:
FOREACH,horse,,3/DAMAGE,100/Name/Plumb to make 100 damage to any horse in 3 range and rename them to Plumb.

If you're using from a spawner, and you want to use the spawn area of the spawner itself, or the region area present, if the regionname is set and there is a valid region with that name, you have to omit the range value, for example this command:
FOREACH,playermobile,bobo/EFFECT,14000,13/DAMAGE,100

will create an exploding effect to any player in the spawn range of the spawner that activated it, but only to those named "bobo" (it's case sensitive, so be careful!).

This can be used on ITEMS TOO!
I warn you, this command, if used not wisely, can cause A LOT of LAG, so use it knowing what you're doing!
-----
Added FLASH, where the mobile, only players of course, will get a flash effect
Syntax is FLASH,int (from 1 to 5, checked if you do it wrong)
1 is fade to black
2 is fade to white
3 is light flash
4 is light to black flash
5 is black flash

You can use this in conjunction with foreach, modifiers on playermobiles or situation where the use is admitted, this is self explanatory.
-----
Added PRIVMSG, to show a message only to a particular mobile over his head (only PLAYERS)

Syntax is PRIVMSG[,probability][,hue]
If the object is a mobile actively connected display the message, it works like the SENDMSG;

--------------------------------------------
OLD MODS used for reference
--------------------------------------------

XmlSpawner2 v3.24
updated 2/11/08
ArteGordon

SUMMARY
A spawn control system based upon bobsmart's xmlspawner with features, items, and commands supporting sophisticated conditional spawn triggering, individual customization of spawns and their drops, and systems for stealable rares, interactive npcs, functional attachments, mob factions, pvp points, custom weapon attacks, item/creature socketing, and quests. 

Spawning System Features:

- spawn items and mobiles.
- spawn in containers.
- spawn stacked items.
- add items to spawned mobiles packs.
- spawnrange (how far they spawn) and homerange (how far they wander). 
- spawn objects that require arguments to their constructors, such as runic hammers, or doors.
- set properties on any spawn without having to make script modifications.
- add items to spawned mobs backpacks without having to make script modifications.
- probabilistic spawning that can be used to implement rare mob spawns, such as a single spawn that you have to kill on average some number of times to get a rare named spawn to appear.
- time-limited spawns, such as rares that only appear for a certain amount of time.
- sequential champ-like spawning that advances by killing spawns.
- spawning in regions.
- linked spawning of multiple spawn entries using subgrouping.
- spawn on difficult surfaces such as multilevel tables/floors and water by adding a leading '*' to the spawn entry.
- special keywords can be used in spawning for control or effects:
- value keywords: RND, RNDBOOL, RNDLIST, RNDSTRLIST, RANDNAME, INC, MUL, MOB, SERIAL, SKILL
- control keywords: WAITUNTIL, IF, WHILE, and GOTO
- action keywords: ADD, EQUIP, GIVE, TAKE, TAKEBYTYPE, CAST, SAY, MSG, SENDMSG, BCAST, BSOUND, RESURRECT, POISON, DAMAGE, MUSIC, EFFECT, MEFFECT, SOUND, GUMP, DESPAWN, DELETE, KILL, ANIMATE, OFFSET, BROWSER
- loot keywords: ARMOR, WEAPON, JEWELRY, JARMOR, JWEAPON, SARMOR, SHIELD, LOOT, LOOTPACK, POTION, SCROLL, NECROSCROLL, TAKEN, GIVEN, ITEM
- access keywords: GET, GETONTHIS, GETONPARENT, GETFROMFILE, GETONSPAWN, GETONCARRIED, GETONMOB, GETONTRIGMOB, GETONNEARBY, SET, SETONTHIS, SETONPARENT, SETONSPAWN, SETONSPAWNENTRY, SETONCARRIED, SETONMOB, SETONTRIGMOB, SETONNEARBY, PLAYERSINRANGE, TRIGSKILL, AMOUNTCARRIED 
- #spawn control keywords: #NOTILES, #TILES, #WET, #DXY, #XY, #RELXY, #CONDITION, #PLAYER, #WAYPOINT, #XFILL, #YFILL, #EDGE
- spawner triggering by: player proximity, speech, player skill use, players carrying specific items, items or mobiles that have certain properties such as open doors or injured mobs, time of the day.
- automatic relocation of inaccessible spawns.
- "SmartSpawning" which allows spawners to automatically and transparently remove and restore spawns based on player proximity, reducing save times and mobile load.

Quest System Features:

- make complex multiple-objective quests ingame without any scripting.
- players can have multiple quests running at the same time.
- allow playermade quests that can be constructed by players and given to other players for things such as guild events.
- supports the following quest objective types: KILL, KILLNAMED, COLLECT, COLLECTNAMED, ESCORT, GIVE, GIVENAMED
- construct interactive npc conversations using the [xmledit command.
- control whether and how often quests can be repeated.
- quests can be assigned difficulty levels that are used to give out quest points on completion of the quest.
- players can be ranked by quest points.  These shardwide rankings can be displayed using the [questranking command or saved to html for web display.
- quest rewards can be purchased using quest credits.

Support Features:

- searching/sorting for spawners/items/mobiles with the "[xmlfind" utility.
- creating interactive dialog objects/mobs ingame with the "[xmledit" utility.
- rapidly adding and configuring spawners and their spawns with the "[xmladd" utility.
- track down any spawn using the "goto" button in the spawner gump
- saving and loading of spawn files with [xmlsave, and [xmlload.
- import .map and .msf format spawn files with the "[xmlimportmap" and "[xmlimportmsf" utilities.
- export and import existing standard distro spawners using the [exportspawner and [importspawners commands.

Addon Systems:

- Spawn Editor 2 visual spawn editing/mapping program 
http://runuo.com/forums/showthread.php?t=70757

- XmlPoints addon
http://runuo.com/forums/showthread.php?t=70750

- XmlMobFactions addon
http://runuo.com/forums/showthread.php?t=70751

- XmlCustomAttacks addon
http://runuo.com/forums/showthread.php?t=70753

- XmlSockets addon
http://runuo.com/forums/showthread.php?t=70755

- PlayerRangeSensitiveMod provides the benefits of having PlayerRangeSensitive=false with virtually none of the server load. 
http://runuo.com/forums/showthread.php?t=73639
Additional Links:

- Tryings beginners tutorial
http://runuo.com/forums/showpost.php?p=297933&postcount=688

- Gator81's custom gauntlet with helpful walkthrough of setting up object-triggered spawners.
http://runuo.com/forums/showthread.php?t=50444

- Eymerich's beginners guide to quest making. (thanks to TMSTKSBK for hosting this!)
http://www.csquarenet.net/ArteGordon/XmlQuest4Dummies.doc

- LordHogFred's xml posts. 
http://runuo.com/forums/showthread.php?t=59892
http://runuo.com/forums/showthread.php?t=60856

- benchmarking information on spawner memory use.
http://runuo.com/forums/showpost.php?p=448568&postcount=1078


CHANGELOG:
[color=red][b]New to version 3.24[/b][/color]
updated 2/11/08

[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed a problem with xmldialogs no longer responding to keywords that was introduced in v3.23.[/b] (thanks to spookyroberts for pointing that out).

[b]- fixed an exploit with playermade quests that allowed players to add to stackable rewards such as gold, and then use the quests as bags of sending.[/b]  Players can no longer add to stackable rewards. (thanks to syznow for pointing this out)

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- modified the #WAYPOINT keyword to use the z coord as well as the x,y coord of waypoint runes when trying to place spawns.[/b]  Previously, only the x and y coord of the rune were used. (thanks to noonehome for the suggestion)

[color=red][b][u]New Features[/u][/b][/color]
[b]- added the new 'BSOUND,soundid' keyword that will broadcast a sound to all players.[/b]  This is essentially BCAST for sounds. This is a standalone keyword. (thanks to BaronVallyr for the idea).

[color=red][b]New to version 3.23[/b][/color]
updated 2/2/08

[u]If you are using SVN 241 or higher you will need to update to this version.[/u]

[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed a problem with the GETONNEARBY keyword when used in condition tests with XmlDialogs.[/b] It was not using the location of the object that the XmlDialog was attached to as the reference location for the nearby search (thanks to Xerocrates for pointing this out).  

[b]- blocked the ability to use questholder rewards (by double clicking them while viewing them) before the quest is completed.[/b] (thanks to ABTOP for pointing this out).

[b]- fixed a bug in which an attachment with a custom OnUse or OnUser function that deletes the item it is attached could cause the default Use function to crash with a null item error.[/b] (thanks to CEO for pointing this out).

[b]- fixed a problem with orphaned attachments that try to remove items that they might be holding when they get cleaned up.[/b]  This could generate warnings during world saves regarding attempts to delete items by attachments. (thanks to Vladimir for pointing this out)

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- optimized the #WAYPOINT keyword for speed.[/b] Rather than searching all world items for named waypoints, it now uses a local hashtable lookup. This can significantly improve spawning performance when this keyword is used, particularly for servers with large item counts.  The table will be reconstructed on server restarts or when spawners are manually reset.  Note that if you use the #WAYPOINT keyword and add new waypoint runes, make sure that you reset the spawner so that they are recognized.  (thanks to Xavier_WER for the suggestion).

[b]- newly duped spawners are now automatically shut off before being placed in a pack.[/b] (thanks to Haazen for the suggestion).

[b]- added support for accesslevel restrictions on constructable objects that was added in SVN 241.[/b]  To enable this feature uncomment this line at the beginning of xmlspawner2.cs
[color=blue]
//#define RESTRICTCONSTRUCTABLE
[/color]
and then you can restrict spawning of objects that have an accesslevel restriction in their Constructable attribute by adjusting the value of this variable around line 92 of xmlspawner2.cs
[color=blue]
        public static AccessLevel ConstructableAccessLevel = AccessLevel.GameMaster; // only allow spawning of objects that have Constructable access restrictions at this level or lower. Must define RESTRICTCONSTRUCTABLE to enable this.
[/color]
If you dont enable this feature, then things will work just as they have in the past, with no restrictions on spawning of objects that are marked Constructable.

[b]- added the MaxTargetRange property to XmlUse attachments that allows you to specify the max allowed distance between the player and the target when using the targeting ability of XmlUse attachments.[/b] Default is 30 tiles.(thanks to Steelcap for the suggestion).

[b]- added the ResetRange property to XmlDialogs that allows dialogs to automatically reset whenever the triggering player moves out of range.[/b]  This means that when you have multiple players waiting to activate a dialog, they wont have to wait until the ResetTime for the dialog expires to trigger it again.  This should improve the apparent responsiveness of dialogs.  The default range is 16 tiles.

[color=red][b][u]New Features[/u][/b][/color]

[color=red][b]New to version 3.22[/b][/color]
updated 8/31/07
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed a crash bug involving invalid XmlDialog reset times[/b] (thanks to Xavier_WER for pointing this out).

[b]- fixed a bug in the SOUND keyword that wasnt allowing it to work properly in XmlDialog Actions.[/b] (thanks to PrinceArda for pointing this out)

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- added some memory optimizations that should reduce save times a bit.[/b]

[b]- added a new 'equippedonly' argument to the GETONCARRIED keyword.[/b]  This allows you to restrict the target carried object to equipped items only.  This upgrades the GETONCARRIED args to match those available to SETONCARRIED.  The new syntax is
[color=blue]GETONCARRIED,itemname[,itemtype][,equippedonly],property[/color]

For example,

GETONCARRIED,*,baseweapon,true,name

would return the name of any equipped weapon on the triggering player.

[b]- added additional journal logging options with the new 'NotifyAddJournalEntry' and 'EchoAddJournalEntry' properties on questholders[/b] (thanks to Syznow for the suggestion).  These work in the same way as the recently added 'AddJournalEntry' property, but will also notify the holder of the quest when the entry is added (or modified) if the 'NotifyAddJournalEntry' property is set instead of the 'AddJournalEntry', and will both notify and echo the entry text if the 'EchoAddJournalEntry' property is used.
For example, the following spawn entry that would add a journal entry to the carried quest and also notify the questholder and echo the text to them

[color=blue]SETONCARRIED,Too many orcs,questholder/echoaddjournalentry/A simple request:You met a young woman named Tess outside of the Sweet Dreams inn. She asked if you could help with a small problem she was having with the growing orc population outside of her house near Britain.[/color]

would echo to the player

Journal entry 'A simple request' has been added to quest 'Too many orcs'.
[color=purple]You met a young woman named Tess outside of the Sweet Dreams inn. She asked if you could help with a small problem she was having with the growing orc population outside of her house near Britain.[/color]

The color of the notification and echoed text can also be configured by adding the following entries to the [XmlSpawner] section of Data/XmlSpawner.cfg .

[color=blue]JournalNotifyColor=0
JournalEchoColor=6[/color]

The numbers are the color values used to display the text.

[color=red][b][u]New Features[/u][/b][/color]
[b]- added a new targeting option to the XmlUse attachment that allows you to create custom use functions that bring up a targeting cursor on double click.[/b]
To enable this feature set the 'TargetingEnabled' property on the attachment to true.
Once this is done, then three additional properties that control targeting behavior become available.
The existing 'SuccessAction' will be performed once the object with the XmlUse attachment is successfully doubleclicked and the target is successfully selected.
When constructing an action, note that GETONTHIS and SETONTHIS will refer to the targeted object.  So for example, a SuccessAction like

SETONTHIS/hue/500

would set the hue of the targeted object to 500.

[u]Properties:[/u]
[color=blue]TargetingAction[/color]
Assign this string to specify custom actions that will be taken when the target cursor is brought up.  The action string can be any spawnable entry string and supports multiple actions separated by semicolons.  

[color=blue]TargetCondition[/color] 
A test string that is the same as any xmlspawner condition test.  It will be tested after an object is selected with the targeting cursor. If it returns true, then the object can be targeted and 'SuccessAction' will be performed.  If it is false, then the 'TargetFailureAction' will be performed.

[color=blue]TargetFailureAction[/color]
This action will be executed when the target selection test in 'TargetCondition' is NOT satisfied.

[b]- added the new 'ITEM,serial' keyword that you can use anywhere that you would normally be able to use loot keywords like TAKEN, or ARMOR to refer to arbitrary items by their serial number.[/b] (thanks to SteelCap for the suggestion)

So, for example, to take an existing item from a nearby container and drop it into a players bankbox you could do something like

[color=blue]SETONCARRIED,,bankbox,equippedonly/ADD/ITEM,{GETONNEARBY,1,,gold,true,serial} [/color]

[b]- added the TakeArms.xml example to xmlextras.zip that demonstrates the use of the new ITEM keyword as well as the new 'equippedonly' argument to GETONCARRIED.[/b]   To test it out, just '[xmlloadhere takearms.xml' and then walk past the spawner while you have a weapon equipped to trigger it.
The spawner will automatically take your equipped weapon and place it in a nearby container.

[b]- added the 'BlockCommand' and 'ChangeCommand' configuration options to Data/XmlSpawner.cfg that allow commands to be blocked, renamed, or be given different accesslevels.[/b]  This allows you to control command access without modifying any scripts. These will work on any commands, not just those added by the xmlspawner system.  These should be added to the [XmlSpawner] section of Data/xmlspawner.cfg
The syntax for the BlockCommand option is

[color=blue]BlockCommand=commandname, commandname, etc.[/color]

The syntax for the ChangeCommand option is

[color=blue]ChangeCommand=oldname:newname[:accesslevel], oldname:newname[:accesslevel], etc.[/color]

If the newname argument is omitted, then the oldname will not be changed.  If the accesslevel argument is omitted, then the accesslevel will not be changed.
Here is an example entry in xmlspawner.cfg

[color=blue]BlockCommand=freeze, freezemap, freezeworld, unfreeze, unfreezemap, unfreezeworld
ChangeCommand=add:a, xmlfind:xf:Administrator, xmlsave::Owner[/color]

This will completely block the freezing and unfreezing commands, rename the 'add' command to 'a', change the 'xmlfind' command to 'xmf' with the accesslevel of Administrator,  and will change the accesslevel of the 'xmlsave' command to Owner. 

[color=red][b]New to version 3.21[/b][/color]
updated 3/15/07
[color=red][b][u]Bug Fixes[/u][/b][/color]
[color=red][b][u]Modified Features[/u][/b][/color]
[b]- restricted the quest journal editing feature to the Owner only.[/b]  This prevents publicly accessible questholders (playerquestboards or placed in the world) from being edited.

[color=red][b][u]New Features[/u][/b][/color]

[color=red][b]New to version 3.21[/b][/color]
updated 3/15/07
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed an issue involving rewards being used directly out of questholders.[/b]  Now, any rewards attached to a questholder such as gold, reagents, charged items, etc. are protected from being accessed by processes that perform recursive searches through a players pack for items (such as spellcasting, and vendors).  For example, this means that gold rewards still attached to a questholder will be viewable, but will not appear in the total gold available to the player, and cannot be used for purchases.

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- added a property test option to the SETONNEARBY keyword that allows you to restrict the objects selected[/b] (thanks to Steelcap for the suggestion).  The new syntax is

[color=blue]SETONNEARBY,range,name[,type][,searchcontainers][,proptest]/prop/value/prop/value...[/color]

So, for example, to set the hue of all nearby creatures with hitpoints of less than 100 to blue you could use something like

[color=blue]SETONNEARBY,10,*,basecreature,false,hits<100/hue/500[/color]

[color=red][b][u]New Features[/u][/b][/color]
[b]- added a Journal feature to questholders that allows a text log to be built that can be accessed from the new 'Journal' tab in the questholder gump.[/b]  Information can be added to the journal by setting the AddJournalEntry property on the questholder to the desired text.  That text will be appended to the running journal log.  The text must be of the form, "EntryID: text", where the EntryID is a unique string label that will be used to identify the journal entry.  Setting the text for a journal entry with the same ID will replace the text for that entry.  To remove a journal entry, just specify an empty text field.
For example, you could add a journal entry to a carried questholder like this

[color=blue]SETONCARRIED,Too many orcs,questholder/addjournalentry/A simple request:You met a young woman named Tess outside of the Sweet Dreams inn.  She asked if you could help with a small problem she was having with the growing orc population outside of her house near Britain.[/color]

or  create a quest with initial journal entries like

[color=blue]questholder/name/Too many orcs/objective1/KILLNAMED,Brakk,orc/addjournalentry/A simple request:You met a young woman named Tess outside of the Sweet Dreams inn.  She asked if you could help with a small problem she was having with the growing orc population outside of her house near Britain.[/color]

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/journal-1.jpg[/IMG]

Entries can also be added and/or modified at any time by using the "Add" button in the gump.

[color=red][b]New to version 3.20[/b][/color]
updated 3/06/07
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed a deserialization problem in the XmlUse attachment that was introduced in v3.19.[/b]

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- disabled spawn entries (lock icon next to entry in spawner gump) are now ignored when determining availability of a subgroup for spawning.[/b]

[b]- added support for console reporting of unrecognized settings during xmlspawner.cfg loading.[/b] The AssignSettings method must now return a bool instead of void.  A true value means successful setting, false means an unsuccessful or unrecognized setting.
[code]
public static bool AssignSettings(string argname, string value)
[/code]

[color=red][b][u]New Features[/u][/b][/color]
[b]- added the "BlockKeyword=keyword[,keyword]..." configuration option to the XmlSpawner section of xmlspawner.cfg to allow selected xmlspawner keywords to be blocked.[/b]  This will disable their use in any context, including spawners, xmldialogs, etc.
For example, to block the use of the BROWSER and SETACCOUNTTAG keywords, add this entry to the [XmlSpawner] section of xmlspawner.cfg

BlockKeyword=BROWSER,SETACCOUNTTAG

[b]- added the new "BROWSER/url" standalone keyword that will open a web browser to the specified url.[/b]  This can be used in a spawner entry on a triggered spawner to open a browser to the triggering player.  It can also be used as an Action in an XmlDialog or an XmlUse attachment.

[b]- added the browser.xml example to xmlextras.zip demonstrating the use of the BROWSER keyword in an XmlUse attachment.[/b] The example creates two signs that will open browsers to the RunUO and XmlSpawnerFan forums when double clicked. To test this out, just do an "[xmlloadhere browser.xml". 

[color=red][b]New to version 3.19[/b][/color]
updated 2/27/07
[color=red][b][u]Bug Fixes[/u][/b][/color]

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- Name tests have been modified to support a special wildcard "*" that will match any name.[/b] (thanks to Kaon for the suggestion)
There are three types of name argument that can be used in tests and keywords

1) standard non-empty name argument (match specific named objects)
2) empty name argument (match only unnamed objects)
3) special * name argument (match objects with any name)

This should work anywhere that a name argument is normally required.
So, for example using a TriggerOnCarried string of

[color=blue]*,heavycrossbow[/color]

would allow triggering when the player was carrying a heavy crossbow regardless of the name.

[b]- added the AllowCarried flag to the XmlUse attachment that toggles the ability to use an item when carried by the player using it.[/b] (true by default).

[color=red][b][u]New Features[/u][/b][/color]
[b]- added support for a new xmlspawner.cfg file in the Data folder of the main RunUO installation.[/b]  This configuration file can be used to specify certain default values without having to modify the settings in xmlspawner scripts themselves.  This can simplify upgrading to new revisions since custom settings can now be specified outside of upgraded scripts and so will be maintained when those scripts are replaced.
If you do not wish to use this configuration feature, you do not have to add an xmlspawner.cfg file.  In that case, the standard system defaults will be used just as they have in the past.  This new feature is completely optional.

Below is an example of a configuration file illustrating the current support for some of the common xmlspawner and xmldialog settings.

Data/xmlspawner.cfg
[QUOTE]
# This is a sample xmlspawner configuration file
# comments can be added anywhere in the file using the # at the beginning of the line
# sections are specified with [section]
# individual setting assignments have the form 'name=value'. Spaces can be placed around the '='
# empty lines are ignored and can be placed anywhere

[XmlSpawner]

XmlSpawnDir=Spawns
DiskAccessLevel=Administrator
SmartSpawnAccessLevel=Administrator
defMinDelay=5
defMaxDelay=10
defHomeRange=5
defSpawnRange=5
defRelativeHome=true

[XmlDialog]

XmlQuestNPCDir=XmlQuestNPC
defProximityRange=3
defResetTime=60
defSpeechPace=10
[/QUOTE]


Other systems can also make use of the configuration file by simply specifying their configuration settings in a custom named section.  These custom sections will have no effect on any other settings in other sections.

For other systems to make use of the configuration file, the following call would be added to their Initialization method which would load in the settings from the named section during initialization.  Individual settings would be processed using the specified custom method.

[CODE]
XmlSpawner.LoadSettings(new XmlSpawner.AssignSettingsHandler(AssignSettings), "XmlDialog");
[/CODE]

where "XmlDialog" would be replaced with a string identifying the section name in the configuration file used to hold the settings for the system.
"AssignSettings" is a custom public static method that would be scripted to process each setting.  An example is shown below from the XmlDialog system.
[CODE]
  public static void AssignSettings(string argname, string value)
  {
  	switch (argname)
  	{
    case "XmlQuestNPCDir":
    	DefsDir = value;
    	break;
    case "defResetTime":
    	defResetTime = TimeSpan.FromSeconds(XmlSpawner.ConvertToInt(value));
    	break;
    case "defProximityRange":
    	defProximityRange = XmlSpawner.ConvertToInt(value);
    	break;
    case "defSpeechPace":
    	defSpeechPace = XmlSpawner.ConvertToInt(value);
    	break;
  	}
  }
[/CODE]

[b]- added the new MEFFECT keyword that allows moving effects to be specified.[/b]  The syntax is

[color=blue]MEFFECT,itemid[,speed][,x,y,z][,x2,y2,z2][/color]

When x,y,z is specified the moving effect will start at the location and move toward the target object.  This syntax must be used as a modifier of a spawned object.  If x,y,z is omitted, then the starting location will be the location of the spawner.

For example, to have an fireball move from the spawner location to a triggering player,

[color=blue]SETONTRIGMOB/MEFFECT,14036,3[/color]

To have it move from a specified location such as (1500,1100,10) to the triggering player

[color=blue]SETONTRIGMOB/MEFFECT,14036,3,1500,1100,10[/color]

Note that the z coordinate should be above ground level to avoid the appearance of ground clipping.

When x2,y2,z2 is also specified the moving effect will start at x,y,z and end at x2,y2,z2 allowing the effect to move between two arbirary locations in the world.  This syntax can be used as a standalone keyword. For example the following entry would create a fireball travelling between the two locations.

[color=blue]MEFFECT,14036,3,1500,1100,10,1520,1120,10[/color]

[color=red][b]New to version 3.18[/b][/color]
updated 1/13/07
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed a possible exploit with the TAKE keyword in which players could hold an item on the cursor and prevent the item from being taken[/b] (thanks to DazedAndConfused for pointing this out).

[b]- fixed a possible crash when using the SET keyword with no args in an XmlDialog Action field[/b] (thanks to morganm for pointing this out).

[b]- fixed a display bug with the 'search for type' button in the spawner gump (little arrow to the right of the spawn entry) not listing all type categories.[/b] (thanks to Irian for the fix).

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- added a new installation step (STEP #13) to the "installation 2.0.txt" file that includes a small mod to lootpack.cs that is required for the LOOTPACK keyword to function under RunUO 2.0[/b] (thanks to snicker7 for pointing this out).

[b]- modified the XmlDeathAction attachment to support multiple actions in a single Action specification.[/b]  Just separate the multiple actions with semicolons.

[color=red][b][u]New Features[/u][/b][/color]
[b]- added the 'GETONNEARBY,range,name[,type][,searchcontainers],property' keyword that can be used to get or test properties on nearby items or mobiles[/b].  This can be used in property assignments or property tests.  If more than one of the specified object is found, it will only return the value from one.

For example, to test to see if someone has placed the longsword named "Grizzleblag" on the ground near the spawner you could use a condition test like

[color=blue]GETONNEARBY,1,Grizzleblag,longsword,visible=true[/color]

Or you could get the size of a pile of gold in a nearby container with

[color=blue]SENDMSG/{GETONNEARBY,1,,gold,true,amount} gold pieces are in the container[/color]

[b]- added the new standalone keyword 'SETONPETS,range' that allows you to set properties on nearby pets belonging to the triggering mob[/b] where the range is the distance from the triggering mob.  You would use it like

[color=blue]SETONPETS,range/prop/value/prop/value... [/color]

[b]- added the new 'GETACCOUNTTAG,tagname' keyword that allows access to account tags on the triggering player[/b]  (thanks to CEO for the suggestion). This can be used in value assignments or property tests.  For example, if you wanted to test for an account tag before handing out a quest, you could use a Condition test like

[color=blue]GETACCOUNTTAG,quest1="done"[/color]

where 'quest1' would be the account tag name, and "done" would be the value of the tag, or

[color=blue]SENDMSG/I see that you already have {GETACCOUNTTAG,numRewardsChosen} veteran rewards.[/color]

where 'numRewardsChosen' is the account tag used to keep track of vet rewards.

[b]- added the new 'SETACCOUNTTAG,tagname/value' keyword that allows you to create or change the value of account tags on the triggering player.[/b]  For example, to create an account tag named 'quest1' with the value 'done' use a spawn entry like

[color=blue]SETACCOUNTTAG,quest1/done[/color]

[color=red][b]New to version 3.17[/b][/color]
updated 11/29/06
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- fixed a bug in which assigning an extremely large expiration time to questholders could cause a crash[/b] (thanks to koluch for pointing this out). Expiration times are now capped at 100 years. This is a particular issue for playermade quests, since it is possible for players to enter such extreme expiration times.

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- modified smartspawning so that mobs that are below maximum hits, stamina, or mana will not be despawned[/b] (thanks to Kamuflaro for the suggestion). The previous test only looked at hits.

[b]- the LOOT,methodname keyword will now work with Loot methods that have multiple overloads of the sort added in RunUO 2.0.[/b]  It will still refer to the zero-arg method in those cases. (thanks to Cheetah2003 for the suggestion).

[b]- extended existing support for accessing Array type properties to all other IList types, including Arrays, ArrayLists, and Lists.[/b]  For example, to get the name of the first attacker on a mobiles aggressors list you could use

[color=blue][xmlget aggressors[0].attacker.name[/color]

where aggressors is a List type property on mobiles, and attacker.name is a property on one of the elements in the list. 
The same syntax can be used to refer to such properties in spawner entries and property tests. 

[b]- the XmlLifeDrain attachment now gives a message and adds effects just like the default succubus life drain attack.[/b]

[color=red][b][u]New Features[/u][/b][/color]
[b]- enabled attachment support for "using" objects that allows you to add custom double-click functionality to any object, even statics and mobiles. [/b]  
If you dont want to use this feature you can disable it by going into PacketHandlerOverrides.cs and commenting out the line in red as shown  below

[QUOTE]
            // this replaces the default packet handler for Use requests.  Items and Mobiles will still 
            // behave exactly the same way, it simply adds a hook in to call the OnUse method for attachments
            // they might have.
            [color=red]//Timer.DelayCall( TimeSpan.Zero, new TimerCallback( UseReqOverride ) );[/color]
[/QUOTE]

With this feature enabled the following overridable methods are available to all attachments
[CODE]
  public virtual void OnUse(Mobile from)
  {
  }
[/CODE]
which will be called whenever the object that the attachment is attached to is used (e.g. double clicked). The 'from' argument is the person doing the using.
[CODE]
  public virtual void OnUser(object target)
  {
  }
[/CODE]
When you add an attachment to a player, this method will be called whenever the player "uses" things.  The 'target' argument is the thing being used.

Note that the attachment system OnUse and OnUser methods dont replace the default RunUO OnUse method, they are called in addition to any OnUse support that a target object might have, so if an object has support for OnUse in its script, it will still be called.
If you want attachments to ignore the default RunUO OnUse call, you can override the following method in your attachments and have it return true:
[CODE]
        public virtual bool BlockDefaultOnUse(Mobile from, object target)
        {
            return false;
        }
[/CODE]

[b]- added the new XmlUse attachment that allows you to control the use of any object.[/b]  By adding this attachment to any object you can specify the conditions required to use the object as well as add new use functions to the object that will be executed on double clicks.  

[u]Properties:[/u]
[color=blue]Condition[/color] 
A test string that is the same as any xmlspawner condition test.  It will be tested whenever the object with the attachment is used (double clicked). If it returns true, then the object can be used. This can be used to control the built-in use functions of an object or the custom use functions that you add on the fly.

[color=blue]MaxUses[/color]
An integer value that restricts the maximum number of uses allowed. (default = unlimited)

[color=blue]Refractory[/color]
An integer that restricts the minimum time in seconds between uses. (default = 0)

[color=blue]MaxRange[/color]
An integer that restricts the maximum distance in tiles allowed from the target object (default = 3)

[color=blue]RequireLOS[/color]
A bool that determines whether line-of-sight between the user and the object is required (default = false)

[color=blue]SuccessAction[/color]
Assign this string to specify custom actions (in addition to the default OnUse functionality) that will be taken when the conditions for use of the object are met.  The action string can be any spawnable entry string and supports multiple actions separated by semicolons.

[color=blue]FailureAction[/color]
This action will be executed when the conditions for use of the object are NOT met.

[color=blue]MaxUsesAction [/color]
This action will be executed when someone tries to use the object after the max uses has been exceeded.

[color=blue]RefractoryAction [/color]
This action will be executed when someone tries to use the object before the refractory period is over.

[color=blue]BlockDefaultUse [/color]
Setting this property to true will allow you to completely disable the default scripted RunUO method called when the object is used.  This can be used to replace existing default use functions with your custom use actions.

[u]Constructors:[/u]

        public XmlUse()

        public XmlUse(int maxuses)

        public XmlUse(int maxuses, double refractory)

[u]Examples:[/u]

For example, to make any object usable only once, just issue this command and target the object

[color=blue][addatt xmluse 1[/color]

Note that you can always just remove the attachment and the object will go back to its default behavior.  The attachment makes no changes to the object.

To spawn a metal box that can only be opened 3 times with a minimum delay of 10 seconds between openings and delivers a message if someone tries to use it more than the maximum number of times use a spawn entry like

[color=blue]metalbox/ATTACH/<xmluse,3,10/maxusesaction/@SENDMSG/Max uses exceeded.>[/color]

To spawn a stone static that pops open a gump when double clicked

[color=blue]static,3796/ATTACH/<xmluse/successaction/@GUMP,Wicked woods,0/Enter here and despair!>[/color]

you could also add this manually to any existing static by simply adding the attachment with

[color=blue][addatt xmluse [/color]

and then opening up the props on the attachment with

[color=blue][getatt[/color]

and assigning the [color=blue]SuccessAction [/color]property the value of "GUMP,Wicked woods,0/Enter here and despair!"

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/dclick1.jpg[/IMG]

To spawn a door that can only be opened by players named "Bob"

[color=blue]metaldoor,1/ATTACH/<xmluse/condition/@GETONTRIGMOB,name="Bob">[/color]

or by players that havent yet completed an objective of a quest

[color=blue]metaldoor,1/ATTACH/<xmluse/condition/@GETONCARRIED,Bunglers quest,questholder,completed1=false>[/color]

To prevent a player from using any metal doors for 2 minutes, create a triggered spawner that will add an xmluse attachment to the player lasting 2 minutes with the following entry

[color=blue]SETONTRIGMOB/ATTACH/<xmluse/expiration/00:02/condition/@GETONTHIS,TYPE!#MetalDoor>[/color]

Note that GETONTRIGMOB will always refer to the player doing the using, and GETONTHIS will always refer to the object being used.

[b]- added an example of the new XmlUse attachment in customuse.xml.[/b]  Just do an "[xmlloadhere customuse.xml" and respawn it.
[u]Examples:[/u]
1. Creates a metalbox that can only be opened by someone with positive karma, and after opening it sends a message, opens a gump, and changes the players karma to evil.  If someone with negative karma tries to open it, they are refused and a gump pops up.

2. Creates a door that can only be opened by someone with enough strength (>70).  If a player is too weak, they will be blocked and a gump will be displayed.

3. Spawns a horse that can only be mounted by someone with high enough chivalry (>90).  If a player lacking the skill attempts to use it, they will be blocked and a message will be displayed.

4. Creates a brazier that will spawn a daemon when double clicked if the player has enough fame (>1000).  

5. Spawns a stone that will deliver a bag of regs when double-clicked with a waiting time between uses of 10 seconds.

6. Creates a magic portal that teleports the user to a site in Ilshenar when double clicked.

Note that examples 4,5, and 6 are done using simple statics that have no default use scripted.

[color=red][b]New to version 3.16[/b][/color]
updated 9/7/06
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- disabled the SpawnIdleTime feature that wasnt working properly under RunUO 2.0[/b] (thanks to Allmight for pointing this out). This feature was designed to reposition spawns that had been around for more than the SpawnIdleTime (72 hours by default) under the assumption that they might not be accessible for players to kill.  Under RunUO 2.0, after the SpawnIdleTime elapsed, spawns were being repositioned on every spawner tick due to changes in the Mobile class CreationTime property.

[b]- fixed the XmlDeathAction attachment so that Action strings that spawn mobiles with property settings will apply those settings to the mobile and not the corpse that spawned it.[/b] So adding an attachment like
"[addatt xmldeathaction "daemon/name/bozo/hue/500" will correctly spawn a blue daemon named bozo when the creature with the attachment is killed.

[b]- fixed [xmlfind so that searches on partial string matches of spawner entries works again.[/b]

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- modified the new BCAST keyword options to allow a unicode font to be specified with a font type of -1.[/b]   So to specify colored unicode broadcast messages, use
[color=blue]BCAST,33,-1/System is going down now[/color]
The default font was also changed from ascii back to the unicode style, so
[color=blue]BCAST/Blorgmeister has been killed[/color]
would broadcast in default white unicode.

[b]- default spawn placement will now automatically take into consideration the CanSwim and CantWalk mobile properties when calculating valid spawn locations.[/b]  This will allow water creatures to automatically be allowed to spawn on water without having to explictly inform the spawner with '*' or #WET, and will prevent creatures that cant walk from being spawned on land.

[b]- slight change to the DAMAGE keyword to allow a range value of 0.[/b] Previously range had to be greater than zero.

[b]- added keyring keys to the list of valid internal map items that are excluded in [xmlfind when the 'Hide valid internal' box is checked[/b] (thanks to Kamuflaro for pointing this out).

[color=red][b][u]New Features[/u][/b][/color]
[b]- added the ability to adjust the spawner timer priority for individual spawners so that you can have things like sequentialspawn-controlled animation running at up to the maximum timer priority.[/b]
One limitation of the current sequential spawning is that the minimum spawner clock tick is 1 second, even if you set min/maxdelay to zero.  That is because the spawner timer priority is fixed at 1 second. To change this priority for individual spawners, set the BasePriority property on the spawner to one of these values (or their int equivalents)

	public enum TimerPriority
	{
		EveryTick,
		TenMS,
		TwentyFiveMS,
		FiftyMS,
		TwoFiftyMS,
		OneSecond,
		FiveSeconds,
		OneMinute
	}

That will define the spawner timer interval when min/maxdelay is set to zero.

To prevent accidentally leaving spawners with modified timer priorities, the BasePriority is reset back to the default of one second on server restarts.  I havent decided whether to allow this to be serialized and restored on restarts.

[b]- included an example of the use of modified timer priority in boulder.xml[/b] which creates an animated boulder moving across the screen triggered by nearby players, and if it detects a collision with the triggering player then it kills them (thanks to Xerrox for the idea).
You can play around with changing the basepriority setting in the spawner entry to see how it changes the animation speed.


[color=red][b]New to version 3.15[/b][/color]
updated 8/28/06
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- modified the [WriteMulti command to support staff names that have spaces in them when accessing files[/b] (thanks to Xavier_WER for the suggestion).

[b]- fixed a problem that was introduced in v3.14 with the addition of ISpawner support in which [xmlhome would not be able to find the home spawner of a creature after a restart.[/b] I had incorrectly assumed that the Spawner information on items/mobiles was being serialized and it isnt.  Now initialization code has been added to restore Spawner information after restarts.

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- modified XmlSpawnerGumps.cs to accomodate changes to Gump handling introduced in SVN rev 78 of the RunUO server.[/b]  This should allow you to compile with the latest version of the server and should also work with pre-78 servers.

[b]- custom regions that get registered after initialization will now be detected and can be used by region spawners.[/b]

[b]- added support for assigning a mobile used to allow spawners to issue commands using the "COMMAND/commandstring" keyword[/b]  by assigning the name of the mobile in the static CommandMobileName variable at line 341 in basexmlspawner.cs.  
Commands in RunUO are required to have a mobile associated with their execution to allow accesslevel verification. This mobile will be used to issue all commands executed with the COMMAND keyword.  The accesslevel of the mobile will determine the commands that can be issued.

This mobile can be a dummy character/creature that was created just for this purpose, or an existing character.
The commandstring is any string that you would normally type on the command line (without the command prefix).

[CODE]
        private static string CommandMobileName = null;
[/CODE]

If the value is left null, then the COMMAND keyword will only work with triggered spawners when the triggering player has sufficient accesslevel to issue the command.

[b]- modified random subgroup spawning.[/b]  Subgroups that cannot be completely spawned will not be selected for random spawning.  All spawn entries in the subgroup have to be below their individual maxcount, and fully spawning the subgroup cannot exceed the overall spawner maxcount. Previously those subgroups would simply spawn the entries of the subgroup that could be spawned.
This will apply to both random and sequential spawning but note that forced subgroup spawning, as part of a conditional statement, for example, will still allow partial spawning of the target subgroup.


[color=red][b][u]New Features[/u][/b][/color]
[b]- added the new #NOTILES,startid[,endid] spawn control keyword.[/b]  This is similar to the #TILES keyword, but it allows you to specify the land/static tiles that the spawns for an entry will NOT be placed on.  Only passable tiles that are not on the #NOTILES list will be used for spawn placement.

The example below has 2 spawn entries. 
The first entry uses the #NOTILES keyword to specify that the orcs should NOT be spawned on grass tiles with ids of 3.  Note that the lava tiles are not passable and so the orcs are placed on dirt, which is the only passable, non-grass tile around. 
The second entry uses the #TILES keyword to place the lavalizards on the lava tiles.  
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/notilespawn1.jpg[/IMG]

[b]- added an optional 'equippedonly' argument to the existing SETONCARRIED keyword that would allows access things like a players bankbox.[/b]  The new syntax is
[color=blue]SETONCARRIED,itemname[,itemtype][,equippedonly]/prop/value/prop2/value...[/color]
where specifying 'true' or 'equippedonly' for the equipped only arg will only look at items that are directly equipped on the mobile, and that would include bankboxes.
So to add something to a players bankbox you would do
[color=blue]SETONCARRIED,,bankbox,equippedonly/ADD/gold,500[/color]

[b]- added the new KILL keyword that can be used to kill mobiles.[/b]  For example, the spawn entry
[color=blue]SETONTRIGMOB/KILL[/color]
would kill the triggering mob, or
[color=blue]SETONNEARBY,5,,rat/KILL[/color]
would kill all of the rats within 5 tiles

[b]- added optional args for specifying hue and font in the BCAST keyword[/b] (thanks to Xavier_WER for the suggestion). The new syntax is
[color=blue]BCAST[,hue][,font]/message[/color]
Note that this uses the same hues and fonts as the SENDASCIIMSG and ASCIIMSG keywords,
[color=blue]SENDASCIIMSG[,probability][,hue][,font]/message text[/color]
[color=blue]ASCIIMSG[,probability][,hue][,font]/text[/color]
so you can use them to test out various text/color combinations without having to actually broadcast to see what it looks like.
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/bcast1.jpg[/IMG]

[color=red][b]New to version 3.14
updated 8/13/06
[/b][/color]
[color=red][b][u]Bug Fixes[/u][/b][/color]
[b]- modified the spawner Reset function to properly reset the refractory period for triggered spawners if that was set[/b] (thanks to Vladimir for pointing that out).

[b]- fixed a possible crash bug with the playermade questholder editing gump[/b] (thanks to Auriel for pointing it out).

[b]- fixed a problem with MinD, MaxD, or Rng values for individual spawn entries being inappropriately cleared when editing an entry string with the text entry book.[/b]

[b]- modified the ASCIIMSG keyword to deal with text sometimes not being visible to all nearby players[/b] (thanks to aph for pointing this out).  

[b]- modified the way xmlspawners keep themselves from being included in container item counts to fix an issue with negative counts under RunUO 2.0[/b] (thanks to haazen for pointing this out).

[b]- fixed a crash bug with xmlfind when using an invalid region[/b] (thanks to seirge for pointing this out).

[b]- fixed a possible crash bug with improperly formatted TriggerOnCarried strings[/b] (thanks to XavierWER for pointing this out).

[b]- fixed a problem with the Repeatable flag on quests not being restored across restarts when set to false[/b] (thanks to Vladimir for pointing this out). This led to people sometimes being able to repeat non-repeatable quests.

[color=red][b][u]Modified Features[/u][/b][/color]
[b]- made the SENDMSG and SENDASCIIMSG keywords usable as value type keywords and not just standalone keywords[/b]. so you can do things like

[color=blue]SETONNEARBY,5,,playermobile/SENDMSG/Greetings friends[/color]

to send messages to all nearby players (thanks to snicker7 for the suggestion).

The syntax for these keywords is

SENDMSG[,probability][,hue]/message text
SENDASCIIMSG[,probability][,hue][,font]/message text

[b]- modified questholders to prevent snooping by other players, but allow staff to open the questholder status gump from questholders being carried by players[/b] (thanks to snicker7 for the suggestion).

[b]- modified the way that the DAMAGE and POISON keywords work when used as value keywords.[/b]
Now, if they are used to modify a spawn object, then their effects will be applied to the spawn object, and if a range argument is used, then things within that range from the spawn object will be affected. (thanks to aph for the suggestion)
For example this spawn entry would apply damage to all players within 5 tiles of the mob named "Blather"

[color=blue]SETONMOB,Blather/DAMAGE,50,20,20,20,20,20,5,playeronly[/color]

Their behavior when used as standalone keywords was not changed.

[b]- added protection against creating infinitely looping sequential spawn definitions.[/b]  Spawn entries can now only be executed once per spawner tick.

[color=red][b][u]New Features[/u][/b][/color]
[b]-added the new standalone keyword "SPAWN[,spawnername],subgroup" which can be used to force spawning of a particular subgroup on a particular spawner.[/b]  If the spawnername arg is omitted, then the current spawner will be used.

[b]- added a TYPE property keyword that returns the object class type.[/b]  For example "GETONTRIGMOB,TYPE" would return the type of the triggering mob.

[b]- added support for the core ISpawner interface.[/b]  This now means that all items/mobiles keep track of the xmlspawner that created them through their Spawner property.
Deleted/killed spawns are now immediately removed from the spawned list instead of having to wait until the next spawner tick.  When monitoring kills, this means that the spawner killcount will be updated as soon as the kills occur.

[b]- added the new #WET and #TILES,startid[,endid] spawn control keywords.[/b]  These allow you to restrict the land/static tiles that the spawns for an entry will be placed on.  This works for both normal and regional spawning. [u]Only tiles that have been frozen into the map will be checked.[/u]  It will not check for static items or multis that have simply been placed in the world.
Use of either of these keywords will automatically ignore surface restrictions during spawn placement (like using * in front of the entry).
You can determine the id of a tile by simply doing a [props on it and looking at the TileID for land targets, and ItemID for static targets. You to specify a single tile or a range of tiles to be included.
The example below has 5 spawn entries. 
The first uses the #WET keyword to specify that the waterelemental spawns should only be placed on tiles that have the Wet tiledata flag set (water tiles).  
The second entry uses the #TILES keyword to specify that the orcs should only be spawned on dirt tiles with ids between 113-120.  
The third entry has trolls that are only spawned on a variety of grass tiles.  
The dolphins spawn only on water tiles with an id of 6044.  
The fifth entry spawns eagles on tree tiles with id 3296.

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/tilespawn3.jpg[/IMG]


[color=red][b]New to version 3.13[/b]
updated 7/6/06
[/color]
[b]- added support for the new WalkingRange property when importing/exporting RunUO 2.0 distro spawners.[/b]

[b]- I forgot to add the updated XmlSpawnerGumps.cs script into the last update that fixed problems with the main gump not being refreshed when using the text entry book or the add item/mobiles gump.  Now it is included.[/b]

[b]- added in a conditional compilation flag to suppport people using the original RunUO 2.0 RC1 release instead of the latest SVN.[/b]  If you are using RC1 uncomment the following line at the beginning of XmlSpawner2.cs.  If you are using the most recent SVN then just leave this line commented out at the beginning of XmlSpawner2.cs

[color=blue]//#define RUNUO2RC1[/color]

[b]- added the option to make addons created with the MULTIADDON keyword partially visible with the new PartialVisibility property[/b] (thanks to Lara for the idea).  By setting this property to a percentage between 1-100, it will make that fraction of the addon components visible.   An example of this is given in becomevisible.xml.

[b]- added the '[WhatIsIt' command that will report the type and name of the target.[/b]  This can be used by players or staff to provide information needed to set up quest objectives or any other situation where knowing the type and name of an object is needed. (thanks to Lara for the suggestion).

[b]- fixed a possible crash bug when using '[xmlsave'[/b]

[b]- fixed a problem with skill triggering not recognizing min/max skill value limits when combined with the '+' or '-' arguments for skill use success/failure[/b] (thanks to Lara for pointing this out).

[b]- fixed a problem with old spawner names not being restored after restarts.[/b]

[b]- fixed a bug with COLLECTNAMED objectives not being displayed properly in the quest status gump.[/b] (thanks to Discord for pointing that out).

[b]- fixed a problem with the [xmladd gump not refreshing properly after adding a spawner or adding a spawn entry from item/mobile selection gump.[/b] For example, it would reset the AutoNumbering checkbox after placing a spawner.

[b]- changed the default smartspawning activation level from Administrator to Owner and added a test to allow any unhidden staff, regardless of accesslevel to activate smartspawned spawners.[/b]  This means that by default, all players and staff will activate smartspawned spawners.  If you change the default level to Player by changing the setting of the SmartSpawnAccessLevel variable at line 100 of in xmlspawner2.cs to something like

[CODE]
  // specifies the level at which smartspawning will be triggered.  Players with AccessLevel above this will not trigger smartspawning unless unhidden.
  public static AccessLevel SmartSpawnAccessLevel = AccessLevel.Player;
[/CODE]

then only players and unhidden staff will activate them, but hidden staff will not (thanks to Erica for the suggestion).

[color=red][b]New to version 3.12[/b]
updated 6/19/06
[/color]
[b]- installation instructions for RunUO 2.0 have been added to xmlspawner2-20-v312-1of3.zip.[/b]

[b]- fixed a problem with the main gump not refreshing after editing textentrybooks or when seleting spawns from the addcategorizedobject gump.[/b]

[b]- added support for Nerun's new .map format in [xmlimportmap.[/b] The [xmlimportmap command will automatically detect new and old formats and import accordingly.  You can even import old and new formats at the same time.

[b]- fixed a problem with the TAKE and TAKEBYTYPE keywords not taking the correct amount from stacked items due to the change in the way RunUO 2.0 handles duping.[/b]

[b]- changed an argument to the OnArmorHit method used by some attachments for RunUO 2.0 compatibility.[/b]  This will affect some addons like the CustomAttacks/Defenses system which will be updated with this change as well.

[color=red][b]New to version 3.11[/b]
updated 6/14/06
[/color]
[b]- added support for proximity triggering by non-player npcs.[/b] Setting the new AllowNPCTrig property on the spawner to true will allow it to be triggered by both players and non-player npcs.
NPC proximity triggering is configured the same as regular player proximity triggering by setting the ProximityRange and the other optional triggering controls such as SpawnOnTrigger or even things like SpeechTrigger (when used with xmlquestnpcs that can generate actual speech), or the PlayerTrigProp property to test for properties on the triggering npc just as it used to for players.

[b]- a small change to the XmlDialog attachment that allows it to be reset by setting the DoReset property via an Action field in XmlDialog entries[/b] (thanks to Vladimir for the idea).  This allows the use of an action such as

SETONTHIS/doreset/true

to allow the xmldialog to become immediately available for reactivation without having to wait for it to timeout from the last player.

[b]- added a new IgnoreCarried flag to xmldialog entries that will allow them to ignore the Trigger/NoTriggerOnCarried settings that normally control their activation[/b]  (thanks to Vladimir for the idea). Previously, if the Trigger/NoTriggerOnCarried fields were set then all speech-dependent entries required that condition to be satisfied before they could be activated. In the [xmledit gump, the flag can be toggled by checking the new IgnoreCar box.

This will allow you to set up entries that you want to keep separate from the main triggering conditions.


[b]- added a check to xmldialogs to prevent assigning invalid speechhue values (greater than 37852) that could cause client crashes.[/b]

[b]- added the new spawn position control keywords #DXY,dx,dy[,dz] and #XY,x,y[,z].[/b]

#DXY will place the spawn at the specified delta xy coordinates relative to the spawner location.
#XY will place the spawn at the specified absolute xy coordinates.

For example, the spawn entries
[color=blue]
#DXY,2,3 ; orc
#XY,5441,1700 ; troll
[/color]
would spawn an orc at a location relative to the spawner and a troll at an absolute location.

[b]- fixed a problem in referring to mobile or item type properties when assigning other mobile or item type properties.[/b]  Mobile or Item type properties that return the name as well as the serial numbers of the target were not being properly parsed that caused examples like masterhelper.xml not to work.  So spawn entries like

[color=blue]SETONSPAWN,1/combatant/GETONSPAWN,2,combatant[/color]

will now work properly.

[b]- added the ability for [xmlfind to search spawners based on the type of objects being spawned and not just the spawner entry string itself.[/b] By specifying the search type as either 'xmlspawner'  or 'spawner' and checking the new 'type' checkbox next to the 'entry' field, the entry string will be treated as the type of the spawn entry to be found instead of just a string to be matched against the spawn entry.
With both the entry and type boxes checked, the search will find all spawners that contain entries that are of the the specified type.  So to find all spawners with vendors on them, specify an entry field of 'basevendor'.  
This will work for both xmlspawners and regular distro spawners.

finding all spawners with baseweapon type spawn entries
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/xmlfindtype2.jpg[/IMG]

[b]- fixed a possible [xmlfind search results gump display synchronization problem.[/b] This may have produced garbled text or lost client connections when displaying search results under certain conditions. (thanks to LowCastle and CEO for pointing this out).

[b]- added a new attachment called XmlDeathAction.  This attachment, when applied to a creature allows any spawnable action to be performed on the creatures death.[/b] (thanks to Syntria for the idea).  This could include sending the killer a gump or a message, adding items to the corpse, spawning another creature, etc. (the killer is considered to be the trigger mob in these actions).
An example of these applications is included in deathaction.xml in xmlextras.zip.  Just "[xmlloadhere deathaction.xml" and start killing the creatures to see what happens.
For example, with this spawn entry

[color=blue]harpy/ATTACH/<xmldeathaction/action/@GUMP,Harpy be gone,0/Congratulations! You killed a harpy.[/color]

killing the harpy gives you this
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/harpykill.jpg[/IMG]

You must perform xmlspawner installation step #2 for this attachment to work.

[b]- added the XmlAddTithing attachment which is just like the XmlAddFame, or XmlAddKarma attachments but for tithing points.[/b]

[b]- fixed a problem with TalkingBaseEscortable destinations that were not being properly restored after server restarts[/b] (thanks to EtraDor for pointing this out).

[b]- added the 'stafflevel' property of the staffcloak (or any other item) to the protected property list that blocks any attempt to set it via xmlspawner to prevent possible exploits[/b] (thanks to snicker7 for pointing that out).

[b]- spawn entry strings displayed in the properties list on mouseover of the spawner crystal are now truncated at 20 chars.[/b] This improves the appearance and avoids any problems the client might have trying to display extremely long spawn entries.

[color=red][b]New to version 3.10[/b]
updated 5/18/06
[/color]
[b]- added the "#RELXY,xinc,yinc[,zinc]" spawn positioning control keyword.[/b]
This will position the spawn relative to the previously placed spawn by the amount xinc,yinc.  

[b]- added the ability to specify multiple spawn control keywords in a single entry by separating them with semicolons.[/b]  This also adds the requirement that all # spawn control keywords be separated from the main spawn entry with a semicolon and not just white space.

[b]- added FastestPlayerSpeed and MovingPlayerCount properties that can be tested for on the spawner that will report the maximum movement speed and number of nearby moving players.[/b]  Proximity detection must be enabled on the spawner by setting ProximityRange in order to make use of these properties.

[b]- added the "#CONDITION,proptest" spawn control keyword that allows individual entries to be made conditional on the specified property test.[/b]
When combined with the new FastestPlayerSpeed and MovingPlayerCount properties, you can make spawn entries that will depend on the speed and number of nearby players with entries like

[color=blue]#CONDITION,movingplayercount<2 ; orc[/color]

which would only spawn the orc if fewer than 2 players were moving nearby.

[color=blue]#CONDITION,fastestplayerspeed>5 ; #PLAYER,3 ; orc[/color]

Which would only spawn the orcs if some player was moving faster than 5 tiles per second and would additionally have the orcs placed within 3 tiles of the triggering player when they are spawned.

You can use the same kind of condition tests that can be used anywhere else, such as compound tests or tests for properties on carried items, or triggering players, etc.  For example,

[color=blue]#CONDITION,GETONTRIGMOB,skills.magery.value>100 ; lichlord[/color]

would only spawn the lichlord if the triggering player had magery greater than 100.

[b]- added an example of this in SpeedKills.xml to xmlextras.zip[/b].  Just do an "[xmlloadhere speedkills.xml". If a player creeps slowly past the spawner, they can avoid triggering any spawns.  If they walk past the spawner, it will trigger 3 orcs around them.  If the player runs past at medium speed, they will spawn 2 trolls.  If they run at maximum speed, they will spawn a titan. (thanks to Sunshine for the idea).

[b]- allow the use of empty attachment names when referring to attachment properties using the GET series of keywords with "[ATTACHMENT,type,name,property]",[/b] This will ignore the attachment name when finding the attachment as in "GETONTRIGMOB,[ATTACHMENT,xmlquestpoints,,points]"

[b]- enable the use of the EQUIP and ADD keywords with mobs that do not have packs by default.[/b]  If these keywords are used on mobs that dont have backpacks to begin with, then they will automatically be given a pack.

[b]- added the ability to access container contents in the SETONNEARBY keyword with the new 'searchcontainers' argument.[/b]  The new syntax is

[color=blue]SETONNEARBY,range,name[,type][,searchcontainers]/prop/value/prop/value...[/color]

where searchcontainers is a flag set to true or false (default is false).  This will only access containers that are placed in the world, not containers carried by mobiles.  If searchcontainers is set, then only items in containers will be included.

So, to delete all ginseng found in containers within 5 tiles of the spawner but not on the ground, you could use the spawn entry

[color=blue]SETONNEARBY,5,,ginseng,true/DELETE[/color]

Without the searchcontainers argument, or setting it to false it would delete all ginseng on the ground within 5 tiles of the spawner but not in containers.

An example of the use of this for filling and deleting contents of nearby boxes can be found in the nearbyboxes.xml example in xmlextras.zip (thanks to snicker7 for the idea).

[color=red][b]New to version 3.09a[/b]
updated 5/8/06
[/color]
[b]- added two new spawn position control keywords, #PLAYER, and #WAYPOINT.[/b]

[color=blue]#PLAYER[,range][/color] - places the spawns around the triggering player.

[color=blue]#WAYPOINT,prefix[,range][/color] - places the spawn at the location of randomly selected waypoint runes that start with the given prefix.

spawn a group of orcs within 2 tiles of the triggering player.
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/player.jpg[/IMG]

place spawns at the randomly selected named waypoints 
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/waydemo.jpg[/IMG]

[b]- added an additional optional argument to the #XFILL, #YFILL, and #EDGE position control keywords that allows an increment value to be specified that will be added to each subsequent position value instead of the default of 1.[/b]
Different values give some interesting fill patterns.
[color=blue]
#XFILL[,inc]
#YFILL[,inc]
#EDGE[,inc]
[/color]
[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/edge4.jpg[/IMG]

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/orcfilljpg.jpg[/IMG]

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/xfill4.jpg[/IMG]

[b]- fixed a problem displaying entries with the new control keywords in the properties list during mouseover of the spawner crystal.[/b]

New to version 3.09
updated 5/7/06
[b]- fixed a possible crash bug involving certain invalid quest objective strings.[/b] (thanks to LowCastle for pointing this out)

[b]- fixed a parsing problem with extended compound conditional tests in the TriggerOnCarried or NoTriggerOnCarried strings.[/b] (thanks to Corbomite for pointing this out)

[b]- added support for exporting custom houses using [WriteMulti command.[/b]

[b]- added support for specifying an empty escortable name in the ESCORT quest objective.[/b] (thanks to Zyle for the suggestion)  The new syntax makes the mobname optional
 
ESCORT[,mobname][,proptest]

So using an objective string like

[color=blue]ESCORT[/color]

will allow you to satisfy the objective by escorting any talkingbaseescortable regardless of their name.

[b]- added the ANIMATE,action[,framecount][,repeatcount][,forward true/false][,repeat true/false][delay] keyword to add animations to any mobile.[/b]  
For example,

[color=blue]SETONTRIGMOB/ANIMATE,32,5,1,true,false,0[/color]

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

[color=blue]SETONTHIS/ANIMATE,32,5,1,true,false,0[/color]

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/greetings.jpg[/IMG]

[b]- added the XmlFreeze[,seconds] attachment that allows you to permanently or temporarily freeze a mobile in place.[/b]  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.

[color=blue]orc/ATTACH/xmlfreeze,10[/color]

would spawn the orc frozen for 10 seconds.

[color=blue]SETONTRIGMOB/ATTACH/xmlfreeze,10/MSG/You are frozen with fear![/color]

would freeze the triggering player for 10 seconds and send them a message.

[b]- added the ability to control the spawn positioning algorithm used for individual spawn entries.[/b]  By default, spawn location is randomly selected from within the spawning area defined by SpawnRange or X1Y1 X2Y2.
By adding one of the following control keywords to the beginning of the entry, several new positioning methods can be used. 

[color=blue]#XFILL[/color] will add spawns by filling the spawn area progressively in rows of X.
[color=blue]#YFILL[/color] will add spawns by filling the spawn area in rows of Y.
[color=blue]#EDGE[/color] will add spawns only around the edge of the spawn area.

These can be used to systematically fill spawning areas, when random positioning is not desired.
For example, using the following spawn entry

[color=blue]#EDGE static,89[/color]

would spawn the specified statics only around the perimeter of the spawing area.

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/edge.jpg[/IMG]

[color=blue]#XFILL static,82[/color]

would fill the spawning area with the given static (depending on the entry maxcount).

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/fill.jpg[/IMG]

[color=blue]#YFILL orc[/color]

does the same thing, but fills first along Y instead of X.

[IMG]http://i35.photobucket.com/albums/d174/XMLSpawnerFan/orcline.jpg[/IMG]

[b]- modified some of the stat and skill mod attachments such as XmlStr, XmlDex, XmlInt, XmlSkill and the fame, karma, and virtue attachments XmlAddFame, XmlAddKarma, XmlAddVirtue so that spawners dont report an error when they attach them.[/b]
The functionality remains exactly the same, it just eliminates the error messages reported by spawners that were inaccurately indicating that the attachments had not worked even when they had.

[b]- added the new OFFSET,x,y[,z] keyword that can be used to shift the location of an object in a single operation.[/b]  

[color=blue]SETONTRIGMOB/OFFSET,5,7,3[/color]

would move the triggering player by the specified x,y,z amount.  This is the same as incrementing the individual x,y,z values like

[color=blue]SETONTRIGMOB/x/INC,5/y/INC,7/z/INC,3[/color]

but it does it in a single step and so is smoother in appearance.

New to version 3.08
updated 3/19/06
[b]- minor cosmetic changes to the questholder and quest log gumps.[/b]  Shifted the next/previous page buttons and eliminated double listings of quests held in xmlquestbooks in the quest log gump.  Increased the spacing between objective descriptions and eliminated slight clipping of quest titles that extend across two lines in the questholder gump.

[b]- slight change to the calculation used to randomly distribute spawns within the spawning area. [/b] (thanks to LowCastle for pointing this out)  The previous calculation was not inclusive of the lower and rightmost bounds so the width and height of the spawning area would end up 1 tile smaller than expected.

[b]- fixed a problem with extremely long entry strings in the [xmledit gump causing client crashes.[/b] (thanks to Galfaroth for pointing this out)

[b]- fixed a problem with the GETVAR keyword not returning a value when used in XmlDialogs.[/b] (Thanks to Connor for pointing this out).

[b]- fixed a parsing problem with the MOB,name[,type] keyword that did not allow the optional type argument to be omitted.[/b] (Thanks to Lordbill for pointing this out).

[b]- added support for specifying cliloc numbers instead of strings in gump titles and main text.[/b] (thanks to Connor for the suggestion)

GUMP, #cliloc,gumpnumber/#cliloc

the way it works is that if you specify a string that starts with a # in the title or main text then it will parse it as a cliloc number instead of a regular string.  This lets you make use of existing cliloc strings in your quest gumps.

[b]- fixed a crash that could be caused by attachments that had methods that themselves added attachments.[/b]

[b]- added the new XmlWeaponAbility attachment that allows mobs to be given special attacks on the fly.[/b] (thanks to Dave1969 for the suggestion)
You can add special attacks to a spawned mob with a spawn entry like

[color=blue]orc/ATTACH/xmlweaponability,BleedAttack[/color]

or manually add it to any mob with

[color=blue][addatt xmlweaponability BleedAttack[/color]

and then target the mob.
Note, the attack name is case sensitive and can be any of

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

which are the special weapon abilities defined in WeaponAbility.cs

You will also need to make this modification to basecreature.cs (or your custom mob script if you only want it to apply to certain mobs).

around line 290 change this
[CODE]
  public virtual WeaponAbility GetWeaponAbility()
  {
  	return null;
  }
[/CODE]
to this
[CODE]
  public virtual WeaponAbility GetWeaponAbility()
  {
  	// ARTEGORDONMOD
  	// allow creatures special attack ability to be specified by the xmlweaponability attachment
  	XmlWeaponAbility a = (XmlWeaponAbility)XmlAttach.FindAttachment(this, typeof(XmlWeaponAbility));
  	if (a != null)
  	{
    return a.WeaponAbility;
  	}
  	else
  	{
    return null;
  	}
  }
[/CODE]

and make sure that you have this at the beginning of the script
[CODE]
using Server.Engines.XmlSpawner2;
[/CODE]

[b]- added support for specifying attachments to be added to components in multi.txt files that are loaded with the MULTIADDON keyword.[/b]  This feature is used by the new XmlSiege system.
Each entry now accepts one or more optional attachment specifications separated by semi-colons

itemid x y z visible [hue] ; attachmenttype[,args]

These attachments will be attached to the components automatically when they are read from the multi file.

 
New to version 3.07
updated 1/26/06

[b]- added a fix for a problem in which the value of the 'Per' field (spawns per tick) in the extended xmlspawner gump was not being saved across server restarts.[/b]

[b]- added the ability to set custom enum properties such as the Faction and Town on factionguards.[/b]  This means that a spawn entry such as "factionberserker/faction/minax/town/britain"  will now work.

[b]- added the new MULTIADDON keyword that allows you to directly import multi-component structure definitions from text files into an addon that can be spawned just like any other object.[/b]  (thanks to godfood for the idea)
The syntax is 

[color=blue]MULTIADDON,filename[/color]

You can use it like any other spawnable keyword (e.g. ARMOR, LOOT, etc.) except you cant spawn it inside of containers or on mobs.

You can generate these multi files by hand, they can be exported from Orbsydia's UO Architect, or they can be created using the new [WriteMulti command.

The files will be automatically found if they are placed either in the main RunUO installation directory, or in the Spawns folder in the main RunUO installation directory.  Otherwise you must include the pathname.

Multi files are text files made up of a series of individual component entries.
Each entry must be on its own separate line with the following format:

itemid x y z visible [hue]
				
where 'x,y, and z' are the relative coordinate offsets of the component, 'visible' is 1 for visible components and 0 for invisible, and 'hue' values can be optionally specified for individual components.

To test it, just add a spawn entry like

[color=blue]MULTIADDON,execution.txt[/color]

where execution.txt is an existing multi file

The image below shows the results of spawning the multis contained in the files wall.txt and execution.txt.  Both of those files can be found in the xmlextras package.
[URL=http://img56.imageshack.us/my.php?image=multi8hu.jpg][IMG]http://img56.imageshack.us/img56/7144/multi8hu.th.jpg[/IMG][/URL]

[b]- added the new WriteMulti command that will allow you to create multi text files that can be imported in UO Architect or spawned with the MULTIADDON keyword.[/b]

[color=blue]WriteMulti <MultiFile> [zmin zmax][-noitems][-nostatics][-nomultis][-noaddons][-invisible][/color]

The optional arguments are available to restrict the extraction to certain types of objects.

The -noitems flag will ignore all items
The -nostatics flag will ignore all static (frozen) tiles.
The -noaddons flag will ignore all addons and their components
The -nomultis flag will ignore all multis and their components
The -invisible flag will include invisible items (by default they are ignored)

You will be asked to target an area, and all items and statics within that area will be exported to the multi text file.

You can easily grab things like existing buildings, sections of existing buildings, addons, multis (like camps), or just bunches of objects that you would like to turn into an addon.

By specifying the min and max z, you can limit the exported items/statics to those within that z range.

The 'handle' (the 0,0,0 point) for the addon will be the location of the character when the area selection is completed.

The multi files will be written out into the Spawns folder by default.

If you try to overwrite a non-multi.txt file or a multi.txt file that you did not write, you will be blocked.
This is accomplished by looking for the first header line of the form

1 version staffname

where 'staffname' is the name of the character that wrote the file.  You can overwrite files that you have written, but you cannot overwrite others.
If the staffname is missing, then no one can overwrite it.

The image below is the healer in britain that was extracted using WriteMulti with the roof cut off and spawned using the MULTIADDON keyword.  It is included as healer.txt in xmlextras
[URL=http://img210.imageshack.us/my.php?image=healer4bo.jpg][IMG]http://img210.imageshack.us/img210/7392/healer4bo.th.jpg[/IMG][/URL]

[b]- the MSG keyword now supports an optional hue argument[/b]

[color=blue]MSG[,probability][,hue][/color]

[b]- added the new ASCIIMSG keyword that is like MSG but uses ascii instead of unicode and supports an optional hue and font argument.[/b] (thanks to godfood for the suggestion)

[color=blue]ASCIIMSG[,probability][,hue][,font]/text[/color]

[b]- the SENDMSG keyword now supports an optional hue argument[/b]

[color=blue]SENDMSG[,hue]/text[/color]

[b]- added the new SENDASCIIMSG keyword that is like SENDMSG but uses ascii instead of unicode and supports an optional hue and font argument.[/b]

[color=blue]SENDASCIIMSG[,hue][,font]/text[/color]

The image below shows the msgspawner.xml example included in xmlextras.
[URL=http://img76.imageshack.us/my.php?image=coloredmsg0iq.jpg][IMG]http://img76.imageshack.us/img76/4876/coloredmsg0iq.th.jpg[/IMG][/URL]

[b]- added the ability to spawn things in 'packs' so that spawns in the same subgroup can be spawned close to one another.[/b] (Thanks to Dian for the suggestion)
To make use of this new feature, first assign the entries that you want to spawn as a pack to the same subgroup. Then set the new 'Rng' field to the right of each entry in the extended spawner gump.
The pack range ('Rng') value will be used to place the spawns for that entry at that range from the first existing spawn in that subgroup.
For example, if you set it to 12, then the spawns for that entry would appear randomly within a +- 12 tile box centered on the first spawn in the subgroup.
If there were no spawns yet in the subgroup, then the spawn would be placed randomly across the spawnrange like normal spawns.

If the Rng is not set (the default), then all of the spawns for that entry would just be randomly placed within the spawners spawnrange, as usual.

By assigning creatures to different subgroups, you can have multiple 'packs'.  Also, by setting the ranges for each entry differently, you can have different distributions for the different creatures in the pack (some tight, others more spread out).

[b]- added pack.xml to xmlextras that demonstrates the new pack range spawning feature.[/b] It spawns two packs of creatures, and also a pack of items consisting of armor surrounded by invisible spike traps. Just [xmlload it and hit respawn a couple of times to see how it works.
[URL=http://img76.imageshack.us/my.php?image=pack24wy.jpg][IMG]http://img76.imageshack.us/img76/3882/pack24wy.th.jpg[/IMG][/URL]

New to version 3.06
updated 1/12/06
- added a fix for importing .map files with [xmlimportmap that was assigning a spawnrange of 0 to spawners that had mixtures of vendors and other creatures.  This was affecting wilderness spawns that included wandering healers. Now it only assigns a spawnrange of 0 to spawners that only have vendors on them (thanks to Anvil for pointing this out).

- fixed a problem with the 'Per' and 'MinD' and 'MaxD' settings for entries being cleared when changing pages on the main spawner gump (thanks to CEO for pointing this out).

- modified the baseartifact.cs script in xmlspawner2-support.zip that handles the doom rares to allow display of properties on mouseover (such as artifact rarity) even when they are locked down (thanks to Novafire for the suggestion).

- added the ability to link switches in simpleswitches.cs and timedswitches.cs together (thanks to godfood for the suggestion).  
When you activate a linked switch it will set the state of all other switches in the link chain to the same state.
Any actions that those switches might have performed when being manually switched to that state will also be performed when they are activated through links.
To link switches, just set their Link property to point to another switch.
You can chain as many together as you like, and you can safely set up closed loops as well.
The SimpleSwitch, SimpleLever, TimedSwitch, TimedLever, and TimedSwitchableItem are all linkable. 

- added the ability to disable switches and levers by setting the new 'Disabled' property (thanks to godfood for the suggestion).  The switches will not respond to double clicks, or to linked activation, and will not allow their state to be changed.

- added an 'Offset' property to the TimedSwitchableItem that allows the location to be shifted based on the switch state (thanks to godfood for the suggestion).  When the switch is in position 1, the offset is added. When it is in position 0 it is subtracted.  This can be used to create timed sliding secret panels, etc.

- slight change to the way in which relative loading of xml spawn files using [xmlloadhere or [xmlnewloadhere works.  If spawns are defined across multiple maps, then only those spawners on the map which matches the first spawner loaded will be relocated to the current map.
This allows quests that might have spawners located across multiple maps to be properly relocated.  The previous method would force all spawners onto the current map.

- added a new button to the left of each spawn entry in the main spawner gump that will allow you to enable/disable that entry (thanks to godfood for the suggestion).
When disabled, the entry will behave as if the maxcount for that entry were set to zero even though the actual maxcount is not changed, and any active spawns for that entry will be removed.


New to version 3.05
updated 12/19/05
- fixed a problem with repeatable quests not giving out quest points.

- fixed a possible crash bug with the DESPAWN keyword when given a non-existant spawner argument.

- changed the quest log to report when quests can next be repeated instead of when they were last completed (thanks to seirge for the suggestion).

- added the 'Bring' button to xmlfind to bring all selected objects to your current location.

New to version 3.04
updated 11/15/05
- added the new "SETONSPAWNENTRY[,spawnername],entrystring/prop/value/..." keyword, that allows you to modify the individual spawn entry properties on a spawner. (thanks to Todo for the suggestion) The entrystring argument will be used to find all spawn entries containing the specified string.  If the spawnername argument is omitted, then the current spawner will be used.  If the entrystring is a numeric value, then it will be used as a zero-based index into the spawn entry list rather than as a string match.

For example, the entry

SETONSPAWNENTRY,testspawner,orc/maxcount/5/subgroup/1

would find all entries containing the string 'orc' on the spawner named 'testspawner', and set the maxcount of those spawn entries to 5 and their subgroup to 1

SETONSPAWNENTRY,testspawner,0/maxcount/5/subgroup/1

would find entry number 0 (the first entry) on the spawner named 'testspawner', and set the maxcount of that entry to 5 and its subgroup to 1


Spawn entry properties that are accessible to this keyword include:
 
string TypeName 
int MaxCount
int SubGroup
int SpawnsPerTick
int SequentialResetTo
int KillsNeeded
bool RestrictKillsToSubgroup
bool ClearOnAdvance
double MinDelay
double MaxDelay.

Note that these are all properties that can also be seen and set in the expanded spawner gump.

- added the example spawnerspawner.xml that demonstrates the use of the new SETONSPAWNENTRY keyword by spawning an xmlspawner with specified spawn entries.


New to version 3.03a
updated 11/13/05
- added support for the OnReattach method in attachments.  This is invoked after an attachment has been deserialized and reattached to its owner.  This allows the attachment to reestablish conditions on a target object that might have been reset by the object during deserialization.  An example of this is the XmlMorph attachment which 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.

- modified the XmlMorph attachment to restore bodymods after server restarts.

New to version 3.03
updated 11/05/05
- added support for 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

- added the new XmlSaveItem 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.

-added the new standalone keyword "DESPAWN[,spawnername],subgroup" which can be used to remove all spawns from a particular subgroup on a particular spawner.  If the spawnername arg is omitted, then the current spawner will be used.  Note that DESPAWN will only remove spawns on entries that have the CLR flag set.  If you want to remove all spawns regardless of the CLR setting, then use the DELETE keyword like this "SETONSPAWN,subgroup/DELETE"

- added the new "UNEQUIP,layer[,delete]" keyword that 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.

- added the new "DELETE" keyword that 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.

- added the new "TAKEN" keyword, which can be used wherever an item keyword like ARMOR could be used.  It will refer to the most recent item obtained via the TAKE or TAKEBYTYPE keyword.  This allows you to take items and then test properties on them, manipulate them, give them back, or even spawn them.
For example, to take some gold and then test to see if you actually got the proper amount, you can do

1 TAKEBYTYPE,1,100,false/Gold
1 IF/GETONTAKEN,Amount < 100/33/44
2 GOTO/1
33 SAY/Sorry, you do not have enough gold
33 GIVE/TAKEN
44 SAY/Very good. Here is your armor
44 TAKEN/DELETE
44 GIVE/ARMOR,1,2

- added the new "GETONTAKEN,property" keyword that allows you to refer to properties on items taken with the TAKE keywords.

- added the new "SETONNEARBY,range,name[,type]/prop/value/prop/value..." keyword that allows you to set properties on all objects of the given name and type within the specified number of tiles from the spawner (thanks to CEO for the idea). The objects can be mobiles, items, or both.

- added the new keywords "SETVAR,varname" and "GETVAR,varname" which can be used to create your own local variables on a spanwer.  These are used in the same way as other SET and GET keywords.  These can be useful when you want to use some value repeatedly as in the following example.

1 SETVAR,MyRand/{RND,1,100}
1 SENDMSG/making a hued set with value {GETVAR,MyRand}
1 platelegs/hue/GETVAR,MyRand
1 platehelm/hue/GETVAR,MyRand
1 platechest/hue/GETVAR,MyRand

This creates a local variable named MyRand, and sets the value of it to a random number between 1 and 100. Note that the local variables hold string values so by using the {} substitution delimiters you assign it the results of evaluating the RND,1,100 keyword instead of the string "RND,1,100"
The contents of the MyRand variable are then used to assign the hue property of the various spawned items using the GETVAR keyword.

Local variables are stored as XmlLocalVariable attachments on the spawner and can be viewed and modified using the [getatt command and targeting the spawner. 

- added the new "GIVEN" keyword, that works the same way as the TAKEN keyword, but refers to items given to npcs as part of GIVE quest objectives.

- added the new "GETONGIVEN,property" keyword that allows you to refer to properties on items given to npcs as part of GIVE quest objectives.

- added the new "AMOUNTCARRIED,itemtype" keyword that will return the total amount of the specified type of item being carried in the backpack of the triggering mob.  You can use this to test for carried items like

IF/AMOUNTCARRIED,gold < 100/33

or add it to a Condition field in xmldialogs or in a triggering condition test on spawners

AMOUNTCARRIED,bandage>100

- added the new example foolsgold.xml and foolsgold.npc that demonstrate the use of the TAKEN and GETONTAKEN keywords in an xmldialog.  To test this out just do an [xmlloadhere foolsgold.xml and interact with the npc as a player.

- added the new example colorme.xml that demonstrates the use of the TAKEN keyword in a spawner. To test this out just do an [xmlloadhere colorme.xml and then as a player, pick up the spawned platelegs.  The legs will be taken from the player and rehued, and then placed into the nearby container.

- added the new example clearrobes.xml that demonstrates the use of the SETONNEARBY keyword.  To test this out just do an [xmlloadhere clearrobes.xml.  The ClearRobes#1 spawner will just create a bunch of deathrobes in the area. When a player says the word "clear" this will trigger spawner ClearRobes#2 which will delete all deathrobes within 15 tiles of the spawner using the SETONNEARBY keyword.

- added the new example huedset.xml that demonstrates the use of the SETVAR and GETVAR keywords. To test this out just do an [xmlloadhere huedset.xml and then respawn the spawner named HuedSet#1 a couple of times.  Each time it will spawn a set of armor, all hued the same random color.

- added the giveharold.xml and harold.npc example that demonstrates the use of the GIVEN and GETONGIVEN keywords.  To test this, just [xmlloadhere giveharold.xml and as a player pick up the questholder that spawns.  When you give the npc Harold a sword, he will customize it with the triggering players name and give it back to him.

New to version 3.02
updated 10/21/05
- added support for the overridable OnBeforeKill and OnBeforeKilled methods on attachments.
  
public virtual void OnBeforeKill(Mobile killed, Mobile killer );
public virtual void OnBeforeKilled(Mobile killed, Mobile killer );

These are called before the OnKill and OnKilled methods allowing you to check things that might be changed in the OnKill or OnKilled methods.

- modified the set property code to allow assignment of nested properties where the property is writable, but the parent is not (this is the correct thing to do).  This allows things like dismounting players by assigning Mount.Rider to null like

SETONTRIGMOB/mount.rider/(-null-)

where mount is readonly, but rider is writable.

- fixed a bug in the new smartspawning algorithm that wasnt properly detecting player activity in active sectors resulting in conditions in which spawners could inactivate and reactivate even when players were around (thanks to Halciet for pointing this out).

New to version 3.01
updated 10/14/05
- added an optional "accesslevel" argument to the [smartstat command allowing you to change the smartspawning accesslevel setting. The current setting will also be displayed by the [smartstat command. 
Use of this option is restricted to administrators by default.
The new usage is

SmartStat [accesslevel Player/Counselor/GameMaster/Seer/Administrator]

Note, this setting will not be saved across server restarts.  For permanent change in the accesslevel setting, change the value of the static SmartSpawnAccessLevel variable in xmlspawner.cs

- modified the system for restricting properties such as "AccessLevel" on Mobiles that the spawner can set.  Now, any properties that you wish to restrict can be registered in the BaseXmlSpawner Initialize method by adding calls like

// register restricted properties that cannot be set by the spawner
ProtectedPropertiesList.Add(new ProtectedProperty( typeof(Mobile), "accesslevel"));

Note, that the restriction on setting "AccessLevel" is added by default.

New to version 3.00
updated 10/13/05
- optimized the smartspawning algorithm for reduced cpu load.  This will increase memory use slightly but will come with significantly reduced cpu usage.  The new smartspawning cpu load is now only a function of the number of players online rather than the number of spawners and their spawn ranges.  It uses hashtable mapping of current player sector occupancy to spawners.  The estimated increased memory use for a fully spawned shard with all spawners set to smartspawn is approximately 0.3M.  The old activation method added a 1-2% cpu load for a fully smartspawned shard while the new method uses less than 0.01% under a benchmark configuration of 3K spawners, avg spawn range 10 tiles, 100 active players.

- added support for setting a smartspawning staff access level.  Smartspawning will ignore staff above the assigned level.  This can be changed by setting the SmartSpawnAccess static variable at the top of xmlspawner2.cs.  The default is set to Administrator level so that anyone will activate smartspawning.  If you want only players and not staff to activate smartspawned spawners, set the level to AccessLevel.Player.

- modified the MUSIC keyword to allow music number as well as MusicName arguments.  So for example MUSIC,9 can be used instead of MUSIC,Britain1.  This also allows access to the new ML music values from 51-66 that are not yet defined in the MusicName enum.

- added support for the multiple spawns per tick feature (Per field in the spawner gump) when spawning subgroups with control keywords IF, WHILE, and WAITUNTIL 

New to version 2.99
updated 10/11/05
- fixed a bug that allowed players to complete COLLECT type objectives for playermade quests while the quests were still on a quest board (thanks to twig for pointing this out).

- fixed the TimedSwitchableItem that was writing out the wrong version number in its serialization (thanks to CEO for pointing that out).

- modified some of the methods for DAMAGE, POISON, MUSIC, and RESURRECT to allow them to be applied to non-player mobs.  This will generally only be of interest to those that are using those methods directly in custom systems.  It will have no effect on the use of those keywords by the spawner in spawn entries.

- fixed a parsing problem with the MUSIC keyword. (thanks to LordHogFred for pointing this out)  Music should now work properly.

- changed the behavior of the GET series of keywords to allow them to specify an empty name argument.  This means that you can test for things that are only specified by type like

GETONCARRIED,,platehelm,visible=true

which has an empty itemname argument where the syntax for the GETONCARRIED keyword is

GETONCARRIED,itemname[,itemtype],property

- slight change in the organization of the zip files.  The script XmlCategorizedAddGump.cs was moved from xmlspawner2-vxxx-1of3.zip to xmlspawner2-vxxx-3of3.zip in the Utils folder.  When installing over an existing installation, make sure that you dont end up with duplicates of this script.

New to version 2.98
updated 9/18/05
- added the new quest points system (thanks to Eymerich for the suggestion).  Individual quests now have a Difficulty property (default value 1) that can be set on the questholder book.  When a quest is completed, the player will receive the corresponding number of quest points.  These points will be maintained on the new XmlQuestPoints attachment, along with a history of completed quests.
Shard-wide rankings of players based upon these quest points will also be maintained.
Quest credits will also be accumulated that can be exchanged for quest rewards at a quest reward stone.
The XmlQuestPoints attachment will automatically be added when completing the first quest for points, so no administrative action is required to enable the system.  If you do not want to use the quest points system, change the QuestPointsEnabled constant in XmlQuest.cs around line 123

		public const bool QuestPointsEnabled = true;


- added the Difficulty property to the questholder item.  This can be set to the number of points that you wish the player to receive when they complete the quest (when the questholder is deleted).  This is an example of a spawn entry that would give out a quest with a set difficulty.

questholder/name/Balron's bane/difficulty/5/objective1/KILL,balron/autoreward/true/rewardstring/ARMOR,1,2

- added the [questleaderboardsave command that can be run by administrators to enable/disable the periodic saving of xml and html quest leaderboard information.  The html file can be used to display ranking information on a website. The leaderboard files will be placed in a folder named Leaderboard in the main RunUO directory. This is the same folder that the XmlPoints system uses for its leaderboard information.

- added the QuestLeadersBoard item that is a bulletin board that when double clicked brings up the current shard rankings for questers.

- added the QuestRewardStone item that can be used to allow players to exchange their quest credits for rewards.  You can add or modify rewards by editing XmlQuestPointsRewards.cs 

- added a handler for the Quest button in the paperdoll to open the quest log that displays current and past quests.  If you do not wish to link the quest log to the Quest button, comment out this line in PacketHandlerOverrides.cs

// This will replace the default packet handler called when the quest button on the paperdoll is pressed.
			Timer.DelayCall( TimeSpan.Zero, new TimerCallback( QuestButtonOverride ) );


- added the [questlog command that can be executed by players to bring up the quest log gump. The new quest log gump contains a list of all completed and currently active quests as well as current point status and ranking.
Completed quests will be listed with he completion date (helpful for time-limited repeatable quests) as well as the number of times the quest has been repeated.
Active quests have an 'Open' button that allows the individual quest gump to be opened.
The top quest players ranking can also be opened from the button at the bottom of the gump.

- added the [questranking command that can be executed by players to bring up the quest ranking gump.

- added the SimpleTileTrap item written by Alari.  This is like a SimpleSwitch object but it is activated when a player moves over it.  It can be used to set properties on target items (such as spawners, doors, etc.) when this occurs. The 1 state item and property assignment is activated when the player moves onto the tile.  The 0 state is activated when the player moves off of the tile.

-added the DiskAccessLevel constant to the XmlSpawner class to simplify adjusting the required access level for commands that perform disk access such as XmlSave, XmlLoad, XmlUnload and the .map and .msf importing functions.  This is set in XmlSpawner2.cs around line 61

		public const AccessLevel DiskAccessLevel = AccessLevel.Administrator; // minimum access level required by commands that can access the disk such as XmlLoad, XmlSave, and the Save function of XmlEdit


New to version 2.97a
updated 9/12/05
- quick update to xmlspawner2-v297a-1of3.zip to add the new timekeeping properties to the spawners as well as the xmldialogs.

New to version 2.97
updated 9/12/05
- added several timekeeping properties to XmlDialog entries that allows you to control their activation based upon time of the day, day of the week, day of the month, or phase of the moon. These properties are:
GameTOD - has values of the form hh:mm:ss, so 14:00:00 would be 2pm
RealTOD - has values of the form hh:mm:ss
RealDayOfWeek - has values Sunday, Monday, etc.  Note, these are enums so when referring to them in property tests precede them with a #, like "RealDayOfWeek=#Monday"
RealDay - has values 1-31
RealMonth - has values 1-12
MoonPhase - has values NewMoon, WaxingCrescentMoon, FirstQuarter, WaxingGibbous, FullMoon, WaningGibbous, LastQuarter, WaningCrescent

There are a number of ways that you might use these new properties.
By setting the Home property on an npc which will cause it to wander to that location. By setting Home at different times, you can have your npcs go to different places throughout the day.

You could also have certain conversations that could only be carried out at certain times of the day, or days of the week.
For example, setting the Condition field in an xmldialog entry to

GameTOD>12:00:00 & GameTOD<16:00:00

would restrict its activation to between the times of 12 and 4pm

- added an example of the use of these new properties in a .npc file timeofday.npc, and a spawner example that loads it up onto an npc in timeofday.xml.  To test it out, just do an "[xmlloadhere timeofday.xml".  The npc will respond with the day of the week in his banter, and if you respond with the keyphrase "hello", you will get different responses depending on the time of day (game time), and even the day of the week (he doesnt work on Sunday).

- added an additional overload for XmlLoadFromFile(string filename, string SpawnerPrefix, bool loadnew, out int processedmaps, out int processedspawners).

- added a new NOT operator (~) that can be used in property tests. (thanks to Sou^^ for the suggestion) By preceeding the property test by a tilde (~), the boolean results of the test will be inverted.  So for example the test

~GETONTRIGMOB,hits<20

would be true whenever the 'hits' property on the triggering mob was greater than or equal to 20.

Or the test

~GETONCARRIED,itemname,visible=true

would be true whenever the item was either not visible, or not found at all. 

- added an additional check to the individual entry min/maxdelay specification to deal with a possible crash bug with integer overflow when entering an invalid min/max value in the spawner gump (thanks to arul for pointing this out).

- fixed the itemid on the reversedbackpack doom rare in xmlextras so that it is actually reversed (thanks to AdminVile for spotting this).

New to version 2.96
updated 9/6/05
- added a new "type-search" button to spawn entries in the xmlspawner gump.  Pressing the arrow button to the right of each entry will do a search through all available object types that contain the string in the entry.  This is similar to the [add gump, but it will also list objects that require arguments to their constructors and will list those arguments.

This feature can be used to find the proper type name or even valid constructors and their arguments when you only have partial string information.
For example, to bring up all of the valid constructors for runic hammers, you could enter the string "runic" in the spawn entry, and press the type search button.  This will bring up a list of all of the available type constructors that contain the string "runic" in them.  Pressing the 'OK' button next to any search result will substitute that result into the spawner entry.  You can right-click the search window to cancel without any substitution.

- pressing the new type search button on an empty entry will bring up the full categorized object list gump.  You can navigate through the list to find available items and mobiles. Selecting an object from the list will place it into the spawn entry. This is the same list displayed when using the [add command. This list will only contain those objects that have zero argument constructors.

- slightly modified the way OnKill and OnKilled attachment methods are called.  Previously they would not be invoked for creature vs creature kills and were restricted to player kills.  Now creature vs creature kills will also invoke those methods if they are enabled on an attachment on the creatures involved.  The OnKill method can also be invoked on item equipped by the killer even if the killer is a creature.

- slight modification to the XmlLightning attachment.  Now the movement detection feature (lightning damage that is given when movement is detected around the object placed in the world that it is attached to) will only work for objects that are not movable. (thanks to Corbomite for the suggestion)
This means if you attach it to a sword to give it lightning-strike hit damage, for example, and then place the sword on the ground, people passing by will not be struck by lightning, but if you attach it to a door that is placed in the world, they will.

New to version 2.95
updated 8/30/05
- added a fix for truncation of long strings entered via the text entry book in [xmledit (thanks to Eymerich for pointing this out).

- slight modification to the command logging format for spawn entry changes (thanks to arul for the suggestion).

- added logging of spawn entry deletions into the command log.

- added a copy of Sno's distro spawner importer/exporter script to the support package.  The commands available are:

[exportspawner filename - Saves distro spawners to 'Saves/Spawners/filename'.  This command can be used with the [global, [multi, [area modifiers to apply it to multiple spawners. e.g. the command

[global exportspawner blah

will save all distro spawners to the file Saves/Spawners/blah

[importspawners filename - Restores distro spawners from 'Saves/Spawners/filename'.  Note, this command does not check for duplication, so if you run it more than once you will end up with multiple spawners.

These spawns can also be imported back in as XmlSpawners by using the '[xmlimportspawners filename' command.

- improved the efficiency of probabilistic spawning.

- reorganized code in xmlspawner.cs and basexmlspawner.cs

- added the PLAYERSINRANGE,range value keyword that gives you access to the number of players within the specified range (thanks to CEO for the idea).  This could be used to control what got spawned based on nearby player number, rather than just trig/notrig. So you could do things like

IF/PLAYERSINRANGE,5>2/33

or

SETONTHIS/maxcount/PLAYERSINRANGE,5

- manually setting the ProximityActivated property to true now activates the refractory timer and allows immediate spawning if SpawnOnTrigger is set. This provides added support for forced external triggering mode (ProximityRange = -2).

- added the ability to specify the number of spawns per tick for each spawn entry.   By changing the new 'Per' field in the spawner gump for a given spawn entry, instead of the default of 1 spawn per spawner tick, multiple spawns of that type can be spawned simultaneously.  This setting corresponds to the ':SP=' parameter in the XML file specification for an entry.

- added the playersinrange.xml example to xmlextras that demonstrates the use of the new PLAYERSINRANGE keyword.  To test it out, just load it up and bring different numbers of players nearby.  The maximum number of allowed spawns will change depending on the number of players nearby, and the spawns will also report that number.

- added the gangup.xml example to xmlextras that demonstrates the new multiple spawns per tick feature.

- added the donthurtme.xml example to xmlextras that demonstrates the manual ProximityActivated modifications with forced external triggering (ProximityRange = -2).  To test it out, just load it and then damage the orc that spawns. That will trigger the second spawner which is in forced external triggering mode. (thanks to Sou^^ for the example idea).

New to version 2.94
update 8/13/05
- newly loaded or imported spawners now have their First and LastModifiedBy user names automatically set to the staff that loaded/imported them.  This is used by the latest version of Spawn Editor 2 (v1.15)

- added logging of spawn entry changes into the command log (thanks to arul for the suggestion).

New to version 2.93
updated 8/5/05
- added support for the most recent version of Spawn Editor 2 allowing it send spawners directly to a live server with memory streamed loads. This is required by the latest version of the Spawn Editor (v1.12) and Transfer Server for real-time spawner loading.

- newly loaded or imported spawners now have their First and LastModified time automatically set to the time they were loaded/imported.

- imported .map spawners now have spawnrange automatically set to 0 for any spawners with basevendors on them to reproduce distro spawner-like behavior (thanks to CEO for the suggestion).


New to version 2.92
updated 8/3/05
- added a display of the current XmlSpawner version number to the [smartstat command (thanks to CEO for the suggestion).

- added support for sending live spawner information to Spawn Editor 2 with memory streamed saves.  This is required by the latest version of the Spawn Editor (v1.11) and Transfer Server for real-time spawner access.

New to version 2.91a
- fixed a possible crash bug with the [smartstat command. Only xmlspawner2.cs from xmlspawner2-vxxx-1of3.zip needs to be updated.

New to version 2.91
updated 7/27/05
- slight modification to the way in which container-held spawners are loaded.  If the z-coord of a container-held spawner is set to autoposition (-32768), then it will place itself in the first container that it finds at that xy location rather than requiring the absolute xy and z coordinate of the container to be specified. 

- adjusted the way .map files are imported with the [xmlimportmap command so that spawners configured with fewer idividual entries than the spawner maxcount will still fill it up properly. (thanks to Greystar for pointing this out).

- added a new Installation step 12 that just provides a suggested addition to basecreature.cs to enhance the use of smartspawning by preventing Paragon and rummaging mobs from being smartspawned.

- added a single argument constructor (attachment name) to the XmlData attachment.  The data will be an empty string.

- added the new GETONPARENT,property and GETONTHIS,property keywords. 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}

- added the example .npc file "getonparent.npc" demonstrating the use of these new keywords along with an example .xml file "getonparent.xml" to load it in.  Just type "[xmlload getonparent.xml" to try it out.

New to version 2.90
updated 7/15/05
- change to the way in which subgroups spawn. Now a subgroup (or any of its members) can only be spawned if ALL of the subgroup members are available for spawning (currententrycount < entrymaxcount).  If any individual entry in a subgroup has reached its max, then the subgroup will not be selected for spawning.
This will improve the behavior of subgroups that include mixtures of standalone keyword entries (that dont persist), and regular spawn objects (items/mobiles).
Each subgroup will now behave more like a single spawner that has the 'Group' flag set in which the spawner will not respawn anything until all of the spawns have been cleared.
I've tested this on the examples, and my own various spawners and have concluded that this is the best way for them to behave.

- improved the test for valid internal map items in [xmlfind.  Previously it was excluding all ICommodity items in order to protect internalized commodity deed commodities.  Now it only excludes those commodities that are actually owned by a deed so it will now uncover those additional invalid ICommodity items that it might have been missed previously.
To search for all invalid internal map items that can probably be safely cleaned, just do a search with only the Internal map selected, and the 'Hide valid internal' option selected.

- fixed an issue with type 5 GUMPS not respawning when closed with the close button in corner of the window (it still thought the player had it open).

- a few minor changes to the spawner gump help menu.  Added bi-directional paging arrows, made the gump wider so text isnt clipped, and moved the Standalone and the Value/Itemtype keywords to separate pages.

- minor change to the blather3.xml example. Changed the order of the spawners in the file so that when [xmlloadhere is used it moves the starting spawners to the current location instead of the final spawner (xmlloadhere uses the location of the first spawner in the file to calculate the relative shift).

- modified the installation instructions so that step 3 no longer needs to be performed (the book content change packet handler is now replaced by default).  Step 3 now explains what to do if you DONT want the mod. If you have an installation that made the step 3 mod previously you dont have to do anything.

- added the RNDLIST,int1[,int2,....] and RNDSTRLIST,val1[,val2,....] keywords that can be used to assign values or test properties against randomly selected elements of a list.  The only difference between RNDLIST and RNDSTRLIST, is that RNDLIST can be used in integer value tests and the list elements must be integers while the elements of RNDSTRLIST can by any string.
For example, to spawn a mob and set its hue to one of 4 random values, and name to one of 3 different strings you could use something like

orc/hue/RNDLIST,100,120,300,500/name/RNDSTRLIST,Gomer,Gubgub,Glorm

- modified the behavior of keywords that take itemname and mobnames as arguments such as the GET and SET series.  Previously, they required unique names and would return nothing if multiple items/mobs with the same name were found.  Now they simply return the first match. Also, specifying an empty name will match any name, e.g. SETONMOB,,balron/hue/500 will set the hue on the first balron in the world that it finds regardless of name.

- added the GETFROMFILE,filename keyword that allows you to substitute direct string content from a file anywhere that other GET series keywords can be used (thanks to Alari for the great idea).

- added the htmldemo.xml example that was directly inspired by one of Alari's scripts to display html from a file into a gump.  It makes a type 4 GUMP and displays the contents of a file into it using the GETFROMFILE keyword (you need to have extracted the welcome.txt into your Spawns directory).  The gump pops up when  a player says 'help'.

- added the randlist.xml example that demonstrates the use of the new RNDLIST keyword.


New to version 2.89
updated 7/7/05
- fixed the TimedSwitchableItem so that it saves its configurable item IDs across server restarts (thanks to DeLaw66 for pointing this out).

- added error logging to the attachment deserialization.  When errors in deserializing attachments occur on server load, an error log file will be created in the root RunUO directory with the name "Attachment Error {timestamp}.log" detailing the problem.
If emailing normal server crash logs has been enabled, then the attachment error logs will also be emailed to the same addresses.
Note that errors loading attachments do not halt the server or prompt for input the way that item/mobile deserialization errors do.

- added support for some features in the upcoming release of Spawn Editor with the "[xmlgo map [x y [z]]" command.

New to version 2.88a
updated 7/3/05
- added the substitution pass into preprocessing of the Text field of XmlDialogs (thanks to Vertigo for the suggestion)  This means that processed strings can be substituted using the {} syntax.  For example, to insert the triggering players name into a text string you would use something like 

Hello there {GETONTRIGMOB,name}

- add a new range command line argument to [xmlfind that will set the range (in tiles) for the search. The new syntax is

[xmlfind [type] [range]

- fixed a problem with the reponse string for type 5 gumps that was adding extra spaces to the end so things like the final reward gump for Draug's quest wasnt matching the response properly.

New to version 2.88
updated 6/27/05
- modified XmlDialogs so that they force a reset after loading a configuration, even if the previous dialog was still active. (thanks to Eymerich for pointing this out).

- added the DoReset property to XmlDialogs to allow them to be manually reset.

- changed the optional command-line argument to [xmlfind so that it now specifies an object type instead of a spawner entry.  So using the command

[xmlfind orcishlord


will bring up the [xmlfind gump with the type field set to "orcishlord" instead of the default "Xmlspawner".

- fixed a possible crash bug in [xmlfind (thanks to Saint666 for pointing this out).

- added the new TemporaryQuestObject attachment that 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).
The syntax is 
TemporaryQuestObject,questname[,expiration]

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).

- added an example of the use of the temporaryquestobject attachment in tempobject.xml

- added some new effects options to XmlQuestNPCs to allow them to display overhead effects indicators.  The EItemID, EHue, EOffset, and EDuration properties define the effect item, hue, xyz offset, and effect duration.  Setting EItemID to zero will disable this feature. 

- added an example of various npc highlighting schemes in questhighlight.xml

- added support for long integers in property tests.

- moved the Doom rares item scripts from support.zip into xmlextras.zip

New to version 2.87
updated 6/24/05
- added two new gumpitem types that can be used in the type 5 GUMP in addition to the existing BUTTON,IMAGE,IMAGETILED,LABEL,ITEM,and HTML

"RADIO,gumpid1,gumpid2,x,y[,initialstate]" - will place a radio button at the x,y location. gumpid1 is the gump art used when selected. gumpid2 is the art used when not selected. The initial state (true/false) of the button can optionally be specified.
The response string associated with a selected radio button will be appended to the response string generated by any button press.

"TEXTENTRY,x,y,width,height[,text][,textcolor]" - will place a text entry gumpitem at the specified x,y location and with the specified width and height with optional textcolor and starting text. Any text entered will be appended to the response string generated by any button press and radio button that might be selected.

- added the ability to generate more complex response strings in a gump composed of combinations of button responses, radio button responses, and text entry responses.
The order of response concatenation is: Buttonstring + Radiostring + Textentry strings

- modified gumpdemo.xml to add examples of the new gumpitems and gump response strings.

- added a new modification to the behavior of banter XmlDialog speech entries when Trigger/NoTriggerOnCarried restrictions are specified.  Currently, specifying DependsOn of -1 (banter) allows that entry to be activated regardless of triggering restrictions (nearby movement is sufficient).  Now, by specifying DependsOn of -2, that entry will behave like banter that will also be suppressed just like speech activated entries if triggering restrictions are not met (thanks to Eymerich for the suggestion). 

- added support for specifying multiple actions in the Action field of an XmlDialog speech entry.  Just place them in the Action string separated by semicolons.  For example, using an Action string like

GIVE/gold,500 ; GIVE/platehelm 

would give the player a platehelm and 500 gold.

- allow multiple IDs in the DependsOn field of an XmlDialog speech entry by separating them with commas. If any of the IDs match then the entry will be considered to satisfy the ID dependency.

- allow selections across multiple pages in [xmlfind.

- added a new sort option to [xmlfind to sort objects based on whether they have been selected or not.  This is useful when trying to organize selections that may have been made across pages.


New to version 2.86a
updated 6/18/05
- fixed a potential crash bug while loading .xml files with invalid min/maxrefract or todstart/end times. (thanks to Shadow1980 for pointing this out). 

- modified XmlDialogs to allow multiple speechentries with the same keywords, branching from the same point in the conversational tree, but with different conditional tests to be properly selected.  (thanks to Eymerich for pointing this out).

New to version 2.86
updated 6/16/05

- modified [xmlfind to run searches in a separate thread so that long searches will no longer tie up the server. This was particularly a problem when specifying property tests in the search criteria which made for slow searches (this is because I havent optimized the property testing algorithm yet, so it reparses the test string every time it is applied). 

- added support for applying a specified command to all selected objects from an [xmlfind search.  The command string can be any targeted command that you would otherwise use with one of the command modifiers such as [global such as get, set, or addtopack.  The command string is entered in the "Command:" text entry area, and the command is applied to all the selected items by pressing the button next to it.
Note, commands are entered without the command prefix (like '[') that you would normally use on the command line.
So, to set the hue of selected items to the value of 50, you would enter the command string "set hue 50"

- added a new GUMP type 5, that allows dynamic ingame configuation of gumps with specifiable buttons, art, labels, and button responses.  The syntax is

GUMP,name,5/width,height ; gumpitem ; response ; gumpitem ; response ...

The width and height will determine the size of the gump.  The name is optional and will not appear anywhere in the gump.
The following gumpitems and their specification syntax are available

"BUTTON,gumpid,x,y"  - will create a button with the specified gumpid art at the x,y location.  Pressing the button will generate the response string that can be used to drive speech entries if used in an xmldialog attachment, or to drive a spawner by setting the GumpState to the response. 

"LABEL,x,y,labelstring[,labelcolor]" - will place a label with the specified string and the optional color at the x,y location.

"HTML,x,y,width,height,text" - will place a scrollable html text box with the specified text string and width and height at the x,y location.

"IMAGE,gumpid,x,y[,hue]" - will place the specified gump art at the x,y location with the optional hue

"IMAGETILED,gumpid,x,y,width,height" - will place the specified tiled gump art at the x,y location spanning the width,height area.

"ITEM,itemid,x,y[,hue]" - will place the specified item art at the x,y location with the optional hue


For gumpitems that dont generate a response, just specify an empty response, e.g.

LABEL, 100, 50, Hello there ;;
IMAGE, 0x2060, 100, 50 ;;
IMAGETILED, 10460,50,50,100,23 ;;

For the button gumpitem, just specify a response string, e.g.

BUTTON, 2130,50,200 ; okay ;


- added the new SpawnOnTrigger flag that allows spawning to occur immediately after triggering regardless of the min/maxdelay settings (NextSpawn is set to zero on triggering).  This simplifies setting up the most common configuration for triggered spawners that previously set min/maxdelay to 0 to achieve this effect. This reduces cpu load since those spawners no longer have to repeatedly poll at short delays.

- added FirstModified and LastModified datetime properties to the spawners.

- added support for datetime properties in conditional tests.  For example, in [xmlfind, using the property test of "lastmodified>6\15\2005" along with the type of "xmlspawner" will search for all xmlspawners that were modified since 6\15\2005, or "lastmodified>6\15\2005 3:30 pm" will find those modified since 3:30 in the afternoon of 6\15\2005.

- minor modification to the way spawner gumps are updated when multiple gumps with multiple text entry books are open.  Previously, closing one of the books under those conditions would close other spawner gumps. That no longer happens.

- minor modification of the spawner gumps so that there is only one extended state instead of two. Clicking on the gump extension button in the lower right corner of the gump will fully extend it instead of having to go through the intermediate subgroup-only-display.

- minor modification to the spawner gump which will now automatically extend when first opened if individual spawn entry min/maxdelays have been specified.

- added a new item, the SimpleMap that allows you to add/spawn maps with preplaced pins.  Set the Bounds property to define the area displayed in the map.
To add a pin to the map, just set the NewPin property to the pin location in world coordinates.
For example, having a spawner spawn something like

simplemap/bounds/(3000,3200,400,400)/newpin/(3100,3350)/protected/true

Note, that bounds are set as (x,y,width,height) in world coordinates.
You can also insert multiple pins by just adding more newpin assignments.


- added an example of the use of the new GUMP type in an xmldialog specification in keypad.npc. Place this file in your default XmlQuestNPC folder. To load up a demonstration, put the keypad.xml file in your default Spawns folder and do an "[xmlloadhere keypad.xml" which will create a sample door and chest with the keypad.npc attachment (hint - the code is 132).
You can also just do "[loadnpc keypad" and target a lockable item, then approach the object as a player.  This will add an xmldialog attachment configured with the keypad.npc file.  To delete the attachment when you are finished, do "[getatt" and target the object again, and select the attachment and then hit the delete button.  To view the attachment you can use "[xmledit" and target the object.

- an example of the use of the new GUMP type in a spawner specification is given in gumpdemo.xml.  Just load it up with "[xmlloadhere gumpdemo.xml".  You need to be a player to trigger it.  It just pops up a dynamically configured gump with the various available elements displayed.  

- added a new quest that uses the new gump type, spawnontrigger feature, and the map item.  It is called draugquest.xml.  You can do an "[xmlloadhere draugquest.xml" to try it out.  Note, you need to have enabled support for skill triggering to run the quest.


New to version 2.85a
- modified the new spawnergump-lockout feature that prevents opening more than one spawner gump on the same spawner.  If staff went offline while a gump was open it would confuse it into thinking the gump was still open thus preventing opening the gump again.  It now checks to make sure that staff are actually online with gumps open.

- Added the GumpReset property that can forcibly override the spawnergump-lockout feature.  Just "[set gumpreset true" on the spawner and you will be allowed to open a gump that was locked out.


New to version 2.85
updated 6/2/05
- eliminated the restriction on BaseVendor spawning (this includes healers) that forced them to spawn at the spawner location.  This was a holdover from the distro spawner behavior but is not necessary with xmlspawner since you can always specify a spawnrange of 0 if that is how you want them to spawn.
This may affect existing vendor/healer spawns if their spawnrange was not set to zero.  

- minor modification to XmlDialogs that prevents changing the ID of entry #0. Entry #0 is the default starting point for all dialogs (it is just a placeholder and is not executed) and so should not be modified.

- fixed an issue with opening multiple text entry books from the spawner gump (thanks to EUORoadkill for pointing this out).

- added the text entry book interface to selected fields in the [xmledit gump. Press the button to the right of the Text,Keywords,Action,condition,Gump,TriggerOnCarried, and NoTriggerOnCarried text entry areas to access this feature.

- added a confirmation gump when attempting to overwrite an existing .npc file using [savenpc or [xmledit

- blocked the opening of multiple spawner gumps from the same spawner. Double clicking a spawner while a spawner gump is currently open will not open another spawner gump.  This also applies to multiple staff attempting to open the same spawner.

- added an option to the TriggerOnCarried and NoTriggerOnCarried strings to allow checking for equipped items only.  The new syntax is

name[,type][,EQUIPPED][,objective,objective,...]

So to test for the longsword named "Balron's Bane" that is not only carried, but also equipped you would use a string like

"Balron's Bane,longsword,EQUIPPED"

When used in the NoTriggerOnCarried, triggering would be prevented if the item was equipped.

Note, if the EQUIPPED option is not specified, then the item will be detected whether it is equipped or carried.

- added the option to resurrect pets with the RESURRECT keyword.  The syntax is

RESURRECT[,range][,PETS]

if the PETS keyword is specified along with a range, like this

RESURRECT,5,PETS

then any pet ghosts belonging to the triggering mob within the specified range will be resurrected.

If only the range option alone is given, like this

RESURRECT,5

then all player ghosts within the range will be resurrected.

If no options are given, then only the triggering player will be resurrected.


New to version 2.84
updated 5/31/05
- added the new "[xmledit" utility 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.  

- minor change to the main xmlspawner gump. When editing entries on pages 2-4, refreshes of the gump will no longer automatically jump back to page 1.

- changed the way the quest npc context menu Talk option is handled.  Now it actually causes the player selecting the option to speak the string entered in the TalkText property.  This allows the context menu Talk option to be used to activate nearby speech-triggered spawners not just XmlDialog configured npcs.

- fixed a problem with [xmlload crashing when trying to access readonly files (thanks to EUORoadkill for pointing this out).

- added a new SpeechHue field to XmlDialog speech entries that allows you to specify the hue of the speech for that entry.  The default value of -1 uses the default speech hue for the object.  For mobs, the default is the hue of the most recent speech, so if you set the hue once, it becomes the default hue.  For items, the default hue is white.

- added a simple XmlDialog example to test the new [xmledit command.  Just load the example "simple.npc" file to an object using the "[loadnpc simple" command and target a mob or object. Then use the [xmledit command on that object to edit the XmlDialog attachment.

New to version 2.83
updated 5/26/05

- added a new Gump property to XmlDialog speech entries that allows you to enter a GUMP keyword string to pop up a gump during npc interactions.  This allows you to mix speech-driven and gump-driven interactions in a .npc specification. 

- added a context menu option to TalkingBaseCreatures and TalkingBaseVendors (so that includes XmlQuestNPCs) that allows initiation of interactions by clicking the npc and selecting the "Talk" option.  By Setting the TalkText property on the npc, that text will be processed by the quest npc as though the player had spoken it. Even if this is enabled, speech can still be used to initiate interactions, so that a player saying the same text instead of selecting the context menu option will start the interaction in the same way, this just provides another alternative to speech.
Note, this only works for npcs  that are configured to interact via the XmlDialog system (TalkingBaseCreatures, TalkingBaseVendors, TalkingBaseEscortables, XmlQuestNPCs, etc.)(i.e they are configured via .npc files).  If you have a speech triggered spawner, using this will not trigger the spawner.

- added a new multiple-selection gump type (gump type 4) that is accessible via the GUMP keyword. To use this new gump use a GUMP string like this:
GUMP,gumpname,4/maintext ; selection; response ; selection ; response etc.
so a specification like

GUMP,MyGump,4/This is the main text of the gump where you would put your main dialog ; End the dialog ; end ; Continue the dialog ; continue; Go eat some cheese; cheese

would pop up a gump with the main text at the top followed by the three selections
End the dialog
Continue the dialog
Go eat some cheese

Selecting the first would produce the response string "end", the second would give "continue", the third "cheese".
If used in a spawner, the GumpState property would be set to those strings.  If used with an XmlDialog npc, the strings would be processed as speech triggering text that could drive other keyword driven entries. 

- added the ability to pop up gumps in XmlDialog (.npc) dialog specifications.  Each speech entry now has a Gump property.  This property can be assigned a GUMP string that will bring up a gump when that entry is reached.  The response strings from the gump will be processed as though the interacting player had spoken them, so that other speech entries can be triggered off of the gump response.  An example of using this feature along with the use of the new GUMP type is provided in harmonsquest2.xml with the .npc file harmon.npc

- added the example quest harmonsquest.xml.  This demonstrates the use of the new multiple selection gump as well as the new XmlAddVirtue attachment.
This is a simple, but fully functional quest that begins by default outside of the Sweet Dreams inn in Britain (or you can set it up to begin wherever you like with "[xmlloadhere harmonsquest.xml". To initiate the quest, approach Harmon and say "hail".  This is also configured so that it can only be done once a day.


- added the example quest harmonsquest2.xml.  This demonstrates the use of the new gump specification via .npc files.  This example uses the harmon.npc file.
This is the same quest as harmonsquest.xml, only the intial npc interaction differs. You can initiate the quest either via context menu on Harmon, or by saying one of the keyword triggers, "hail", "help", "wrong". You can set it up to begin wherever you like with "[xmlloadhere harmonsquest2.xml"
Make sure you [xmlunload harmonsquest.xml if you had that loaded up since they are redundant.

- minor change to the SimpleArtifact that updates the properties display when you change the artifact rarity.

- added several new attachments (XmlAddVirtue, XmlAddFame, XmlAddKarma).  To use these in a spawner you could attach them to a player with

SETONTRIGMOB/ATTACH/xmladdvirtue,Justice,3

which would give 3 justice points to the triggering player, or

orc/name/Schmeil the good/ATTACH/xmladdkarma,-500

would result in a -500 point karma loss for killing that creature.

- The "XmlAddVirtue, virtuename, virtuepoints" attachment allows you to give virtue points to a player directly, or when attached to mob, give the virtue points when the mob is killed.

- The "XmlAddFame, famepoints" attachment allows you to give fame to a player directly, or when attached to a mob, give the fame when the mob is killed.

- The "XmlAddKarma, karmapoints" attachment allows you to give karma to a player directly, or when attached to a mob, give the karma when the mob is killed.

New to version 2.82
updated 5/24/05
- fixed a lag issue that could be introduced by carrying active spawners in a pack that tried to spawn mobs. (thanks to EUORoadKill for pointing this out)
- fixed a problem setting multiply nested properties like skills.archery.base (thanks to Ian Frey for pointing this out).
- fix to [optimalsmartspawning that was skipping spawners. (thanks to sUpplier1 for pointing this out).
- adjusted the way .map files are imported with the [xmlimportmap command so that spawners configured with fewer idividual entries than the spawner maxcount will still fill it up properly. (thanks to sUpplier1 for pointing this out).
- the quest status gump now stays up after using the Collect button making it easier to collect multiple items without having to reopen the quest gump every time. (thanks to Shadow1980 for the suggestion).
- fixed a typo that crept in at some point that removed the protection against setting the accesslevel property. (thanks to Xavier_WER for spotting this).
- inactive spawners will now continue to display their properties instead of hiding them (they will still show Active/Inactive status)
- resolved some problems that were introduced in 2.77 with sequential advancement and the GOTO and WAITUNTIL control flow keywords.
- minor change to the syntax of the "ATTACHMENT,type,name,property" attachment property specification string used when accessing attachment properties. Specifying an empty string for the name will allow matching all attachments of that type.
For example "ATTACHMENT,xmlvalue,,value" would refer to the value property on an xmlvalue attachment regardless of the attachment's name and commands like
"[global xmlset ATTACHMENT,xmlpoints,,points 100 where playermobile"
could be used to set the points property on the xmlpoints attachments on all playermobiles.
- small change to the whiletest.xml example (changed the maxcount from 9 to 16).
- added a new item, the SimpleArtifact, in the xmlspawner2-support.zip file that allows you to create a generic artifact and assign its rarity (thanks to LordHogFred for the idea). Just do an "[add simpleartifact itemid", or you can spawn it like "simpleartifact,itemid/name/My new arti/artifactrarity/3"

New to version 2.81
updated 4/13/05
- fixed a potential crash bug with several of the attachments such as xmlmagicword that could occur when they were attached to items and the attachment properties display modification was in place. (thanks to akrondar for pointing this out).

- modified the ARMOR keyword to only drop armor and no shields.  The new SARMOR keyword now does armor-and-shields. (thanks to EUORoadKill for the suggestion).
                              
- added several new loot keywords. 
SHIELD,minlev,maxlev spawns a random magical shield between the minimum and maximum level (level range is 1-5).
SARMOR,minlev,maxlev spawns a random magical shield-or-armor piece (same as the old ARMOR keyword).

- added the new LOOT keyword that allows you to invoke arbitrary Loot class methods for generating random loot.  The syntax is "LOOT,methodname".  The method must be one of the public static methods in the Loot class that takes no arguments, and it must return an item.  
For example, to spawn a random statue use the keyword

LOOT,RandomStatue

where RandomStatue() is a defined static Loot class method that returns a random statue.
Other Loot methods that are part of the standard 1.0.0 distribution include, Gems, clothing, Wands, Reagents, Instruments, and other things, so all of the following would be valid

LOOT,RandomGem
LOOT,RandomClothing
LOOT,RandomWand
LOOT,RandomReagent
LOOT,RandomInstrument
LOOT,RandomNecromancyReagent
LOOT,RandomArmorOrShieldOrWeaponOrJewelry
LOOT,RandomGrimmochJournal

You can also define your own Loot methods in Loot.cs to return different types of random item if you like.

For example, if you are using the XmlSockets addon and have made the Loot.cs modification, you could spawn a random augmentation by using 

LOOT,RandomAugment

Like the other loot keywords, this can be used to spawn random items or to add them to mobs or containers using the ADD keyword.  For example, to add a random statue to a spawned mob, you could use something like

orc/ADD/LOOT,RandomStatue

and you can set properties on the resulting random item just as you would any other spawned item, like

LOOT,RandomReagent/amount/20

to spawn a random reagent and set the amount to 20


version 2.80
update 4/7/05
- added support for timespan properties in conditional tests.  For example, in [xmlfind, using the property test of "mindelay>0:10:00" along with the type of "xmlspawner" will search for all xmlspawners with a mindelay of more that 10 mins. 

- fixed an issue with triggered sequential spawners not waiting for triggering to advance the sequential index.
 

version 2.79
updated 3/25/05
- reorganized the xmlextras.zip file a bit to make it easier to just extract directly into the main RunUO installation directory and have the various types of files in the proper default locations.

- modified the calling args required for custom gumps used with the GUMP keyword that is used to display user gumps. Gumps must now be constructed with argument lists of the form 

public XmlNewGump( XmlSpawner spawner, string gumptext, string gumptitle, int gumpnumber, BaseXmlSpawner.KeywordTag tag, Mobile from )

The gumps can still be called from spawners, NPCs or other xmlspawner2 related systems by using "GUMP,title,number,gumpconstructor/text".

- added a sanity check to smartspawning that limits the size of the smartspawning detection range to 512x512 tiles.  (thanks to Thraxus for pointing this out).

- fixed smartspawning initialization to only initialize those spawners that were actually configured for smartspawning.  

- changed the required AccessLevel for the [xmlset command to Administrator. Since it provides access to public properties that are not flagged with CommandPropertyAttributes, it is significantly more powerful than [set and should not have the same access. (thanks to LucidNagual for pointing this out).

- added the ability to refer to objects by serialno in the SET and GET keywords. If a hex value is substituted for the itemname in the general syntax of

SET,itemname[,itemtype]/property/value/...
and 
GET,itemname[,itemtype],property

then that value will be used as a serial number to look up the object in the world. The hex value to use would be the value returned if you used the "[get serial" command and targeted the object.  So for example

SET,0x400017BD/visible/false

would make the item with serial number 0x400017BD invisible. 
Note that serial numbers for objects are are unique to a particular shard.  Once an object is made, it will have a serial number and that number wont change as long as that object continues to exist, but that number will not mean anything on another shard, since objects will have their own unique serial numbers dependent upon when they were made. So a spawner entry that used serial references would not be transportable to other shards.

- added the RNDBOOL keyword that simply returns a random boolean true/false value.  


version 2.78
updated 3/13/05

- the Hide valid internal map option in [xmlfind will now also hide MovingCrates which are valid internal map residents in 1.0.0

- fixed a crash bug with the [xmladd gump when using the Krrios client (thanks to tbird for pointing this out).

- fixed a problem with TriggerObject references being saved to .xml files (thanks to Gator81 for pointing this out).

- the info buttons next to each spawn entry in [xmladd now allow partial string searches of item/mobile types to be selected via the same menu system that is used when using the "[add" command. For example, entering in "elemental" into one of the [xmladd spawn entries and hitting the info button will bring up all objects with "elemental" in their type name.  Selecting one of those from the menu (e.g. AgapiteElemental) will result in that type being added to the spawn entry.
Pressing the info button on empty entries will result in the full item/mobile menu listing being brought up.

- creatures that are tamed and immediately released will no longer remain under spawner control blocking further spawning.  These creatures will now be handled like creatures that are tamed and later released.

version 2.77
updated 2/23/05
- fixed min/maxdelays for two doom rares spawns, the titan's hammer and blade of the righteous. (thanks to A_Li_N for pointing that out).

- the Hide valid internal map option in [xmlfind will now also hide the new GenericBuyInfo items which are valid internal map residents in 1.0.0

- slight modification to the autonumbering system in [xmladd.  Now autonumber value will only be incremented when placing a spawner while autonumbering is selected.

- The exception trapping around the core spawning code now reports any such exceptions to the console.  This eliminates the possibility of hiding spawning errors that might arise as a result of problems in routines such as the new overridable OnBeforeSpawn and OnAfterSpawn.

- made timedswitches and timedlevers movable=false by default.

- added the new RestrictKills flag (RK field in the extended spawner gump) to spawn entries under sequential spawning. When set to true kills of that entry will only be counted if they come from the currently active sequential subgroup.  So for champ-like spawning, when advancing a level, mobs from previous levels cannot be used to advance the current levels count (thanks to CEO for the suggestion). This can be used with the ClearOnAdvance flag that determines whether mobs from the previous subgroup levels will be automatically removed when advancing.
The default is false which means if spawns are not cleared on sequential advance, they can be counted as kills on other sequential spawn levels (this is how distro champ spawns work as well).

- added the new ClearOnAdvance flag (Clr field in the extended spawner gump) to spawn entries under sequential spawning. When set to true (default) the selected entries will be cleared on sequential spawn advancement (this was the previous default behavior). When set to false, the selected spawns will remain following sequential spawn advancement (thanks to CEO for the suggestion). 
If the RestrictKills flag is not set for those spawns, they can be counted as kills on any sequential spawn level (distro champ spawn behavior).
Note, zero kill entries will now clear on advance by default.  This differs from the previous default behavior.

- added a new region search option to [xmlfind.  This allows you to restrict searches to items/mobs/spawners that are within a named region (note that region names are case sensitive). So, for example, to find all of the xmlspawners in Deceit, just set the type to Xmlspawner, the region to Deceit, and do a search.

- added the ability to specify separate min/maxdelay times for each spawn entry.  The main spawner OnTick function (spawns can only occur during a main spawner OnTick) will still be governed by the spawner min/maxdelay times, and it is the only timer that is actually running, so there is no additional timer overhead associated with this feature, but individual spawns can be set to be longer delay times (basically multiples of the main spawner timer).
The time remaining until an individual spawn entry will be available for spawning is now shown in the extended spawner gump under the 'NextSpawn' column.  Note, because individual min/maxdelay times are not governed by independent timers, the times displayed under nextspawn are best estimates and may sometimes vary from the expected values.

- Individual spawn entry Min and Max delay times can be entered in the extended spawner gump columns labeled 'MinD' and 'MaxD'.  Values are entered as minutes (so to specify 30 seconds you would enter 0.5).
Note that entering individual min/max delay times that are less than the spawner min/maxdelay will NOT result in faster spawning.  Spawns cannot occur faster than the main spawner min/maxdelay. 
If no individual entries are specified, then the spawning time for that entry will be determined by the main spawner min/maxdelay.
When setting individual min/maxdelays for spawns with sequential spawning, make sure to check the KillReset property to make sure you are allowing enough OnTicks to actually achieve the desired target KillCount.  KillCount will still be reset if the number of main spawner OnTicks specified in KillReset passes without making a kill, so for example, if you make the main spawner min/maxdelay 1 minute, and an individual spawn min/maxdelay 10 minutes, you should set KillReset to at least 10 (10 OnTicks would be 10 minutes), to allow spawning to occur (and thus give the players something to kill) before the killcount was reset.

- added a simple example of the use of min/maxdelay in a non-sequential spawner in thighmaster.xml

- added new champ-spawn examples champ3.xml and champ4.xml that demonstrate the use of the new flags.  Champ3.xml is a variation of champ2.xml with smooth transitions between levels (Clr=false) and kills restricted to within level (RestrictKills=true), and a few of the spawns slowed down (MinD/MaxD=0.3 mins).

Description of champ4.xml

This creates a spawner that implements a simple sequential spawning configuration that starts with some harpies.  Killing at least one (Kills=1) will advance to subgroup 1.
Subgroup 1 spawns orcs and trolls.  The trolls will spawn a bit faster than the orcs.  The orcs will not be cleared when the sequence advances (Clear=false) but cannot be used later on to advance any other level (Restrict=true). The trolls will be cleared on advancement (Clear=true).  
The next level spawns an ogre.  Because the kill requirement is set to zero, this level will advance automatically on the next OnTick (20 seconds). Because Clear=true, the ogre will be cleared when the level advances.
The next level is a lich that has to be killed within 10 minutes to advance (Reset=10).  If it is not killed within the time limit, the sequence will be reset back to subgroup 0 (To=0).
If the lich is killed, the sequence will advance to the final level which is a pile of 500 gold pieces that has to be picked up to advance (Kills=1).

Each line is a spawn entry and the number next to it refers to the subgroup assigned to the entry.

spawner Champ#4
0	harpy/SAY/I guard the master		Kills=1	MinDelay=2 mins MaxDelay=3 mins	Clear=true
1	orc/SAY/I think I'll hang out here	Kills=1 MinDelay=1 min	MaxDelay=2 mins	Restrict=true Clear=false
1	troll						MinDelay=30 sec	MaxDelay=1 min	Clear=true
2	ogre/SAY/Just stopping by...		Kills=0	Clear=true
3	lich/SAY/You will never get past me!	Kills=1	Reset=10 mins	To=0
4	gold,500/MSG/Here is your reward	Kills=1

SequentialSpawn
MinDelay 20 seconds
MaxDelay 20 seconds

version 2.76
updated 2/10/05
- allow attachments to register staff kills as well as just player kills (why let players have all the fun).  This will affect attachments like XmlPoints that previously restricted points activity to players only.  Now those systems may optionally elect to allow staff participation as well.

- allow attachments to register staff movement and speech.  Individual attachments are now reponsible for restricting staff triggering.  The included attachments in the XmlAttachments folder that would be affected by this change have been modified to restrict triggering to player only (so they will continue to behave the way they did before).

- added the ability to select and save spawners to xml using the [xmlfind interface.  After doing a search, select the spawners you wish to save, enter the filename next to the 'Save to file:' button, and press the button.  It will save out the spawners in xml format in the same way that they would be saved using [xmlsave.
With this feature you can find and save spawners within a certain range, or with certain spawn entries, or certain properties, or with a name containing a certain string (not just starting with one).

- all interactive npcs, including TalkingBaseCreatures, TalkingBaseVendors, TalkingBaseEscortables, now use the XmlDialog attachment for handling dialog.  The new system is backward compatible with the old system, so any existing interactive npcs that you have spawned should work exactly the same as they did.  

- the [loadnpc command will now work on any targeted object.  You can even target items to load up .npc files.  For example, try "[loadnpc travelagent" and target a mob or item.  You can now interact with the target according to the travelagent.npc file specification.  One difference between item dialog and creature dialog is that when loaded onto a creature, the dialog will be actual speech which can trigger other dialog objects.  When loaded onto an item, the dialog is just overhead text and not real speech, so you cannot have dialog between items, only between creatures.

- slight modification to the foul language regular expression list in jeweler.npc to be a bit more selective with legitimate phrases that include the string "hell".

- added additional line-of-sight restrictions to the use of simple/timed switches and levers.

Version 2.75a
updated 2/08/05
- added a small fix to talking npcs. I had unintentionally changed the quest npcs so that they no longer produced actual speech and instead were only displaying overhead messages that looked like speech. This was supposed to be for testing only and I had not intended to leave this in the release. As a result, examples such as whosonfirst.xml that use interacting npcs stopped working. 
Also fixed a small bug that affected multi-entry spontaneous banter that did not have to be speech activated in talking npcs (thanks to ssalter for pointing this out).
xmlspawner2-support1of2.zip was updated with the fix.

Version 2.75
updated 2/05/05
- modified the stealing.cs file to allow containers to be stolen if they are flagged as stealable.

- added the StaffCloak item to xmlspawner2-support2of2.zip that allows staff to quickly switch between player and the assigned staff level (just do an [add staffcloak). This is handy for testing of quests/spawner triggering/npc triggering which require player access level to activate. The item is only useable by staff that already have the specified staff level.  An administrator can set the Level property to the desired staff level for each cloak.  Access level is changed to Player upon equipping the cloak.  Removing the cloak either manually or on death (for example) restores the original staff access level. A home location/map can also be specified by the owner which is the location they will be teleported to on double click (just a handy way to quickly get back to Green Acres or wherever your staff/testing area is).

- inactivated smartspawned spawners now remain inactivated following a server restart.  This eliminates the need for inactivated smartspawned spawners to gradually respawn and then inactivate again following a server restart. This has the effect of significantly improving smartspawning percentages following restarts as can be seen by doing a [smartstat.

- allow attachments to register kills of players by creatures as well as just by other players.

- added an autonumbering feature to [xmladd that when enabled will automatically append a number to the name of placed spawners.  The number is automatically incremented with successive spawner additions, allowing systematically numbered naming of placed spawners.  The current autonumber value will be saved/loaded the same way as other default parameters.

- expanded the spawn Entries section of [xmladd to allow for more spawn types to be listed and selected.

- added info buttons next to each spawn entry in [xmladd that allows item/mobile types to be selected via the same menu system that is used when using the "[add" command. This is like issuing the "[add" command but instead of creating the target object in the end, it just adds the object name to the spawn entry selection list.  It uses the same Data/objects.xml information as the "[add" command.

Version 2.74b
updated 1/23/05

- fixed a problem with subgroup information on spawner entries not being properly loaded from .xml files.  This appears to be specific to 1.0.0 (Thanks to Trying for pointing this out).

Version 2.74a
updated 1/22/05

-  fixed a bug in the spawner gump that prevented the increment-spawn arrow button from working on the first spawn entry. (thanks to Trying for pointing this out).


Version 2.74
updated 1/22/05

- IMPORTANT: this version contains modifications that are specific to RunUO 1.0.0 

- modified questholder and questnote items to allow them to be spawned into containers in the world.

- added support for use of hex values (values with the format 0x#####) in property tests.

- added support for use of item/mob serial values in property tests and assignments.  This allows, for example, the use of [xmlfind to find objects by serial number using the serial=0x##### property test.

- additional optimization to smartspawning.  Now, only the individual objects with the HoldSmartSpawning property set to true will be restricted from smartspawning instead of the entire spawner being restricted.  This allows further reduction in mob count when using smartspawning.  The amount of improvement depends on how many mobs were defined with the HoldSmartSpawning property.

- added a "Goto" button on the spawner gump to replace the "Close" button (which was redundant with right click to close the spawner gump).  This will teleport you to the location of the spawner.

- added a range test (default 2 tiles) to use of the simple and timed switch items. (thanks to aka Reu for the suggestion).

- calls to the the OnSpawned method have been replaced with the 1.0.0 OnAfterSpawn method that is now part of the standard distribution.  OnAfterSpawn is invoked at the same point during spawning as OnSpawned was - after placement but before any spawn entry property modifications.  

- support for the OnAfterSpawned method has been removed.

- support has been added for the 1.0.0 OnBeforeSpawn method that is called after spawn creation but before spawn placement.  This also provides support for the 1.0.0 Paragon system.

- new 1.0.0 installation instructions have been added (basically the same as the RC0 instructions but with updated line numbers based on the 1.0.0 files).

- modified 1.0.0 versions of container.cs and stealing.cs have been added to support the stealable rares system under 1.0.0

Version 2.73
updated 1/14/05
- improved detection of roaming mob spawns which can suppress smartspawning.  This will tend to yield around a 10% further reduction in mob count when using smartspawning. 

- added the "[smartstat" command that provides information on the effectiveness of smartspawning on the server by reporting the total number of xmlspawners, the total number of spawns, and the number of spawns that are currently being suppressed as a result of smartspawning.

Version 2.72
updated 12/26/04
- modified installation step 11 to include displaying attachment properties on jewelry.

- minor modification of attachment properties display on mouseover (eliminated extra cr at the end. thanks to sUpplier1 for pointing this out).

- added Tokuno map support to xmlfind, xmlsaving, xmlloading, skill triggering, and .map importing. 

Version 2.71
updated 12/04/04
- improved attachment efficiency by cleaning up attachments on deleted targets every save rather than only on restart.

- Added the readonly Attached and Owner properties to attachments that allow access to the object that the attachment is attached to and the object that the attachment is owned by. Note, while what an attachment is attached to and owned by are generally the same, Attached and Owner could be different for example when attachments are used as quest rewards and are owned by, but not attached to, questholder objects.

- added the ability to get attachments by serial number using "[getatt serialno" which will bring up the properties gump on the specified attachment.

- added an Owner field to the search results of [xmlfind that will display the name of the container or mobile currently in possession of container-held items.  For attachments, it will also display the name of the owner of the attachment. Search results are color-coded by the type of owner (world-black, container-in-world-blue, creature/npc-purple, player-orange) 

- modified the [xmlfind interface by moving the "Select All" button down to the lower right corner of the gump. 

- fixed a minor display bug in the recently added "properties display mod" that allowed properties from deleted attachments to continue to appear on the properties list of attached items.

Version 2.70
updated 11/28/04
- fixed a crash bug caused by calling the "[addatt" command with no arguments. (Thanks to thegrandmystic for pointing this out).

- added support for displaying attachment information in the properties list of items with the new static method "static void XmlAttach.AddAttachmentProperties(object parent, ObjectPropertyList list)".
This can be added into the GetProperties call of any item to add the information returned from the OnIdentify method of an attachment to its properties list. This uses cliloc 1062613 for attachment properties.

- added the new attachment method "InvalidateParentProperties()" that can be called by attachments to force a refresh of the parents properties list.

- added a new installation step 11 to support the automatic display of attachment properties on mouseover/click on weapons and armor items.

Version 2.69
updated 11/25/04
- fixed a potential crash bug in initializing attachments for the first time that was introduced in v2.68.

- fixed a parsing problem with the SET keyword when used in the "SET,name,type" form (it was only parsing 2 instead of 3 args).

- added the OnArmorHit method to XmlAttachments that allows them to respond to being hit with a weapon.

- added an additional installation step 10 to support the OnArmorHit method.

- minor attachment change. The XmlAttach.AttachTo static method now returns false if the attachment is deleted while being attached. One small cosmetic consequence of this change is that some attachments that automatically delete themselves if attached to an inappropriate target (like trying to attach XmlPoints to an item) will now be reported as having failed to be attached when using the [addatt command.


Version 2.68
updated 11/15/04
- some attachment code optimizations.

- small change in the way speech is handled.  It will no longer ignore speech that has already been handled by another object, such as another spawner, so multiple nearby spawners can all speech trigger off of the same speech.

- modified the [xmlspawnershow command. Spawners are no longer made movable by that command. I think that some people may have been having problems with some of the automatic dungeon sweeper scripts out there that will pick up and destroy any movable object, even if they were invisible.


Version 2.67
updated 11/06/04
---------------- spawner changes -------------------------

- added support for compound TriggerOnCarried/NoTriggerOnCarried tests using the & and | operators.  This allows testing for multiple carried items.  For example to trigger the spawner when a player is carrying both the platehelm named 'Helm of Light' and the longsword named 'Sword of Light' you could use the following string in the TriggerOnCarried property, "Helm of Light,platehelm & Sword of Light,longsword"

- the SET series of keywords (this includes SET, SETONMOB, SETONTRIGMOB, SETONCARRIED, SETONSPAWN) now supports assigning properties on attachments.  Whereever a property would normally be specified for those keywords, the new property keyword ATTACHMENT,type,name,property can be used.  For example, to set the value property to 34 on an xmlvalue attachment with the name XS on a triggering mob you would specify "SETONTRIGMOB/ATTACHMENT,xmlvalue,XS,value/34" (See attachtest3.xml for examples). 
The attachment properties can basically be treated as extensions of the target object's properties.

- modified the syntax for referencing attachments using the GET series of keywords. 
Whereever a property would normally be specified for those keywords, the new property keyword [ATTACHMENT,type,name,property] can be used.  For example, to read the value property on an xmlvalue attachment with the name XS on a triggering mob you would specify "GETONTRIGMOB,[ATTACHMENT,xmlvalue,XS,value]". The change involved using [] instead of <> for the ATTACHMENT delimiters.  This was to resolve a conflict with the use of the old syntax in conditional tests.  The example attachtest1.xml has been modified to reflect the change. 


---------------- attachment changes -------------------------

- added gump support for displaying/editing/deleting attachments on an object that can be accessed with the [getatt, [delatt, or [xmlfind commands.

- added support for displaying and editing attachment properties using the standard properties gump.  

- modified the [getatt command to bring up a gump listing all attachments on a targeted object.  Selecting the properties gump button next to the desired attachment will bring up the standard properties gump to support for display and editing of attachment properties that have been flagged with the command property attribute (just like item and mobile properties).

- added the AttachedBy property to attachments that has the name of the staff or spawner that first applied the attachment.

- added the DoDelete property to attachments that allows spawners to delete attachments by setting this property to true. For example, to delete the the xmlvalue attachment with the name XS on a triggering mob you would specify "SETONTRIGMOB/ATTACHMENT,xmlvalue,XS,dodelete/true" (See attachtest3.xml for examples).  

- modified the [delatt command to bring up the attachment gump if used in targeting mode rather than deleting all attachments on the targeted object.  Attachments can still be deleted directly by serial number using the "[delatt serialno" command.

- added support for the OnKill(Mobile killed, Mobile killer) method that will be called when a player kills something.  The HandlesOnKill property must be set to true on the attachment for this to be invoked.  Installation steps 2 and 6 must be performed to support this.

- added support for the OnKilled(Mobile killed, Mobile killer) method that will be called when a player or mob is killed.  The HandlesOnKilled property must be set to true on the attachment for this to be invoked.  Installation steps 2 and 6 must be performed to support this.

- added the XmlEnemyMastery attachment that will increase damage by the specified percentage when enemies of the specified type are hit with a weapon.  This can be attached to mobiles or weapons. An example of spawning a weapon with this attachment is given in enemymastery.xml

- added support for a mob faction system. The full description of this system along with additional mob faction related attachments is in a separate submission thread (XmlMobFactions).

- added support for a pvp points system. The full description of this system is in a separate submission thread (XmlPoints).

- added an installation step (step 9) to support the OnEquip and OnRemove attachment methods (this is needed to take advantage of the XmlFactionEquip attachment). 

---------------- quest changes -------------------------

- added a new AttachmentString property that works in the same way as the RewardString only for attachments.  This allows both reward items and reward attachments to be specified by string in a single quest.

- changed the way RewardString works so that attachments can no longer be specified in it.  Now there are separate specification strings for reward items and reward attachments.

- modified several of the .xml examples to reflect these changes.

- pressing the display reward button on the quest gump will identify the reward attachment if any is present as well as displaying the reward item. 


---------------- xmlfind changes -------------------------

- added the ability to open the attachments gump from [xmlfind.  Objects with attachments will have a blue bullet button at the beginning of their entry that will open the attachments gump for that object.

- modified [xmlfind to use the location of the parent mobile or container for items when using the range search option.  This allows you to use the range option to locate items even if they are carried by a mob/player or in a container within range.

- added support for searching for attachments directly by selecting the "attachment type" option and entering an attachment type.  At the moment, when this is selected, the other search options are not applied (so for example you cant search for all of the xmlpoints type attachments on players that are within 50 tiles).  I will be adding support for that later.




Version 2.66
updated 10/19/04
- added support for flagging quests as either non-repeatable, or repeatable but only after some time period.  If the Repeatable property is set to false on a questholder or questnote item, when the quest is completed and deleted, the player will be given a quest attachment (XmlQuestAttachment)  that will flag the player as having completed the quest.  If the Repeatable property is set to true (the default) and the NextRepeatable property is set to a TimeSpan value, then the attachment will be set to expire after that time.  As long as the XmlQuestAttachment with the quest name is attached to the player, objectives for that quest cannot be completed. The quest can still be held by the player and when the attachment expires, the player can then repeat the quest.  Note, staff can add or remove these attachments in-game using [addatt and [delatt to manually control whether specific players can repeat specific quests. The repeatability status of a quest will be shown at the bottom of the quest status gump.
For example spawning a quest as
 
questholder/name/waitforme/objective1/KILL,orc/autoreward/true/rewardstring/ARMOR,1,2/nextrepeatable/10:00

would make a quest named 'waitforme' with the objective to kill an orc and a random armor auto reward that could only be repeated once every 10 hours.

questholder/name/onlyone/objective1/KILL,balron/autoreward/true/rewardstring/ARMOR,4,5/repeatable/false

would make a quest named 'onlyone' with the objective to kill a balron and a random armor auto reward that could only be done once.

- added the .xml example repeatquest.xml that spawns a quest that can be repeated once a day and gives 2 hours of life drain ability as a reward.

- an additional help panel has been added that lists the syntax for the various quest objectives.  This can be accessed by selecting the arrow button in the top right of the help panel to advance from keywords, to commands, and then to quest objectives.

- added three new attachments.  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.


Version 2.65
update 10/13/04
- added two new attachments, XmlMorph, and XmlDialog.

- added additional .xml examples of the use of the XmlMorph and XmlDialog attachments in morph.xml and dialog.xml.  The dialog.xml example assumes that you have the travelagent.npc file installed either in your RunUO home directory, or in the XmlQuestNPC folder in the home directory.  Dialog.xml will spawn a chest that will interact with players using the travelagent.npc speech file.  Morph.xml will spawn one item that morphs when approached, one that morphs when the word "open" is spoken next to it, and several mobs that morph in different ways for different lengths of time.

- modified a few of the previous attachments to support mob speech and movement.

- made a namespace modification to avoid class/namespace conflicts (changed the attachment namespace from Server.Engines.Xmlspawner to Server.Engines.Xmlspawner2).  Unfortunately, this will cause previous attachments in existing saves to be removed when they are loaded on the next server restart (it will complain about not being able to deserialize them).

- installation steps 7 and 8 have been changed to reflect the namespace change.

Version 2.64
update 10/10/04
- added support for the OnAfterSpawned() method that can be defined in any mobile or item class and will be invoked when that item/mobile is spawned and placed in the world and AFTER any spawn entry modifications are applied.  This allows individual objects to script in actions that they wish to occur at spawn time that require knowledge of the object's map and location.  This differs from the OnSpawned() method that is applied BEFORE spawnentry modifications.  This allows the OnAfterSpawned() method to take into account any properties that are changed in the spawn entry. 

- a major system has been added that allows dynamic functionality to be added to items/mobs without requiring any modification to the item/mob scripts themselves.  The system is called the "attachment" system, and is something like scripted "post-its" that can be stuck onto any item or mob, and can then give them new user-scriptable abilities. Multiple attachments can be added to targets. (thanks to Elementi for the inspiration)
For example, placing the simple xmlhue attachment onto a mobile allows you to change its hue for some duration, after which it gets changed back to its original hue.  In order to do this conventionally you would have to modify the playermobile script with additional variables, serialization/deserialization, timers, etc.  If you also wanted to be able to do the same thing for creatures, you would have to add the same mods to basecreature, armor... basearmor, etc.  With attachments, you can add the hue changing ability to any item or mob with no script modification of the target class.  This includes things that are derived directly from inaccessible classes such as statics.

- several new commands have been added for staff support of attachments. [addatt, [getatt, [delatt, [availatt

[addatt attachmenttype [args] - allows attachments of the specified type to be added to targeted objects.  For example, to have a door display a message whenever it is approached, you could do "[addatt xmlmessage Welcome!".  To also have a sound played you could add "[addatt xmlsound 1048"

[getatt [type] - allows the attachments on a targeted object to be listed.  If the optional type argument is given, then only attachments of that type are displayed.

[delatt [type][serial] - allows attachments on a targeted object to be deleted.  If no arguments are given, then all attachments on the object are deleted.  If the type is specified, then only attachments of that type are deleted.  If a serial number is specified, then the specific attachment with that serial number is deleted (use [getatt to see the serial numbers).

[availatt - opens a gump that lists all of the available attachments and their various constructors and arguments.  All constructors for objects derived from the XmlAttachment class and flagged with the [Attachable] attribute will be listed.

- a new checkbox has been added in the [xmlfind gump to allow searching for items/mobs with attachments.  If the attach box is selected, then an additional filter for objects with attachments associated with them will be applied.

- the new ATTACH keyword has been added to the spawner that allows attachments to be added to spawned items/mobs.  It is very similar to the ADD keyword, but instead of adding items, you add attachments.  The syntax is "ATTACH[,probability]/attachmenttype".  If you further wish to set properties on the attachment that you are adding, you would use the syntax "ATTACH[,probability]/<attachmenttype/prop/value/prop/value...>".  For example, the xmlmagicword attachment has a requireidentification property that can be set, that forces players to identify the attachment before it can be used.  This property can be set at spawn time with "ATTACH/<xmlmagicword/requireidentification/true>".  See attachtest2.xml for an example.

- the GET series of keywords (this includes GET, GETONMOB, GETONTRIGMOB, GETONCARRIED, GETONSPAWN) now supports retrieving properties from attachments .  Whereever a property would normally be specified for those keywords, the new property keyword <ATTACHMENT,type,name,property> can be used.  For example, to read the value property on an xmlvalue attachment with the name XS on a triggering mob you would specify "GETONTRIGMOB,<ATTACHMENT,xmlvalue,XS,value>" (See attachtest1.xml for examples). 

- spawner triggering can be made dependent upon attachments on the triggering mob by using the "ATTACHMENT,name,type" string in the TriggerOnCarried or NoTriggerOnCarried properties.  This will make triggering dependent on attachments on the mob, or an attachment on an item equipped by the mob, or an attachment on an item in the top level of the mobs backpack (see attachtest1.xml for an example). 

- attachments can also be used as quest rewards by specifying them in the RewardString of a questholder or questnote just as you would in the ATTACH keyword.  You should also enable autoreward to have them automatically applied on quest completion.  They will be displayed as a "Bonus:" in the quest gump.  The details of the attachment cannot be queried at the moment, but I will add that capability (See minionstrike.xml for an example)

- attachments are scripted and have class definitions that look similar to items or mobiles.  Users can script their own attachments in much the same way that they would script new items or mobs.  All attachments are derived from the XmlAttachment class that implements the IXmlAttachment interface.  This interface defines support for several features that all attachments have access to, including activation on movement, speech, and weapon hits (see XmlAttachment.cs for the interface specification). See the XmlAttachments folder for example scripts.

- attachments can also be used in other scripts by simply creating new instances of the attachments (e.g. XmlAttachment attachment = new XmlHue(200); ) and then applying them to the target with AttachTo(targetobject, attachment);
Note, that the attachment is achieved via an object/attachment hash table association, so there is no actual modification of the targetobject.

- all attachments are maintained in hashtables that are serialized separately from the item and mobile tables.  The save information for attachments can be found in the Saves/Attachments folder.

- attachments support activation via speech or movement using the OnSpeech and OnMovement methods that can be defined in any attachment script.  This is accomplished by adding additional speech and movement event handlers.  I have done extensive stress test profiling of these handlers up to loads equivalent to 10,000 simultaneous players and have calculated the additional overhead to be around a maximum of 1-3% additional cpu overhead for movement at 10K players, and less than 0.1% for speech, with a proportional decrease in load with fewer players.  While it is highly unlikely that anyone would notice any impact of these handlers, they can be disabled if desired (of course, speech/movement attachment triggering will also be disabled) by simply commenting out the EventSink.Speech and EventSink.Movement handler lines in the Initialize method of XmlAttach in XmlAttach.cs. 

- note that optional installation steps 2 and 6 have been modified.  For those that had the previous modifications, in BaseCreature.cs just change 
XmlQuestToken.RegisterKill( this, ds.m_Mobile);
to
XmlQuest.RegisterKill( this, ds.m_Mobile);

and in ReportMurderer.cs change
Server.Items.XmlQuestToken.RegisterKill( m, g);
to
Server.Items.XmlQuest.RegisterKill( m, g);

- a new optional installation step 7 has been added to support the OnWeaponHit attachment method allowing attachments to be triggered when the targeted mob/weapon hits a defender. 

- a new optional installation step 8 has been added to support the use of the ItemIdentification skill to reveal attachments on targeted items/mobs.

- the scripts in the package have been reorganized into folders.

- description of the new attachments included in this version:
XmlDex, XmlInt, XmlStr - these attachments simply apply temporary dex/int/str mods to the recipient.  The value and duration can be specified.

XmlHue - allow the hue of the target to be temporarily modified. The value and duration can be specified.

XmlSkill - When applied to a mob, allows the specified skill to be temporarily modified.  A word can also be specified which is required to activate the modification.  If applied to a weapon or armor, the item must be equipped when the word is spoken to activate the skill mod. The skill, value, triggering word, and duration can be specified.

XmlDate, XmlData, XmlValue - these attachments allow bits of information to be added to the target.  XmlDate supports DateTime information, XmlValue supports ints, XmlData supports strings.  These can be added and read by spawners (see attachtest1.xml for an example).

XmlSound - allows a sound to be played whenever a player comes in range of the object it is attached to or says a triggering word.  The sound value, minimum interval between activations, number of uses, and triggering word can be specified.

XmlMessage - allows an overhead message to be displayed whenever a player comes in range of the object it is attached to or says a triggering word.  The message value, minimum interval between activations, number of uses, and triggering word can be specified.

XmlFire, XmlLightning - when attached to a weapon, it will apply additional fire/lightning damage on weapon hits.  When attached to an object in the world it will apply damage when a player comes in range of the object.  The amount of damage, minimum interval between activations, and how long the attachment will last (expiration) can be specified.

XmlMinionStrike - a personal favorite. When attached to a weapon, it allows the specified minions to be spawned with some probability every time the weapon hits a defender.  These spawns will be under the control of the weapon owner.  When attached to a mob, this ability will be applied to any weapon the mob wields (including fists). The minion type, chance of spawning, minimum interval between activations, and how long the attachment will last (expiration) can be specified (see minionstrike.xml for an example of its use).

XmlMagicWord - this is something of a template for a general speech activated attachment that has different abilities that can be unlocked depending on the word spoken.  If it is added to a weapon or armor, the items must be equipped before the words can activate it. 9 words have been added
Lepto - gives a dex mod of +20
Malik - gives a str mod of +20
Shoda - gives an int mod of +20
Vas Malik - gives a str mod of +40
Tarda - gives a tactics skill mod of +20
Marda - gives a magery skill mod of +20
Narto - spawns a tamed drake
Santor - spawns a tamed horse
Velas - make you invisible
The activating word, duration of each effect, the number of uses, and how long the attachment will last (expiration) can be specified (see attachtest2.xml for an example).  



Version 2.63
updated 9/26/04
- added some additional error logging for the .msf import function [xmlimportmsf.  Details are now logged in badimport.log

- optimized the OnSpawned() and HoldSmartSpawning function support.

- modified spawn placement so that mobs will no longer be able to spawn in restricted regions such as private houses (thanks to jaynigs for pointing this out)

Version 2.62
updated 9/21/04
- added some automatic syntax checking on questholder quest objectives to flag incorrect formatting or item/mob types that are not recognized.  Any resulting error status information is displayed at the bottom of the quest gump when it is opened.

- added the Status property to the XmlQuestHolder class that contains any error status information that might have been generated due to improper objective specification, testing, or reward generation.  Note that opening up the quest gump will run the syntax check that will overwrite any current status information, so check the Status property manually by doing a [props if you want to avoid that.

- modified the quest objective descriptions in the quest gump for questholder items.  They are a bit more descriptive now and include type information when it is specified. e.g. specifying the objective KILLNAMED,Sniveler,balron,5 will be described as "Kill 5 balron(s) named Sniveler", while the objective KILLNAMED,Bobo will be described as "Kill 1 mob(s) named Bobo".

- the .xml examples that referred to questnotes have been modified to refer to questholders.

- some minor changes to the properties displayed on mouseover.

- added support for the OnSpawned() method that can be defined in any mobile or item class and will be invoked when that item/mobile is spawned and placed in the world but before any spawnentry modifications are applied.  This allows individual objects to script in actions that they wish to occur at spawn time that require knowledge of the object's map and location.  

- added support for the HoldSmartSpawning property that can be defined in any mobile or item class and will be tested when the spawner attempts to inactivate when SmartSpawning is set.  This allows individual items/mobiles to define conditions under which smartspawning is suppressed on the spawners that spawned them.
Note, you dont HAVE to add the OnSpawned() method or the HoldSmartSpawning property to anything if you dont want to.  The spawner will still work just fine.  They are both completely optional.

- Below is an example of this new functionality used with Wyatts paragon system (paragon setting code taken from Wyatt's modified spawner in his paragon system).  
Add this to BaseCreature.cs to support paragon spawning and combined paragon/smartspawning without any modification to the spawner code.
Also note, that by overriding this method in any mob, you can determine whether they can become paragon or not, or even the chance of becoming paragon.

	// ARTEGORDONMOD
        // added support for the OnSpawned() method that is invoked after the creature is spawned and placed
        // added support for the HoldSmartSpawning property that can suppress smartspawning inactivation for a spawner when true

        public virtual bool HoldSmartSpawning
        {
            get{
		// dont do smartspawning inactivation if the spawner has a paragon on it
                if(Paragon) return true;
                return false;
            }
        }

        public virtual void OnSpawned()
        {
        
        /*+Wyatt+*/
		        if ( this.Map == Map.Ilshenar && 0.05 >= Utility.RandomDouble() && !SpellHelper.IsTown( this.Location, this ) )
				{
				    if ( !( this is BaseEscortable || this is BaseVendor ) )
 			 	       this.Paragon = true;
				}
        /*-Wyatt-*/
            
        }



Version 2.61
updated 9/18/04
- added the new XmlQuestHolder class that is intended to replace the XmlQuestToken.  Both are supported but the XmlQuestHolder is preferred. It has the same functionality but supports display of quest rewards.  It also resolves all weight issues and possible exploits that were addressed in the previous updates.

- added the new QuestHolder item that is intended to replace the QuestNote.  It has the same functionality but supports display of quest rewards.
It also resolves all weight issues and possible exploits that were addressed in the previous updates.  The questnote is still supported but the questholder is preferred.  The questholder takes the form of a book rather than the scroll of the questnote.

- the xmlquestmaker stone for playermade quests now hands out questholders instead of questnotes.

- updated the .xml examples boboquest.xml and questbook.xml to use the new questholder item.

Version 2.60b
updated 9/17/04
- disabled the ability to open and view attached quest rewards on questnotes.  I've discovered some problems involving players weight including the weight of quest rewards so I have disabled this feature for now.


Version 2.60a
updated 9/16/04
- modified the playermade quest reward system to prevent certain possible minor player exploits such as using containers set as reward items to carry items, or to automatically return items to a remote return container.

- fixed playermade quests to correctly reflect the weight of the items added as rewards.  Playermade quests will now have the weight of the reward items that they contain.  This is to prevent exploits involving use of playerquests as weight-free containers. Non-playermade quests are still weightless.

- reward weight is also now reported in the questgump.

Version 2.60
updated 9/15/04
- modified the way in which COLLECT and GIVE type quests work with playermade quests.  The items collected or given will now be returned to the quest creator and placed into the specified return container (or the creators backpack if nothing is specified).  This allows resource contract type quests to be made, in which players offer rewards in return for certain goods.
For example constructing a quest with this objective
COLLECT,goldingot,100
would create a basic contract for 100 gold ingots.
COLLECT,greatercurepotion,100
would create a basic contract for 100 greater cure potions.

- added a button to [xmlfind to hide valid internal map items/mobs.  By selecting this button along with the internal map button you can search for all probable invalid internal map items/mobs.  The selection criteria for valid entries are based on the internalitems/internalmobiles scripts by Fury. Note, like those scripts, this will not hide items/mobs that might have been intentionally put on the internal map due to custom scripts, so use caution, although in all likelihood they were put there unintentionally and can be safely deleted.

- added a button to [xmlfind to select all entries.  This button is in the upper right corner of the [xmlfind gump, just to the left of the 
select-displayed button.  When checked, it will select all of the entries found in the search (not just the ones currently displayed).  The entries can then either be deleted, reset, or respawned by selected the corresponding buttons along the bottom of the gump.  Note that individual entries cannot be toggled when the select-all option is enabled. 

- changed the questnote to bring up the quest status gump directly on double click. The original questnote with the more RP-friendly scroll gump is still available as OriginalQuestNote.

- some cosmetic changes to the way in which quest gumps are brought up from the questbook to reduce overlap and ease quest browsing.

- enforced culture invariance in specification of floating point numbers when used to specify occurrence probabilities with the keywords ADD, EQUIP, SAY, MSG, TAKE, and TAKEBYTYPE.  Only decimal point separator formats are now allowed.  This was to avoid ambiguity in the culture-dependent use of commas as both an argument separator and a decimal separator. (thanks to Brennan for pointing this out).

- item and mobile deletion calls in [xmlfind now have their exceptions trapped since some objects may not delete gracefully (those with a null map are particularly error-prone).


Version 2.59
updated 9/12/04
- modified smartspawning to temporarily block inactivation if any spawn is drawn outside of its home range.  (Thanks to jaynigs for pointing this out).

- added an additional optional type argument to several keywords to suport enhanced item/mob specificity.
These keywords are:
GETONCARRIED,itemname[,itemtype],property
SETONCARRIED,itemname[,itemtype]/prop/value
TAKE[,prob[,quantity[,true,[typename]]]]/itemname
GET,itemname[,itemtype],property
SET,itemname[,itemtype]/prop/value
GETONMOB,mobname[,mobtype],property
SETONMOB,mobname[,mobtype]/prop/value
MOB,name[,type] 

- added support for an additional optional type argument to the TriggeronCarried and NoTriggerOnCarried property to enhance target item specificity.  The syntax is
itemname[,type][,objective,objective,...]

- added an additional optional type argument to quest objective keywords for greater specificity in target objectives.  
These keywords are:
COLLECTNAMED,itemname[,itemtype][,count][,proptest]
GIVENAMED,mobname,itemname[,itemtype][,count][,proptest]
KILLNAMED,mobname[,mobtype][,count][,proptest]

- added an installation step that will provide support for player kill contracts.
If suggested installation STEP 6 is followed, the player quest system will allow for various types of player kill contracts to be constructed. 
For example, a player constructing a quest with an objective
KILLNAMED,playername,PlayerMobile
would create a basic contract that would give the reward when the named player was killed.
KILL,PlayerMobile,5,kills>10
would create a contract that would give the reward when 5 murderers with more that 10 kills were killed
KILL,PlayerMobile,5,kills=0
would create a contract that would give the reward when 5 innocents were killed

Note that specifying the PlayerMobile type avoids exploits that would be possible with just a simple name specification of the target (for example killing a pet named the same as the target player).

- added the playerquestboard item that is a bulletinboard that can be placed in the world and allows players to drop and received playermade quests (such as the player kill contracts). Just place it with "[add playerquestboard"

- minor display changes in the quest and questmaker gumps.

- minor xmlquesttoken optimizations.

- changed the player questmaker gump to block use of xmlquesttokens and xmlquestbooks as rewards in playermade quests

- changed all simpleswitches and timedswitches so that they are immovable by default (thanks to jaynigs for the suggestion).


Version 2.58
updated 9/03/04
- Added the XmlQuestBook which can hold multiple XmlQuestToken type items such as questnotes, and will display status, allow them them to be viewed or dropped from the book. (thanks to paole for the suggestion)  Basically a BOD book for quests.  The books also have a Locked property that when set, prevents players from adding or removing XmlQuestTokens from it.  This can be used to create fixed XmlQuestBook items that contain a predefined set of quests that need to be completed.  By checking the IsCompleted property of the book, you can determine whether all of the quests contained within it have been completed.  This feature can be used to create superquests composed of multiple subquests.
Note, that for staff with accesslevel GM or higher, double clicking a questbook will both open the questbook gump as well as open the questbook container allowing you to view and manipulate the individual xmlquesttokens in it (remember to close the container before becoming a player).  For players, only the gump opens.

- modified the XmlQuestToken gump to display the quest description string in a scrollable html window.

- modified the constraints on placement of XmlQuestTokens and XmlQuestBooks to allow them to be spawned on and dropped by mobs. The assignment of blessed status also now occurs when a player takes the item rather than at construction.

- added support for attaching quest rewards directly to XmlQuestTokens with the RewardString and RewardItem properties.  By specifying an
item in the RewardString property, that item will automatically be constructed and attached as the RewardItem.  A picture of the RewardItem will be 
displayed in the quest gump when it is opened.  The actual reward item can be displayed by clicking on the blue button next to the image.  Availability of this button can be toggled with the CanSeeReward property.  The RewardString uses the same spawn specification strings as the spawner, so just enter it as though you were spawning it.  Mobiles cannot be used as a reward.

- added support for XmlQuestTokens automatically giving rewards upon quest completion with the AutoReward property. When this is set to true, and a RewardItem or RewardString has been specified, upon completion of the quest, the reward item will be given to the owner and the quest token automatically deleted.
This allows complete quests to be made without any additional spawner support.

- added the CanSeeReward property to XmlQuestTokens that can toggle whether or not the actual reward items are allowed to be seen via the display item button in the quest status gump.

- added the PlayerMade property onto XmlQuestTokens.  When this property is set, players can edit blank questnotes by double clicking them.  This brings up an editing gump that allows them to enter their own objectives, text, and attach their own rewards.  These quests can be given to other players or placed on playervendors.  Player quests are set to AutoReward when reward items are attached.

So that player quests can always be distinguished from non-player quests by spawners and other triggering items, player quests will have "PQ: " automatically appended to the beginning of their name.
When playermade quests expire or are deleted before being completed, the reward item that was attached to them will be returned to the quest creator.  This way, players can hand out quests without worrying about losing the committed reward if the quest isnt used or completed.  
The ReturnContainer property can be set to receive quest reward returns.  If not set, then it is returned to the players backpack.

- added the xmlquestmaker item that is simply a stone that dispenses blank playermade quests to be edited (double click it to dispense).  Just [add xmlquestmaker to place it.

- added an example of the new questbook and blank playermade quest features in questbook.xml that spawns two mobs that drop quests and questbooks.

- added an example of the autoreward features in boboquest.xml

- added an age test in [xmlfind that can be used to find creatures that are > or < a certain age.  For example, searching for basecreatures with age > 2400 will return all of the mobs that are more than 100 days (2400 hours) old - useful for tracking down stale or orphaned spawns. 
Searching for basecreatures with age < .01 will return all of the mobs that have been created in the last 36 seconds - useful for monitoring active spawn patterns.  Searching for playermobiles with age < 24 will return all players added in the last 24 hours, etc.
Note, this only applies to mobiles, not items.


Version 2.57
updated 8/27/04
- added another fix for spawners not reactivating when smartspawning was true. (thanks to Ingvarr for his help)

- modified smartspawning to suppress inactivation when a spawner has damaged mobs.  This way if a player injures a spawn on a full spawner, and then leaves and later returns, he can be guaranteed that the same spawn will still be there as long as it is still damaged. (thanks to Fluke for the idea).

- added support for saving and restoring the WayPoint property in .xml saves.  If the waypoint pointed to by the WayPoint property is named, then on [xmlload the waypoint will be looked up by name. If the waypoint uses the default name or has no name, then it will be saved and looked up by serial number.  The named approach allows a world-independent specification.  Using the serial approach means that the waypoint will only be restored when [xmlloaded back into the same world, but it is a bit more straightforward, since you dont have to manipulate your waypoint in any way. (thanks to Knightshade for the suggestion).

- [xmlloadhere type commands will now do relative z adjustment of loaded spawners, so they can be loaded onto second floors or any other relative-z surface (thanks to paole for the suggestion).

- minor modification to the goto-spawn button in the main spawner gump. Reports spawns that no longer exist instead of trying to go to them.


Version 2.56a
updated 8/24/04
- fixed a problem with spawners not reactivating when smartspawning was true and spawnrange was zero. (thanks to BlackNova for pointing that out) or when players just entered an activating sector at the time of world saves (thanks to Ingvarr for pointing that out).
To activate the fix, just install the new xmlspawner2.cs script from xmlspawner2-v256a-1of2.zip and then do a 
"[global xmlset isinactivated false where xmlspawner" to refresh any smartspawning spawners that might be inactivated.


Version 2.56
updated 8/20/04
- enhanced the properties gump that is called from the main spawner gump to display all xmlspawner properties in a single gump (no more paging through them), and also highlights all properties that have been changed from their default values to easily see how a spawner has been configured.  If you like the old properties gump, you can go back to it by simply commenting out the first line of XmlSpawnerGumps.cs (//#define NEWPROPSGUMP).  Note, this does not affect the standard props gump that comes up with the [props command.


Version 2.55
updated 8/17/04
- added the RANDNAME,nametype keyword for assigning random names to mobs (thanks to brodockbr for the suggestion)

- added the EQUIP keyword which has the same syntax as the ADD keyword except that it will equip the item on the target mob if possible instead of just adding to its pack.  If the item cannot be equipped it will just be placed in the mobs pack.

- the TRIGSKILL keyword has been updated to allow its use in property assignment and string substitution (I forgot to enable this earlier).

- fixed a bug in [xmlimportmap that was ignoring the "overridemap" directive. (thanks to joshma2 for pointing that out).

- added new xml examples skilltrigger5.xml and equipper.xml demonstrating the new features.  Equipper.xml spawns a ratman, gives him a random male name, and equips him with a random level 5 magical weapon with a random female name, and a hitfireball 100% weaponattribute which you will notice if you fight him.
Skilltrigger5.xml shows how the TRIGSKILL keyword can be used with string substitution or to assign other properties based upon skill base, value, cap, or name.  It is triggered by using the Musicianship skill within the trigger range of the spawner and sends a message displaying skill information using string substitution, and spawns gold in an amount based on the skill value using property assignment.


Version 2.54a
updated 8/15/04
- fixed a crash bug when using the goto spawn button on an empty spawn entry


Version 2.54
updated 8/11/04
- added a goto-spawn button in the spawner gump (to the right of each text entry area, next to the extended text entry gump button) that will take you to the location of currently spawned objects for a given spawner entry.  If there are multiple spawned objects for an entry, it will cycle through them with repeated clicks.  Useful for tracking down spawns.

- the Add button in [xmladd now uses targeting to place spawners rather than just putting them at the location of the placer.  Targeting a container will place it in the container, targeting the ground will place it on the ground, targeting a surface will place it on top of the surface.


Version 2.53
updated 8/8/04
- added the [xmlimportmsf command that allows basic megaspawner .msf files to be imported.  This ignores megaspawner-specific features such as individual entry overrides or any of the triggering or despawning features, and only imports the basic spawn counts, types, grouping, home/spawn range, and delays.  It also does not handle container spawns.


Version 2.52
updated 8/7/04
- added the SmartSpawning property.  This can reduce mob/item counts and memory load by regulating spawning based on player activity.  In areas where there is no player activity (no active sectors within the spawn range of the spawner, or in the spawning region if defined), all spawns will be removed and the spawner will be placed in an inactive state until it is activated by a player entering its active range (an active sector in its spawn range). (thanks to godfood for the idea).
To use this feature, just set the SmartSpawning property on a spawner to true.  When the spawner is fully respawned and no players are detected, it will remove all spawns. When it detects player activity in range, it will fully respawn again making it appear as though it had simply been left in the fully respawned state.
It is somewhat similar, but complementary, to the PlayerRangeSensitive mod which reduced cpu load by regulating mob ai.  This will reduce memory load by regulating spawns.
In testing, use of this feature resulted in a 20-50% reduction in memory usage, total mob/item counts, and save times.   This will vary based upon player activity, total number of spawns, an proportion of spawners set to use the feature. There is a small cpu overhead in monitoring spawners for player activation which amounted to about 1-2% under tests with a modestly spawned world (~2300 spawners, 14K spawned mobs, 50K spawned items) and all spawners set for smart spawning, so I would take this as a likely upper limit.
To see what the best-case improvement might be, you can do a "[global set smartspawning true where xmlspawner" and then watch as the item/mob count drops (or if you are impatient you can also do a "[global set nextspawn 0 where xmlspawner" to see the effects immediately).
To undo it just set them back with "[global set smartspawning false where xmlspawner".
This can also reduce cpu load if a shard is using PlayerRangeSensitive=false since it reduces the number of mobs with active ai.  In testing, I was able to run with PlayerRangeSensitive set to false (i.e. all mob ai active all the time) and only 5% cpu load on server that otherwise would be running at 50% load without smartspawning set.

- added the new command "[OptimalSmartSpawning [max home/spawnrange diff]".  This is just a convenient way to quickly set up spawners for smart spawning in a way that will be most transparent to players.  This will evaluate all xmlspawners and set the SmartSpawning property to true on those that look like good candidates based on several criteria.  First, it looks to see whether there are any basevendors being spawned on it. This includes things like wandering healers.  If they are found, then smartspawning is not set.  If the homerange exceeds the spawnrange by more than the default of 1 tile (this can be changed by passing it an integer value), smartspawning will not be set.  It will not be set on any proximity triggered spawner.
Note, there is no harm in setting smart spawning on spawners other than the ones selected by [optimalsmartspawning, or on all spawners for that matter.  The optimal setting is simply what will make the smart spawning look as transparent as possible. When smart spawning is set up using [optimalsmartspawning, it is unlikely that anyone will be able to tell that the feature is being used, other than the fact that memory use, item/mob count, and save times will all be reduced.

- improved search for spawners identified as having invalid spawn entries (err selection button) in [xmlfind.

- added the option to search on property test condition in [xmlfind.  This uses the same property test function as xmlspawners so you can limit searches to those items/mobs that satisfy the test condition along with any of the other search options that are set.  For example, you could do a search for all spawners that were first created by a particular individual using the property test "firstmodifiedby="Slacker"", or all mobs with high fame and low karma using "fame>20000 & karma<-20000", or all damaged mobs with "hits<hitsmax", or smartspawning spawners "smartspawning=true".  Note, any public property can be tested and you can test against other properties or against constants.

- a few cosmetic fixes to [xmlfind and [xmladd


Version 2.51
updated 7/31/04
- added the Description1-5 properties to XmlQuestTokens to allow the description of quest objectives to be explicitly specified.  When this string is defined it will override the default description provided for the different types of quest objectives.  Jeweler2.xml has been modified to use this new feature.


Version 2.50
updated 7/30/04
- added support for an additional property test argument to the quest keywords like COLLECT,type,[count][,proptest].  The property test can also be used with the other quest keywords like KILL, GIVE, and ESCORT (thanks to BlackNova for the idea)

- added support for conditional testing of enum type property values by using the # modifier (e.g.  resource=#Iron or planthue=#Blue or loyalty!#WonderfullyHappy, where resource, planthue, and loyalty are all enum type properties and Iron, Blue, and WonderfullyHappy are values that they can take on).
At the present, the enum tests are restricted to equals and not equals (= and !).  I'll add < and > later.

- allow the property gump to be opened on items with null maps in [xmlfind.  Useful for tracking down the source of these items if you have problems with this.

- fixed a bug in [xmladd in which the Duration entry in the [xmladd gump was not being applied to added spawners. (Thanks to BlackNova for pointing this out).

- moved XmlAdd.cs from xmlspawner2-support1of2.zip to xmlspawner2-vxxx-2of2.zip since it is actually a required, rather than an optional script.

- npcs no longer automatically say "Thank you", or "I have no need for that." when given items for GIVE type quests.

- added the Condition property to BaseTalkingCreatures entries to allow conditional entry activation. Property tests are the same as those available to XmlSpawner2.

- added an example of the new Condition tests and quest options in jeweler2.xml and  jeweler2.npc.  The conversational
branches of Jules the jeweler will depend on the karma, fame, and amount of gold the triggering player is carrying.
With negative karma the jeweler will tell you to leave.  With fame < 5000 he will ask if you need help.  With fame > 10000 he will offer to tell you a rumor.  If you are carrying less than 100 gold, he will emote that you are a beggar.  If you are carrying over 1000 gold he will emote that you are wealthy.
The spawner also creates a questnote that calls for 3 exceptional platehelms to be given to Jules the jeweler.


Version 2.49
updated 7/24/04
- modified the way in which container spawns will respawn if just moved within the container.  In version 2.48 this was considered to have been taken and therefore could allow respawning.  Now, just moving things inside of a container will not allow respawning since these items will not be considered to have been taken yet (Thanks to siran for pointing this out).

- added some skill trigger optimizations to make skill testing map-specific.

- added TriggerOnCarried and NoTriggerOnCarried properties to TalkingBaseCreatures which are the same as the XmlSpawner counterparts to control activation of talking NPCs in mini quests.

- added the drop-in quest dracondarquest.xml that uses the new triggering features, along with the npc conversational files samantha.npc, winthrop.npc, and dracondar.npc.  
Unlike previous demonstration mini-quests that were designed to illustrate features for gms, this one is intended to run as-is for players.
Dracondar Quest Description:
The quest begins in the Mystical Lute in Minoc where the bard Samantha reveals a rumor regarding another bard by the name of Winthrop.  He has stolen a lute from a dragon and the dragon has offered a reward for its return. If the quest is taken by following the positive branch of the conversational tree, then she explains that winthrop can be found in lord british's castle.  To find him you must hide for a certain period of time in the proper room in the castle.  This will spawn Winthrop, and on questioning he will reveal the location of the lute, which is hidden in the bottom level of deceit.  To get it, the player must use the mining skill at the proper location which will spawn the quest lute.  This lute is then taken to the shrine of sacrifice, where playing it will call the dragon Dracondar.  when dracondar arrives, he will try to take the lute without providing the player any reward.  There is a conversational branch at this point.  If the player gets angry and threatens the dragon, the quest ends unfavorably, the player is poisoned and no reward is given.  If the player begs the dragon or asks nicely, he will be given the chance to complete the quest by returning the head of a named ancient lich that spawns nearby, but only between midnight and 3am.  The lich is a rare spawn and his placeholder liches must be killed in order to get him to spawn. Returning the head to Dracondar will then give the player a reward.  

- added the ability to search for items/mobiles with null map values in [xmlfind


Version 2.48
updated 7/17/04
- added spawner triggering on skill use.  By setting the SkillTrigger property to a string of the form "skillname[+/-][,minval,maxval]" the spawner can trigger when the named skill is used and optionally when the skill value falls within the specified range and is either successful (+) or unsuccessful (-).  If +/- is omitted then it will trigger on either success or failure - simply using the skill is enough.  For example, specifying a SkillTrigger string of "Hiding" would trigger the spawner whenever the hiding skill was used within the specified ProximityRange of the spawner, regardless of skill level or whether or not it was successful.  Using "Hiding,+" would trigger whenever the skill was successfully used. "Hiding,50,100" whenever the skill was used and the user had a skill level between 50 and 100 (inclusive).  "Hiding,-,50,100" whenever the skill failed and the user had a skill level between 50 and 100. Note, the skill names are case sensitive.  Several examples of skill triggering are given in xmlextras (skilltrigger1-4.xml).  Skilltrigger3.xml gives an example of how to spawn mobs or give special drops on mining based on skill level.  Skilltrigger4.xml demonstrates triggering on failed hiding. Skilltrigger1 and 2 trigger on musicianship. (Thanks to MarkC777 and Nix4 for the suggestion).

- added the property keyword "TRIGSKILL,name|value|base|cap" that returns information on the triggered skill for use in property testing and property value assignment.  See examples of this in the skilltrigger xml files.

- added a free running trigger mode that allows the spawner to execute multiple spawn entries after triggering with those entries behaving as though they had each been triggered by the same condition.  This is enabled by setting the FreeRun property on the spawner using "SETONTHIS/freerun/true".  The spawner will continue to run as though it were triggered until freerun is turned off with the spawn entry "SETONTHIS/freerun/false". An example of this is given in skilltrigger2.xml. Compare this with skilltrigger1.xml that uses a subgroup block to achieve a similar effect.

- extended the properties that are accessible to spawner manipulation to all public properties, not just those with the command property attribute (CPA) set.  This means that even properties that dont show up on the [props gump (those with CPA set) can be accessed if they are public.  An example of this is in the UsesRemaining property of musical instruments, which is public but not CPA.  Previously, such a property could not be set, but now an instrument can be spawned with a set number of uses with a spawn entry like "lute/usesremaining/25"

- added the SETONPARENT keyword for accessing properties on parent containers in container held spawners.

- minor modification to the way container spawned items are placed within the container.  If spawnrange is set to 0, then items will be placed at the spawner location in the container, enabling precise placement.  If spawnrange is > 0 then they will be randomly placed in the container. Previously it was based on item count, so that single items would be placed at the spawner location and multiple items would be scattered.

Version 2.47
updated 7/10/04
- added the TalkingBaseEscortable class.

- Added the GIVE type quest objective to XmlQuestTokens.  Using an objective string of the type "GIVE,mobname,item[,count]" or "GIVENAMED,mobname,itemname[,count]" will produce an objective that is satisfied when the specified item(s) are dragged and dropped onto the named mob.

- Added the ESCORT type quest objective.  Using an objective string of the type "ESCORT,mobname" will produce an objective that is satisfied when the specified TalkingBaseEscortable class mob is successfully escorted to its destination.
Note, the destination is specified by setting the Destination property on the escort to a region name.

- added support for Talking NPC keywords that use regular expressions.  Use of this can be seen in the talkingjewler.npc where one of the foul language keywords "hell", would also trigger on "hello".  By using these regular expression entries ([\s]hell[\s],^hell,hell$), the triggering can be made more specific to only match hell surrounded by whitespace, or at the beginning or end of a line. 

- added an example of the new quest types and the use of the new TalkingBaseEscortable class used for fetch and escort quests in "katarquest.xml" and "katar quest.npc". 

- changed the rules for invalid XmlQuestTokens to eliminate hording or trading so that they can no longer be placed in containers and will automatically return to the player's pack if the player attempts to place them in any invalid location (such as another container, a bankbox, or another player).  If they are placed on ground they will be automatically deleted.

- added optimizations for KILL type quests in which only players that are flagged as carrying XmlQuestTokens are checked on kills.

- added the 28 doom artifacts/rares based on DarkRages previously submitted doom rares using the new stealable system.  Item locations, rarity, and spawn times were based on information taken from the UORares (www.uorares.com) and Pacific Trading Company (www.pacifictradingco.net) sites (many thanks for that helpful information).  Any additional information for fine tuning the spawns is welcome.  For example, I may not have gotten the precise location of some of the items exactly right.
These items can be found in the xmlspawner2-support2of2.zip file under DoomRares.  The spawn file is in  Spawns/Malas/DoomRares.xml in xmlspawner2-xmlextras.zip

- added a a new system for flagging items as stealable, Any item can flagged as stealable with this system without any modification to the item scripts. 
An item that is flagged as stealable overrides all other restrictions on stealing such as blessed, newbied, and locked down.  Once an item has been stolen, it returns to normal status and follows the same rules as other items so that it can be safely locked down by players without danger of being re-stolen.   
This system also modifies the difficulty for stealing artifacts based on the ArtifactRarity property.  Any item that has the ArtifactRarity property will work with this system, including existing items (see the spawning examples of the existing doom artifacts such as the ZyronicClaw).  Artifact stealing difficulty is not based on weight but on rarity.  Artifact rarity of 1 requires a minimum of 100 stealing and the difficulty scales linearly with rarity up to rarity 12 which requires a minimum of 118 stealing.  

- added the new command [stealable that allows any item to be examined or set for stealability

- added the new STEALABLE property keyword for spawner support of the new stealable system.

- reinstated support for the flag fix for resolving issues of maintained spawner control on spawned items.  See the end of this file for an explanation of the issue.

Description of katarquest.xml: 
This spawns an orc and two talking NPCs, one is a TalkingBaseEscortable.  One spawner (KatarQuest#1) sets up the NPCs and the other is for delivering the reward when the quest objectives have been met (KatarQuest#2).

spawner (KatarQuest#1)
0	orc/x/INC,40/ADD/<longsword/name/Shemps Blade/hue/32>
0	talkingbaseescortable,0/name/Shemp/destination/britain graveyard
1	xmlquestnpc,1/name/Katar/configfile/katar quest/loadconfig/true

The first entry creates an orc and then moves him 40 tiles away.  It also adds the quest item named "Shemps Blade" to his pack.
The second entry creates the escortable NPC named Shemp (the zero arg passed to the constructor forces him to be male) and assigns his escort destination to the "britain graveyard" which is a defined region name.
The third entry creates the talking NPC Katar (the arg of 1 passed to the constructor forces her to be female) and loads it with the conversational configuration file named "katar quest.npc"

spawner (KatarQuest#2)
1 	SETONSPAWN,KatarQuest#1,1/SAY/Thank you for your help! Here is your reward
1	TAKE/Help Shemp
1	GIVE/LOOTPACK,filthyrich

TriggerOnCarried "Help Shemp"
ProximityRange 5
MinDelay 1 sec
MaxDelay 1 sec

The first entry has the Katar NPC (subgroup 1 on Spawner KatarQuest#1) say something
The second entry takes the "Help Shemp" questnote from the player.
The third entry gives a random lootpack reward of the filthyrich level to the player.

Katar quest.npc

This file contains the conversation that drives the quest, and also has the npc handing out the questnote for the quest.
There are 5 random banter entries.

When a player initiates a conversation with any of the keywords "hello,greetings,hi,help,trouble", Katar describes the situation and then gives the player a questnote through the html entry in katar quest.npc

<Action>GIVE/&lt;questnote/name/Help Shemp/titlestring/Shemp/notestring/Return Shemp's sword and take him to visit his mother's grave./objective1/ESCORT,Shemp/objective2/GIVENAMED,Shemp,Shemps Blade&gt;</Action>

which GIVES the player a questnote named "Help Shemp" with the objectives "ESCORT,Shemp", and "GIVENAMED,Shemp,Shemps Blade".
To satisfy these objectives, the item Shemps Blade must be taken from the orc that carries it and given to Shemp by dragging and dropping it onto him.  Then Shemp must be escorted to his destination location.


DESCRIPTION:
Version 2.46
updated 7/2/04

- fixed a bug in [xmlfind which was referencing items from the incorrect display page with reset/respawn/delete in a multi-page selection list.

- added checks to prevent attempts to respawn through the use of the DoRespawn property during a respawn.  This was possible if you had a spawner attempt to respawn itself in a spawn spec.  Respawning would lock the spawner in recursion.  It now properly supports spawner self-respawning.

- added support for a default "Spawns" subdirectory for saving and loading .xml spawn files.  If this subdirectory exists in the main RunUO installation directory the [xmlload, [xmlunload, and [xmlsave type commands will automatically look here first for the files (thanks to ekardnam for the suggestion).

- added a new TalkingBaseCreature class that can be used to make interactive talking creatures by using it anywhere that BaseCreature is used .  The XmlQuestNPC is derived from that class and an example of a talking drake is included as talkingdrake.cs (it is just the drake.cs file with TalkingBaseCreature replacing BaseCreature as the base class) along with an xml file to load it in talkingdrake.xml and an npc file to program its speech in drake.npc

- added a new TalkingBaseVendor class that can be used to make interactive talking vendors by using it anywhere that BaseVendor is used .  An example of a talking jeweler is included as talkingjeweler.cs (it is just the jeweler.cs file with TalkingBaseVendor replacing BaseVendor as the base class) along with an xml file to load it talkingjeweler.xml and an npc file to program its speech in jeweler.npc

- added the LockConversation property to to talking NPCs allowing you to specify whether a conversation with the NPC should be locked to the first player to interact with it (LockConversation=true) until the conversation resets, or whether you want it to be able to interact with anyone at any time (LockConversation=false). This also allows a new conversationalist to be established in mid-conversation when it is disabled in a single entry. This is true by default.

- added the AllowNPCTrigger property to each speech entry in talking NPCs that allows npcs to trigger a speech entry.  This allows conversing npcs to be set up. This is false by default. An example of this is given in whosonfirst.xml that loads the npcs Abbott.npc and Costello.npc in which they perform part of their classic Who's on First routine.

- added the PrePause property to each entry in talking NPCs that allows a pause to be introduced before the speech is displayed for the appearance of more natural conversational flow.
Note, this differs from the Pause property which defines the pause until the next entry can be triggered. (prepause = pause before, pause = pause after).   Using the default value of -1 enables automatic delay calculation based upon the length of the triggering speech.

- added the "*" match-all keyword to talking NPCs for conversational triggering that will allow any speech to advance the conversation from that point.

- added the SpeechStyle property to talking NPCs that allows you assign a MessageType to a speech entry like Regular (the default), Yell, Whisper, Emote.


Version 2.45
updated 6/27/04
- added the and (&) and or (|) operators to allow compound conditional tests of the form  "a=b & c<d",  "e<f | g!h".  These can be extended arbitrarily, i.e. "a*b $ c*d $ e*f $ g*h ..." , where * is one of <>!= and $ is one of &|, but the current default grouping precedence is not exactly intuitive.
Default grouping follows this rule  "(a*b $ (c*d $ (e*f $ g*h)))" where, due to parsing efficiency, conditional pairs at the end of an
expression are tested first and then recursively work their way back to the beginning.

An example of using this feature is given in chestguardian2.xml in xmlextras.
In this example the guardian spawner is triggered by the property test (TriggerObjectProp)  "totalitems<1 | totalweight<20" which will lead to triggering of the chest guardian if anyone removes the pile of gold from the chest completely (leaving totalitems=0), or removes some of the gold, (reducing the totalweight to below 20).
Another example is given in chestguardian3.xml in xmlextras.
In this example the guardian spawner is triggered by the property test (TriggerObjectProp)  "totalitems>1 & totalweight>40" which will lead to triggering of the chest guardian if at least one additional item is added (totalitems>1), and the added items weigh enough to push the totalweight above 40.

- added the special property keyword COUNT to be used in GETONSPAWN,subgroup,COUNT or GETONSPAWN,spawnername,subgroup,COUNT to allow access to the number active spawns on a subgroup.
An example of the use of this feature is given in orcpurge.xml in xmlextras.

- added optimizations for speeding up access to properties on objects (gets, sets, conditional tests, property assignments).  As a benchmark, standard spawning of a single mob (e.g. orc) takes about 500 microseconds (absolute number will be machine dependent, this is on a 1.7GHz P4 Centrino) which is the same as the distro spawner.  Spawning a mob with one property set (e.g. orc/hue/500) used to add about another 220 microseconds with most of that going into searching the property list for the named property (hue).  With optimization it now only adds about 60 microseconds with each additional prop adding the same (e.g. orc/hue/500/name/blah takes about 620 microseconds ). So about a 4-fold improvement in performance.

Description of orcpurge.xml: 
This spawns orcs and broadcasts messages depending on how many are currently spawned.  This is example
demonstrates how the COUNT property keyword is used with the GETONSPAWN keyword to make spawn-count dependent spawning.  When the orc count
goes above 2 then the message "Isnt anyone going to clear out these orcs?" is broadcast. When it goes above 5 the message "We are being overrun!" 
is also broadcast.  When the orc count is zero then the message "Calm is restored. The orcs have been purged." is broadcast.

spawner (OrcPurge#1)
1	orc	maxcount=7
2	IF/GETONSPAWN,1,COUNT=0/55
2	IF/GETONSPAWN,1,COUNT>2/33
2	IF/GETONSPAWN,1,COUNT>5/44
5	GOTO/1
33	BCAST/Isnt anyone going to clear out these orcs?
44	BCAST/We are being overrun!
55	BCAST/Calm is restored. The orcs have been purged.

mindelay=10secs
maxdelay=10secs
sequential spawning


Version 2.44
updated 6/21/04
- fixed a crash bug with GET keywords trying to access invalid property names (thanks to Fluke for pointing this out).
- modified XmlQuestNPC speech triggering so that once a conversation is started with one player, it wont listen to speech from anyone else until the npc resets
- changed the XmlQuestNPC default pause between non-keyword triggered dialogue entries from 5 to 2 seconds.

Version 2.43
updated 6/16/04
- Inspired by the excellent conversational NPC by Arya, I have added a new mobile, the XmlQuestNPC.
This mobile can be programmed with branching conversational sequences that are advanced by keywords at each sequence point.  Additionally, an action can be associated with each sequence point.  The action is a string that is treated as an xmlspawner spawn spec, so it can include spawned items, mobs, keywords, etc.  basically anything that could be entered as an xmlspawner spawn spec.
Therefore XmlQuestNPC can be thought of as a conversationally driven spawner.
Multiple entries activated by the same keyword can be associated with a branch point (one-to-many branching) in which case one of the entries is chosen at random.  This allows for random variability in a conversational sequence, with each branch having its own unique text and actions, while still allowing for the branches to end at a common conversational sequence point.
If no keywords are specified, then an entry can be automatically advanced after a time delay specified by the Pause field (in seconds) of the current state has elapsed.
Each entry will check its DependsOn field to determine if it can be reached from the current point in the conversation (defined by the ID of the currently active conversational entry).
The DependsOn value will be checked against the ID field for the current entry.  Note, this is not necessarily the same as the EntryNumber.  By allowing multiple entries to share the same ID one can set up a many-to-one branch convergence in which separate conversational branches can converge back to a common point. See how this is used in the testnpc example to allow the conversation to begin with 7 randomly selected spontaneous entries, with the first keyword driven entry (entry 0) depending on have activated any of them (since they all share the ID of 3).
ID defines the conversational state, entrynumber is just used to keep track of the separate entries and can be any arbitrary number.
Conversations will reset after a period of inactivity defined by the ResetTime property (they reset to entry 0).
By default conversations begin at EntryNumber 0.  
If an entry has a DependsOn value of -1 (doesnt depend on any previous conversational state), then it can be activated spontaneously by players movement within the ProximityRange of the NPC.  Once activated (i.e. a conversational sequence has begun), spontaneous entries will not be activated until the conversation is reset (i.e. the conversation is over).
The NPC definition can be saved to, or loaded from an xml file that has the default .npc extension. 
An example of an npc definition file is included in xmlextras as testnpc.npc.  Also, a spawner that automatically creates an xmlquestnpc and loads the configuration is included as questnpc.xml. To try out all of these features, just "[xmlload questnpc.xml" .
There is no gump interface at this time, but I will add it in later.  While it is possible to program the NPC directly from the [props gump, or via a spawner (first select EntryNumber and then enter the values for that entry), the best approach at this point is to edit the .npc files and load them.
To facilitate this, two commands have been added. "[savenpc filename"  allows you to target an XmlQuestNPC and save its configuration information to the named file. "[loadnpc filename" allows you to target an XmlQuestNPC and load its configuration information from the named file.
By default, .npc files will be saved/loaded to the main RunUO directory, or to the XmlQuestNPC subdirectory in the main RunUO directory if it exists.
So you could do an "[add xmlquestnpc", and then "[loadnpc testnpc" and target the new npc to load it with the configuration information in testnpc.npc
- Restructured a number of BaseXmlSpawner calls in order minimize or eliminate specific XmlSpawner dependencies, allowing entities such as the XmlQuestNPC to invoke the basic spawning methods.  I've tried to test everything out to make sure no bugs crept in as a result, but keep an eye out.
- Added the SETONTHIS keyword for selfreferencing (see how it is used in the testnpc example).

Description of the testnpc.npc file:
The file begins by defining an npc name Bugwort that is activated by players within a range of 3 tiles.  The conversational sequence will reset after 15 seconds (0.25 mins) of idle time.
There are 14 speech entries.
7 of these entries have DependsOn of -1, which means they can be spontaneously triggered.  When a player approaches the npc it will make one of the following 7 statements.
Each of these has an ID of 3, which defines them as all belonging to the same conversational state (3)
Are you new here?
A fine day!
It looks like rain.
I wish I hadn't drunk so much last night. hic!
Who says my hump is unattractive.
My, you are an ugly one.
Hmmm, what's that smell?  <pause of 2 secs> Oh, its just you.

The first conversational keyword driven entry is entry 0 which DependsOn 3. This can be activated after any of the spontaneous statements has been activated and a player says any of the following keywords:  hello,greetings,stranger,new
after which the npc will respond with:
Greetings stranger. (entry 0) <pause of 1 sec> It is so hard to tell who is a friend and who is an enemy these days! (entry 4, DependsOn 0, no keywords)
and will execute the SOUND,1055 action (throat clearing sound)

There are 3 conversational branches from this point depending on how the player responds.

saying the keyword: enemy
will activate the entry 2 which DependsOn 4 and has this response
Then we fight to the death!
and activates this action:
SETONTHIS/combatant/TRIGMOB/DAMAGE,80,10,10,10,70,5,playeronly/EFFECT,14000,15/POISON,greater,5,playeronly/
which directs the npc to attack the triggering player by setting its combatant field to the triggering player, and also apply damage of 80 distributed over phys,fire,poison,energy to all players within 5 tiles, poisons players within 5 tiles with greater poison, and displays an explosion effect over the npc.

saying the keyword: friend
will activate entry 1 which which DependsOn 4 and has the response
Glad to hear you are a friend. I have left you a simple gift in the nearby chest.
and activates the action:
SET,checkitout/ADD/&lt;longsword/hue/500&gt;/EFFECT,14662,15/
which adds a blue longsword to the nearby chest named checkitout, and displays an animated effect over it.

saying any of these non-obvious keywords: master,lord,king
will activate the entry 8 which DependsOn 4 followed by 9 which DependsOn 8 to produce the response
Ah, I didnt recognize you m'lord! <pause of 1 sec>  Please accept this generous gift!
and activates the action:
GIVE/LOOTPACK,filthyrich
which places random items from the filthyrich lootpack template (luck-dependent) into the triggering players pack

there is no further progression of the conversational branching, and it will reset back to the initial state after 15 seconds.

Version 2.42
updated 6/10/04
- Added the DespawnTime property that specifies the maximum time in hours that a spawn can exist before being automatically deleted.  By default this is set to zero which means the spawn will never be automatically deleted.  Setting this to 24 hours will lead to spawns that get automatically refreshed every 24 hours.  Note, this will work on both item and mobile spawns, but mobiles will not be deleted while players are around (an active zone). It can also be used to create limited duration spawns, much like using the Duration property, except that Duration can be less than the min/max delay period and allows very precise timing control (because it is run on a separate timer), while DespawnTime is only checked during Defrag (every min/max delay period), does not have a separate timer, and would therefore be used for longer time window despawning. Can be used to make difficult or rare mob spawns time limited.
Thanks to Ingvarr who originally suggested this feature as a way of dealing with idle spawns that may be in inaccessible locations.  Unlike SpawnIdleTime, this is a property that can be set individually for each spawner. When used with items that spawn in containers it would allow them to decay just as items on the ground normally would.  This could be used with triggered container spawns that you only wanted to last for a limited period of time before being removed so that the spawner could be triggered again.  For example, you could set up a triggered spawner that filled a container with loot that was a function of the triggering players luck or fame, and then even if the player didnt take the loot it would only last a limited period of time and the spawner would be ready for triggering by another player.
- Added the "LOOTPACK,loottype" keyword.  This can be be used to add items to a mob or container using the distro lootpack system.  The loottypes are poor, meager, average, rich, filthyrich, ultrarich, superboss.  If the keyword is used in a triggered spawn, then the luck of the triggering mob will also be factored in when generating the loot (otherwise a default luck of zero is used in the loot calculation). Because of the way in which distro lootpack generation works, lootpacks added to a container will not contain stackable items such as gold. 
- Modified the properties list to display spawner name on mouseover or mouseclick.
- Modified region initialization for spawning by region.  This resolves an issue with custom regions that may be defined after the spawner assigns regions. (Thanks to Thraxus for pointing this out).
- added an example of the new features in lootpack.xml.

Description of lootpack.xml: 
This spawns a container containing a lootpack triggered by a player coming into range.  This is an example that
demonstrates how the LOOTPACK keyword and the DespawnTime property can be combined to set up time-limited, luck-dependent spawns.
The spawner spawns a metal chest, ADDs an ultrarich lootpack that will depend on the luck of the triggering mob, makes it immovable, and hues the chest. It sets the DespawnTime property to 30 seconds, which means that after 30 seconds, the chest will disappear.  The RefractoryMin/Max properties are set for 2 mins, which means the spawner cannot be triggered again for 2 mins.  A ProximityTriggerMessage is also set announcing the appearance of the chest.

spawner (Lootpack#1)
0	metalchest/ADD/LOOTPACK,ultrarich/hue/1150/movable/false

mindelay=0secs
maxdelay=0secs
proximity triggering enabled (range=5)

Version 2.41
updated 5/19/04
- Added a test for idle spawns that may be in inaccessible locations and hence should be relocated.  Spawns that are idle (not respawned) for more than SpawnIdleTime (72 hour default, defined by a constant in xmlspawner2.cs) will be repositioned as though they were being respawned. (note, they are not actually respawned).  Vendors, bankers, and healers are not tested and will never be repositioned. 
This feature can be disabled by setting the SpawnIdleTime to -1 (actually any value less than or equal to zero).  (Thanks to Ingvarr for the idea.)
Note, spawns that were made using version 2.40 with the ignore surface requirement flag (*) should be manually respawned once to be sure that the repositioning algorithm handles them properly.  That only needs to be done once, and only for the special case of *spawns made under 2.40.
Also note, you can easily locate and respawn these spawns using [xmlfind with * as the entry string, searching, then selecting them all with the select column button in the upper right, and press the respawn button.
- fixed a minor inconsistency in the default SpawnRange.  Spawners that were manually added with the "[add xmlspawner" command were getting a default spawnrange of zero, while those placed with the "[xmladd" interface would default to 5.  Now they both assign defaults of 5.
- optimized object lookup for named items/mobs/spawners.  This will significantly improve performance of keywords that refer to named objects such as the SET and GET series.
- fixed a problem that was recently introduced in which displaced X1_Y1 spawn region specifications were not correctly restored during [xmlload (they were being centered on the spawner instead of at their actual displacement).  This could be seen in the deathmaze.xml example which now loads with the proper geometry (walls form a square region instead of a plus). 

Version 2.40
updated 5/11/04
- Added the ability to flag spawns to ignore the normal surface requirement for spawning by adding a leading '*' to the spawn spec.  This allows spawns on water as well as on objects such as tables or other normally invalid locations.  (thanks to Knightshade for the suggestion).  For example, to spawn water elementals so that they will can be placed on water, spawn them as *waterelemental instead of just waterelemental.
- Added the ability to access spawns from other spawners through the GETONSPAWN and SETONSPAWN keywords.  The new extended syntax is "GETONSPAWN[,spawnername],subgroup,propertyname" and "SETONSPAWN[,spawnername],subgroup/prop/value/..."
- Added a SERIAL property value keyword that is used anywhere that a property name would be used but returns the serial id of the target. Only supported for GetProperty not SetProperty (i.e. you can get the serial id of an item/mob but you cant change it).  
- Note that the SKILL property keyword is no longer needed in RC1-0 since skills can now be accessed directly as named properties instead of by index into the Skills array.  So you can do things like spawning a mob with an archery skill of 100 using "orc/skills.archery.base/100"
- Modified booktextentry to allow spawn entries of more than the previous limit of about 230 chars.  Now text entry is only limited by book length (20 pages, or about 3000 chars)
- Examples of these features has been added to xmlextras in the files waypoint.xml, chestguardian.xml, and doorguardian.xml

  
Description of doorguardian.xml: 
(note, after loading the example do a respawn on both to quickly set them up)
This uses two spawners. One spawns three doors, and the other spawns a mob that is triggered by opening one of the doors.  This is an example that
demonstrates how the SERIAL and GETONSPAWN keywords can be combined to set up self-configuring triggered spawners rather than having to explicitly
use targeting to select triggering objects.  The first spawner spawns 3 metal doors and makes them immovable. At the same time it sets the TriggerObject property on the second spawner (named DoorGuardian#2) to the serial id of the first spawn entry (one of the metal doors).  It also sets the TriggerObjectProp propery of the second spawner to "open=true", which will cause the second spawner to be triggered when that door is opened.
The second spawner simply spawns the guardian mob that is a standard troll with its hits and str buffed.
Each line is a spawn entry and the number next to it refers to the subgroup assigned to the entry.

First spawner (DoorGuardian#1)
1	metaldoor,0/movable/false
1	SET,DoorGuardian#2/triggerobject/GETONSPAWN,1,SERIAL/triggerobjectprop/open=true

Second spawner (DoorGuardian#2)
troll/name/Door Guardian/hitsmaxseed/1000/hits/1000/str/200

Note, this spawner example is exactly the same as manually creating the doors, then creating the guardian spawner and setting its TriggerObject and TriggerObjectProp properties by hand.


Description of chestguardian.xml:
This is similar to doorguardian.xml but uses chests instead of doors, and is triggered when a player removes the contents of the chest.


Description of waypoint.xml:
Uses a spawner to create waypoints and randomly move them, and then spawns mobs and assigns them the waypoints created by the spawner.


Version 2.39
updated 5/07/04
- Modified the SETONSPAWN keyword to allow all spawned members of a subgroup to be set instead of just the first member.
- fixed a typo that was looking for GETONSPAWNED instead of GETONSPAWN in the keyword check for property assignment.
- Added support for setting item/mobile type properties by serial number.  This allows properties such as combatant, or anything else that would normally be assigned by targetting to be set using the SET series of keywords.  
- added a new xml example in xmlextras that uses these two new features  (masterhelper.xml).  This example is shown below.
Each line is a spawn entry and the number next to it refers to the subgroup assigned to the entry.
  
Description of what this spawner does:
This will spawn 8 orcs, 4 orcish lords and a troll with the name "Orc master".  
Entry number 3 checks to see if the troll is attacked (its combatant property is not null).  If it is, then it spawns subgroup 33 which sets the combatant property of all of the spawned members of subgroup 1 (all of the orcs and orcish lords) to the attacker of the troll and also has them all say a message.

Spawner example taken from masterhelper.xml in xmlextras:

1	orc 		maxcount=8
1	orcishlord	maxcount=4
2	troll/name/Orc Master
3	IF/GETONSPAWN,2,combatant!(-null-)/33
4	GOTO/1
33	SETONSPAWN,1/combatant/GETONSPAWN,2,combatant/SAY/We are coming master!

mindelay=2secs
maxdelay=4secs
sequentialspawn enabled


Version 2.38
updated 5/06/04

- Added the "GETONSPAWN,subgroup,propertyname" and "SETONSPAWN,subgroup/prop/value/..." keywords.  These can be used to get and set properties on spawns that have already been created.  They are referenced by the subgroup number of the target spawn entry and will return or set the value of the first spawned member of the subgroup.  An example is shown below (this can also be found in the xmlextras file changeling.xml).  Each line is a spawn entry and the number next to it refers to the subgroup assigned to the entry.
  
Description of what this spawner does:
This will spawn a daemon (subgroup 1) and then an orc (subgroup 2).  After they are spawned, entry number 4 will randomly change the color (between 50 and 100) and body type (between 16 and 21) of the daemon by using SETONSPAWN and referring to the daemon's subgroup number (SETONSPAWN,1). 
Next, entry number 5 will test to see if the hits on the orc spawn has dropped below 40.  If it has then it spawns subgroup 77 which will cause the daemon and orc to say some things including each others names, and the ai of the daemon will be changed to healer (causing it to heal the orc).  
After entry number 5 is complete, entry number 6 will randomly spawn either subgroup 55 or 66 which switch the ai of the daemon to either melee or mage type.  At the same time the daemon and the orc will say some things including named references to their friend.
Entry number 8 then sets the spawn sequence back to entry 1.
Note the use of the substitution delimiters {} along with the GETONSPAWN keyword to place properties such as the name of an existing spawn into a spawn spec.
Also note the use of GETONSPAWN in the IF conditional of entry 5 to test for values on existing spawns. 

Spawner example taken from changeling.xml in xmlextras:

1	daemon
2	orc/SAY/I'm {GETONSPAWN,1,name}'s buddy
4	SETONSPAWN,1/hue/RND,50,100/bodyvalue/RND,16,21
5	IF/GETONSPAWN,2,hits<40/77
6	IF/RND,0,1=1/55/66
8	GOTO/1
55	SETONSPAWN,1/ai/ai_melee/SAY/I will crush you!
55	SETONSPAWN,2/SAY/Whack em {GETONSPAWN,1,name}
66	SETONSPAWN,1/ai/ai_mage/SAY/I call upon the circles of magic!
66	SETONSPAWN,2/SAY/Blast em {GETONSPAWN,1,name}
77	SETONSPAWN,1/SAY/I will defend you {GETONSPAWN,2,name}
77	SETONSPAWN,2/SAY/Help me {GETONSPAWN,1,name}, I'm hurt!
77	SETONSPAWN,1/ai/ai_healer

mindelay=2secs
maxdelay=4secs
sequentialspawn enabled


Version 2.37
updated 5/02/04
- Added substitution delimiters { and }, used as {keywordspec} with the GET series and RND keywords to replace strings in a spawn spec prior to actual spawning.  The way this works is that prior to spawning a spawn spec, any instances of {keyword}, anywhere in the spawn spec, are replaced by the results of the keyword evaluation (works with GET series or RND keywords). Then the resulting spawn spec is spawned as usual.  Since the GET keywords allow you to read strings and other values off of mobs and items, this feature allows you to have items/mobs and their properties define/modify spawn specs. 
See an example of the use of this feature with the new Rewardstring property on XmlQuestToken items such as the questnote.
Another use would be customizing spawns based on the triggering mob.  e.g. the spawn spec "orc/SAY/I will have {GETONTRIGMOB,name} for lunch!" would spawn an orc that would say the message that would include the name of the triggering player. Note that string values are stripped of their beginning and ending double-quotes (") when being substituted. 
- Added a literal modifier for setting of property values with otherwise invalid chars.  Preceding a property value with the '@' sign will cause the remainder of the line to be assigned as the value.  This can be used to assign strings that contain otherwise illegal chars such as the '/'.  For example, to set the new Rewardstring property on a quest object you might use the spawn spec "questnote/name/blazequest/Rewardstring/@GIVE/<longsword/name/Blazer/weaponattributes.hitfireball/50>" this would set the Rewardstring property on the questnote to the string "GIVE/<longsword/name/Blazer/weaponattributes.hitfireball/50>". When combined with the new substitution delimiters, a reward spawner could read the Rewardstring property and spawn the string that it contained by using the spawn spec "{GETONCARRIED,blazequest,Rewardstring}"  which would then become the spawn spec "GIVE/<longsword/name/Blazer/weaponattributes.hitfireball/50>".
- Added the RewardString property to XmlQuestToken items such as the questnote.  This is a string that can be assigned and then used to spawn a reward.
- modified permissions for a few commands. Changed [xmlget, [xmlset, and [xmlhome from Admin to GameMaster.
- Added the ability to set the default gump position for the [xmlfind gump along with the other gumps through the Options button.
- Added example xml files to Xmlspawner2-xmlextras.zip that demonstrate the new features. blazequest.xml makes use of the new rewardstring and substitution system, and pickem.xml demonstrates a few uses of substitution to provide more dynamic, player-specific spawning. Also modified the config file (xmlquesttoken.xml) to assign a rewardstring in a questnote using LoadConfig.


Version 2.36
updated 4/27/04
- Added the BCAST/msg keyword to send shardwide messages to all players  (thanks to Bane for the suggestion).
- Added the SAY[,prob]/msg keyword that is used as part of a spawn spec to cause the item or mob to say the given message with some probability.
Similar to the MSG keyword. 
- Added the JEWELRY,minlevel,maxlevel keyword for random magic jewelry drops.
- Added the ability to set the default gump positions for the main spawner gump and the [xmladd gump.  These are saved in the defaults files (Save/Load buttons in the [xmladd gump).  They can be set via the Options button in the [xmladd gump.
- Added a -defaults option to the [xmladd command (can be used to restore the default values in the same way as pressing the Restore Defs button in the [xmladd gump). It is called as "[xmladd -defaults".
- Added an example to demonstrate the use of the new keywords in the file v236.xml in xmlextras.

Version 2.35
updated 4/22/04
- Added the ability to specify a list of spawn entries in the [xmladd gump.  Specific entries to be included in an added spawner can be selected using the check boxes to the right of each entry.  Named default configurations including all spawner settings and spawn lists can be saved to files.  Each staff can maintain their own default configurations.  Multiple named configurations can also be maintained.  For example, a dungeon spawn configuration could be made that included typical undead dungeon spawns, and this could be saved to the dung1 configuration file, while a regs file containing lists of regs could be saved to the regs1 config file. You are not required to assign a name in which case it just saves it as an unnamed (the standard) config.  e.g. try clicking on RestoreDefaults and then just click on Save without entering any config name.  You will see how it is saved.
The configuration files are given the .defs extension and will be saved either to the root installation directory or to the SpawnerDefs directory if it exists in the main install directory.
The extended gump displaying the spawn entries can be shown/hidden with the gump extension button in the lower right of the gump.
- Modified the ARMOR and WEAPON keywords so that they only drop armor and weapons, not jewelry.
- Added the JWEAPON and JARMOR keywords that drop weapons or jewelry, and armor or jewelry (these are the same as the previous ARMOR and WEAPON keywords, and yield the same type of drops as the PackArmor and PackWeapon basecreature methods).

Version 2.34
updated 4/20/04
- Added the [xmladd command that opens a tool for adding xmlspawners with default settings that can be entered in the gump.  Settings are maintained individually for each staff while the server is running but are not saved/restored on server restarts.  The most recently added spawner can also be deleted or can be teleported to.

Version 2.33
updated 4/18/04
- fixed a problem with duped spawners not being assigned the correct spawnrange.
- changed the refresh order for props and spawner gumps called from [xmlfind so that they appear in front.
- added the ability to delete items/mobs from the xmlfind gump, as well as reset, and respawn selected spawners.  To use these features, select items in the xmlfind gump by toggling the selection button to the right of each entry.  The toggle at the top of the column will toggle all of the selection buttons in the column.  Selected entries are colored red.  Then clicking on the delete button will bring up a confirmation gump asking if you want to delete the items/mobs.  If the selections are xmlspawners then you can also reset (clear spawns, turn off spawner), or respawn all of the selected spawners.  After deleting you can see the updated status of the items by clicking on the refresh button next to the Display text entry field in the lower right of the gump.
- added an xmlfind search button (err) to allow you to find spawners that are reporting status errors.
- added the script for the Commoner NPC used in some of the sample mini-quests in xmlextras.

Version 2.32
updated 4/14/04
- Added the [xmlfind command that provides a gump interface to search for any world item/mob/spawn based on type, name, distance from player, or map or any combination of them.
It can also search for Xmlspawners or regular spawners that contain specified spawn entries.  Search results can be sorted on the same attributes, and the player can be teleported to the location of the item/mob/spawn, can open its properties gump, or can open the spawner gump if it an xmlspawner or regular spawner, all directly from the xmlfind gump.  Container held items are highlighted with the location of the parent given.  After teleporting to any mob/items the player can return to the original location at which they first opened the gump.
- Added the GET series of keywords. "GETONTRIGMOB,property" , "GETONCARRIED,itemname,property", "GETONMOB,mobname,property", "GET,itemname,property".
These can be used as a value specification in any spawn string or in conditional tests e.g. with the IF keyword. For example, using a spawn spec of the form "IF/GETONTRIGMOB,fame>1000/77/66" and subgroup 66 that has a spawn spec of "SET/locked/true" and subgroup 77 that has a spawn spec of "gold/amount/GETONTRIGMOB,fame/amount/MUL,0.1" and "SET/locked/false", the sample .xml file fameopen.xml contains a spawner that will open a door, spawn a mob, and then drop an amount of gold that is 10% of the triggering players fame, but only if the triggering mob has fame>1000, otherwise the door is locked. To try this out just [xmlload the file, create a door ([add metaldoor 0) and set the SetItem prop to point to the door.
- fixed a problem with the WAITUNTIL keyword being called without a timeout argument waiting indefinitely.
- fixed a problem with the [xmlnewload and [xmlnewloadhere commands in which doing a new load with self-referencing spawners while the original load was still present could alter references on the original.  Newload spawners now are forced to take unique names to avoid any confusion with existing spawners.  The new names are assigned as the original names with a unique guid appended.
- fixed [xmlload error reporting so that spawner references that get resolved in the second self-reference resolution pass are not reported as errors. So now when it says that there is an error during loading there really is.

Version 2.31
updated 4/4/04
- Added the LoadConfig and ConfigFile properties to the spawner allowing them to read their configuration information from an XML file.  This is similar to the [xmlload command except that it does not create a new spawner to replace an existing one.  This allows updating of selected properties without having to respecify all of the properties. e.g. having an .xml file that just contains the spawn object definitions being loaded into an existing triggered spawner would allow that spawner to have dynamically configured spawns.  The spawner property names are identical to those contained in the standard [xmlsave files.
The dataset and table names have been changed to avoid any possible confusion as to what is intended to be a fully specified [xmlloadable .xml file and a partially specified config file.  An example of several .xml config files are included in the xmlextras package.
Several ways in which this could be used would be to have a switch or other object target the spawner with the TargetProperty string "/configfile/dynamicspawn.xml/loadconfig/true" or have a spawner do the same thing with a spawned SET command "SET/configfile/dynamicspawn.xml/loadconfig/true" and the target spawner as the SetItem target, even having a spawner reconfigure itself.

- Split out many static functions to a new BaseXmlSpawner class

- Added a new proximityrange setting.  Setting proximity range to -2 disables both proximity detection as well as free spawning.  This allow a spawner to be set to spawn only under external direction by having the ProximityActivated property explicitly set to true by some external agent, such as another spawner, or a switch, etc.
This can be used to create spawn chains that are triggered by one spawner, and then propagate to other spawners.  e.g. Have a quest spawner that triggers on a player, and then causes another spawner to trigger using the spawn spec "SET/triggermob/TRIGMOB/proximityactivated/true".  Because the proximityrange is set to -2, this becomes the only way to activate the spawner.

- Added 4 new flow-control keywords, WAITUNTIL, IF, WHILE, and GOTO

- Added the WAITUNTIL[,duration][,timeout][/condition][/spawngroup] keyword that holds spawning and triggering until a given time elapses or a given condition is satisfied.
If called as "WAITUNTIL,duration" this essentially creates an empty spawn that will last for the specified duration in minutes.
If called as "WAITUNTIL/condition" it will hold further spawning until the condition is satisfied.
If called as "WAITUNTIL/condition/spawngroup" it will hold spawning until the condition is met, and then spawn the specified subgroup.
The timeout can be used to add in a safety release to prevent indefinite blocking of spawning if a condition may never be met.
If the duration is used in conjunction with a condition, then it will control the polling time (frequency with which the condition is checked).
In general this keyword can be used to introduce simple delays into sequential spawning patterns or to pause spawning until a particular condition is met.
An example is provided in the xmlextras file that shows how it can be used to spawn gumps and wait for responses.
An important characteristic of WAITUNTIL is that the spawngroup will be spawned with the triggering information of the keyword.  This allows for a series of spawns to be triggered once, with the triggering player information carried forward throughout all of them without any further retriggering.  The xmlextras example provided is a good example of the application, where a player activates a series of gumps which are delivered only to that player, and the spawner is only triggered at the beginning of the series.

- Added the IF/condition/thenspawn[/elsespawn] keyword that will spawn the specified subgroups if the condition is met. Note, this does not change the sequential spawn index to the specified subgroups.  Think of them as subroutines that are executed followed by return of control to the point of the If keyword.

- Added the WHILE/condition/spawngroup keyword.  This allows spawning to be maintained at a certain group until a condition is met.  As with the IF and WAITUNTIL keywords, the spawngroup is executed like a subroutine, with sequential spawning continuing at the point of the WHILE keyword, not the conditional spawngroup.

- Added the GOTO/subgroup keyword that advances the sequential spawning index to the specified subgroup.

- At the moment, the condition statements for IF, WAITUNTIL, and WHILE keywords can only test properties on the spawner itself.  This will change with the introduction of the GET series of keywords in the next release.

- Added proximity triggering optimizations to reduce number and redundancy of trigger checks.  Particularly helpful when large numbers of players engage a proximity triggering spawner.

- Added two properties for tracking spawner modification. FirstModifiedBy stores the name of the staff who first opened the spawner. LastModifiedBy stores the name of the most recent staff to open it (thanks to Carpatheon (IN2) for the idea).  Note, this information is not stored in xml files when [xmlsaved.

- Added a Sort button to the spawner gump.  This will sort the spawn entries according to subgroup.

- Added a button to expand the text entry area in the main spawner gump.  This is an arrow next to the page selection buttons near the bottom of the gump.

Version 2.30
updated 3/25/04
- Added the LoadConfig and ConfigFile properties that allow XmlQuestTokens to read their configuration information from an XML file. This allows XmlQuestToken items such as the QuestNote to be dynamically specified offline without having to set properties or spawner entries directly. e.g. you could spawn a questnote with the spawn string "questnote/configfile/xmlquesttoken.xml/loadconfig/true" and any properties that were specified in the xmlquesttoken.xml file would be set in the spawned note. Therefore, a single spawner with a fixed spawn entry can have its spawned quests changed simply by editing the .xml file. 
You can also override xml-loaded properties by simply setting them in the spawn string after the loadconfig is performed, e.g. "questnote/configfile/xmlquesttoken.xml/loadconfig/true/objective1/KILL,lichlord,5" would load the properties from the xmlquesttoken.xml file, but then change objective1 to "KILL,lichlord,5".  Note, the order is important (load config first, change properties second). This allows for basic template .xml files that can be loaded up with standard quest settings and then overridden in individually spawned quest items. (Thanks to nix4 for this idea!)
Note that the files are assumed to be located in the runuo installation directory.  To specify files in subdirectories just specify the path (use backslashes not forward slashes). e.g. "questnote/configfile/Myquests\Defaults\xmlquesttoken.xml/loadconfig/true"

- a sample XmlQuestToken configuration file was added to the xmlspawner2-xmlextras.zip file.
- Moved the TitleString and NoteString properties from the QuestNote class to the XmlQuestToken class.

Version 2.29
updated 3/25/04
- Added the DoReset and DoRespawn properties that allow the Reset and Respawn functions that are available in the gump to be accessed via properties, and therefore spawners can control this function in other spawners using the SET keyword (e.g. allowing one spawner, or perhaps a switch item, respawn another spawner).  Also, functions such as "[area set dorespawn true where xmlspawner", will work.  Handy for limited respawn or reset control.
- Added the AllowGhostTrig property that can be used to allow or disallow triggering of spawners by players who are ghosts (thanks to Bane for the suggestion). When AllowGhostTrig is true, then only ghosts and not players will trigger the spawner.  When it is false, then only players and not ghosts will trigger.
- Removed the flag test that allowed stolen items to be removed from the defrag list.  The previous mod to stealing.cs that was listed in the text file is no longer supported. Because it uses an item flag that can be set by anyone, it was just too uncontrolled.
- Added the PartyEnabled and PartyRange properties to XmlQuestToken items like the QuestNote.  When this is set to true, KILL and COLLECT type quests will allow all members of a party to have quest objectives satisfied if any member of the party kills or collects quest objective targets.  For the KILL type quests, each member will get credit for a kill made by the party.  For COLLECT type quests, regardless of who in the party collects the target items, they will be distributed to randomly selected party members. If the PartyRange is set to a value zero or greater, then only members of the party within the specified range will share the quest targets. The default range is -1 which means infinite range. PartyEnabled is set to false by default.  Both party enabled and range status are shown in the upper right corner of the quest status gump. (Thanks to Bane for the suggestion).

Version 2.28
updated 3/22/04
- Modified gump text entry. Editing spawn strings in the spawner gump will no longer add a new spawn entry, but instead will simply change the existing one.
- Added a new extended text entry system that uses the book interface rather than the text entry gump interface.  Pros are that it allows more text to be entered, has mouse text editing support, and should work with the 3d client.  Cons are that it requires a book item to be made (temporarily), and involves hijacking the book changecontent packet handler, so anyone with custom basebook.cs mods should test it (regular books will work just fine).  You can return to the old text entry gump system by commenting out the #define BOOKTEXTENTRY lines at the beginning of the files XmlSpawnerGumps.cs, and XmlTextEntryBook.cs (thanks to nix4 for the suggestion)
- Fixed a problem with the COLLECT keyword in the XmlQuestToken items that would fail to remove non-stackable items after collection (thanks to nix4 for pointing this out).
- Modified the recalculation of X1_Y1 X2_Y2 on spawner location changes.
- Added a couple of example .xml files, Flashyorc.xml, and Deathmaze.xml that are created in green acres.

Version 2.27
updated 3/18/04
- Added the "MUSIC,musicname[,range]" keyword that lets you play music when spawned/triggered.  Note, it will override any ongoing ambient regional music that might be playing but will only briefly interrupt, not replace, the combat music if a player is in combat mode (that already overrides regional music).  This can be used to add additional ambience to triggered events, such as playing MUSIC,Victory upon completion of a quest, or MUSIC,Death on triggering a nasty spawn. This can spawned on its own e.g. "MUSIC,Britain1" or added as part of a spawn spec e.g. "orc/MUSIC,Death/", so that individual spawns could have their own music associated with them.  See the MusicName enum in the docs for list of available musicnames (note, they are case sensitive). There are some pieces of music (I think the non-repeating pieces like Death and Victory) that dont seem to be able to be played directly one after the other without playing a continous piece (such as the regional pieces Britain1, Britain2, or other background pieces such as Combat1, Tavern01, etc.)
When the optional range argument is given, then the music will be sent to all players within the specified range when it is triggered.  Otherwise, by default,only the triggering player receives the music.
- Added the RESURRECT[,range] keyword.  Will resurrect any player within the optional range argument, or the triggering player if no range is specified.  This does not bring up the res gump, and does not apply karma or fame penalties.  Penalties could be added by grouping it with SETONTRIGMOB using the INC or MUL keywords.  When done in this way penalties could include things like karma, fame, hits, stam, str, etc.  You could also group it with the TAKE keyword to take gold or items on res.
- Added the DAMAGE,damage,phys,fire,cold,pois,energy[,range][,playeronly] keyword.  This will apply the specified damage either to the triggering player or to all mobs within the range if it is specified.  When the playeronly flag is added, then damage will be applied to inrange players only, and not mobs. The damage will be distributed across the different types based upon the arg values.  So to deliver 50 damage to the triggering player with 100% of it phys type, use the spec "DAMAGE,50,100,0,0,0,0".  To deliver 10 damage to all mobs within a range of 5 tiles with half of it poison and half energy use the line "DAMAGE,10,0,0,0,50,50,5". To deliver 10 damage to all players within a range of 5 tiles with half of it poison and half energy use the line "DAMAGE,10,0,0,0,50,50,5,playeronly".
- Added the SOUND,value keyword.  This will play a sound to all players within range of the spawner. If this keyword is used as part of an item/mob spawn spec then the sound is played at the location of the item or mob (with no range argument available).  For example to spawn a grunting orc that also says something, use the spawn spec "orc/MSG/Die human!/SOUND,1068/"
- Added the EFFECT,itemid,duration[,x,y,z] keyword. For example, to spawn orcs with sparkle effects and sounds at the same time use the line "orc/EFFECT,14155,15/SOUND,400/" or to have a door that does damage, poisons, adds an effect and plays a sound use the line "SETONTRIGMOB/DAMAGE,50,100,0,0,0,0/POISON,Greater,5/EFFECT,14000,15/SOUND,519/" set the door as the TriggerObject and set the TriggerObjectProp to "open=true".  The absolute position of the effect can also be specified with the optional x,y,z arguments.
- Added the POISON,level[,range][,playeronly] keyword. Poisons either the triggering mob or all mobs (not just players) within range if it is specified.  The poison levels are Lesser,Regular,Greater, and Deadly. When the playeronly flag is added, then damage will be applied to inrange players only, and not mobs.
- add the SETONMOB,mobname keyword.  Same as the SETONTRIGMOB keyword but finds the mob based upon its unique name. Allows you to set properties on the mob.  For example, you could change a mobs color, or strength, or hits upon triggering the spawner, or have it say something, or add something to its pack, etc. For example you could have a triggered spawner heal a mob named The butcher with the spec, "SETONMOB,The butcher/hits/INC,20/MSG/I'm feeling much better/".

Version 2.26
updated 3/7/04
- added the TriggerAccessLevel property that lets you set the access level required to proximity trigger the spawner (the level is Player by default). Any player at the specified access level or below will be able to trigger the spawner.  This can be used for testing spawner triggering while remaining at admin access levels.  Thanks to Carpatheon (IN2) for the suggestion. (now I use it all the time).
- added the "[xmlimportmap filename" command that allows .map files to be loaded.  Note, this will only add, not replace spawners, so calling this more than once with the same .map file will result in duplication.  If you wish to be able to [xmlunload spawns defined in .map files, you should import them and then [xmlsave them into an xml file.  You can then unload and load them as you could any xml spawn file. If a directory name is specified as the filename argument, then the directory will be recursively searched for all .map files beneath it.
- modified the [xmlload and [xmlunload commands to also support recursive subdirectory loading/unloading of .xml files. when a directory name is given instead of a filename.
- modified MinDelay and MaxDelay properties to readjust the spawn timer when they are set.  Previously the timer would retain the previous countdown until the next OnTick so that when min/maxdelay values were modified they would not take effect immediately.
- added the commands "[xmlnewload filename [spawner prefix][-maxrange range]" and "[xmlnewloadhere filename [spawner prefix][-maxrange range]" which are the same as the [xmlload and [xmlloadhere commands except that they do not attempt to replace existing spawners by checking for matching GUIDs (every xmlspawner gets one), but rather automatically add new spawners and assign them new GUIDs on loading.  They also override any specified Map settings in the file and use the players current map instead.  This allows you to make a .xml file and use it as a template for creating spawners that can be placed repeatedly.  Note, that you will not be able to [xmlunload spawners that are loaded in this way since there would not be a file containing the new GUIDs.  If you wish to be able to unload them, then after loading spawners in this way, I would recommend doing an "[xmlsave filename [spawner prefix]" of them so that they are now uniquely defined in their own "[xmlunload"-able file.
The [xmlnewload" command can also be used to copy spawns between felucca and trammel.  For example, to duplicate felucca in trammel, go to felucca and do an [xmlsave, then go to trammel and do an [xmlnewload (thanks to Quantos for the suggestion).
- added the -maxrange option to the [xmloadhere and [xmlnewloadhere commands that allows the user to determine the range beyond which spawners will not be loaded with a relative location (i.e. if they are farther than maxrange from the first spawner in the file, which determines the origin for loadhere, then they are loaded with their absolute coordinates as defined in the file. default is 48 tiles).  The syntax is "[xmlloadhere filename [spawner prefix][-maxrange range]" or "[xmlnewloadhere filename [spawner prefix][-maxrange range]"

Version 2.25
updated 3/5/04
- added the "[xmlloadhere filename <prefix>" command that will load spawners from an xml file to the present location of the player.  Useful for creating a set of spawners to implement mini-quests in a test area (like green acres), and then loading them into a player area.  The location of the first spawner in the xml file is used as the origin.  Spawners that are beyond 48 tiles of the center will be loaded with their defined coordinates (not relative shifted), so for example, going to britain and doing an [xmlloadhere of the blather2.xml mini-quest example would load the starting and ending spawners at the player location, but would leave the deceit spawners in their original locations.
Note, just as with the [xmlload command existing spawners from previous loads of the same file will be removed before loading, so using the command repeatedly will not make additional copies of the spawners described in the file.
- modified [xmlunload to no longer check for matching maps (xml and spawner map can differ and it will still be unloaded).
- added a help button on the spawner gump describing commands and keywords.
- modified proximity triggering to ignore staff with accesslevel Counselor and above (previously only admins were ignored).
- added the SENDMSG keyword that sends a message to the triggering mob. Syntax "SENDMSG/text".
- add the INC and MUL modifiers for values, allowing incremental modification of existing property values instead of just simple assignment.  Syntax "propname/INC,value" or "propname/INC,min,max" and "propname/MUL,value" or  "propname/MUL,min,max"  where the use of the min,max form will use a random value between min and max for the modifiers.  This could be used, for example, to take away hit points on a triggering player by using the spawn spec "SETONTRIGMOB/hits/INC,-10".  A variant of this would be to set a short min/maxdelay (like 0), turn on proximity detection, and use the spec "SETONTRIGMOB/hits/MUL,0.95". This will work like an area life drain, gradually taking off hits while a player is in range of the spawner.  Same could be done for stam or mana etc.
Another application would be to add Karma or Fame as part of a mini-quest, "SETONTRIGMOB/fame/INC,100/karma/INC,100", and perhaps subgroup with "SENDMSG/You have gained some fame and karma"
Note, any of the items included in the support files that can make item property assignments, such as the switches and levers, can also make use of this (and any of the other non-trigger dependent) keyword.

Version 2.24
updated 3/1/04
- added more support for kill and collect type quests to XmlQuestToken class items with special objective specification keywords "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", the Objective2 property to "KILL,lichlord,5", and the 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.
- included an example of a kill and collect quest that is created in green acres in the xmlextras file killtask.xml
- added the "SKILL,skillname" keyword that 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". (thanks to Nim for the suggestion)
- 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.
- added an additional quantity argument to the TAKE keyword "TAKE,probability,quantity/itemname" allowing 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. (thanks to DeepFreez for the suggestion)
- added a new keyword TAKEBYTYPE with syntax "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.
- added an argument to TAKEBYTYPE and TAKE keywords allowing bankboxes to be included in the searched items.  The syntax is "TAKE,probability,quantity,true/itemname" and "TAKEBYTYPE,probability,quantity,true/itemtype"

Version 2.23
updated 2/21/04
- Added subgrouping to the spawn specs so that selected subsets of spawns can be triggered together at one time.  During normal spawning, if any one of the group is selected to spawn, then the spawner will attempt to spawn each member of the group (linked spawns). Enter the subgroup number in the textentry field next to the spawn entry.  Subgroup zero is the default and indicates no subgrouping for the entry (i.e. spawns in subgroup 0 spawn normally, not linked to other subgroup 0 spawns).
- Added sequential spawning enabled by setting the SequentialSpawn property to a value 0 or greater.  This works in conjunction with subgrouping by setting the spawn order based on the subgroup number.  Normal spawning selects randomly from the entire list of available spawns when determining what to spawn next.  With sequential spawning enabled, on each spawner OnTick (the interval set by min/maxdelay) the next spawn is the subgroup that follows the currently spawned subgroup (SequentialSpawn property contains the currently spawned subgroup)
This can be combined with the Group property, or the Kill field in the extended spawner gump, to create progressive spawning with timed reset.  The Group property normally operates by forcing the spawner to spawn all of its spawns as a "group", and it will not respawn until all spawns in the "group" are gone.  When both SequentialSpawn and Group are set, then the spawner will fully spawn a subgroup and will not advance to the next subgroup until the current group of spawns has been eliminated.  This allows "champ-like" progressive spawns in which each subgroup is a "level", and the level must be cleared to advance.  There is also the option of setting reset timers that place a time limit on "clearing" the level.  This is set in the Reset (reset time) field of the extended spawner gump and is a value in minutes.  If the "level" is not cleared before the time expires then the "level" (i.e. subgroup) is reset to the value given in the To (reset to) field.  
For example, if the "To" field is set to 0 then failing to clear the spawns in the current "level" before the "Reset" time expires will result in the spawner clearing the current spawns and returning to the spawns of subgroup 0. Setting "To" to the previous subgroup, will cause the spawner to move the sequence back one when the level is not cleared in time, in a champ-like fashion.
Setting the reset time to zero means unlimited time, and the sequence will not reset.
The Kills (kills needed) field of the extended spawner gump allows an additional criterion for advancement to be set, and that is the total required number of kills in that subgroup.   If the "kills needed" is greater than zero, then the specified number of kills must be made at that level in order to advance.  This can be used in conjunction with, or instead of, the Group property to control level advancement based on kills.  A subgroup that has "kills needed" to advance will automatically clear any remaining spawns associated with the subgroup when it advances.
Note that KillCount is also normally reset if the kills are not made fast enough as determined by the KillReset which specifies how many regular spawner OnTicks can pass without a kill being made before KillCount is reset to zero. Each time the level is reset under sequential spawning, the KillCount of the spawner is also reset to zero. 
Note that in the extended gump, only the primary spawn entry for a subgroup displays the reset timer and level information, but this still applies to all of the spawns in the subgroup.
Subgroup 0 cannot have reset information assigned to it.  When the sequence reaches the final level, it "wraps around" back to the lowest level.
Subgroup numbers can be any non-negative value, only the order matters, so setting spawns to subgroups 1,10,30,100 will give the same behavior as setting them 1,2,3,4.
Because the current sequence state is available on the SequentialSpawn property, this can be used to chain spawners by making one spawner (or any other object such as the Combination lock) dependent on the sequence level of another spawner.  For example, make a spawner, set the TargetObject to a second spawner, and set the TargetObjectProp to "sequentialspawn>3", and that spawner will not trigger until the second spawner passed level 3.
These features can be used to generally create progressive spawn patterns in which the spawns change or become more difficult as more kills are made in the same area.  For example, a graveyard spawn that initially is just skeletons, but as more kills are made, the spawn pattern changes to spectres, then liches, etc., and then after a period of inactivity, goes back to skeletons.
Or it could be used to produce a decreasing spawn pattern with use, for example, decreasing item spawns if they are consumed quickly (overharvesting).
- Added two sample champ-like .xml files that load into green acres.  One is the standard VenomType champ-spawn, with the venom boss. The other is a bit more amusing.
- Added the ability to directly enter maxcount values for the spawner and for each spawn entry from textentry fields in the spawner gump.
- Changed [xmlhome to search all xmlspawners for the home of a targeted mob, not just those nearby.
- Added display of the total current spawn count next to the spawner maxcount.
- Added a refresh button that updates the spawner gump (same as closing and reopening the gump).
- Modified the props gump button to leave the original spawner gump window up as well as the props gump.
- Added new sequential spawning fields to each spawn entry.  These are accessible via the expanded spawner gump (press arrow in lower right corner of the spawner gump)
- Modified the format of spawn specifications in .xml files created with the [xmlsave command to allow the use of previously forbidden chars (':', "=") and to support the extended sequential spawn and subgroup information.
- Added the [xmlsaveold command to allow spawner information to be saved in the old .xml format (it will not save subgroup or sequential spawn information)
- Added OmegaRed's mod allowing specification of spawning area using region names (RegionName property).  If set, this overrides other spawnrange, and X1Y1X2Y2 settings.

Version 2.22
updated 2/15/04
- added the CAST keyword to allow 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.  Casting normal circle spells does not use mana or reagents, Necro/Paladin spells use mana/tithing points of the caster, and both paladin and necro spells check for skill requirements on casting.  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", or to summon a creature "CAST,summoncreaturespell", or bladespirits "CAST,bladespiritsspell", and to cast it with a random target within +-5 squares of the player use "CAST,bladespiritspell,5". Note, not all spells will work automatically.  Item targeted spells such as mark, recall, and sacredjourney will cast and bring up a targeting cursor.
- added a new optional argument to the SET keyword. The "SET,itemname/prop/value/prop/value/..." form allows you to set property values on uniquely named items without having to set them as predefined targets using the SetItem property.  This can be used to set properties on things that cannot be targeted because they are not necessarily available as existing objects at the time, such as spawned items.
- added an addspawn property interface that will allow you to add spawns to a spawner without opening the gump. This allows other objects to add spawns to the spawn list. Also provides the ability to actually spawn spawners with specified content with spec lines like "xmlspawner/addspawn/helmofinsight/addspawn/orc/proximityrange/5/mindelay/1/maxdelay/1"
- added line editing to the spawn text gump.  This allows modification of substrings in a spawn specification string without having to retype the entire string. To use this feature, open the text entry gump for a spawn spec by clicking the parchment icon to the right of a spawn entry line on the main gump. The text entry gump now has two text entry lines at the bottom.  The old text is entered in the top line, the new text in the bottom.  The first occurrence of the old text will be replaced by the new text when the Apply button is pressed.
- added multiple pages to the spawn gump to allow more than 15 spawn specs per gump  (maximum is now 60). The additional pages are accessed throught the numbered buttons at the bottom of the spawn spec entry list on the main gump.

Version 2.20
updated 2/8/04
- allow arguments to be passed to spawn constructors so that objects that require arguments can also be spawned.  The syntax is spawntype,arg1,arg2,..
For example, to spawn a door with a particular facing use the spawn spec "barredmetaldoor,northccw", or to make a 2 page writable book use "redbook,2,true" or a golden runic hammer with 30 uses "runichammer,gold,30". The valid constructable arguments can be found in the documentation for constructable objects.   Note this
can also be used with the ADD keyword.  For example to add a runichammer to a mobs loot use "orc/ADD/runichammer,gold,30"
- added an external trigger hook that 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 target0property 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. (thanks to DeepFreez for the suggestion).
- added an additional condition for quest token invalidation, now they will also become invalid if placed in the players bankbox.
- renamed the QuestStatusGump class to XmlQuestStatusGump to avoid conflict with some existing custom quest scripts (thanks to atriticuss for pointing this out).
- fixed an old crash bug on invalid file paths to the [xmlsave command. (thanks to dominus for pointing this out).
- included documentation written by DeepFreez in the file xmlspawner2doc.txt

Version 2.19
updated 1/26/04
- added a new 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.
- added the NoTriggerOnCarried property, that 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.
- changed carried-item triggering to find the named item anywhere on the player, in a players pack, or in containers within the pack, not just at the top level.
- added the SETONCARRIED keyword.  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.
- added a sample xmlquest blather2.xml that uses the new triggering features and shows the use of the questnote XmlQuestToken item, with multiple objectives that are updated in the quest status gump as they are completed, with additional objectives added during the quest.  The quest status gump can be opened by pressing the icon in the lower left corner of the questnote item.

Version 2.18
updated 1/20/04
- added 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.
The GUMP keyword can also be used to display user gumps with the syntax "GUMP,title,number,gumpconstructor/text".  Gumps must be constructed with argument lists of the form public XmlNewGump( XmlSpawner spawner, string gumptext, string gumptitle, int gumpnumber, BaseXmlSpawner.KeywordTag tag )
From within the usergump methods the spawner GumpState is can be assigned a string value using the GumpState property (e.g. spawner.GumpState = "accept"; )
- included a sample xml quest file. To test it just place the file blather.xml in the main RunUO directory and "[xmlload blather.xml".  To unload it type "[xmlunload blather.xml".  The file places a quest mob and 3 successive quest gumps in green acres. To begin, simply approach the mob (as a player, not an admin) and follow the text. The "fetch" mob is on the 3rd level of Deceit near the lich room and entrance to lev 4. Approach and make the request, then return to green acres to open the conclusion gump and receive a reward.  Note the use of the "SET/gumpstate//" specs, and the SetItem prop to clear the gumpstate of previous gumps, and the use of refractory period to set the minimum interval between quest restarts, and the use of TriggerOnCarried to initiate quest phases, and TriggerObjectName and TriggerObjectProp to chain quest gumps based on user responses.
This is work in progress, so there will be additional refinements to handle mid-quest restarts, and re-triggering of quests already in progress, but this should give an idea of the possibilities.

Version 2.17
updated 1/18/04
- fixed an error in the constructables in which they were not assigning the default spawnrange. (thanks to sUpplier1 for pointing this out)
- added new keywords ARMOR, WEAPON, SCROLL, NECROSCROLL, 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. SCROLL,mincircle,maxcircle drops a random scroll between mincircle and maxcircle, POTION drops a random potion, NECROSCROLL,index drops a necro scroll of the specified index.
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.
The line "woodenchest/ADD/WEAPON,3,5/ADD/ARMOR,3,4/ADD/ARMOR,3,4/ADD/POTION/ADD/SCROLL,4,6/ADD,.1/<WEAPON,2,3/slayer/elementalban>" would spawn a chest with a magic weapon, two pieces of magic armor, a potion, a scroll, and occasionally a lev2-3 elemental slayer.


Version 2.16
update 1/17/04
- added the 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 substibuted 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.
- added 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"
- added 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", or "GIVE,probability/itemtype", or "GIVE,probability/<itemtype/prop1/value/prop2/value...>"
- added 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.
- added the TODMode property that allows Time of Day (TOD)-dependent spawning to be in either Gametime or Realtime.
- allow non-proximity based triggering of spawns with the object property, and mob property triggering features.  By setting either of these triggers, and leaving proximityrange off (-1), the spawners will check for trigger conditions on each spawn tick rather than requiring a player to be present.  This allows free-running spawners to still be made object or mob dependent.  For example, you could have a spawner running (bunch of minions) as long as a particular named mob (the boss mob) existed, or have a spawner running while a switch is in a given position.  With proximityrange > -1, proximity triggering behaves as it always has.
- changed decrement arrow behavior in the spawner gump. Previously, decrementing a spawn to zero would remove the entry from the spawn table.  Now, an entry can reach zero. To actually remove it you must decrement it again once it reaches zero.
- tuned triggering behavior under full spawn and group conditions.  Triggering will now be supressed unless spawning could actually occur on the next tick.


Version 2.15
update 1/14/04
- added [xmldefaults command to display and alter default parameters used when creating spawners.  "[xmldefaults" with no arguments displays current defaults.  "[xmldefaults propname value", sets the default for propname to value. "[xmldefaults load filename", loads defaults from an xml file. "[xmldefaults save filename", saves defaults to an xmlfile.  Note, defaults are not serialized, so they must be reloaded after a server restart.
- changed the way that X1Y1 X2Y2 behave when setting spawning regions.  X1Y1 will now define the beginning of a rectangular bounding region, and X2Y2 will set the opposite corner. The constraints on setting them as lower left and then upper right have been removed, so that it is not possible to set an invalid region any longer.  The program will now calculate the proper lower left, upper right bounds based upon the region specified.  After setting X1Y1 the user should define the opposite corner, otherwise the region will be a single space box at X1Y1 by default.  To observe the new behavior of spawn region definition, set ShowBounds to true and set X1Y1 and X2Y2 values.
- changed the way killcount is computed.  It now more accurately reflects actual kills by computing them from the defrag routine (thanks to DeepFreez for the suggestion).
- added a KillReset property which allows you to specify the number of spawn ticks that pass without a kill before the killcount resets.  default = 1;
- blocked the ability to modify player's accesslevel property to avoid exploits (thanks to dominus for pointing this out).

Version 2.14
update 1/10/04
- added 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.
- added 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.
- added 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.

 
Version 2.131
update 1/10/04
- very minor change in the import routine.  By default, relative home range is now set to false for imported spawners to more accurately reproduce the behavior of regular spawners.

Version 2.13
update 1/10/04
- added the command [xmlimportspawners, which was taken from Sno's package for importing and exporting regular spawners.  Allows you to create xmlspawners from the xml descriptions of regular spawners created by his program.  This can be used to easily convert from regular spawners to xmlspawners.  Simply install Sno's package, do a "[global exportspawner file.xml" to make the regular spawner xml file, "[spawngen remove" to delete them from the world, then "[xmlimportspawners file.xml" in order to reload the spawners as xmlspawners.  Of course this can also be done a region or a map at a time, or even individually.  For instance, this provides an easy way to take advantage of atomics ultimate spawner maps using xmlspawner.

Version 2.122
update 1/9/04
- fixed an internal map spawning bug when invalid X1Y1 X2Y2 coords were specified.
- added new constructables [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.

Version 2.121
update 1/8/04
- fixed an error in the serialization.  Forgot to change the version number to 9. Unfortunately, if you have already done a server save with version 2.12 you will have to make a temporary modification to the Deserialize routine in order to things to load up property. 

so around line 3913 change this 


Code: 

               case 9: 
                { 
                   this.m_TriggerProbability = reader.ReadDouble(); 
                    goto case 8; 
                } 
                case 8: 
                { 
                   this.m_MobPropertyName = reader.ReadString(); 
 


to 

Code: 

               case 8: 
                { 
                   this.m_TriggerProbability = reader.ReadDouble(); 
//                    goto case 8; 
//                } 
//                case 8: 
//                { 
                   this.m_MobPropertyName = reader.ReadString(); 
 



What you need to do is this. 

Step 1: install the new version 2.121
Step 2: make the changes listed above. 
Step 3: load things up and you should get no errors. 
Step 4: do a [save 
Step 5: quit the server 
Step 6: undo the change, i.e. go back to 

Code: 

               case 9: 
                { 
                   this.m_TriggerProbability = reader.ReadDouble(); 
                    goto case 8; 
                } 
                case 8: 
                { 
                   this.m_MobPropertyName = reader.ReadString(); 
 


Version 2.12
update 1/7/04
- added a triggering probability set with the TriggerProbability property.  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.
- 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 unlock 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.


Version 2.11
updated 1/5/04
- added player and mob property triggered spawning.  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)
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.
- added the new command [xmlspawnerunload (shorthanded as [xmlunload) that 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.
- added the not equals operator (!) to the property values tests (=<>!)

Version 2.10
updated 1/4/04
- added two keywords to the spawn specification string.  ADD allows you to add items to mobs packs.  RND allows you to generate random values when specifying properties
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.

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.
As a further example, this can be combined with the note object added in v2.09 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

Version 2.09
updated 1/4/04
- improved the spawner interface with a separate spawner text specification gump that can be accessed from a button next to each spawner entry.
- added 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").

Version 2.081
updated 1/3/04
- improved exception handling and reporting to badxml.log when loading questionable or corrupted xml files.
- totalitems on the spawners set to -1 to avoid detection based upon number of items when in containers (thanks to roadmaster for pointing this out).

Version 2.08
updated 1/2/04
- added 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.
- tweaked the way killcount works to better deal with proximity triggering.  
- removed the optimization to pack searching for items when using the player-carried item triggering feature.  Too many ways to get around it.

Version 2.07
updated 1/1/04
- renamed the property TriggerOnItem to TriggerOnCarried, and TriggerOnProperty to TriggerObjectProperty to improve property grouping in the gumps and to minimize confusion between item carrying and object property triggering features.
- forgot to serialize the player-carried item trigger, so fixed that.
- added in the xml file support for object property triggering and proximity-triggered messages.  Note that the user is responsible for making sure the object used as a target has a unique name.  If it doesnt then the targeting feature wont be restored.  This will be noted during xml loads and will be saved in a log file so that you can go back and set them manually if you have to.  Note, this only applies to xml save/loads.  Unique names are not required for the feature to work ingame, and everything gets restored on server restarts/reloads through deserialization, so that is all taken care of.

Version 2.06
updated 1/1/04 (Happy New Year!)
- added a user-definable proximity trigger message (the ProximityMsg property) that is displayed over the player when the spawner is triggered.  Based on the original idea by David in his movement spawner.
- added 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 TriggerOnProperty field with the property and the value to test. e.g. 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.
- added a killcount property to the spawner which can be used in conjunction with the property-triggering feature to chain spawners based upon the number of kills made on it.  killcount is incremented for each spawn that occurs while the spawner is not full.  When it reaches full spawn the counter is reset to zero.  Therefore, it will keep track of player kills as long as they can keep up with the spawn and prevent it from becoming full again.  Multiple chaining of spawns becomes possible with this feature (champ like spawn scenarios) with final boss mobs.
- added support for 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.
Note, the object property triggering and proximity-triggered message features are NOT supported in xml files.
Also note, the killcount does not count the actual number of kills made, but rather the number of spawns generated, so it should be taken as a close approximation rather than an accurate count of kills.

Version 2.05
updated 12/30/03
- added 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.  The property TriggerOnItem 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.
- added commandline-like spawn specification.  This feature 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.  Note that 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.  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.  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.

Version 2.04
updated 12/29/03
- added proximity range sensing for activating and inactivating the spawner.  More precisely it is movement of players within the proximity range that triggers the spawner.  ProximityRange sensing is off by default (value is -1)  by setting it, spawner will be activited when a playermobile moves in range.  After activation, delay, duration, spawnrange, spawn probability, and other settings apply as usual.
- added the property proximitysound which allows you to set the sound played when a proximity triggered spawner is tripped by a player (a click and sparkle sound by default).
- added min/max refractory period for proximity triggered spawning.  This is the period following triggering during which the spawn cannot be proximity triggered again. e.g. setting proximityrange to 2, min/maxdelay to 3 seconds, and min/maxrefract to 10 mins, will create a spawn that is triggered by a player within 2 squares of the spawner, with the spawn appearing 3 seconds after triggering, and cannot be retriggered for 10 mins.
- added time of day properties that let you specify the period of the day during which spawns can occur. Time of day (TOD) is specified in 24 hour format.  Note, if TOD start is later that TOD end, this indicates that the interval spans midnight.  e.g TODStart=22:00:00 TODEnd=5:00:00 will enable spawns between 10pm and 5am every day.  TOD windowing also applies to proximity-triggered spawns, so they can only be triggered during the enabled period.  Spawns will be removed when outside of the TOD window.
- added some new buttons to the spawner gump. an on/off indicator button, a reset button (delete all spawns, reset timers, stop)
- enabled spawning items in stacks using the stackamount variable as a quantity indicator.  This replaces the earlier team variable hack for specifying amount.

Version 2.03
updated 12/28/03
- added xml file save/load support for container held spawners.  Note, while it is possible to place spawners in nested containers, the xml file support only handles the top level container. So xmlloading a nested spawner will place it in the topmost container.
- added xmlspawnershowall support for container held spawners.  Places an invisible mast static over containers that hold the spawner.
- added shorthand command aliases for xmlspawnershowall/hideall operations, [xmlshow and [xmlhide
- added new command [xmlhome that returns the coordinates of the xmlspawner for the targeted object. Also takes arguments 'go' that teleports you to its spawner,'gump' that opens its spawner gump, and 'send' that sends the object back to the spawner location"

Version 2.02
updated 12/27/03
- added a SpawnRange parameter to the spawner properties. This will maintain compatibility with the X1Y1 X2Y2 scheme of the original xmlspawner.  If you set the spawning region using the x1y1 x2y2 scheme, the spawnrange will show a value of -1.  If you set the spawnrange directly, it will automatically set x1y1 x2y2 to the proper values.  Basically just an easier way of setting the spawn range.
- fixed a divide by zero error with a spawner with zero count spawn entries.
- spawning multiple items on a spawner in a container will use dropitem to place them which will spread them out, instead of placing them on top of each other (thanks to Fury for this suggestion).  Single item spawns will still be placed at the spawner location if precise item placement is desired.

Version 2.01
updated 12/27/03
- enabled spawning items in stacks using the team variable as a quantity indicator.  Just set the spawner team variable to the quantity desired and the item (if stackable) will spawn in stacks of that amount.
- added some timer optimization for full spawners (which is virtually all of them under normal conditions) to reduce timer overhead.  Should reduce system load by some amount.

Version 2.0
updated 12/26/03

Xmlspawner was originally designed by bob smart as part of the world spawner package that included the spawner along with scripts from mutiple contributors for creating a more or less fully spawned and functional world.  It was a modification of the distribution spawner, with xml support, and some additional tools and features. Knightshade stripped the xml spawner from the package and made it available as a standalone spawner.  I took that standalone spawner and added the following features, fixes, and modifications.

-------------------
New commands: 
-------------------
[xmlspawnerrespawn - forces a respawn of all xmlspawners in the region
[xmlspawnerrespawnall - forces a respawn of all xmlspawners in all regions

-------------------
Weighted probabality 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.
e.g.
open up the xmlspawner
add a balron, count = 1
add a gargoyle, count = 10
go to the xmlspawner props and set maxcount to 1
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.
e.g. settings of
<MaxCount>1</MaxCount> 
<Objects>ratman=15:ratmanarcher=15:barracoon=1</Objects> 

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)

-------------------
Container spawning: 
-------------------
placing a spawner in a container will allow items to be spawned in it (but not mobs).

-------------------
Spawn 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, that when saving spawns to an xml file the duration parameter will be saved as seconds, not minutes. 

-------------------
Proximity range sensing: 
-------------------
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.
Admins will not trigger the sensor.
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.

-------------------
Time of Day (TOD) spawn limiting
-------------------
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).


NOTES:
Because additional spawner parameters are serialized/deserialized, this xmlspawner has a version number associated with it.  If you install it, it will read your old xmlspawners, but if you save and then decide to go back to the earlier version, you will have to go through the serialize/deserialize steps required to revert to older versions. 
It will read all xml spawner files created for the older versions, and conversely, any xml spawner file saved with this version will be readable by older versions.


CHANGES/FIXES:
- added a small fix to the spawner that was posted in the forums (sorry, dont remember who posted it) dealing with internal map spawns by moving map assignment after location specification.
- turned off visibility of xmlspawners by default when using the [xmlspawnershowall command.  Admins can still see them but players cannot.
- blocked mob spawning when the spawner is in a container such as a pack.  The xyz coordinates are invalid in that condition.
- added item spawning in containers.  Note, storage limits on the container are not checked on spawning.
- xmlspawnersave will ignore spawners carried by players (such as admins), again an invalid condition.
- container held spawners will only save the xyz location of the container on xmlspawnersave (sorry, for now wont save any container info so xml loads will not place spawners back in containers but rather will put them at the location of the container - i will update this).
- added a flag test in defragging to deal with item spawns that are stolen/taken but remain under the control of the spawner.  This feature will not be active without additional modification to files stealing.cs and container.cs.  This mod is described in the included .txt file. These mods do not have to be made if you choose not to.




FIX FOR STOLEN/TAKEN ITEM SPAWNS THAT REMAIN UNDER SPAWNER CONTROL

Note, this completely optional.  Dont do it if you dont want to.

With all current spawners, any spawned item, if set back on the ground before the defragger has a chance to see it inside of your pack or a container (e.g. at spawn or respawn) and take it off of the spawn list, will continue to be owned by it. This means it will continue to be checked, will block further spawning, will be subject to spawner-initiated deletion, recalling to home, etc. 

It shows up most obviously with the rare spawns because the time between defrags is basically the time between spawns, so if you pick up the item and walk around with it for 3 days and then put it down, a spawner with a 5 day timer is probably still going to have it on its list. (and exception to this would be if the server were restarted sometime in those 3 days with the item in your pack since it does a defrag on restart) 

So currently, the only safe way to make sure your spawned rares dont get deleted is to leave them in a container until the next respawn. After that they are safe.
With the fix described below all items will be immediately protected including regular non-stolen rares, as well as any other item spawn. Stealing or dragging and dropping it into your pack flags it for removal in the next defrag pass (i.e. the spawner will forget about it).  

replace your container.cs and stealing.cs files with the modified distribution files included in xmlspawner2-support2of2.zip

Stealing.cs also contain a mod supporting flagging rares/items as stealable even when initially locked down.  Once they are stolen by a player they cannot be stolen again if locked down.  This feature makes use of item SavedFlag 0x00200000 and does not require any modification to any items or item scripts.  If you wish to add stealability into the item constructor by default (e.g. making stealable rare item scripts) just make a call to 
ItemFlag.SetStealable(this,true);
Items can also be manually flagged as stealable or not using the [stealable command.
To spawn an item as stealable, use the special STEALABLE property keyword like this

zyronicclaw/movable/false/STEALABLE/true

This can be used to spawn stealable items in containers like the OSI shop containers.  
Any item can be flagged as stealable using this technique.  Even items that would not normally be stealable such as blessed or newbied items can be flagged in this way.  Also handles stealable stackables.
Note, once a flagged item is stolen or placed in a container by a player, the flag is reset and the item behaves as any normal item would.
