Courageous
Wanderer
Courageous Random Encounter System
Version: 1.3
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
UPDATED 28 OCT 2006
Major update. This version of the Random Encounter Engine now includes a fully populated distro. This distro follows directly from Nerun's but inserts the encounters as region-based, probability-based, level-limited entries into the classic encounter system.
Removed a crash bug associated with the prior version of the cleanup system.
PLEASE NOTE: YOU NEED TO INSTALL THE SEARCHES SCRIPT SYSTEM FOR RANDOM ENCOUNTERS TO WORK NOW.
UPDATED 22 OCT 2006
Substantially overhauled the cleanup system. It is now totally persistent, and functions on a unified (single) timer. Also changed the cleanup cycles somewhat. If players are in range of to-be-cleaned up encounter material (items or mobiles), these will not be cleaned up for count cleanupGrace="n" (a new configuration variable) number of times. If this variable is set to "0", the local presence of a player always squelches cleanup.
Tamed creatures are never cleaned up, even if they later become untame. Items, once owned by any mobile, are never cleaned up, even if they are disgarded and dropped on the ground.
UPDATED 7 OCT 2006
Fixed a bug that caused general encounter areas (like default wilderness) to override more specific encounter areas (like wilderness covetous entrance).
Allows the graphical debug animation effect to be controlled separately from the text logs.
Allows specific mobile spawns to have custom animations with hues (a daemon spawned in a pillar of fire, for example).
Allows the spawn to be forced to attack the player right away, to eliminate spawn/attack delay.
UPDATED 11 SEP 2006
Fixed a small bug that caused small animal's to attack players during a random encounter. This system is no NO LONGER BETA.
[many other updates deleted]
ABOUT RANDOM ENCOUNTERS...
This is a region-based "random encounter" engine for RunUO. It operates based on named regions of interest, probababilities, understanding of the character's "level," and night, day, on road, off road, on-water, and other parameters.
Encounters do not have to be hostile. For example, this is a good way to make your world "come alive". You can set it up so that wilderness creatures frequently appear near the player when the player is in the wilderness. Since these creatures are only spawned at or near where an active player can see them, no CPU is wasted. It also adds an element of unpredictability to the shard.
The system is fully configurable, by facet, by region type, and by named regions (if desired). Additional options include level limitation (the player must be at least a "5th level" mage), time limitation (encounter only occurs at Night), road limitation (this encounter only occurs either on-road or off-road), and encounter scaling (this encounter scales up to match the player's ability). These features allow the administrator great control over who has what encounters, when and where.
For example, one might set up the 4th level of dungeon Covetous to have a few random dangerous encounters.One might further set it up so that one has to be at least "3rd level" to get the encounter, and that if one is a significantly higher "level", the encounter scales up to match the player's abilties.
Clever admins will note that, with the help of a region creation tool, one can combine Random Encounter regions with novel new regions of one's own creation. For example, create a custom named region called "Evil Swamp," over an area of swamp you want to have area-based encounters for, and add an entry to the RandomEncounters.xml file. Voila! No more point-based spawners.
The system runs off a configuration file; the system rescans this file periodically, if it notices that the file has been written. Your shard does not have to be bounced for you to make configuration changes.
INSTALLATION
Extract the zip file into your Scripts/Custom directory. Extract the Searches.zip into your Scripts/Custom directory. Note that the configuration file "RandomEncounters.xml" is expected to reside in Scripts/Custom/RandomEncounters. If you want to put it somewhere else or name it something else, find the variable "m_EncountersFile" in the RandomEncounterEngine class and fiddle with it.
HOW TO
The Random Encounter Engine is entirely controlled by its configuration file, so understanding its format is essential. Before we talk aboutthat, though, a few preliminaries:
The system is controlled on a common clock that periodically checks to see if players (player mobiles with access level == Player, not staff members!) qualify for a random encounter. To see if they qualify, first the system decides which picker is in use. There are two.
The first picker is the "sqrt" (square root) picker. Its the default. When the sqrt picker is in use, the system finds the square root of the number of players online. The system then picks this many players to see if they further qualify for a random encounter. No more than one encounter per player.
The second picker is the "all" picker. Using the all picker, the system considers all players online for a random encounter.
Note switching between pickers is a dramatic event, which will GREATLY impact the number of random encounters your player see; you should decide early which picker you're going to use.
A player qualifies for a random encounter when:
Now on to the details. Consider the following example:
This is a standard nested tag formatted xml file. It supports the following tags:
"RandomEncounters" tag. This supports the following attributes and defaults:
Note how Mobiles and Items can appear embedded in one another. To know the rules, use some common sense. An Item can be in a Mobile (e.g., "orc has a Sword"), and an Item can be in an Item (e.g., "sword in a chest"), but a Mobile cannot be in an Item! A Mobile, however, might belong to another Mobile's team...
Now a little word on picking. Consider the following (modified) fragment:
The above says "pick 2, each randomly from OrcCaptain and OrcishLord. Then for each leader, attach 1-3 Orcs, and likewise for each leader, offer a .25 chance to have an OrcishMage. This calculates to a maximum of 10 Mobiles for the whole encounter.
Sub items spawn IN their parent items. Sub mobiles spawn NEAR their parent mobiles.
(note that if a valid spawn point can't be found, a mobile or item might not be spawned, and if this happens, the remaining part of a whole encounter might be skipped).
EQUAL PROBABILITIES
It's both possible and okay to list two encounters in the same region with the same probability. In this particular case, the system draws randomly from all matching probability levels, so you don't get the wierd case where one is always preferred over the other. This also makes it so that you don't have to do gymnastics to separate all the possibilities. One could just use ".3" ".2" and ".1" for everything, letting the system sort out the equal probability encounters...
SPECIAL THANKS
Thanks to Arte Gordon for his contribution of pieces of Xml Spawner to this code base.
Thanks to Nerun, who's spawners I imported to create the distro.
Thanks to Gandalf Parker for pointing me to RunUO and inspiring this code to be written in the first place, due to his disgruntled mumblings about the inadequacy of point-based spawners.
Courageous' (aka Joe Kraska)
Random Encounter Engine 1.3
Random Encounter Engine 1.3
Version: 1.3
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
UPDATED 28 OCT 2006
Major update. This version of the Random Encounter Engine now includes a fully populated distro. This distro follows directly from Nerun's but inserts the encounters as region-based, probability-based, level-limited entries into the classic encounter system.
Removed a crash bug associated with the prior version of the cleanup system.
PLEASE NOTE: YOU NEED TO INSTALL THE SEARCHES SCRIPT SYSTEM FOR RANDOM ENCOUNTERS TO WORK NOW.
UPDATED 22 OCT 2006
Substantially overhauled the cleanup system. It is now totally persistent, and functions on a unified (single) timer. Also changed the cleanup cycles somewhat. If players are in range of to-be-cleaned up encounter material (items or mobiles), these will not be cleaned up for count cleanupGrace="n" (a new configuration variable) number of times. If this variable is set to "0", the local presence of a player always squelches cleanup.
Tamed creatures are never cleaned up, even if they later become untame. Items, once owned by any mobile, are never cleaned up, even if they are disgarded and dropped on the ground.
UPDATED 7 OCT 2006
Fixed a bug that caused general encounter areas (like default wilderness) to override more specific encounter areas (like wilderness covetous entrance).
Allows the graphical debug animation effect to be controlled separately from the text logs.
Allows specific mobile spawns to have custom animations with hues (a daemon spawned in a pillar of fire, for example).
Allows the spawn to be forced to attack the player right away, to eliminate spawn/attack delay.
UPDATED 11 SEP 2006
Fixed a small bug that caused small animal's to attack players during a random encounter. This system is no NO LONGER BETA.
[many other updates deleted]
ABOUT RANDOM ENCOUNTERS...
This is a region-based "random encounter" engine for RunUO. It operates based on named regions of interest, probababilities, understanding of the character's "level," and night, day, on road, off road, on-water, and other parameters.
Encounters do not have to be hostile. For example, this is a good way to make your world "come alive". You can set it up so that wilderness creatures frequently appear near the player when the player is in the wilderness. Since these creatures are only spawned at or near where an active player can see them, no CPU is wasted. It also adds an element of unpredictability to the shard.
The system is fully configurable, by facet, by region type, and by named regions (if desired). Additional options include level limitation (the player must be at least a "5th level" mage), time limitation (encounter only occurs at Night), road limitation (this encounter only occurs either on-road or off-road), and encounter scaling (this encounter scales up to match the player's ability). These features allow the administrator great control over who has what encounters, when and where.
For example, one might set up the 4th level of dungeon Covetous to have a few random dangerous encounters.One might further set it up so that one has to be at least "3rd level" to get the encounter, and that if one is a significantly higher "level", the encounter scales up to match the player's abilties.
Clever admins will note that, with the help of a region creation tool, one can combine Random Encounter regions with novel new regions of one's own creation. For example, create a custom named region called "Evil Swamp," over an area of swamp you want to have area-based encounters for, and add an entry to the RandomEncounters.xml file. Voila! No more point-based spawners.
The system runs off a configuration file; the system rescans this file periodically, if it notices that the file has been written. Your shard does not have to be bounced for you to make configuration changes.
INSTALLATION
Extract the zip file into your Scripts/Custom directory. Extract the Searches.zip into your Scripts/Custom directory. Note that the configuration file "RandomEncounters.xml" is expected to reside in Scripts/Custom/RandomEncounters. If you want to put it somewhere else or name it something else, find the variable "m_EncountersFile" in the RandomEncounterEngine class and fiddle with it.
HOW TO
The Random Encounter Engine is entirely controlled by its configuration file, so understanding its format is essential. Before we talk aboutthat, though, a few preliminaries:
The system is controlled on a common clock that periodically checks to see if players (player mobiles with access level == Player, not staff members!) qualify for a random encounter. To see if they qualify, first the system decides which picker is in use. There are two.
The first picker is the "sqrt" (square root) picker. Its the default. When the sqrt picker is in use, the system finds the square root of the number of players online. The system then picks this many players to see if they further qualify for a random encounter. No more than one encounter per player.
The second picker is the "all" picker. Using the all picker, the system considers all players online for a random encounter.
Note switching between pickers is a dramatic event, which will GREATLY impact the number of random encounters your player see; you should decide early which picker you're going to use.
A player qualifies for a random encounter when:
- The facet name, region type, and region name the player is in has encounters described for it (example, the player is on Facet the facet named "Felucca", in a "Dungeon" region named "Covetous").
- Failing #1 above, the the system finds a region named "default" that otherwise qualfies by facet name and region type (example, the player is in a Felucca Dungeon, and is in Covetous, but the administrator did not define a named region for Covetous. If there is a default region for Felucca Dungeons, this will be used instead).
- The system draws a random number 0.0-1.0, and searches for the LOWEST probability encounter it can match.
Now on to the details. Consider the following example:
Code:
<!--mycomment-->
<RandomEncounters picker="sqrt" delay="15.0" interval="15.0:25.0:35.0" cleanup="300.0" debug="true">
<!--mycomment-->
<Facet name="Felucca">
<Region type="Wilderness" name="default">
<Encounter p="1.0" distance="7">
<Mobile pick="OrcCaptain,OrcishLord">
<Mobile n="1:3" pick="Orc"/>
<Mobile p=".25" pick="OrcishMage"/>
</Mobile>
<Item pick="WoodenTreasureChest">
<Item pick="OrcHelm"/>
<Item pick="ChainChest,BattleAxe"/>
</Item>
</Encounter>
<Encounter p=".05" distance="7">
<Mobile pick="EvilMage"/>
<Mobile n="2:3" pick="Brigand"/>
</Encounter>
</Region>
</Facet>
</RandomEncounters>"RandomEncounters" tag. This supports the following attributes and defaults:
- picker = the picking method, defaults to "sqrt"
- language = the globalization code, defaults to "en-US".
- skiphidden = tells the system to exclude hidden players from encounters, defaults to FALSE
- delay = amount of secs before encounters begin after server start, defaults to "60"
- interval = frequency in secs encounters are checked, defaults to "1800". This field can be separated into as many as 3 values, one each for dungeons, wilderness, and guarded regions. Separate with ":"
- cleanup = how long to wait before shutting down spawned mobiles, defaults to "300"
- debug ="false" (print out extra debugging information)
- debugEffect="false" (display an animation on screen with every spawn)
- RTFM="false" (you have read and configured your config file)
- name = (mandatory tag naming the facet)
- type = (mandatory tag specifying region type; can be "Guarded", "Dungeon", and "Wilderness")
- name =(mandatory tag naming the region; use "default" to pick up generic)
- p = probability of encounter, default of "1.0", which means 100%. If p is set to * (e.g., p="*"), the encounter will always be had in addition to any other encounter the player might have for the region
- distance = the preferred distance from the player for the encounter, a number or a range (example "1" or "0:2" or "1:3"). Default is "7".
- water = water mobiles can't spawn without this; land mobiles can't spawn with it, default is "false" (DEPRECATED... use landType="Water" instead please)
- landType= Water, OnRoad, OffRoad, or AnyLand. Default is "AnyLand".
- time=Night, Twilight, Day, or AnyTime. Default is "AnyTime".
- level=notional level of the character required to have the encounter; defaults to 1. An optional second argument can be sent to the level indicating class after a separating colon. E.g., "8:Necromancer". Valid current class names are Fighter, Ranger, Mage, Necromancer, Thief, and Overall.
- scaleUp=true/false, whether or not to scale up encounters that are waker than the player; defaults to false. Never more than triples an encounter.
- p = probability of the mobile being included in a picked encounter, default is "1.0"
- pick = (a comma-separated list of mobiles to pick from (NO SPACES!); one is picked randomly)
- n = a number or a range (example "1" or "0:2" or "1:3"), default is "1"
- effect=Smoke, Fire, Vortex, Swirl, Glow, None (default is None); a colon in the string with an optional integer value indicates hue (e.g., "Smoke:96").
Note how Mobiles and Items can appear embedded in one another. To know the rules, use some common sense. An Item can be in a Mobile (e.g., "orc has a Sword"), and an Item can be in an Item (e.g., "sword in a chest"), but a Mobile cannot be in an Item! A Mobile, however, might belong to another Mobile's team...
Now a little word on picking. Consider the following (modified) fragment:
Code:
<Mobile n="2" pick="OrcCaptain,OrcishLord">
<Mobile n="1:3" pick="Orc"/>
<Mobile p=".25" pick="OrcishMage"/>
</Mobile>Sub items spawn IN their parent items. Sub mobiles spawn NEAR their parent mobiles.
(note that if a valid spawn point can't be found, a mobile or item might not be spawned, and if this happens, the remaining part of a whole encounter might be skipped).
EQUAL PROBABILITIES
It's both possible and okay to list two encounters in the same region with the same probability. In this particular case, the system draws randomly from all matching probability levels, so you don't get the wierd case where one is always preferred over the other. This also makes it so that you don't have to do gymnastics to separate all the possibilities. One could just use ".3" ".2" and ".1" for everything, letting the system sort out the equal probability encounters...
SPECIAL THANKS
Thanks to Arte Gordon for his contribution of pieces of Xml Spawner to this code base.
Thanks to Nerun, who's spawners I imported to create the distro.
Thanks to Gandalf Parker for pointing me to RunUO and inspiring this code to be written in the first place, due to his disgruntled mumblings about the inadequacy of point-based spawners.
and I waited and waited... and they were not disappearing... 
