Open GoogleCodeExporter opened 9 years ago
If I understood correctly from the source code currently minerals and gas are
added continuously instead of increments of 5. To fix it you should store time
for each drone when it brought minerals or gas last time and increment
minerals/gas by 5 each time.
BTW due to intensive computations currently EcBuildOrder.mineMinerals() method
accounts for 20% of the application build time (in revision 69). Switching to
integers and counting of time passed since drone brought minerals/gas last time
may have positive impact on performance as well. You may also consider storing
drones in queues, so you will have to check elapsed time only for one drone in
each queue instead of iterating through all available drones.
Original comment by sergey...@gmail.com
on 29 Oct 2010 at 3:10
In addition to counting them in increments of 5 instead of continuously the
rate at which minerals are consumed should not be an average of the collection
rate at full saturation but a function of the number of workers on each patch.
So for each base 1-8 workers would be ~.14166 trips per second per worker, 9-16
would be the same ~.14166 trips per second per worker, and 17-24 would be
~.1111 trips per second per worker.
Also, gas increments by 4 I think, not 5.
Original comment by tetracyc...@gmail.com
on 30 Oct 2010 at 2:13
I changed extractor trick in r72.
I also did some research into resources and found that EC was too optimistic.
Simply changing the values to the correct income rates greatly reduces the
errors in build preference. This is also in r72
Original comment by AudioL...@gmail.com
on 30 Oct 2010 at 4:27
In the meantime, your numbers are off for 'far mineral' harvest rates. One
drone mines 35 per minute, two do 75?
Original comment by Dmir...@gmail.com
on 2 Nov 2010 at 11:38
Original comment by Frit...@gmail.com
on 10 Nov 2010 at 7:03
Original issue reported on code.google.com by
Frit...@gmail.com
on 26 Oct 2010 at 1:55