Transporter V2

[JonathanSafer]

Transporter fills extension in organized manner, fewer and bigger transporters

[jordansafer]

transporter should do a greedy bfs of empty extensions, and go to the first one it sees. it might be cheaper than hardcoding since you don't have to read order from memory each tick, especially if you are only searching a couple squares away for the next extension on average.

[jordansafer]

findClosestByPath might be good enough

[JonathanSafer]

The problem with findClosestByPath is that transporters may get stuck on the same route. Alternatively, there could be a list of ids for each city (maybe even stored in global). T iterates through the list until it finds an empty extension, then goes to fill it. T also saves element #, and continues from there on following scan. Upon completion of list, go dormant and reset element # in memory. This would allow a potential second transporter to be active at the same time and do the list backwards

[JonathanSafer]

If T !isNearTo next target after successful deposit, start moving to next target already (can move and deposit on same tick) Also, move after withdrawing under same condition.

[jordansafer]

It would be nice to keep the transporters working on different parts of the list so they aren’t bumping into each other if we do this. Possibly we only need one transporter anyway? findclosestbypath could also be good enough if we only need one transporter

[JonathanSafer]

Fcbp takes a minimum of 0.2 cpu per call, even with cached results, this will not work

[JonathanSafer]

All bases except E9N1 using fcpb. E9N1 using list from memory

[jordansafer]

profiled fccp at 1.3ish cpu vs 1.8ish for cached path with better version of FCCP so going with that. We can look at optimizing Fccp more (max ops 30 rn, but could try lower like 15 and see if that hurts/helps)