Xmlspawner2 v2.22

[ArteGordon]

thanks. fixed for the next version. I'm afraid all of the constructables currently ignore their spawnrange settings forcing you to set it after you make it.

 

[ArteGordon]

updated to version 2.17

Added keywords allowing random magic items to be dropped, added to spawned mob, or given to players.

from the changelog:

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.

For example:
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.

 

[ArteGordon]

updated to version 2.18

- added the GUMP keyword that will send a gump containing the designated text to the triggering player. Handy for using the spawners to create quests.

- added a sample xmlfile quest (blather.xml) using the spawner triggering and gump features.

from the changelog:

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". Where gumpconstructor is the name of your gump constructor. Gumps must be constructed with argument lists of the form public XmlNewGump( XmlSpawner spawner, string gumptext, string gumptitle, int gumpnumber )
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.

 

[sh1ny]

Hmz this is what i got when i've tried to load it :

# Failed SetItemProperty Object initialization : 20.1.2004 г. 17:27:08: Format: ObjectName X Y Z Map SpawnerName Fileposition Xmlfile
Blather7 5441 1169 0 Felucca Blather8 -1

# Failed TriggerObject initialization : 20.1.2004 г. 17:27:08: Format: ObjectName X Y Z Map SpawnerName Fileposition Xmlfile
Blather7 5441 1169 0 Felucca Blather8 -1

 

[ArteGordon]

is this with 2.18 installed? When you do an [xmlload you should see a message near the end indicating that it is resolving self references.
I'll double check it.

(edit)
Sorry, I went back and double checked. Even tho it complains it is fine. Just [xmlload it a second time (not actually necessary, but it will load without warnings if you do). It complains because of the order in which the spawners are defined in the file (it makes Blather8 before it makes Blather7), but it gets resolved in the last pass so you can ignore those warnings.

I'll fix it up so that it doesnt complain about stuff like that.

 

[k0t]

Can't download the newest version!

 

[Shard Admin Adam]

Link is down...

 

[ArteGordon]

I uploaded it again. Link should be working now.

 

[[mute]]

I don't suppose you would know a way to edit the properties of an xmlspawner added via a basecamp script? ;D Trying to edit homerange/spawnrange and if possible even the creatures set to spawn, upon the addition of the new xmlspawners.

using System;
using Server;
using Server.Items;
using Server.Mobiles;

namespace Server.Multis
{
public class GodCamp : BaseCamp
{

[Constructable]
public GodCamp() : base( 0x108B )
{
}

public override void AddComponents()
{

ConquerSwitch CS = new ConquerSwitch();

AddItem( CS, 0, 0, 0 );

XmlSpawner XMLS = new XmlSpawner();

AddItem( XMLS, -1, 0, 0 );

XmlSpawner XMLS2 = new XmlSpawner();

AddItem( XMLS2, -1, -1, 0 );

XmlSpawner XMLS3 = new XmlSpawner();

AddItem( XMLS3, -1, +1, 0 );

XmlSpawner XMLS4 = new XmlSpawner();

AddItem( XMLS4, +1, -1, 0 );

XmlSpawner XMLS5 = new XmlSpawner();

AddItem( XMLS5, +1, 0, 0 );

XmlSpawner XMLS6 = new XmlSpawner();

AddItem( XMLS6, +1, +1, 0 );

XmlSpawner XMLS7 = new XmlSpawner();

AddItem( XMLS7, 0, +1, 0 );

XmlSpawner XMLS8 = new XmlSpawner();

AddItem( XMLS8, 0, -1, 0 );

//AddMobile( new XmlSpawner(), 1, -1, -1, 0 );

}

public GodCamp( Serial serial ) : base( serial )
{
}

public override void Serialize( GenericWriter writer )
{
base.Serialize( writer );

writer.Write( (int) 0 ); // version

}

public override void Deserialize( GenericReader reader )
{
base.Deserialize( reader );

int version = reader.ReadInt();
}
}
}

Ideas?

 

[ArteGordon]

sure. You can set/get any of the public xmlspawner properties.

For example, after you make the items, just set the props you want like

[code:1]
XMLS.HomeRange = 5;
XMLS.SpawnRange = 5;
[/code:1]

The prop names will be accessible as they appear on the [props gump. You can also look in the CommandProperties section of the xmlspawner2.cs script (starting around line 3400).

Note there are several different constructables that take different args, so without args you just get an empty default spawner.
[code:1]
new XmlSpawner(string creatureName);
[/code:1]
would make one that spawns a single creature

[code:1]
new XmlSpawner( int amount, int minDelay, int maxDelay, int team, int homeRange, int spawnRange, string creatureName );
[/code:1]
would make a spawner with the given delay/range specs and would spawn the given number (amount) of creatures

 

[[mute]]

Hey thanks I'll let you know how it goes.

 

[[mute]]

Oh, sorry, another question. What about multiple creatures for same xmlspawner? From the method I see there's only room for one 'string creaturename'.

 

[[mute]]

arg, that method doesn't seem to work with my script. I have included the server.mobiles but it doesn't recognize orc.

- Error: Scripts\Custom\Tru'sSystem ComboPack\ConquerSwitchAddon.cs: CS0103: (l
ine 23, column 60) The name 'orc' does not exist in the class or namespace 'Serv
er.Multis.GodCamp'

:?:

 

[[mute]]

arg again, nevermind. Been repairing computers all day, brain's fried.

 

[atriticuss]

ok ive been away for a little while and havent checked out the latest version yet but one thing i think would help if you havent already done it would be to make the spawning lines more veiwable since with all your addons can get lengthy on certain spawns i have to type blindly and there was no way to scrol over to see what i typed and if i typed it correctly so im thinking a scroll button or a customizable window or maybe just a bigger window would help. how would i change the horizontal size of the gump?

 

[ArteGordon]

in the latest version, I have added a button to the right of each spawn description line that opens up a large text gump to facilitate viewing and editing those long lines. I had previously just expanded the horizontal gump size, but that didnt really add enough real estate and made the gump a bit unwieldy. Unfortunately, there still isnt any way to actually edit text in the line itself other than deleting from the end of the line and retyping. This is a client-side limitation of text entry into gumps and I have yet to find an alternative. If someone knows of a more sophisticated text-entry gump let me know.

 

[ArteGordon]

updated to version 2.19


- Added new questnote item, and XmlQuestToken class for multipart spawner quest construction.
- Added a second xmlquest (blather2.xml) that demonstrates the new quest items and triggering features.
- Added the SETONCARRIED keyword that allows you to set properties on a named item carried by the triggering player.
- added the NoTriggerOnCarried property, that blocks spawner triggering when the player is carrying the named item.

from the changelog

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

 

[atriticuss]

umm, i got this error with v219


- Error: Scripts\Custom\XmlSpawner2-v219\QuestNote.cs: CS0104: (line 145, colum
n 8) 'QuestStatusGump' is an ambiguous reference
- Error: Scripts\Custom\XmlSpawner2-v219\QuestNote.cs: CS0103: (line 146, colum
n 32) The name 'g' does not exist in the class or namespace 'Server.Items.QuestN
oteGump'

 

[ArteGordon]

I will check the zip to make sure I got all of correct files in there but I would double check to make sure you extracted all of the scripts from the archive. In particular, the QuestStatusGump is in XmlQuestGumps.cs, so make sure that got updated.

(edit)
I unzipped into a clean b36 install and ran with no errors, so either it is an imcomplete extraction, or perhaps there were other copies of files from previous versions that were left/renamed/modified.

The files included in the archive should look like this after extraction

01/20/2004 11:55 PM 12,487 blather.xml
01/26/2004 10:32 PM 14,339 blather2.xml
01/25/2004 10:10 AM 4,788 QuestNote.cs
01/04/2004 02:16 AM 4,293 SimpleNote.cs
01/17/2004 03:23 AM 26,973 SimpleSwitches.cs
01/26/2004 10:10 PM 7,751 XmlQuestGumps.cs
01/26/2004 10:09 PM 8,779 XmlQuestToken.cs
01/26/2004 10:42 PM 316,563 XmlSpawner2.cs
01/26/2004 10:51 PM 50,768 xmlspawnermod2.txt

 

[DeepFreez]

Refactoring suggestion

I have a bit of a suggestion on how to change the code structure.

The functionality of the XMLSpawner is becoming less and less spawnerlike and more and more event-trigger-like.
Why not put that distinction in the code itself.

Make two Items

• XMLSpawner: doing all the spawn stuff, and only spawn stuff. It will have two ways to spawn things: with its own internal timer and with the call of an external method (say trigger)
• XMLTrigger: doing all the trigger testing and questlike things. This thigny will be able to test conditions on Mobiles and Objects, do range checking etc. If it is determined that it should fire, it will display range messages, set properties on Objects, Mobiles or the triggering Player and finally call the trigger method for the spawner it is associated with.
  [/list:u]
  
  Doing the above split gives you a plethora of cool new things you could do.
  
  • Create an interface ITriggerEvent that has one function called trigger. This will meand that you could very easily have a trigger fire events at other things than just spawners.... like a state holder (something like the combination lock, only more generic) or even a statemachine!!!!
  • A trigger could have a list of things to trigger, meaning that one trigger can set of more than one spawner or other thingy.
  • The trigger itself could have an independant timer for more complex timing or monitoring of conditions elsewhere.
  • A trigger could implement ITriggerEvent itself, allowing one trigger to activate another.
  • etc.
    [/list:u]
    
    And lastly, it would simplify the code, making it easier to extend and maintian
    
    Sound like it makes sense?