Full Version : XmlSpawner2 v3.14 [RunUO 2.0] released
xmlspawner >>XMLSpawner - Releases & Updates >>XmlSpawner2 v3.14 [RunUO 2.0] released


<< Prev | Next >>

ArteGordon- 08-13-2006
updated to RunUO 2.0 version 3.14

New to version 3.14
updated 8/13/06

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

- modified the way xmlspawners keep themselves from being included in container item counts to fix an issue with negative counts under RunUO 2.0 (thanks to haazen 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.

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

New Features
-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 support for the core ISpawner interface. 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.

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