Haven't had much time to play but so far it's great. Good job, this is exactly what I've been dreaming of, can't wait to have more time to play with it!

@u-238 I'm not seeing a findInArea in the API but if you're referring to lookForAtArea or findInRange I don't think that will help in this case. The room positions for all of a bunker's paths are already cached in an array which is used to check for missing / damaged roads every 1000 ticks which is pretty light on CPU. Originally I was just sorting by range but was surprised with how little CPU PathFinder uses to determine closest position by travel distance despite hundreds of goals which works a lot better when walls or swamps complicate things. Even without getting the index returned and having to do the additional search, this approach is only using around 0.06 CPU per bunker on average. Getting the index would lower this even more and reduce complexity...

@deft-code In my case I'm using pathfinder to find the closest damaged/missing road position by travel distance using range of 3 so there's a lot of wasted CPU since there's often hundreds of goals to filter by range using the path's final position. I've figured out some tricks to mitigate the CPU usage but getting the index from the results would just be so nice.

When passing an array of goals to PathFinder.search, it would be very useful if the returned object included the index of the selected goal. This would save CPU when you need to determine the object associated with the returned path. Currently you have to search using the last room position in the path which gets messy when using a range and multiple object types.

@artch Will we be able to customize the "test matches" to create specific conditions / environments that we are testing for? Would be cool if you could then save them to use as a sort of unit test.

@artch Have you decided how you will handle CPU? As one option, I like the idea of setting it up similar to a chess clock. Each side gets x CPU for the entire match and if you run out you lose. Also ensures these types of matches have a well defined life span and adds weight to CPU management as a strategy. Could run this as an alternative option to the existing x CPU / tick + bucket system.

@artch Looking good! Any plans to use the latest version of Lodash in arena API?

@artch For the "10000 CPU" cost option, I assume your normal CPU tick limit (max 300) would still be available to use since that 10k is strictly coming from the bucket? If so, this is definitely the best route as it increases the difficulty in farming pixels without causing undesired limitations in other areas. You would still have enough CPU for high priority intents like tanking tower damage during a siege. This lets you farm pixels 100% of the time if you solve the problem where the other route forces you to suspend pixel generation in situations where skipping intents for one tick is not an option.

I wonder if arena will include our current GPL and power creeps

@eduter said in Disable default notifications:

foo

That worked, thanks!