Courageous' Random Encounter Engine

[Chinook]

Another user requested cleanup support for mobiles spawned by OrcBrutes. This turned out to not be feasible to do except at system start up time, because the sheer number of mobiles on a shard could cause a significant lag hiccup at the cleanup point. Also, it turned out to be impossible to know which creatures were children of creatures created by random encounters.

Just letting you know that I have added mods to other methods to handle this, as I dug into the problem I found that this issue will also plague shards that don't use this system. Example the OrcBrute even on a spawner, when spawning the child spawns they are left off the spawners control creating the same problem of stray spawn not controled by any system. So what I did was make 2 new bools to handle clean up via the basecreatures onthink method. When not in combat and is not apart of a spawner or Courageous' Random Encounter Engine, the mobile will delete itself. If you want to have the code edits I did for this to mess with for your system or to find a better way to do this, then please PM me.

Also if anyone is interested in this code mod for there shard to control child spawns please PM me I'll send ya the edits needed to achive this.

 

[Courageous]

When I looked at the code, I decided that the "correct" hypothetical way of handling children spawnage would be to have parent and child track eachother. I.e., a parent creator could keep a list of children created and at the same time, children could keep track of the parent. To do that, you'd create some kind of SpawnChildMobile method that did all the book keeping, as well as putting attributes on a base class for tracking purposes.

I decided I didn't want to get into that, though, as the change was too much of a design decision change to what's already out there...

C//

 

[Courageous]

BUG ALERT. TOO MANY ENCOUNTERS GENERATED.

At 957 in RandomEncounters.cs there is a block of code that looks like this:

                foreach( EncounterSet encounterSet in possibleEncounters )
                {
                    double draw = Utility.RandomDouble();

                    if ( draw <= encounterSet.Probability ) 
                    {
                        int choice = 0;
                        
                        if (encounterSet.Count!=0) { choice = Utility.RandomMinMax( 0, encounterSet.Count-1 ); }

                        RandomEncounter encounter = (RandomEncounter) encounterSet[choice];

                        //Console.Write( encounter.ToString() );

                        GenerateEncounter( chosenMobile, encounter, cleanupList );

[COLOR=Red][B]                        break;[/B][/COLOR]
                    }

The code in red needs to be added, or too many encounters will be generated. What's happening now is that it's generating one encounter for every encounter in a region that matches the probability criterion. What is wanted is for it to match the first criterion.

C//

 

[Greystar]

BUG ALERT. TOO MANY ENCOUNTERS GENERATED.

At 957 in RandomEncounters.cs there is a block of code that looks like this:

                foreach( EncounterSet encounterSet in possibleEncounters )
                {
                    double draw = Utility.RandomDouble();

                    if ( draw <= encounterSet.Probability ) 
                    {
                        int choice = 0;
                        
                        if (encounterSet.Count!=0) { choice = Utility.RandomMinMax( 0, encounterSet.Count-1 ); }

                        RandomEncounter encounter = (RandomEncounter) encounterSet[choice];

                        //Console.Write( encounter.ToString() );

                        GenerateEncounter( chosenMobile, encounter, cleanupList );

[COLOR=Red][B]                        break;[/B][/COLOR]
                    }

The code in red needs to be added, or too many encounters will be generated. What's happening now is that it's generating one encounter for every encounter in a region that matches the probability criterion. What is wanted is for it to match the first criterion.

C//

Whoops!

EXTRA

 

[Courageous]

Updated to 0.9.7B

Fixed the too many encounters bug.

Added support for level minimum and scaleUp on encounters.

How it works: each character is said to have a "level" based on a selection of the characters stats, highest dozen or so skills, and so forth. Levels will range from 1 to approximately 10 for a character with 120 point skills.

Each encounter can be tagged with a level= tag to indicate what the minimum level a player has to be to have the encounter. This works in natural conjunction with the previous probability-based picking system, simply hunting up the tree for encounters the player may qualify for until one is found that matches both the probability draw as well as level requirements of the encounter.

Encounters can be marked scaleUp=true (they default to false). If an encoutner is set to scale up, what happens is this: if the player is significantly higher level than the mobiles in the encounter, the number of mobiles may be increased by as much as a factor of 2 ( 2X increase = 3X encounter size ).

System appears to be working.

My current thoughts are on diffierentiating the level by a sort of virtual class. I.e., "this character is 8th level outdoorsman". This ability to differentiate what the player is good at will allow shard admins to do things like make it so that a high level outdoorsman is more likely to get deer spawns (and more likely to get more deer) than a player without outdoors skills.

 

[Greystar]

Updated to 0.9.7B

Fixed the too many encounters bug.

Added support for level minimum and scaleUp on encounters.

How it works: each character is said to have a "level" based on a selection of the characters stats, highest dozen or so skills, and so forth. Levels will range from 1 to approximately 10 for a character with 120 point skills.

Each encounter can be tagged with a level= tag to indicate what the minimum level a player has to be to have the encounter. This works in natural conjunction with the previous probability-based picking system, simply hunting up the tree for encounters the player may qualify for until one is found that matches both the probability draw as well as level requirements of the encounter.

Encounters can be marked scaleUp=true (they default to false). If an encoutner is set to scale up, what happens is this: if the player is significantly higher level than the mobiles in the encounter, the number of mobiles may be increased by as much as a factor of 2 ( 2X increase = 3X encounter size ).

System appears to be working.

My current thoughts are on diffierentiating the level by a sort of virtual class. I.e., "this character is 8th level outdoorsman". This ability to differentiate what the player is good at will allow shard admins to do things like make it so that a high level outdoorsman is more likely to get deer spawns (and more likely to get more deer) than a player without outdoors skills.

Nice mod, could also make it so mage type characters get more mage type attacking mobiles like more orc mages instead of normal orcs, or more wisps are attracked to magic, etc. Just ideas...

 

[Morxeton]

Nice mod, could also make it so mage type characters get more mage type attacking mobiles like more orc mages instead of normal orcs, or more wisps are attracked to magic, etc. Just ideas...

Not a bad idea. Maybe a feature to have mage type characters get more magical resistant mobs, and warrior type characters get more physical resistant and/or higher AR mobs to add to the difficulty.

 

[Chinook]

When I looked at the code, I decided that the "correct" hypothetical way of handling children spawnage would be to have parent and child track eachother. I.e., a parent creator could keep a list of children created and at the same time, children could keep track of the parent. To do that, you'd create some kind of SpawnChildMobile method that did all the book keeping, as well as putting attributes on a base class for tracking purposes.

I decided I didn't want to get into that, though, as the change was too much of a design decision change to what's already out there...

C//

Ya np, like I said I found a really simple way to clean up the child spawn from any mobile that spawns child spawn. I also adapted it so any stray spawn will auto delete itself, "stray spawn" meaning spawn thats not connected to a system or spawner.

 

[Jarrod]

Something you shard owners might want to consider when using this script:

create secondary versions of your mobiles that you want to spawn with this.

i.e. Orc -> EncounterOrc
and in the EncounterOrc.cs REMOVE the
public override bool CanRummageCorpses{ get{ return true; } }

Otherwise, mobiles spawn, gank your player, and then while they are running back from the healers, the mobiles disappear with some of the players items

 

[Courageous]

It would, theoretically, be possible to force mobiles to drop anything in their packs just before being "cleaned up"... this would have certain consequences, of course. 50/50.

C//

 

[Vertigo]

Hola
Courageous in download list only v0.9.6B
can u upload new version plz

 

[Courageous]

Uploaded, updated to 0.9.8B.

New release includes support for "class" detection of players, to be used in conjunction with the level filter.

C//

 

[RavonTUS]

Greetings,

C// you have been busy. I like it! I will be updating this weekend.

In the meantime, I have a question about "EQUAL PROBABILITIES". If I understand you correctly, I can set up several encounters with "P=.9" and RE will it will pick just one of them. If I have several "P=.8" in the same encounter it will pick one from that group too. Thus, picking one ".9" and one ".8" for a total of two possible encounters.

What about "P=1", that would be 100% chance, however, if there are several of them, will it still pick just one, or will it place all of them?

In my thinking, it should pick all encounters with a "P=1". I use this for decorum (adding bones, webs, tree, lights, etc.).

-Ravon

 

[Courageous]

For any encounters that have an equal probability rating (e.g., .9 and .9 or 1.0 and 1.0), it randomly picks just one of them.

To better understand why this is, and how the system works, know this:

1. Random encounters draws a random number.

2. It then begins scanning up the probability list, least likely first.

3. When it encounters a possible match, it tests it. In the current system, it asks: is the p draw sufficient for this encounter? and is the character high enough "level" for this encounter?

4. When it matches, the encounter is selected. Thing is, some encounters have the same probability level. If I did it this way, without further refinement, the system wouldn't work right--some encounters would never be selected. So all encounters of a matching probability are thrown into an array, and that's scanned randomly.

5. If the p draw runs out to the top of the list, the player doesn't have an encounter.

6. If at any time the spawn finder says there are no possible spawn points, the player doesn't have an encounter.

There was a bug in the old system--I have no idea how long it was there, I don't think it was always there--where the system might continue picking up the the tree, choosing multiple encounters for the player for encounters that could satisfy the p draw. This was never supposed to happen.

There might be a way to arrange a special tag for the behavior you describe. It would require some internal engineering to make it work correctly. I'll think on it.

C//

 

[RavonTUS]

Greetings,

Ah, I understand now. Thank you for the details.

I now understand why something did not always appear when I thought they should. Maybe I was sleeping during that part of the readme.txt...lol.

Your doing a great job, thanks.

-Ravon

 

[Courageous]

Updated 0.9.9B.

This is a very minor update. If an encounter has its p value set to * (e.g., p="*") it is always selected as an encounter, inclusive of any other encounter the player may qualify for.

C//

 

[RavonTUS]

Greetings,

I saw a message and now it's gone. I must be loosing my mind..

C// You asked why I would want this feature and the answer is, yes, my mind is twisted.

Have you ever played Diablo? The orginal, because it was better the DII. I liked the way the dugeon would change with each game. I am using your RE system to do the same sorta thing. Webs, lights, treasures, traps, and monsters that change with each adventure.

I also use it for a "Dark Forest", a largly unpopulated region, that grows "trees" and magical monsters.

So the effect I am looking for looks like this...

<Region type="Dungeon" name="Doom Exit">
	<!-- Decorum -->
	<Encounter p="1" distance="7:14">
	<Item n="3:5"  pick="BrazierTall,Brazier"/>
	</Encounter>
	<Encounter p="1" distance="7:14">
	<Item n="5:10" pick="Torso,Head,LeftArm,RightArm,LeftLeg,RightLeg"/>
	</Encounter>
	<Encounter p="1" distance="7:14">
	<Item n="1:5"  pick="PelvisBone,RibCage,Spine,Blood"/>
	</Encounter>
</Region>

So I want to see a light, assorted body parts, and blood & bone. If I put them all in one Encouter I may not get the correct combination.

In any case, I see you have already made the change. I will give it a run tonight. It sounds like it will work great!

-Ravon

 

[Courageous]

Yes, I was bored, so instead of waiting for your answer, I made a guess at what you were using it for, and coded the simplest solution that I thought would work. I wanted to avoid having to scan the entire probability set for inclusive items, so I only support one inclusive item, the all inclusive item '*'. This is coded by setting its probability to -1. This allow me to scan the inclusive set, without having to scan the entire exclusive set--ie., a performance optimization. Kindof hacky, actually, but that's where I am at for now. Tell me how you like it.

C//

 

[RavonTUS]

Greetings,

Thank you, again. I did not get to play with it much this weekend (a friend brought over his computer and said can you fix it. I hate that = wasted weekend).

Anyway, my decorum looks good and the random stuff is popping up correctly. I need to tweak some personal stuff in my XML, good thing it's slow at work this week.

-Ravon

 

[RavonTUS]

Greetings,

C// May I make one more suggest? [restartRE

Sometimes I can't type or my brain just stops. While the shard is live, I will make changes to the XML file and your system will attempt to read it. If I screw up, RE yells at me and gives me the "FAILED to load" message.

Unfortunately, the only way to get RE running again is to shutdown and restart the server. It would be nice if there were a command to restart RE from within the game.

-Ravon