Topics created by 4nytime

So I ran the profiler and I find the result quite interesting. Most of the CPU usage is indeed pathfinding and creep.moveTo(). Seems I will start working on caching paths in memory now. Thanks for the help!

Another tip on performance: Trying to move to the center of the room new RoomPosition(25,25,roomName) can lead to a very high cpu usage if there are walls at and around that position, because you can never reach that position so that the search is quite exhaustive to find a route. Better moveTo the target position directly. Also don't forget to add the range option to each goal that is in the wall (like controller, source) because of the same reason. For a source range:1 is enough.

It seems I found a solution. Now I am just directly accessing memory at a specific index. It's possible to simply write memory.roomData[index] = some_data; and it will create a new object index at that position.

I have monkey-patched Creep.move() and Creep.moveTo() methods, first one to save the creep's intended move direction, and second one to inject different defaults (reusePath: 50 and ignoreCreeps: true), as well as use custom CostMatrix callback so I can mark some specific creeps as unwalkable at some specific situations. Then after all the creep logic has run its course I run another loop of collision resolver, that checks if there's a creep in the creep's intended move direction, whether it is moving or not, and tries to move the blocker creep out of the way, with some role-specific overrides provided, too. Took me a few hours to code, a couple of days to iron all the edge cases, but now it works pretty well for 99.8% of cases. The remaining 0.02% result in some weird creep dancing, but tend to resolve themselves in a few ticks on their own.

@orlet Yes, I am aware that there is a .spawnCreep() function. It is not yet updated in the tutorial, which is still using .createCreep()