As I posted a while back, I have a bunch of mobs that go out looking for players (well a few) originaly they used a shortest path algorithm (the one in the stock code) I do not like this it means the mob will head towards the player. So I decided to go for mobs following the tracks in a room this works well until the tracks are lost or the mob follows a false trail, then it just cycles on the last set of tracks as the most recent until they fade out. there is also the problem, due to my dislike of tracks that directly point to a player, it could point to the type of tracks (animal tracks, small boots, huge feet, wagon tracks, ...), so I have for now hit coders block, has anyone else tried to do something similar?

I'm not 100% clear on the details (read it a few times, still confused), howver, why not simply implement a tracking system for players, and then program mobs to use it? If you're using tracks per room, and want them differentiated, you could tag each track with two attributes... Race and size. Then you could base the accuracy of a track attempt on skill level, perhaps returning a different race or size if the attempt screwed up. Players could, of course, use this system easily. For mobs, all they'd have to know is the size and race of the target, and then utilize the track command accordingly.

You could add in other attributes, such as weight, but, I think simplicity is a better route. That said, I've never implemented a tracking system myself (I'm too eclectic to do something so actually useful), but I imagine this would work.

One solution would be to include the sequence of previous vnums a player has recently been in, in order; a list which slowly gets freed from the bottom forward (as the tracks become too old to follow).
At each step of the mob's tracking algorithm, the hunter goes through this list to find the most recent entry with the vnum that the tracker is in; in other words, if the hunter is in room 1000, it checks the list for the most recent entry of the player being in room 1000. The next item in the list, say 1001, is the room where these tracks lead, hence the direction the hunter should turn.
This has a couple advantages. If the player circles around and crosses her own path, when the hunter comes to this intersection of tracks, they will automatically pick the more recent one, like a real tracker would; but if the hunter somehow gets teleported into that circular part of the path, he does not instantly become lost.
The disadvantage lies in those labyrinthine areas where, for example, room 1000 has more than one exits both leading to 1001. in this case the rules of physics are tossed all about. the player may have gone north (to 1001), but the mob might go south (also to 1001). Whether this makes "physical sense" is a difficult conundrum because this room layout does not make "physical sense" to begin with!
In a case like this, with multiple exits to choose from, the code should be written so our hunter selects the "best" exit-- taking an open, unrestricted path above a closed door above a closed, bashproof, pickproof door, etc.
You might also want to ask yourself whether things like portals should be handled differently. If I were a wizard being hunted, I might hide my tracks by creating a portal whose other end was only 10 feet ahead of me, but by stepping through this tiny warp, it would effectively make a gap in my trail. all things for you to consider.
Of course this method would be very RAM expensive! Would not recommend having those tracks last for any long period of time...

Sorry, it isn't clear. when a track is left in a room, the track is in memory as a combination of race, size, direction, shoes (if they are wearing), and loading (heavy tracks, light tracks...), and % concealment (if they were covered)

this works fine, and mobs can use the same routine as players as far as looking at tracks. The problem arises when a mob loses a trail or (if I enable them) follows a false trail. when it gets to the end I would like (in an ideal world of unlimited processeing power, speed and memory) to have the mob be able to backtrack and not follow the same tracks again, but look for the next (or a different) set of "booted, and heavy human sized tracks", but, I am at a loss of how to implement this practicaly (I can think of a few methods, but it quickly gets out of hand processor of memory wise)

My main aim is to avoid having the id, or name, or a pointer to the character that made the tracks, if Bob is wearing the same boots as fred, and weighs about the same (for simplicity) and they are both carrying the same load, then their tracks should look identical, if I am trackin bob, and I know his boots have a notch cut into the heel then they should be a traceable track. (Ahh if only I had the time/money to do it)

Karlan,

I actually wrote a system fairly similar to what you've suggested for my own MUD. It is, unfortunately, fairly processor-intensive; I wasn't willing to give up the extra features, though.

Instead I simply created a "predator" flag that enables the tracking behavior on a mob, in concurrence of course with the presence of the requisite levels of tracking skill.

Since not all mobs are constantly searching for tracks in this manner it keeps the CPU usage to a reasonable level, but obviously the reasonableness is dependent on the number of mobs... so it isn't a solution to your quandary so much as it is a workaround for a mud that doesn't plan on having huge numbers of tracking mobs.

Anyway, sorry I couldn't add anything more helpful. Good luck.

Storing an array of 'already viewed Track IDs' with a mob shouldn't be processor or memory-intensive. Even 1000 viewed tracks will only take up 4K or so, and you can free that once the mob stops tracking.

Easy solution... Make the tracks doubly linked. That way, the character can simply backtrack along and, at every fork, take a random direction... Assuming they travelled far enough, over enough forks (if not, too bad), then they will search a different path.

Alternatively, you could doubly link then keep a pointer (in the mob) to the last room with a fork in the trail, as well as which direction they came from, so they won't follow that direction again.

Rather then store this on a player, or 3rd party list, why not store it in the room itself?

Each room stores a list of "last tracks" this can be manipulated rather easily depending on the scent power. The information would be as follows:

Player A enters (scent recorded)
Player A leaves (scent recorded in direction)

So the array would be something like this:

{{scent_type, exit_direction, timestamp}, {scent_type....}}

This way you don't have to worry about managing large lists of movements.... and you could cycle these out depending on the duration of the scent.

Also, if a player wants to fool someone by doing something like this:

go e,w,e,w,e,w,e,w,e,w,n

you could have your scent display the two possible directions (in this case east and north):

The faint smell of delicious ham is to the north, and east.

If the player goes east:

The faint smell of delicious ham is to the west (ovbiously you've been duped).

On the game for which I once programmed, I wrote a system that was fairly robust for tracking. I added an array to each exit which kept account of the player/NPC ID, direction of travel, pace of travel and a series of other data, including sex, encumbrance, height, and a decay factor, which was computed based upon the terrain, weather, and amount of travel through the area - the more travel which occured, the higher the chance of decay.

Thus, not only could NPC's track players (or other NPCs), but players could track others. Depending upon their ability in tracking, they would be given more information. If they knew the person they were tracking really well, they may even recognize those tracks as belonging to that person:

A woman walked to the east recently.
A man ran in from the west not too long ago.
KaVir dashed in from the west quite awhile ago. His tracks appear as though an attempt was made to erase them.
Some poor soul dragged themselves through this area quite some time ago. Dried blood provides mute testimony of their passage.

I did not really write it clearly at the start. I already have a hunter, tracker flags for mobs so they do not all do it, in fact if not aggro a hunter will not hunt, unless it has someone in memory (it remembers thos who have attacked it and as long as it is alive it will hunt them all down), or has been made to (via script or spec proc)

each room contains (potentially) 10 tracks in a queue, and each track contains details such as race, how laden, if barefoot, size, %hidden if they have been attempted to hide tracks, direction and age. different types of weather age tracks differently, and the mob will follow the most recent match for what it is looking for (ie laden booted human), but I was looking for a way to avoid having each hunter maintain a list of rooms it has been in, or junctions, but I think for now I might just leave it, if you can throw it off the scent it loses you, and for now does not back track till it finds a alternative.