audriusrudalevicius / evolutionchamber

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

Sub-optimal supply management #37

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The program usually deliver a situation where you are supply block on 
completion of the requirements, thus preventing you to be optimal after.

Original issue reported on code.google.com by Quen.An...@gmail.com on 22 Oct 2010 at 10:47

GoogleCodeExporter commented 8 years ago
Edit : One solution could be to implement a compulsory 3-15 food margin on 
completion of the build, depending on the total supply at the moment. Formula 
could be for instance MargSupply = TotalSupply/10

Original comment by Quen.An...@gmail.com on 22 Oct 2010 at 10:51

GoogleCodeExporter commented 8 years ago
One solution could be that you look at the amount of overlords it has made for 
your build, and manually set the number of overlords it should make to (needed 
amount)+1 ;)

Original comment by azzur...@gmail.com on 22 Oct 2010 at 11:00

GoogleCodeExporter commented 8 years ago
That's what I am doing at the moment, an easy workaround indeed, so this should 
be low priority :). Amazing work in any case.

Original comment by Quen.An...@gmail.com on 22 Oct 2010 at 11:08

GoogleCodeExporter commented 8 years ago
I think the supply management is optimal. There should never be something 
implemented that slows the fastest build down, just because you end 
supply-blocked.
It should always be left to the user if he wants to not be supply-blocked when 
the build finishes.

Original comment by azzur...@gmail.com on 22 Oct 2010 at 8:26

GoogleCodeExporter commented 8 years ago
How best should we accomplish this? The workaround of overlords+1 is fine, and 
seems to make the most sense as well, as you can't be sure how much supply is 
going to be used until the build is nearly complete, then it is a matter of 
stop, overlords+1, start, and see where it gets to.

Andre, since there are two distinct cases (a perfectly lined up rush, and a 
build that accounts for the future), is there a method to do this without 
cluttering up the UI?

Original comment by Frit...@gmail.com on 23 Oct 2010 at 5:15

GoogleCodeExporter commented 8 years ago
The two distinct cases seem like they're already being planned for by having 
standard and econ fitness. Econ fitness does/should score excess supply up to 8 
as more valuable, and there's no need to do that in standard fitness.

Original comment by AudioL...@gmail.com on 26 Oct 2010 at 11:51

GoogleCodeExporter commented 8 years ago
Why not just add excess supply as another requirement?

Very cool project by the way.

Original comment by Alexande...@gmail.com on 1 Nov 2010 at 10:32

GoogleCodeExporter commented 8 years ago
IMO this is fixed with dynamic overlord weighting.Can this be confirmed by 
someone else?

Original comment by AudioL...@gmail.com on 7 Nov 2010 at 4:13

GoogleCodeExporter commented 8 years ago

Original comment by AudioL...@gmail.com on 9 Nov 2010 at 12:37