This refactors the target-finding code in a way that makes it more modular, with some state wrapped into a processor class. It also splits the "computation" and "update" phases apart from each other.
This could be used to parallelise the computation phase in the future, although directly doing that seems to be less efficient on the 0.3 competition chain; but it could be possible to do in the future. Also, with this it would be easier to instead optimise by loading all combat entities into memory first, then doing in-memory parallel target finding (without having to synchronise database accesses), and then doing the updates from one thread again.
This refactors the target-finding code in a way that makes it more modular, with some state wrapped into a processor class. It also splits the "computation" and "update" phases apart from each other.
This could be used to parallelise the computation phase in the future, although directly doing that seems to be less efficient on the 0.3 competition chain; but it could be possible to do in the future. Also, with this it would be easier to instead optimise by loading all combat entities into memory first, then doing in-memory parallel target finding (without having to synchronise database accesses), and then doing the updates from one thread again.