Improving Traveler: Features
These are some features that are new with the version of traveler released on 2017-06-05.
I've added a few visuals to make traveler more interesting and useful. These visuals do not add any overhead to the cpu. Instead of having an option to show visuals or not, I've made it very clear in the code which statements are producing them, and you can comment them out if it is undesirable.
On ticks where a new path is discovered, you can now see where your creep is headed. If the path was complete it will show up as orange, if incomplete it will show up as red.
If your creep can't move due to fatigue, it will now be surrounded by a blue halo. Think of this as a sticky puddle of creep persperation.
If your creep discovered it didn't move last tick, it will start showing a purple halo of confusion and doubt. This gets brighter as your stuck value increases until the creep finally decides to repath or it becomes so bright that your monitor catches on fire, whichever comes first.
This is a new option that allows you to avoid making a new pathfinding call when your destination is only 1 position away from what it was previously. The new direction is just added to the path. This should be used with caution or with a higher range value as it could end up giving you a winding path, depending on how your destination is moving.
In this mode, swamps are given a cost of 1. So all passable tiles will have a cost of 1 regardless if they are a road, plain, or swamp. This is useful for creeps that carry energy who currently don't have a load. If they aren't carrying anything, they won't incur fatigue even when moving over swamps. This lets you keep your roads clear for traffic that can benefit from the road.
This replaces options.ignoreStuck and represents the stuckCount at which your creep considers itself stuck. As before, stuckCount is incremented on ticks where your creep is trying to move but isn't going anywhere (and reset to 0 on ticks where it has successfully moved along the path). However, creeps don't repath automatically after reaching the stuckValue. Rather, there is a 50% chance they will repath after this happens. In my experience this results in better unstuck-behavior. There is a chance one creep will move first and that breaks up the congestion, and also stops them from all trying to move along the same detour at once. The default value is 2.
If you want to completely ignore stuck repathing (like ignoreStuck did) just pass in Number.MAX_VALUE.
Giving a creep a higher-than-default stuck value essentially gives it the "right of way", other creeps will repath before it does most of the time.
This lets you set a probability that your creeps will repath even with the same destination. It can be helpful in situations where your creeps need to reevaluate their path more often (perhaps a raiding situation where the costmatrix is changing). Setting it to 1 will make them repath every tick, .5 will give them a 50% chance of repathing, and .1 a 10% chance.
If you supply traveler with an empty object, it will return all sorts of useful information. Here is the interface that shows the data that is returned:
interface TravelToReturnData {
nextPos?: RoomPosition;
pathfinderReturn?: PathfinderReturn;
state?: TravelState;
path?: string;
}
Here is an example of how you might use it:
let data = {} as TravelToReturnData;
creep.travelTo(destination, {returnData: data});
if (data.path) { creep.say(`${data.path.length} more!`); }
Since findRoute has some overhead, it isn't used in cases where the room-distance is 2 or less. The vast majority of PathFinder calls do not fail in these circumstances, and findRoute might even force it to take a less than ideal path. However, there are some locations in the screeps world that are unusually tricky to path to, and this heuristic breaks down. In cases where the initial path attempt fails without findRoute, it will now repath using findRoute using this option.
Another alternative is to just use options.useFindRoute = true. Hopefully future versions of Traveler will have a more elegant solution to this problem and a similar class of problems, most likely by using a different algorithm for including/excluding rooms.