Full Version : XmlSpawner2 v3.21a [RunUO 1.0]
xmlspawner >>XMLSpawner - Releases & Updates >>XmlSpawner2 v3.21a [RunUO 1.0]


<< Prev | Next >>

godfood- 12-26-2005
XmlSpawner2
v3.21a
RunUO 1.0
updated 3/20/07
ArteGordon

Summary:

A spawn control system supporting sophisticated conditional spawn triggering, individual customization of spawns and their drops, spawn/item/mob search utilities, offline visual spawn editing, and systems for stealable rares, doom rares, interactive npcs, functional attachments, mob factions, pvp points/duels/games, custom special attacks, socketed items/creatures, and quests.


New to version 3.21a

updated 3/20/07
Bug Fixes
- quick update to v3.21a to fix a nasty bug with rewards in PlayerMade quests (thanks to Syznow for pointing this out).

Modified Features
- restricted the quest journal editing feature to the Owner only. This prevents publicly accessible questholders (playerquestboards or placed in the world) from being edited.

This only involves an update of XmlQuestHolder.cs and XmlQuestHolderGumps.cs in XmlSpawner2-v321a-2of3.zip

If you have recently updated to v3.21, I strongly recommend updating your XmlQuestHolder.cs to the latest v3.21a version.

New to version 3.21
updated 3/15/07
Bug Fixes
- fixed an issue involving rewards being used directly out of questholders. 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.

Modified Features
- added a property test option to the SETONNEARBY keyword that allows you to restrict the objects selected (thanks to Steelcap for the suggestion). The new syntax is

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

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

SETONNEARBY,10,*,basecreature,false,hits<100/hue/500

New Features
- 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. 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

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.

or create a quest with initial journal entries like

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.

user posted image

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

New to version 3.20
updated 3/06/07
Bug Fixes
- fixed a deserialization problem in the XmlUse attachment that was introduced in v3.19.

Modified Features
- disabled spawn entries (lock icon next to entry in spawner gump) are now ignored when determining availability of a subgroup for spawning.

- added support for console reporting of unrecognized settings during xmlspawner.cfg loading. 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)


New Features
- added the "BlockKeyword=keyword[,keyword]..." configuration option to the XmlSpawner section of xmlspawner.cfg to allow selected xmlspawner keywords to be blocked. 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

- added the new "BROWSER/url" standalone keyword that will open a web browser to the specified url. 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.

- added the browser.xml example to xmlextras.zip demonstrating the use of the BROWSER keyword in an XmlUse attachment. 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".

New to version 3.19 from version 3.11
updated 2/27/07
Bug Fixes
- 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 (thanks to DazedAndConfused for pointing this out).

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

- fixed a bug in which assigning an extremely large expiration time to questholders could cause a crash (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.

- modified the [WriteMulti command to support staff names that have spaces in them when accessing files (thanks to Xavier_WER for the suggestion).

- modified the spawner Reset function to properly reset the refractory period for triggered spawners if that was set (thanks to Vladimir for pointing that out).

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

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

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

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

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

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

- fixed a possible crash bug when using '[xmlsave'

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

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

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

Modified Features
- Name tests have been modified to support a special wildcard "*" that will match any name. (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

*,heavycrossbow

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

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

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

- disabled the SpawnIdleTime feature. 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. I found it to be more trouble than it was worth. I'll think about a different way of testing for inaccessible spawns.

- modified smartspawning so that mobs that are below maximum hits, stamina, or mana will not be despawned (thanks to Kamuflaro for the suggestion). The previous test only looked at hits.

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

[xmlget aggressors[0].attacker.name

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.

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

- added optional args for specifying hue and font in the BCAST keyword (thanks to Xavier_WER for the suggestion). The new syntax is
BCAST[,hue][,font]/message
Note that this uses the same hues and fonts as the SENDASCIIMSG and ASCIIMSG keywords,
SENDASCIIMSG[,probability][,hue][,font]/message text
ASCIIMSG[,probability][,hue][,font]/text
so you can use them to test out various text/color combinations without having to actually broadcast to see what it looks like.
user posted image
Unicode font (the default) can be specified with a font type of -1. So to specify colored unicode broadcast messages, use
BCAST,33,-1/System is going down now

- default spawn placement will now automatically take into consideration the CanSwim and CantWalk mobile properties when calculating valid spawn locations. 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.

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

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

- added support for assigning a mobile used to allow spawners to issue commands using the "COMMAND/commandstring" keyword 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;


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.

- modified random subgroup spawning. 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.

- made the SENDMSG and SENDASCIIMSG keywords usable as value type keywords and not just standalone keywords. so you can do things like

SETONNEARBY,5,,playermobile/SENDMSG/Greetings friends

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

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

- modified the way that the DAMAGE and POISON keywords work when used as value keywords.
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"

SETONMOB,Blather/DAMAGE,50,20,20,20,20,20,5,playeronly

Their behavior when used as standalone keywords was not changed.

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

- added the option to make addons created with the MULTIADDON keyword partially visible with the new PartialVisibility property (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.


- changed the default smartspawning test to allow any unhidden staff, regardless of accesslevel to activate smartspawned spawners. 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;


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

- added support for Nerun's new .map format in [xmlimportmap. 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.

New Features
- added support for a new xmlspawner.cfg file in the Data folder of the main RunUO installation. 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



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");


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;
  }
 }


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

MEFFECT,itemid[,speed][,x,y,z][,x2,y2,z2]

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,

SETONTRIGMOB/MEFFECT,14036,3

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

SETONTRIGMOB/MEFFECT,14036,3,1500,1100,10

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.

MEFFECT,14036,3,1500,1100,10,1520,1120,10

- added the 'GETONNEARBY,range,name[,type][,searchcontainers],property' keyword that can be used to get or test properties on nearby items or mobiles. 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

GETONNEARBY,1,Grizzleblag,longsword,visible=true

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

SENDMSG/{GETONNEARBY,1,,gold,true,amount} gold pieces are in the container

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

SETONPETS,range/prop/value/prop/value...

- added the new 'GETACCOUNTTAG,tagname' keyword that allows access to account tags on the triggering player (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

GETACCOUNTTAG,quest1="done"

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

SENDMSG/I see that you already have {GETACCOUNTTAG,numRewardsChosen} veteran rewards.

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

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

SETACCOUNTTAG,quest1/done

- enabled attachment support for "using" objects that allows you to add custom double-click functionality to any object, even statics and mobiles.
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.
            //Timer.DelayCall( TimeSpan.Zero, new TimerCallback( UseReqOverride ) );


With this feature enabled the following overridable methods are available to all attachments
CODE

 public virtual void OnUse(Mobile from)
 {
 }

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)
 {
 }

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;
       }


- added the new XmlUse attachment that allows you to control the use of any object. 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.

Properties:
Condition
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.

MaxUses
An integer value that restricts the maximum number of uses allowed. (default = unlimited)

Refractory
An integer that restricts the minimum time in seconds between uses. (default = 0)

MaxRange
An integer that restricts the maximum distance in tiles allowed from the target object (default = 3)

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

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

FailureAction
This action will be executed when the conditions for use of the object are NOT met.

MaxUsesAction
This action will be executed when someone tries to use the object after the max uses has been exceeded.

RefractoryAction
This action will be executed when someone tries to use the object before the refractory period is over.

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

Constructors:

public XmlUse()

public XmlUse(int maxuses)

public XmlUse(int maxuses, double refractory)

Examples:

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

[addatt xmluse 1

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

metalbox/ATTACH/<xmluse,3,10/maxusesaction/@SENDMSG/Max uses exceeded.>

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

static,3796/ATTACH/<xmluse/successaction/@GUMP,Wicked woods,0/Enter here and despair!>

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

[addatt xmluse

and then opening up the props on the attachment with

[getatt

and assigning the SuccessAction property the value of "GUMP,Wicked woods,0/Enter here and despair!"

user posted image

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

metaldoor,1/ATTACH/<xmluse/condition/@GETONTRIGMOB,name="Bob">

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

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

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

SETONTRIGMOB/ATTACH/<xmluse/expiration/00:02/condition/@GETONTHIS,TYPE!#MetalDoor>

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

- added an example of the new XmlUse attachment in customuse.xml. Just do an "[xmlloadhere customuse.xml" and respawn it.
Examples:
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.

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

- included an example of the use of modified timer priority in boulder.xml 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.

- added the new #NOTILES,startid[,endid] spawn control keyword. 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.
user posted image

- added an optional 'equippedonly' argument to the existing SETONCARRIED keyword that would allows access things like a players bankbox. The new syntax is
SETONCARRIED,itemname[,itemtype][,equippedonly]/prop/value/prop2/value...
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
SETONCARRIED,,bankbox,equippedonly/ADD/gold,500

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

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

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

- added the new #WET and #TILES,startid[,endid] spawn control keywords. 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. Only tiles that have been frozen into the map will be checked. 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.

user posted image

- added the '[WhatIsIt' command that will report the type and name of the target. 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).

Description:

see xmlspawner2.txt in xmlspawner2-support.zip for details and complete changelog.

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.

- control spawning location and selection with control keywords #XY, #DXY, #XFILL, #YFILL, #EDGE, #PLAYER, #WAYPOINT, #RELXY, #CONDITION

- 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, 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

- access keywords: GET, GETONTHIS, GETONPARENT, GETFROMFILE, GETONSPAWN, GETONCARRIED, GETONMOB, GETONTRIGMOB, GETONNEARBY, GETACCOUNTTAG, SET, SETONTHIS, SETONPARENT, SETONSPAWN, SETONSPAWNENTRY, SETONCARRIED, SETONMOB, SETONTRIGMOB, SETONNEARBY, SETACCOUNTTAG, 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:

The following additional optional addon systems are also available:

The Spawn Editor 2 visual spawn editing/mapping program can be found here Spawn Editor 2

The XmlPoints addon can be found here XmlPoints system

The XmlMobFactions addon can be found here XmlMobFactions system

The XmlCustomAttacks addon can be found here XmlCustomAttacks system

The XmlSockets addon can be found here XmlSockets system

The XmlSiege addon can be found here XmlSiege system

The PlayerRangeSensitiveMod provides the benefits of having PlayerRangeSensitive=false with virtually none of the server load. PlayerRangeSensitiveMod .

Additional Links:

Tryings beginners tutorial
Beginner's tutorial

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!)
Beginner's quest guide

LordHogFred's xml posts.
Diablo 2 quests
Halloween spawns

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

Installation:

STEP 1:
With RunUO 1.0.0 installed, simply unzip the contents of the package into your custom scripts directory.

The three xmlspawner2-vxxx-[123]of3.zip files are required.

The xmlspawner2-support.zip file is recommended.

The xmlspawner2-xmlextras.zip is completely optional.
It contains .xml file examples of some of the spawner capabilities as well as other spawn files. It is a good place to start learning what xmlspawner2 can do.
To run the examples, make a folder called Spawns in the main RunUO installation directory (where your server.exe is) and place the .xml files in there. Then make a folder named XmlQuestNPC in the main RunUO installation directory and place the .npc files there. Note, the zip file already places the files in the proper default locations if you just extract it into your main RunUO folder.
Test them out by using the [xmlload command on the example .xml files. Most of these will load up in Green Acres. You can also use the [xmlloadhere command to force them to load whereever you happen to be.

Note, XmlSpawner2 is fully compatible with all existing xml spawn file descriptions and can also co-exist with the standard distribution spawners and other spawners.
You can use xmlspawners and other spawners at the same time if you like.

ADDITIONAL RECOMMENDED STEPS:

There are additional installation steps that provide additional functionality to the XmlSpawner2 system. None of the additional steps are absolutely required for basic spawner functioning, but they do add additional features that will enhance the use of the system.
Feel free to go through the steps and select the ones that seem like they would be of use to you, or select none if you decide you would rather not make additional modifications.

For details on these steps, see the installation text files in xmlspawner2-vxxx-1of3.zip

NOTE: If you have installed xmlspawner2-support.zip you MUST either follow Step 4 or get rid of the custom container.cs and stealing.cs files from this package

Files:

XmlSpawner2-v321-1of3.zip required
XmlSpawner2-v321-2of3.zip required
XmlSpawner2-v321-3of3.zip required
Xmlspawner2_support.zip Recommended (Additional information on this package can be found in the next 2 post's)
XmlSpawner2_xmlextras.zip Recommended (Additional information on this package can be found in the next 2 post's)

ArteGordon- 12-27-2005
XmlSpawner2 support archive is a recommended download that contains the following files:

xmlspawner2.txt - the complete changelog and description of features

SpawnerExporter.cs - utility for reading and writing distro spawners to importable XML format

SimpleArtifact.cs, BaseArtifact.cs - classes for easily creating new artifacts

Stealing.cs, Container.cs - replacement for the distro scripts that adds support for the xmlspawner STEALING system and fixes issues with rare spawns remaining under spawner control.

StaffCloak.cs - a cloak that allows staff to quickly switch between player and staff access levels for testing of triggered spawners, quests, or other features that require player access level.

xmlspawner2doc.txt - some additional documentation

ArteGordon- 12-27-2005
XmlSpawner2 extras is a recommended download that contains spawner and quest examples to demonstrate spawner features:

DoomRares - this folder contains the scripts for 24 doom rares. These can be automatically spawned in their proper locations using the doomrares.xml file in the Spawns/Malas folder

Spawns - this folder contains example XML files that demonstrate various spawner features.

XmlQuestNPC - this folder contains .npc files that are used to configure the XmlDialog npcs used in the XML examples.

xmlquesttoken.xml, xmlspawner.xml - sample files that demonstrate the setting of spawner and questholder properties via XML file.

Frank21- 09-28-2009
Thanks for the information about the updates..I will download it when i got home..Thanks.


Regards

Albert

______
Pret immobilier