Is moveTo the enemy of cpu ?

  • Hi,

    So in parts of the docs and the helper popups, it is repeated that moveTo, or more over the path finding code underneath, uses a lot of CPU. I have gotten the point where my CPU is getting to 17/20, I have a few rooms. So i am looking for targets to reduce that CPU. An obvious one, is do more with less creeps, however once you hit that limit, should I be putting time into movement code. It seems like a lot of effort to me, to solve this problem, when I could be doing more interesting challenges.

    MY question is, have people found this to be one of their biggest challenges as they expand, have they implemented custom code to get around path finding over head? Or is there other hidden things to look out for with higher CPU?

    Would it logically follow that a distance further away, would take more CPU, to calculate the path finding for?


  • Pathfinding is expensive, in moveTo you can find a few opts reusePath, is the easiest one to help lessen the cost with some/most creeps. Default it is 5, so every 5 ticks if your creep has not reached its destination / changed rooms it will recalculate a path. Saves CPU, but creeps will react slower to things in their way.

    Beyond that, you can use pathfinder to find paths and save them for creeps to use with moveByPath. As for already created solutions I hear Traveler is something folks use.

  • ATM I am using moveTo for in-room movement. For inter room movement, I am storing paths created by PathFinder in memory (as a one move per character string). Store paths between relevant spawns, controllers, sources and minerals in memory, then use moveTo to move onto the path and the path after that. If the path gets blocked by a newly built structure, I can use PathFinder to regenerate the path.

    After I did this CPU went from around 2*creep numbers to 0.4 creep numbers.

  • Yes, moveTo is inconsistent in cpu costs; It blows up sometimes, so the less you use moveTo the less chance you have for it to blow up.

    You can test this by doing a moveTo every tick, forcing it to repathfinding and every once in a while it'll blow up cpu wise. I believe this has to do with the cached matrices and they being recalculated or cleaned up.

    The more rooms you are moving through, the more matrices that are created for that movement, so the more expensive it can be. Example is when your moving from your main room to a remote room 3 rooms away, it will create 3 matrices. When you move to the next room, it will either create the 2 matrices or get them from cache.

    Caching a path and using moveByPath is very good for remote sources, so your haulers are not pathfinding every time they go back and forth from source to storage, then it doesn't matter how many rooms it goes through but only the distance from storage.

    I have a lot of custom code around caching paths. I do not want to store it in Memory - due to parsing costs and the number of remotes. So I cache it in segments, and then when I use it store it in heap memory.

  • @likeafox I've wondered about using segments for caching like this. Do you keep those segments active all the time or do you manage fetching segments on demand somehow?

  • @donatzor Traveler is pretty great until you have time to write your own solution but you'll have to update it to support power creeps so it doesn't get stuck on them.

  • @systemparadox You can only access 10 segments at most, and I use around 20 segments to store paths in. So I cannot access all the segments, so I try to keep them stored in heap memory for easier access later on.

    Example of how it's stored in segments:


  • @likeafox I was mainly wondering what you do when one of your creeps needs to use a path that's not in the heap and not in an active segment. Have you got some sort of on-demand system so the creep flags the segment as required and then waits a tick for it to be loaded? Or do you actively reload all the paths from all the segments after a heap reset?

    How are you dividing the paths up across multiple segments? By source or destination room? Or something cleverer?

  • @systemparadox If they aren't on heap or segment then it just uses findPathTo and moveByPath and adds that into heap.

    Due to having 450~ haulers when the heap resets they each have different times when they need segment info. So they moveTo until they reach the end(source) or beginning(storage) then start looking for the paths in segments and heaps.

    Dividing the paths by the home room, each segment has around 2-3 home rooms depending on there remotes. It's a balance between wanting access to that segment and lowering the parsing costs. Lower number of segments means the higher chance that I can access that segment, while the higher number of rooms makes parsing expensive.

    What happens is that CPU costs for the first 100-200 ticks after a heap reset is expensive, but after that they all move by the same path over and over again.

  • @likeafox wow, you are clearly operating in a different ball game with 450 haulers ha. What are the heap and segments. Are they a screeps thing or a js thing?

    Some good info here. Thanks people 😀

  • Heap Memory is a screeps things example is:

    var codePush; function didCodePush(){ if (codePush === undefined){ codePush = Game.time; }else if(Game.time%100 > 0){ return; } console.log('Last CodePush:', codePush, "Time Passed:", (Game.time - codePush)); }

    Segments can be found: 0_1592664294219_f6d44729-332b-4472-9df4-01fc18afac2d-image.png

  • thanks. looks interesting and advanced. Also does RawMemory.foreignSegment, mean you could "hack" your enemies, if you can access their internal memory.

  • @maddokmike Can't hack enemies, but you can communicate with other code bases via segments.