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
jaynigs said:
@ cosmos, you type in the command where u normally would type in your spawn on the spawner.. so instead of just an OGRE you add the extra bits.

ie ogre/hue/RND,1,500 which will spawn an ogre with a random hue, if ive read that correctly
yep, right on.
 

cosmos

Wanderer
Thanks guys, it is working for me now... I guesss what threw me is that when I enter the special commands as CAPS, they do not show that way on the screen after saving. But no matter... you all earn your tolerance award for the day.
 

jaynigs

Wanderer
For those that want to use brazier script i have found a way round my problem. It seems that all lights in game cannot be set to false from property menu..but.. it lets you set true... i guess its an issue with baselight.cs, i have found a work around that does the same thing more or less.

use SET/burning/true in spawner and burning=false in triggerobject properties.
This way the spawn starts when the brazier is off and then the spawner turns it on and stops the spawn. You cant tell the difference anyway as the brazier doesn't actually go out.. lol.

Required effect achieved, if someone can improve it in anyway, please do..


Enjoy

Jay
 

ArteGordon

Wanderer
jaynigs said:
Hi again, sorry about this, ive reached another problem that i dont know how to resolve.

The brazier works great except that i cant use the set command to turn it off after spawn. I also still cant set it to false in props menu. I can only change this by double clicking the brazier.

Can anyone help please?

Thanks again and sorry!
the way baselight works is that when you try to change the value of burning, it sets it to true, and then starts a timer and when the timer expires burntout is set to true and burning is set to false. Also the itemid is then set to the UnlitItemID or BurntOutItemID if it is available.
If burntout is true, then you cant reignite it by double clicking.
So to reignite, set burntout to false, then double clicking will set burning to true again for the time period set by duration.
 

ArteGordon

Wanderer
jaynigs said:
For those that want to use brazier script i have found a way round my problem. It seems that all lights in game cannot be set to false from property menu..but.. it lets you set true... i guess its an issue with baselight.cs, i have found a work around that does the same thing more or less.

use SET/burning/true in spawner and burning=false in triggerobject properties.
This way the spawn starts when the brazier is off and then the spawner turns it on and stops the spawn. You cant tell the difference anyway as the brazier doesn't actually go out.. lol.

Required effect achieved, if someone can improve it in anyway, please do..


Enjoy

Jay
:) creative solution. if it works it works.
 

Quantos

Lord
I have a problem with the new version. When the spawner is double clicked the primary gump opens up, but when the props button is used the primary gump doesn't close. It has to be manually closed in order for the max count to take if you edit it. It was a little more convenient in ver 2.19 when the primary gump would close when props was used.

Is there a feature that makes use of this new method?
 

ArteGordon

Wanderer
Quantos said:
I have a problem with the new version. When the spawner is double clicked the primary gump opens up, but when the props button is used the primary gump doesn't close. It has to be manually closed in order for the max count to take if you edit it. It was a little more convenient in ver 2.19 when the primary gump would close when props was used.

Is there a feature that makes use of this new method?
oh, I did that intentionally. I didnt like having to reopen the spawner gump after using the props gump. Its really easy to change it back to the previous behavior if you prefer it.
around line 7680
Code:
    // Show the props window for the spawner, as well as a new gump
                    state.Mobile.SendGump( new XmlSpawnerGump(m_Spawner, this.X, this.Y, this.m_ShowGump));
                    state.Mobile.SendGump( new PropertiesGump( state.Mobile, m_Spawner ) );
                    return;
take out the SendGump line for the XmlSpawnerGump

Note, with the new refresh button you can just press it after doing a props to have the values updated in the spawner gump.
 

jaynigs

Wanderer
@Arte, is there a way to use the SET command in addition to a spawn,

IE Daemon/set/burning/true... to spawn a daemon and change the set item state?

Also..

Can i spawn random spawn with the RND command?
 

ArteGordon

Wanderer
jaynigs said:
@Arte, is there a way to use the SET command in addition to a spawn,

IE Daemon/set/burning/true... to spawn a daemon and change the set item state?

Also..

Can i spawn random spawn with the RND command?

look at subgrouping. That is basically what it does. It links together multiple entries so that they are "spawned" together. Just add one line for your daemon, and a separate line for your set. Then assign them to the same subgroup and you are done. That way they will always spawn together.

making random spawns with the RND command eh... I'm not exactly sure what you want to do. If it is randomly spawn one mob from a list of mobs that you specify, then that is quite easy. You dont even need to use RND. What you do is just list all of the mobs you might want to spawn in separate entries in the spawner, set the maxcount of the spawner to 1, and thats it. The spawner will randomly pick one from the list. If you change the max counts for each of the entries, it will affect the probability of getting that entry. For example having 10 spawns with max counts of 1 each, and then having one of them with a max count of 10 will make that one much more likely to be selected for spawning (there is a little description of probabilistic spawning in the xmlspawnermod2.txt file).
 

jaynigs

Wanderer
Excellent, thanks....

With subgrouping, how exactly does it work.. heres a scenario..


group 1

deamon
SET/burning/true

group 2

fire steed
SET/burning/true


max spawn set to 2? so that when daemon spawns the set trigger goes off, and then when fire steed spawns the set trigger goes off.. then back to the daemon?
 

ArteGordon

Wanderer
jaynigs said:
Excellent, thanks....

With subgrouping, how exactly does it work.. heres a scenario..


group 1

deamon
SET/burning/true

group 2

fire steed
SET/burning/true


max spawn set to 2? so that when daemon spawns the set trigger goes off, and then when fire steed spawns the set trigger goes off.. then back to the daemon?

Depends on whether you have sequential spawning set. If you just run it as usual then each time it spawns it will randomly select one of the two groups. If you set it for sequential spawning then it will go in order, first one, then the other, then back, as you described.

and yes, you would want maxcount set to 2 since when it spawned a subgroup you would want it to spawn both things in the subgroup.
 

jaynigs

Wanderer
Thanks mate, im full of questions today...lol

Ive sussed most of it out.. just one problem

i cant use my set command in 2 different groups as if one already exists.. it just deletes it :( thinking its a duplicate enty
 

ArteGordon

Wanderer
jaynigs said:
Thanks mate, im full of questions today...lol

Ive sussed most of it out.. just one problem

i cant use my set command in 2 different groups as if one already exists.. it just deletes it :( thinking its a duplicate enty
ah, yes. I'm planning on changing that in the next release. It is just trying to be too clever. You can get around it for now by just making the strings different, like adding a / at the end of one.
 

ArteGordon

Wanderer
Quantos said:
I have a problem with the new version. When the spawner is double clicked the primary gump opens up, but when the props button is used the primary gump doesn't close. It has to be manually closed in order for the max count to take if you edit it. It was a little more convenient in ver 2.19 when the primary gump would close when props was used.

Is there a feature that makes use of this new method?
ah, ok, now I see what you are talking about. I had stopped setting maxcount from the props once I made it accessible from the main gump, so I didnt notice the behavior you were referring to. My refresh suggestion is of no help with that. Indeed, closing the spawner gump before changing maxcount in the prop gump is the only way for it to know which maxcount is "correct". Its a bit tricky now that maxcount can be changed in both gumps. As it now stands, the spawner gump always wins and as you point out, you have to close it to override that behavior.
 

Quantos

Lord
Well heck Cleetus don't that beat all... ... we dun even try ta change it in thar...

Now I don't have to open props just to change the MaxCount :)
 

jaynigs

Wanderer
Thanks arte , it didnt work as "a", maybe i set it wrong, but i tried b4 i seen your post.. numbers worked for me tho.. ie SET/burning/true/1 .../2.../3 etc

All works fine and does the job, theres only one flaw left which aint that big of an issue and absolutely nothing to do with your spawner.. but apart from that its all good stuff... Thanks for your time and effort!!!

Jay
 

ArteGordon

Wanderer
Quantos said:
Well heck Cleetus don't that beat all... ... we dun even try ta change it in thar...

Now I don't have to open props just to change the MaxCount :)
ROFL!
(wouldnt let me post with just ROFL! too short! double ROFL!)
 

ArteGordon

Wanderer
jaynigs said:
Thanks arte , it didnt work as "a", maybe i set it wrong, but i tried b4 i seen your post.. numbers worked for me tho.. ie SET/burning/true/1 .../2.../3 etc

All works fine and does the job, theres only one flaw left which aint that big of an issue and absolutely nothing to do with your spawner.. but apart from that its all good stuff... Thanks for your time and effort!!!

Jay
yeah, actually you can append anything to an otherwise valid specification string and even though it will complain about not recognizing them as properties, it will have no effect on anything (everything up to that point will already have been done). It just ignores invalid properties. Using the single numbers at the end (any string there would work) is a clever little hack that avoids having the complaints show up.
 
Top