Mordengaard's Guide to TPatrolPointSplitters

Location:  Actor->NavigationPoint->TPatrolPoint->TPatrolPointSplitter

A TPatrolPointSplitter (henceforth referred to as a "splitter") is identical to a standard patrol point actor for all intents and purposes, except that it has additional properties allowing bots arriving at it to use alternative routes.  The splitter has two modes (SplitterType property in the TPatrolPointSplitter section of the actor properties) - EPPST_Random, which sends the bot to a random patrol point as listed in the NextPointTags property, or EPPST_RoundRobin, which sends the bot to the next patrol point in the list. The NextPointTags list replaces the Event tag which standard patrol points use to indicate the Tag of the next patrol point.

And that's really all there is to it, but I thought it might be helpful to give you some examples to highlight some of the uses of this actor in the context of a Thievery map, because I've found more in using it than I envisioned when I came up with the idea and whipped Joel into coding it.

Example 1:  Walking around obstacles

Any mapper who has ever placed an obstacle in the middle of a room (a table, for instance), and had a bot walk through the room as part of an extended patrol, knows that unless the room is brightly lit they have probably created a "safe" zone for thieves, who (knowing the bots route) can happily sit on the other side of the table and never have to worry about being discovered.  Here's how to give them a shock!

Given the standard patrol route went A-B-C-D, all we need to do is replace B with a splitter and  put in patrol points E and F (E leading to F, which then leads to C).  Then we set B's NextPointTags to C and E.  Now any bot following this route has the "option" to walk around the table, either randomly or alternating on each circuit.

Example 2:  There and back again

Most patrol routes in current maps are circular in nature, even when they don't look like it.  The bot walks along the route, and then generally returns to the start of the route and does it again.  For mappers trying to do a A->Z then Z->A reversed route, this is a nightmare, especially if the bot has to walk a complicated path, as the bot needs twice the number of patrol points.  Not any more!

To achieve the pictured route normally would require four patrol points - A, B, C, and a second patrol point at position B.  By making B a round robin splitter pointing to C and then A, we reduce the number of patrol points required by one (I know, not a big saving here, but imagine this on a long complicated route).  The bot walks from A to B, the splitter sends him on to C, then C sends him back to B which this time sends him to A, and so the loop continues.

Example 3:  Checking the cells

Mappers hate having to put branches off their patrol routes (well, I know I do).  In this example, to produce the same effect -without- splitters would require eight patrol points but with splitters we only need six.  Not much of a saving, I hear you say, but wait, there's more.

You can probably already see how it's laid out - A, E, F and D are standard patrol points, while B and C are round-robin type splitters which point to E and C, and F and D respectively.  However, without adding a single extra patrol point or splitter, the bot on this route can walk -back- from point D to point A, checking each cell on his way back.  How?  Easy really, and it uses basically the same system as example 2.

Look at splitter B - if this was a one way route (i.e. A->D) B would be set with E and C as it's NextPointTags entries.  The first time the bot reaches this point it walks to E, then the next time it gets here (on the way back from E) it walks to C.  Next time around the circuit, it repeats this sequence.  However, doing an A->D->A loop would only require the addition of two more entries in the NextPointTags list - E again, and then A!  To achieve this loop without using splitters would require fourteen patrol points!

Example 4:  You take the high road...

Multiple bots on the same route have to be considered when designing your paths.  In the above examples I assumed only one bot was walking the route.  In this case, let's assume there are two, and let's convert the splitter (B) to a round robin type.

The first bot walks into the room, reaches point B, and walks straight on to C and then leaves.  The next bot walks in, hits B, and then goes to E and F before going to C and exitting the room.

This behaviour can cause problems, particularly in there-and-back routes like that in example 2, because the first bot would reach B and walk on normally, but the second bot would reach B and return to A - then the first bot would reach B on his way back from C and be bounced back to C.  Both bots would then continue to bounce backwards and forwards (assuming the distances were the same).  There is a way to use this behaviour to your advantage, however.

Let's say you set up a route walked by two bots - one bot handles the 'A' side of the route, while the other handles the 'C' side.  Careful setting of the properties of the splitter B would allow the bots to stay on their own sides of the patrol route, while there were two bots walking the route.  As soon as either bot is disrupted, however (knocked out, or off investigating) the B 'gate' would allow the other bot to pass through into the other side.  Once both bots are back walking the route, they'd return to walking each side (although they may swap sides) using the B point as a "bouncer".

There are probably more uses for splitters than I've dealt with here, especially when you tie them in with the other bot-control actors like orderchangers, but these are main ones I've come up with so far.  I'll add more as I encounter them.  In the meantime, enjoy making superior patrol routes! 

If you have any questions of a technical nature regarding TPatrolPointSplitter actors, please address them to Joel.  Comments on this guide or ideas for additional uses of splitters should be directed to myself.

--- Mordengaard