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 v2.22
- Thread starter ArteGordon
- Start date
- Status
ArteGordon
Wanderer
cmonkey123,
yeah, thought about the props gump. Even did some quick code testing on it. It can definitely be done. Just a bit more effort. Right now the command line interface seems enough to give the idea a test run.
It's working, just doing stress testing.
yeah, thought about the props gump. Even did some quick code testing on it. It can definitely be done. Just a bit more effort. Right now the command line interface seems enough to give the idea a test run.
It's working, just doing stress testing.
ArteGordon
Wanderer
I noticed a small bug in v2.04 in which loading a save with old xmlspawners could incorrectly set the proximity range to zero instead of -1, thus making them all proximity sensor spawners.
If you have already done this and are cursing me and other members of my family because your spawners all all disabled, I have added a small command to fix this by turning off proximity sensing in all existing xmlspawners.
The command is [xmlproximityoffall
This is fixed in v2.05 soon to be uploaded.
If you have already done this and are cursing me and other members of my family because your spawners all all disabled, I have added a small command to fix this by turning off proximity sensing in all existing xmlspawners.
The command is [xmlproximityoffall
This is fixed in v2.05 soon to be uploaded.
ArteGordon
Wanderer
ok, v2.05 is done. This one has some fun stuff in it. Added the item-triggered spawning and the ability to set properties on spawns.
From the changelog:
- added item-dependent triggering. This is used in conjunction with proximity sensing. When a player with a specific named item in his pack comes within proximity range of the spawner, the spawn will be triggered. The property TriggerOnItem is used to specify the name of the trigger item. If it is set to null then items are not checked and it behaves like a normal proximity-triggered spawner. To prevent excessive pack searching, the item test is only conducted once upon crossing the proximity threshold, and the item must be in the top level of the backpack - no nested searching.
- added property specification for individual spawns. This feature allows you to set properties of each spawn in the spawner using a /propertyname/value/ format.
Multiple properties can be specified for each spawn allowing mob/item naming, unique property setting, etc. Note that this works well in conjunction with the item-triggering feature since you can create items with specified names that match the trigger name of another spawner.
An example of the specification would be instead of just listing an ogre to be spawned you would list an ogre/name/The Butcher/str/190/damagemax/50/hue/500, which would create a blue ogre, named "The Butcher", with 190 strength, and maximum attack damage of 50.
You can also spawn items in the same way e.g. specifying a woodenchest/hue/300/movable/false would create a green locked down chest, or katana/name/Master of elements/slayer/elementalban/hue/200 would create a named light blue elemental super slayer.
Note, the properties that you can set are basically the same as those that you can change with the [set command.
From the changelog:
- added item-dependent triggering. This is used in conjunction with proximity sensing. When a player with a specific named item in his pack comes within proximity range of the spawner, the spawn will be triggered. The property TriggerOnItem is used to specify the name of the trigger item. If it is set to null then items are not checked and it behaves like a normal proximity-triggered spawner. To prevent excessive pack searching, the item test is only conducted once upon crossing the proximity threshold, and the item must be in the top level of the backpack - no nested searching.
- added property specification for individual spawns. This feature allows you to set properties of each spawn in the spawner using a /propertyname/value/ format.
Multiple properties can be specified for each spawn allowing mob/item naming, unique property setting, etc. Note that this works well in conjunction with the item-triggering feature since you can create items with specified names that match the trigger name of another spawner.
An example of the specification would be instead of just listing an ogre to be spawned you would list an ogre/name/The Butcher/str/190/damagemax/50/hue/500, which would create a blue ogre, named "The Butcher", with 190 strength, and maximum attack damage of 50.
You can also spawn items in the same way e.g. specifying a woodenchest/hue/300/movable/false would create a green locked down chest, or katana/name/Master of elements/slayer/elementalban/hue/200 would create a named light blue elemental super slayer.
Note, the properties that you can set are basically the same as those that you can change with the [set command.
ArteGordon
Wanderer
next on the list is spawner-triggered spawning in which you have to clear one spawner, or make a certain number of kills on a spawner in order to activate another.
This allows creating chained or progressive spawns, that end in a boss or an item or items, like the champion spawns. In fact, you could create the champ spawns in this way.
Also putting in an /additem/itemname/ specification for the spawnstring, allowing items to be added to mobs in the same way that properties are set.
Have to deal with spawnstring specifications that will get too long for the simple text entry interface.
Probably add a separate gump for spawnstring parameters. That would allow the current spawner gump to go back to a more reasonable size.
This allows creating chained or progressive spawns, that end in a boss or an item or items, like the champion spawns. In fact, you could create the champ spawns in this way.
Also putting in an /additem/itemname/ specification for the spawnstring, allowing items to be added to mobs in the same way that properties are set.
Have to deal with spawnstring specifications that will get too long for the simple text entry interface.
Probably add a separate gump for spawnstring parameters. That would allow the current spawner gump to go back to a more reasonable size.
Cmonkey123
Wanderer
Another cool feature would be being able to link the spawner to say a switch or a door.
ArteGordon
Wanderer
actually, I will have it set up so that any named item will be able to trigger a spawner. It will work like this.
You specify the name of the itemtrigger and propertyfield to test for. The simplest are just the boolean fields, so you give it /objectname/field=true/
and whenever that field becomes true on that object, the spawner is triggered. It will be tied to the proximity sensor just as the item trigger is now.
Note, you could also tie this to things like a mobs BardPacified property so that you trigger a spawn whenever a named mob is calmed.
You could name a door, and tie it to the open property to trigger on opening.
The switch idea would obviously follow from the above examples.
I will also have basic the algebraic tests > < for scalar properties so you can link it to a mobs health for instance, or trigger when the amount of gold or number of items in a nearby chest exceeded or went below a certain amount.
Obviously lots of things that could be done with it.
The spawner chaining will be one of those things.
You specify the name of the itemtrigger and propertyfield to test for. The simplest are just the boolean fields, so you give it /objectname/field=true/
and whenever that field becomes true on that object, the spawner is triggered. It will be tied to the proximity sensor just as the item trigger is now.
Note, you could also tie this to things like a mobs BardPacified property so that you trigger a spawn whenever a named mob is calmed.
You could name a door, and tie it to the open property to trigger on opening.
The switch idea would obviously follow from the above examples.
I will also have basic the algebraic tests > < for scalar properties so you can link it to a mobs health for instance, or trigger when the amount of gold or number of items in a nearby chest exceeded or went below a certain amount.
Obviously lots of things that could be done with it.
The spawner chaining will be one of those things.
Cmonkey123
Wanderer
I love you then (in a non-gay way)! 
ArteGordon
Wanderer
sh1ny, its basically just one more line of code (consider it petty theft). Just have to add a proximitymessage property. It already has a proximitysound property that is played on triggering so its just a matter of displaying a string as well.
ok, actually 5 lines, one line for the property declaration, one line for the display, one line for the serialize, one for deserialize, one for the property gump.
I'm a bit mindful of getting too carried away with the properties but I liked David's idea. I will put it in.
ok, actually 5 lines, one line for the property declaration, one line for the display, one line for the serialize, one for deserialize, one for the property gump.
I'm a bit mindful of getting too carried away with the properties but I liked David's idea. I will put it in.
S
Seven
Guest
Now this won't spawn a bunch of crap in internal (0,0,0) will it?
ArteGordon
Wanderer
in all of the testing it has never put anything on the internal map, and I've tried a lot of obscure things.
S
Seven
Guest
Great. Thanks...I guess I'll go ahead and use it
ArteGordon
Wanderer
ok, just added the latest version. v2.06.
from the changelog:
Version 2.06
updated 1/1/04 (Happy New Year!)
- added a user-definable proximity trigger message (the ProximityMsg property) that is displayed over the player when the spawner is triggered. Based on the original idea by David in his movement spawner.
- added the ability to make player-proximity triggered spawning also dependent upon a property of any targetable item. This allows spawn chaining by making one spawner dependent on the state of another spawner. It also allows spawners to be made dependent upon things such as switches, doors, number of items, weight, or amount of gold in containers, etc. To use this feature, select the TriggerObject property in the props list, then target the object to trigger off of. Then set the TriggerOnProperty field with the property and the value to test. e.g. maxgold=20, or killcount>10, or open=true. Where maxgold, killcount, and open are property names on the objects. Supports <, >, and = operators for testing the values. Supports, int, bool, string, and double value types.
- added a killcount property to the spawner which can be used in conjunction with the property-triggering feature to chain spawners based upon the number of kills made on it. killcount is incremented for each spawn that occurs while the spawner is not full. When it reaches full spawn the counter is reset to zero. Therefore, it will keep track of player kills as long as they can keep up with the spawn and prevent it from becoming full again. Multiple chaining of spawns becomes possible with this feature (champ like spawn scenarios) with final boss mobs.
- added support for setting nested attributes on items such as armorattributes. To access these attributes use dot notation e.g. to change luck on a weapon use the specification string katana/attributes.luck/50 , or platehelm/armorattributes.magearmor/1/skillbonuses.skill_1_name/anatomy/skillbonuses.skill_1_value/20 to set magearmor and add +20 anatomy.
These are the same property names that appear in the props list.
Note, the object property triggering and proximity-triggered message features are NOT supported in xml files.
Also note, the killcount does not count the actual number of kills made, but rather the number of spawns generated, so it should be taken as a close approximation rather than an accurate count of kills.
from the changelog:
Version 2.06
updated 1/1/04 (Happy New Year!)
- added a user-definable proximity trigger message (the ProximityMsg property) that is displayed over the player when the spawner is triggered. Based on the original idea by David in his movement spawner.
- added the ability to make player-proximity triggered spawning also dependent upon a property of any targetable item. This allows spawn chaining by making one spawner dependent on the state of another spawner. It also allows spawners to be made dependent upon things such as switches, doors, number of items, weight, or amount of gold in containers, etc. To use this feature, select the TriggerObject property in the props list, then target the object to trigger off of. Then set the TriggerOnProperty field with the property and the value to test. e.g. maxgold=20, or killcount>10, or open=true. Where maxgold, killcount, and open are property names on the objects. Supports <, >, and = operators for testing the values. Supports, int, bool, string, and double value types.
- added a killcount property to the spawner which can be used in conjunction with the property-triggering feature to chain spawners based upon the number of kills made on it. killcount is incremented for each spawn that occurs while the spawner is not full. When it reaches full spawn the counter is reset to zero. Therefore, it will keep track of player kills as long as they can keep up with the spawn and prevent it from becoming full again. Multiple chaining of spawns becomes possible with this feature (champ like spawn scenarios) with final boss mobs.
- added support for setting nested attributes on items such as armorattributes. To access these attributes use dot notation e.g. to change luck on a weapon use the specification string katana/attributes.luck/50 , or platehelm/armorattributes.magearmor/1/skillbonuses.skill_1_name/anatomy/skillbonuses.skill_1_value/20 to set magearmor and add +20 anatomy.
These are the same property names that appear in the props list.
Note, the object property triggering and proximity-triggered message features are NOT supported in xml files.
Also note, the killcount does not count the actual number of kills made, but rather the number of spawns generated, so it should be taken as a close approximation rather than an accurate count of kills.
ArteGordon
Wanderer
notice that while I mentioned earlier that I would allow using mobs and mob attributes to trigger spawners in addition to items, I didnt add it to this release. Actually, I implemented it and tested it out, but I became a bit concerned about lag issues since mobs can generate a lot of onmovement events. Thats why its not in.
I'll continue to think about it.
I'll continue to think about it.
ArteGordon
Wanderer
thanks. I have to admit that a lot of it is selfish, since these are the things that I want to have in order to torment my friends - more interesting ways to bring them death, as they put it. But Im glad that other people benefit can from it.
I still want to have a bit more control over item drops on spawned mobs, and I would like to revisit the mob-triggered spawning, since one tactic they like to use is pulling mobs into relatively safe areas to pound on them... or at least what they thought was safe, hehehe.
I'm going to have to address the spawn specification issue since I cant just keep making the gump wider
, so probably a separate gump for entering in the strings. I dont think I will go all the way to using the props gump itself. I will be keeping the current string specification scheme since it really allows transparent backward compatibility and makes life much easier for me.
I still want to have a bit more control over item drops on spawned mobs, and I would like to revisit the mob-triggered spawning, since one tactic they like to use is pulling mobs into relatively safe areas to pound on them... or at least what they thought was safe, hehehe.
I'm going to have to address the spawn specification issue since I cant just keep making the gump wider
, so probably a separate gump for entering in the strings. I dont think I will go all the way to using the props gump itself. I will be keeping the current string specification scheme since it really allows transparent backward compatibility and makes life much easier for me.Philantrop
Sorceror
ArteGordon said:
That means those spawner attributes won't be exported to/imported from XML files?
If so: Could you possibly change this?
Thanks, btw, for the great work!
- Status