Is moveTo the enemy of cpu ?
-
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:
+4217E17S324912E17S3248136766676+3725E19S322749E18S3128482222222223333333333333+1631E55S580022E55S580122333333333333444445556+1416E18S320035E18S3101353333344444446666665+0521E55S572349E55S5723481188188888888881111888888821+1631E55S582500E56S58260144444544444444465655455555555566777767676766667767777788778776788888+4042E18S312749E18S3128482222222223344+1416E18S320600E18S3206015555455544454444+1843E56S570033E56S58013444444323343344333332332222323232333322111111111811212888888888188888+1713E17S310549E18S3106482222222888888877777+1631E55S584933E55S584832887777777768687788866678866688767+1843E56S572549E56S5724488888878+1713E17S314935E17S31483487776666677777787777667888888111181118877877888888112122333333345+3823E19S312749E18S3128482222222223333333333333+2830E56S570033E56S58013444444323343344333332332222323232333322111111111811212828888888811888+2830E56S572849E56S5727488881111111221111121+1416E18S320020E18S32011922222223324444+1737E17S334920E17S32482165666665566656666666667766666676+3836E17S334920E17S3248216566666556665666666666776
-
@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:
-
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.