RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

XmlSpawner2

ArteGordon

Wanderer
Knightshade said:
We're not interested in saving all waypoint data, just the ability to tell the spawn that, upon spawning, it needs to go to "this waypoint."

For this sort of thing, one option to consider is to assign the "Home" location on spawning instead of using waypoints. This will allow you to spawn in one spot, and then have the mobs migrate to the target "Home" location. It accomplishes the same thing as using a waypoint, but without the additional item overhead.
Also, depending on how you set it up, it may be preferable because you can specify different target locations for each spawn as opposed to having to set up a different spawner for different waypoints.
The waypoint has the advantage of being easier to set up and manipulate.

The roving band example that I posted a little while back demonstrates this sort of thing, although you wouldnt need the two spawners or the SETONSPAWN, you could just do it as

orc/home/(5417,1168,0)

Code:
<?xml version="1.0" standalone="yes"?>
<Spawns>
  <Points>
    <Name>RovingBand#2</Name>
    <UniqueId>380f291e-4a72-4d34-ac71-63a09a6dfc38</UniqueId>
    <Map>Felucca</Map>
    <X>5431</X>
    <Y>1146</Y>
    <Width>10</Width>
    <Height>10</Height>
    <CentreX>5436</CentreX>
    <CentreY>1151</CentreY>
    <CentreZ>0</CentreZ>
    <Range>5</Range>
    <MaxCount>4</MaxCount>
    <MinDelay>2</MinDelay>
    <MaxDelay>2</MaxDelay>
    <DelayInSec>False</DelayInSec>
    <Duration>0</Duration>
    <DespawnTime>0</DespawnTime>
    <ProximityRange>-1</ProximityRange>
    <ProximityTriggerSound>500</ProximityTriggerSound>
    <TriggerProbability>1</TriggerProbability>
    <InContainer>False</InContainer>
    <ContainerX>0</ContainerX>
    <ContainerY>0</ContainerY>
    <ContainerZ>0</ContainerZ>
    <MinRefractory>0</MinRefractory>
    <MaxRefractory>0</MaxRefractory>
    <TODStart>0</TODStart>
    <TODEnd>0</TODEnd>
    <TODMode>0</TODMode>
    <KillReset>1</KillReset>
    <ExternalTriggering>False</ExternalTriggering>
    <SequentialSpawning>2</SequentialSpawning>
    <AllowGhostTriggering>False</AllowGhostTriggering>
    <SmartSpawning>False</SmartSpawning>
    <Team>0</Team>
    <Amount>1</Amount>
    <IsGroup>False</IsGroup>
    <IsRunning>True</IsRunning>
    <IsHomeRangeRelative>True</IsHomeRangeRelative>
    <Objects2>SETONSPAWN,RovingBand#1,1/home/(5447,1147,0)/SAY/let's go!:MX=1:SB=1:RT=0:TO=0:KL=0:OBJ=SETONSPAWN,RovingBand#1,1/home/(5436,1131,0)/SAY/Move it!:MX=1:SB=2:RT=0:TO=0:KL=0:OBJ=SETONSPAWN,RovingBand#1,1/home/(5437,1173,0)/SAY/Time to go!:MX=1:SB=3:RT=0:TO=0:KL=0:OBJ=SETONSPAWN,RovingBand#1,1/home/(5417,1168,0)/SAY/I'm bored.:MX=1:SB=4:RT=0:TO=0:KL=0</Objects2>
  </Points>
  <Points>
    <Name>RovingBand#1</Name>
    <UniqueId>d7077bfa-4d4e-4981-b6f3-f87f1e72f312</UniqueId>
    <Map>Felucca</Map>
    <X>5430</X>
    <Y>1146</Y>
    <Width>10</Width>
    <Height>10</Height>
    <CentreX>5435</CentreX>
    <CentreY>1151</CentreY>
    <CentreZ>0</CentreZ>
    <Range>5</Range>
    <MaxCount>7</MaxCount>
    <MinDelay>5</MinDelay>
    <MaxDelay>10</MaxDelay>
    <DelayInSec>False</DelayInSec>
    <Duration>0</Duration>
    <DespawnTime>0</DespawnTime>
    <ProximityRange>-1</ProximityRange>
    <ProximityTriggerSound>500</ProximityTriggerSound>
    <TriggerProbability>1</TriggerProbability>
    <InContainer>False</InContainer>
    <ContainerX>0</ContainerX>
    <ContainerY>0</ContainerY>
    <ContainerZ>0</ContainerZ>
    <MinRefractory>0</MinRefractory>
    <MaxRefractory>0</MaxRefractory>
    <TODStart>0</TODStart>
    <TODEnd>0</TODEnd>
    <TODMode>0</TODMode>
    <KillReset>1</KillReset>
    <ExternalTriggering>False</ExternalTriggering>
    <SequentialSpawning>-1</SequentialSpawning>
    <AllowGhostTriggering>False</AllowGhostTriggering>
    <SmartSpawning>False</SmartSpawning>
    <Team>0</Team>
    <Amount>1</Amount>
    <IsGroup>False</IsGroup>
    <IsRunning>True</IsRunning>
    <IsHomeRangeRelative>True</IsHomeRangeRelative>
    <Objects2>orc:MX=4:SB=1:RT=0:TO=0:KL=0:OBJ=orcishmage:MX=1:SB=1:RT=0:TO=0:KL=0:OBJ=orcishlord:MX=2:SB=1:RT=0:TO=0:KL=0</Objects2>
  </Points>
</Spawns>

(edit)

just tested saving and restoring waypoints on xmlsave/xmloads using the scheme I described earlier and it works fine. I'll add it to the next release.
 

ArteGordon

Wanderer
paole said:
hi again.

one thing i always notice is, that the spawner loads at the wrong height when i do a xmlnewloadhere. for example i got a 2-story-house and i'm staying in the 1st floor and do the load, the spawner is getting loaded on ground floor. staying on ground floor, the spawner gets loaded on 1st floor.

not really tedious, but sometimes bothering. :eek:

ok, I figured out a way to make this work and it looks pretty good. It will be in the next release.
 

ArteGordon

Wanderer
updated to version 2.57

from the changelog

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

(edit)

sorry, forgot to add one more thing to the update..
(if you already dl'd it it is just an update to XmlSpawnerGump.cs in xmlspawner2-v257-2of2.zip)

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

paole

Wanderer
ogol said:
:confused: how do i use this script? :confused:
read the instructions shown on page 1 of this thread.

if the server runs, type [addxmlspawner and that's it.
ask again if you don't get it.
 

ArteGordon

Wanderer
updated to version 2.58

quite a few things in this one

from the changelog

DESCRIPTION:
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 to 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.
 

ArteGordon

Wanderer
sorry, I made a quick update to XmlQuestToken.cs in xmlspawner2-v258-2of2.zip

It wasnt restoring reward return container information in player made quests on server restarts . If you have already downloaded it, then just update that file and it will be fine.
 

jaynigs

Wanderer
Hi arte, i have a question about smartspawning please.

If you can picture this scenario,

a group of warriors lure away a monster from its spawn point so they can kill it easier, they go say 2 - 3 screens away from the spawn point, and the spawner "switches off" does the monster dissapear? as ive had reports of them vanishing without a trace with smartspawning set to true.

Thanks and good work

Jay
 

ArteGordon

Wanderer
ah, excellent point. Yes, once players are out of the activation range of the spawner it could reset if the spawner was full and the mob undamaged. I can put in an ai check to see if any mobs are active before resetting. Thanks for pointing that out.

(edit)

I've added a homerange check on the mobs so that if they are not within their normal homerange (and therefore in general within the spawner activation range) then it will not inactivate until they return.
I'm testing it out but it will probably be in the next release. Thanks.
 

jaynigs

Wanderer
Hi arte, something else i thought id add.

2 problems with Simpleswitches,

1) The Decay
2) They are movable


Just thought id mention this, ive fixed it for my shard, but i thought id let you know. Not sure if that was by design.
 

ArteGordon

Wanderer
you're right. Probably better to have them immovable by default than to expect everyone to set them to immovable after they have positioned them.
 

Brennan

Wanderer
Little Problem with BaseXmlSpawner

Hi All,

I'm using the xmlspawner v2.58 and noticed that drop_probability is not working correctly on my computer.
So I chaged this code in BaseXmlSpawner.cs:

try{drop_probability = Convert.ToDouble(keywordargs[1]);}

with this one:

try{drop_probability = XmlConvert.ToDouble(keywordargs[1]);}

And now it works.
 

ArteGordon

Wanderer
thanks, I'll take a look at it.

(edit)

I could not reproduce this. Could you perhaps post the .xml for a spawner that is not behaving properly. I suspect it is due to some embedded chars in the spawn spec perhaps due the editor that you are using but that's just a guess.
 

ArteGordon

Wanderer
updated to version 2.59

from the changelog

DESCRIPTION:
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,[itemtype]]]]/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).
 

Brennan

Wanderer
Hi ArteGordon, Thanks for great spawner.

I have RunUo 1.0 RC0 and Microsoft Framework v1.1.4322.

On my computer the Convert.ToDouble(string) didn't working, when string is like "0.25" and working when string is "1", "2", i.e. integer. I guess that this is a framework problem.

Little example:

using System;
using System.IO;
using System.Xml;

class A
{
static void Main()
{

string S = "0.2";
double D= Convert.ToDouble(S);

Console.WriteLine(S);
Console.WriteLine(D);
}
}


Generates errors on my computer.
If i'm using XmlConvert.ToDouble, then all is ok.


I'm using the notepad for editing and standart .xml files from your instalation pakage v.2.58.

P.S. and i,m using a simple spawn: ogre/ADD,0.25/WEAPON,2,5
 

ArteGordon

Wanderer
yeah, I thought that it might be a framework issue. There are a number of spots where Convert.ToDouble gets used. I assume that you hit them all. I checked out XmlConvert.ToDouble and I'm not sure which is preferred, but Ill look at this issue for the next release.
 
Top