Alain Delocke
Wanderer
Awesome, thanks a lot!
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!
[RunUO 2.0 RC1] Courageous Random Encounter System
- Thread starter Courageous
- Start date
Courageous
Wanderer
I looked into the cleaner thing. No, RandomEncounters doesn't clean Mobiles after a shard restart. I should warn you, if I did do that, and a mob had rummaged a corpse, you might not much like the outcome.
Random encounters sets the homerange for the mob. They wont wander far from their spawn point. This is how normal spawners work, as far as I know. The difference between normal spawners and random encounters, is that with normal spawners, there is a fixed upper limit on the number of mobs on your shard. With random encounters there's not. In some ways, that's the point: make players out in the wilds and in dungeons constantly have to deal with creatures.
So I can see how this might be a concern. I suppose I could subject tagged mobs to a timer, but force them to drop pack items just prior to being deleted on shard restart.
Anyway, I updated to 1.1R today. A number of fixes and small changes.
C//
Random encounters sets the homerange for the mob. They wont wander far from their spawn point. This is how normal spawners work, as far as I know. The difference between normal spawners and random encounters, is that with normal spawners, there is a fixed upper limit on the number of mobs on your shard. With random encounters there's not. In some ways, that's the point: make players out in the wilds and in dungeons constantly have to deal with creatures.
So I can see how this might be a concern. I suppose I could subject tagged mobs to a timer, but force them to drop pack items just prior to being deleted on shard restart.
Anyway, I updated to 1.1R today. A number of fixes and small changes.
C//
Boulder
Sorceror
random encounter
i get this message
i jest down loaded and put it in customs foulder not sure whats wrong the
RandomEncounters.xml is there
i get this message
Code:
Reports: Stats: Loading...done
Reports: Staff: Loading...done
Sorious' Ingame Forums
---------
Loading...done
---------
Xanthos.Utilities.ConfigParser attempting to load Data/ClaimConfig.xml...
Xanthos.Utilities.ConfigParser success!
Xanthos.Utilities.ConfigParser attempting to load Data/AuctionConfig.xml...
Xanthos.Utilities.ConfigParser success!
RandomEncounters: Could not find config file: ./Scripts/Custom/RandomEncounters
RandomEncounters.xml
##### RandomEncounters: ***FAILED INITIALIZATION***!
----------
Loading ACC...
- Loading Central Memory - Done.
Done in 0.0 seconds.
----------RandomEncounters.xml is there
Courageous
Wanderer
I have a sense of humor. Thing is if you don't read the notes and the config file, you're almost certain to ask us some dumb questions next. 
C//
C//
But fortunately I found it out soon enough 
Ok, let me start off by saying... wow.
Secondly, I am relatively new to this stuff, and I have a few questions that your post didn't clarify.
Obviously, this system removes the need for world spawners. It does not remove the need for spawners for vendors and champions and such though, right?
Secondly, if I am running a relatively small shard (10-20 players online at any time), what is the difference (hardware usage wise) between this and a conventional spawner system? Given that the conventional system will spawn when a player is in range.
Thirdly, since this is a region-wide thing, to set specific spawns for specific locations I would still need to use a spawner?
Thank you in advance. ^_^
Secondly, I am relatively new to this stuff, and I have a few questions that your post didn't clarify.
Obviously, this system removes the need for world spawners. It does not remove the need for spawners for vendors and champions and such though, right?
Secondly, if I am running a relatively small shard (10-20 players online at any time), what is the difference (hardware usage wise) between this and a conventional spawner system? Given that the conventional system will spawn when a player is in range.
Thirdly, since this is a region-wide thing, to set specific spawns for specific locations I would still need to use a spawner?
Thank you in advance. ^_^
Courageous
Wanderer
The system is very flexible. Like point spawners, random encounters only spawn up around players. That is, by definition, how it works. Random encounters is a regional spawing system, but before it's that, it's a random-player selection system.
I.e., some percentage of your players are picked for encounters, and then, depending one what region they are in, whether they are on or off road, whether it is day or night, whether they are in the water or not, whether they are a certain "level," and so forth, they may get an encounter that is appropriate for those circumstances.
If it were me, I'd keep a few point based spawners around, but then use random for spice, wilderness regions, and of course for the cracks between the spaces in dungeons and what not. You can also use it for scenery. One clever user used it to spawn scenery items, like spider webs in dungeons.
Another clever user correctly discerned that if he created lots of his own regions, he could use random encounters at a finer level of granularity than would first be assumed.
Vendors, you'll want to be in predictable locations, and reliably present. However, I do know someone who was spawning vendor camps with random encounters, and only selling interesting items through these camps.
I don't have any reason to believe that random encounters is anything except very light weight. I shouldn't expect you to need any different hardware at all.
The one issue I could sort of imagine, only on a larger shard, is that the encounter system checks people for encounters all at once. If you had 500 qualifying players, this might be enough to cause a brief hiccup in the shard. If someone told me that were happening, I'd find a way to kick off the encounter checks in staggered timers. Easy fix, but it hasn't come up.
One user has noticed that mobiles spawned by the system are never despawned. I haven't fixed this yet, although I am thinking about it. Note that mobs are never spawned if not on a player. Random Encounters is definitionally player-focused.
If the mobs creep up on your shard, and the players don't kill them, you could, theoretically, have a problem (a similar problem with items was taken care of a long time ago). I have yet to set up mob deletion due to rummaging. Like, what to do? No one has told me that this is a real problem. If they did, I would be sure to put in a fix.
In other news, a system to spawn in the direction the player is running in is almost finished. This is part of a more generalized set of geometry based search tools I'm building.
C//
I.e., some percentage of your players are picked for encounters, and then, depending one what region they are in, whether they are on or off road, whether it is day or night, whether they are in the water or not, whether they are a certain "level," and so forth, they may get an encounter that is appropriate for those circumstances.
If it were me, I'd keep a few point based spawners around, but then use random for spice, wilderness regions, and of course for the cracks between the spaces in dungeons and what not. You can also use it for scenery. One clever user used it to spawn scenery items, like spider webs in dungeons.
Another clever user correctly discerned that if he created lots of his own regions, he could use random encounters at a finer level of granularity than would first be assumed.
Vendors, you'll want to be in predictable locations, and reliably present. However, I do know someone who was spawning vendor camps with random encounters, and only selling interesting items through these camps.
I don't have any reason to believe that random encounters is anything except very light weight. I shouldn't expect you to need any different hardware at all.
The one issue I could sort of imagine, only on a larger shard, is that the encounter system checks people for encounters all at once. If you had 500 qualifying players, this might be enough to cause a brief hiccup in the shard. If someone told me that were happening, I'd find a way to kick off the encounter checks in staggered timers. Easy fix, but it hasn't come up.
One user has noticed that mobiles spawned by the system are never despawned. I haven't fixed this yet, although I am thinking about it. Note that mobs are never spawned if not on a player. Random Encounters is definitionally player-focused.
If the mobs creep up on your shard, and the players don't kill them, you could, theoretically, have a problem (a similar problem with items was taken care of a long time ago). I have yet to set up mob deletion due to rummaging. Like, what to do? No one has told me that this is a real problem. If they did, I would be sure to put in a fix.
In other news, a system to spawn in the direction the player is running in is almost finished. This is part of a more generalized set of geometry based search tools I'm building.
C//
I love a quick response, and I think you have definately gotten the award for that!
But, on a more serious note, thank you very much for your clarifications. This is definately something I will be looking into very deeply for use on my server.
About the rummaging issue, is it possible to set a flag if the monster has rummaged, and use that flag to determine if he should be deleted? Does this mean that if I was just running as fast as I could through an area, anything that spawned (and I subsequently ran away from) would be there forever, until of course some other player came along to kill it? If that is the case, I think I might rather have the rummaged item gone and just explain to players beforehand that if not blessed, items could possibly end up rummaged and destroyed. If that were my choice, how could I go about getting the system to cleanup the mobiles?
And on a side note, the flexibility of the system is one of the primary reasons I am so interested. I am developing a very in-depth race system for my server (which is 100% RP) and being able to use this to custom tailor PvM to those races will be a huge boon.
But, on a more serious note, thank you very much for your clarifications. This is definately something I will be looking into very deeply for use on my server.
About the rummaging issue, is it possible to set a flag if the monster has rummaged, and use that flag to determine if he should be deleted? Does this mean that if I was just running as fast as I could through an area, anything that spawned (and I subsequently ran away from) would be there forever, until of course some other player came along to kill it? If that is the case, I think I might rather have the rummaged item gone and just explain to players beforehand that if not blessed, items could possibly end up rummaged and destroyed. If that were my choice, how could I go about getting the system to cleanup the mobiles?
And on a side note, the flexibility of the system is one of the primary reasons I am so interested. I am developing a very in-depth race system for my server (which is 100% RP) and being able to use this to custom tailor PvM to those races will be a huge boon.
Courageous
Wanderer
Gustin said:
Edit: sorry I told you the wrong thing. There is a timer that cleans up mobiles under a variety of conditions, however if you save you shard and then stop/start it, the timer goes away. Mobiles caught in this cycle are not cleaned up yet.
Although it's like maybe two or three lines of code to put the (shard restart-surviving) delete tag on the mob in order to get it cleaned up.
Gustin said:
It wouldn't be so hard to put a race qualifier on the system. It could perhaps add some generic qualifier system that searched a mobile for props in order to test for encounter qualfication. Doesn't have the prop, no encounter.
Thank you for you kind words,
C//
Courageous
Wanderer
Not exactly.
I've been forgetting something.
There is a timer, that sweeps them under certain conditions (e.g., not if they are engaged with the player). That's what the cleanup timer does. However, if the shard restarts, they are not swept.
Items are.
So a few can be widowed and become permanent after a shard restore, that's all. As I said, it's an easy mod to make. I'll look into it.
Remembering all this, I'm not sure why I have the persistent tag for items, and not for mobiles. I guess it was because some of the items spawned (treasures chests) and what not were not deleteable by the player. That would lead to ever increaing permanent shard pollution, and so had to be fixed.
Edit: jogging my memory, I believe that there was a shard start up time penalty. Perhaps I'll revisit this from another angle to see if there might be a faster way.
C//
I've been forgetting something.
There is a timer, that sweeps them under certain conditions (e.g., not if they are engaged with the player). That's what the cleanup timer does. However, if the shard restarts, they are not swept.
Items are.
So a few can be widowed and become permanent after a shard restore, that's all. As I said, it's an easy mod to make. I'll look into it.
Remembering all this, I'm not sure why I have the persistent tag for items, and not for mobiles. I guess it was because some of the items spawned (treasures chests) and what not were not deleteable by the player. That would lead to ever increaing permanent shard pollution, and so had to be fixed.
Edit: jogging my memory, I believe that there was a shard start up time penalty. Perhaps I'll revisit this from another angle to see if there might be a faster way.
C//
HellRazor
Knight
Courageous said:
This would definately be a good enhancement, especially if its easily implemeneted! Hope you will decide to add it!
Even though its a relatively small number of NPC's left behind to run loose in the world, stuff like this tends to stack up (especially when other scripts are leaving unattended stuff laying around the world as well). Plus it's just a good practice for the system to police itself automatically.
Thanks Courageous, I'm going to give this system a spin on my test shard.
Quick question, I already have XMLSpawner installed, and I am installing this as well. Obviously there are duplicate scripts involved. My question is merely, are the xmlspawner scripts included in your package the exact same as the ones in the XMLSpawner package? If not, which are more complete: meaning, which scripts do I use, the ones that came with RandomEncounters or the ones from XMLSpawner? Thanks once again. This is going to be very entertaining to set up.
Oh, I almost forgot. If your going to add a persistant tag to fix the issue we have all been discussing, do you have any idea when? Not trying to pressure you or anything, just that I am anxious!
Thanks Courageous.
Oh, I almost forgot. If your going to add a persistant tag to fix the issue we have all been discussing, do you have any idea when? Not trying to pressure you or anything, just that I am anxious!
Thanks Courageous.
Courageous
Wanderer
I've been working on an upgrade to Random Encounters. The persistent tag thing will be in the next release. It's hard to say when that will be... schedule's a bit hectic. A week or two, perhaps. And I wouldn't worry too much. I believe that that there are quite a few users of this system, and this problem is not really a problem. To reiterate, it is only a problem for mobs that have been saved, where a shard restore occurs, and then the mobile is not killed by a player. It's not a problem for spawned items at all. And as we know, players tend to kill stuff in UO, if it's killable.
Now that I've finished the Searches code (one will note that the Octant Search allows me to pick the octant towards which the player is running--a specific Random Encounters request), I'll be able to go back and look at base features. Right now, the priorities are these:
EDIT: Upon review of the code, which was the first code I wrote for #runuo, I have decided to overhaul the entire DeleteEncounter timer system to use a single unified common clock that makes better use of the attachment system. This will solve the forementioned shard save/restore problem, be more efficient, and do the right thing, 100% of the time.
C//
Now that I've finished the Searches code (one will note that the Octant Search allows me to pick the octant towards which the player is running--a specific Random Encounters request), I'll be able to go back and look at base features. Right now, the priorities are these:
- Spawns in the direction of run.
- The spawner tag for deletion of appropriate mobiles on startup. I'm going to try to get this right, so they won't be deleted right away, but maybe 10 minutes after shard startup, only if they are not fighting, or owned by the player and so forth. A bit tricky.
- A system that allows arbitrary props adjustments on spawned creatures and items (e.g., maxstr+30).
EDIT: Upon review of the code, which was the first code I wrote for #runuo, I have decided to overhaul the entire DeleteEncounter timer system to use a single unified common clock that makes better use of the attachment system. This will solve the forementioned shard save/restore problem, be more efficient, and do the right thing, 100% of the time.
C//
Soulwalker
Wanderer
I'm not a coder so I apologise if this seems a strange question. Is it possible to have action/events attached to a random encounter? As an example, if my random encounter spawned a demon, would it be possible to immediately apply some fire damage to player mobiles in a certain range?
Courageous
Wanderer
Yes. That would be possible. The question is not whether or not it is possible, because plainly it is, but rather whether or not that should be a feature of RandomEncounters, and if so, how should that feature be applied.
Right now, for example, it is possible to add one of about 5 effects to a spawn if you want to. I could see how someone might make the next logical leap to having the effects actually be more than eye candy. But how would you want to say it? Look at the specification for the effect, and tell me how you'd like to specify the damage type, range, and amount.
It would also be possible for Random Encounters to just kind of punt on the issue, and let you specify a bit of code to call. Like this:
<Mobile pick="Daemon" onspawn="My.Namespace.Onspawn">
I could then use reflection, and call the method with known arguments. Where, what, and so forth. That, of course, would require that the person using the system know how to do a little scripting.
C//