Regarding active structure checks
-
I've noticed one of the biggest cpu uses in my code is
utils.checkStructureAgainstController. Even with the partition check it's easily .2 cpu per call to see if a structure is active (biggest offender for me is towers, with all tower operations costing .4 cpu on success due to intent and active checking).There also seems to be an issue with the partition being unstable, in some cases changing which structures are considered active on each tick. Although this might depend on the storage engine of choice.
Since this is something that doesn't really change all that often, I think we're wasting a lot of cpu. What I'm wondering is if we can refactor this to recalculate active structures all at once and only for the following events:
- Controller level change
- Controller claim/unclaim
- Structure added
- Structure removed
-
Whereas I don't check my own structure count against controller level (yet), I do check enemy active structures and plan my sieges off that. This obviously doesn't happen often, but in some rooms it's a bit funky, especially with the bug you mentioned.
-
the issue with this active check is how it's implemented : the engine searches for all structures , sorts them by range to the controller and returns true/false based on that .... but it's NOT cached.
This is especially bad for extensions as you can imagine, if you want to test which extensions are active and you have 40 of them, you'll do this check (sorting, checking if the current extension is in the allowed set) for EACH of them
-
Sure, feel free to make a PR.
