mulander / evolutionchamber

Automatically exported from code.google.com/p/evolutionchamber
0 stars 0 forks source link

Code up bursty minerals/gas #78

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Minerals and gas come in increments of 5, and should be changed using a small 
buffer to account for this.

Also, as part of this, change back extractor trick from 15 minerals to 19, as 
it is 'technically' inaccurate.

Original issue reported on code.google.com by Frit...@gmail.com on 26 Oct 2010 at 1:55

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by Frit...@gmail.com on 10 Nov 2010 at 7:03