|
5.2 seems to converge on builds much, much faster. And it seems to be actually using chronoboost now (maybe due to converging on builds faster?).
In any case, here's a 2-base 5-gate push
8:30
2 nexus
5 gate
10 zealot
10 stalker
7 sentry
+ Show Spoiler + 0:02.00: 50M 0G 0E 6/ 10S - Build Probe
0:19.00: 73M 0G 10E 7/ 10S - Build Probe
0:36.00: 106M 0G 19E 8/ 10S - Build Probe
0:44.10: 100M 0G 24E 9/ 10S - Build Pylon
0:54.19: 50M 0G 29E 9/ 10S - Build Probe
1:11.19: 107M 0G 39E 10/ 18S - Build Probe
1:11.19: 57M 0G 39E 11/ 18S - Chrono Nexus
1:22.52: 136M 0G 20E 11/ 18S - Build Probe
1:31.19: 153M 0G 25E 12/ 18S - Chrono Nexus
1:33.85: 174M 0G 2E 12/ 18S - Build Probe
1:37.08: 150M 0G 3E 13/ 18S - Build Gateway
1:45.19: 64M 0G 8E 13/ 18S - Build Probe
1:52.11: 75M 0G 12E 14/ 18S - Build Assimilator
1:59.19: 63M 0G 16E 14/ 18S - Build Probe
2:08.12: 100M 0G 21E 15/ 18S - Build Pylon
2:15.33: 67M 0G 25E 15/ 18S - Chrono Nexus
2:15.90: 72M 0G 0E 15/ 18S - Build Probe
2:27.24: 139M 0G 7E 16/ 18S - Build Probe
2:40.19: 233M 0G 14E 17/ 26S - Build Probe
2:42.08: 204M 0G 15E 18/ 26S - Build Cybernetics Core
2:42.08: 54M 0G 15E 18/ 26S - Move Probe To Gas
2:57.19: 216M 11G 24E 18/ 26S - Build Probe
2:59.78: 196M 12G 25E 19/ 26S - Chrono Nexus
2:59.78: 196M 12G 0E 19/ 26S - Build Assimilator
3:09.38: 231M 19G 5E 19/ 26S - Build Probe
3:09.38: 181M 19G 5E 20/ 26S - Build Zealot
3:09.38: 81M 19G 5E 22/ 26S - Move Probe To Gas
3:21.19: 219M 36G 12E 22/ 26S - Build Probe
3:38.19: 378M 59G 22E 23/ 26S - Build Probe
3:38.19: 328M 59G 22E 24/ 26S - Research Warp Gate Transformation
3:38.19: 278M 9G 22E 24/ 26S - Move Probe To Gas
Waypoint 1 satisfied:
3:47.38: 390M 27G 27E 24/ 26S
Income: 740M 114G
Buildings: 1 Nexus 2 Assimilator 2 Pylon 1 Gateway 1 Cybernetics Core
Units: 21 Probe 1 Zealot
Upgrades:
3:48.19: 400M 28G 27E 24/ 26S - Build Nexus
3:55.19: 82M 42G 31E 24/ 26S - Build Probe
4:00.77: 100M 52G 34E 25/ 26S - Build Pylon
4:12.19: 135M 74G 41E 25/ 26S - Build Probe
4:12.19: 85M 74G 41E 26/ 26S - Chrono Cybernetics Core
4:12.19: 85M 74G 16E 26/ 26S - Move Probe To Gas
4:12.19: 85M 74G 16E 26/ 26S - Move Probe To Gas
4:17.79: 150M 91G 19E 26/ 26S - Build Gateway
4:28.67: 128M 124G 25E 26/ 34S - Chrono Nexus
4:29.01: 133M 125G 0E 26/ 34S - Build Probe
4:29.01: 83M 125G 0E 27/ 34S - Move Probe To Gas
4:34.58: 150M 145G 3E 27/ 34S - Build Gateway
4:40.35: 68M 165G 7E 27/ 34S - Build Probe
4:45.05: 75M 182G 9E 28/ 34S - Build Assimilator
4:49.10: 50M 197G 11E 28/ 34S - Build Sentry
4:53.19: 53M 111G 14E 30/ 34S - Build Probe
5:10.19: 231M 172G 23E 31/ 34S - Build Probe
5:13.11: 220M 183G 25E 32/ 34S - Chrono Cybernetics Core
5:13.11: 220M 183G 0E 32/ 34S - Build Gateway
5:19.04: 150M 204G 3E 32/ 34S - Build Gateway
5:27.19: 107M 233G 8E 32/ 34S - Build Probe
5:28.19: 71M 237G 8E 33/ 44S - Build Probe
5:28.19: 21M 237G 8E 34/ 44S - Move Probe To Gas
5:38.19: 169M 280G 14E 34/ 44S - Convert Gateway To Warp Gate
5:39.58: 190M 286G 15E 34/ 44S - Convert Gateway To Warp Gate
5:44.19: 259M 306G 17E 34/ 44S - Build Probe
5:45.19: 224M 311G 18E 35/ 44S - Build Probe
5:49.58: 244M 330G 21E 36/ 44S - Convert Gateway To Warp Gate
5:49.58: 244M 330G 21E 36/ 44S - Build Sentry
5:49.58: 194M 230G 21E 38/ 44S - Build Sentry
5:57.56: 275M 165G 25E 40/ 44S - Chrono Nexus
5:57.56: 275M 165G 0E 40/ 44S - Build Pylon
Waypoint 2 satisfied:
5:59.58: 207M 173G 1E 40/ 44S
Income: 942M 261G
Buildings: 2 Nexus 3 Assimilator 3 Pylon 3 Warp Gate 1 Cybernetics Core
Units: 30 Probe 1 Zealot 3 Sentry
Upgrades: Warp Gate Transformation
6:00.64: 223M 178G 2E 40/ 44S - Build Probe
6:01.19: 182M 180G 2E 41/ 44S - Build Probe
6:11.98: 318M 227G 8E 42/ 44S - Build Probe
6:12.63: 279M 230G 8E 43/ 44S - Chrono Nexus
6:18.11: 380M 254G 12E 43/ 44S - Convert Gateway To Warp Gate
6:18.11: 380M 254G 12E 43/ 44S - Build Probe
6:23.31: 429M 277G 14E 44/ 52S - Build Probe
6:23.31: 379M 277G 14E 45/ 52S - Build Pylon
6:23.31: 279M 277G 14E 45/ 52S - Build Stalker
6:23.31: 154M 227G 14E 47/ 52S - Build Pylon
6:23.31: 54M 227G 14E 47/ 52S - Build Sentry
6:28.11: 92M 148G 17E 49/ 52S - Convert Gateway To Warp Gate
6:29.91: 125M 155G 18E 49/ 52S - Build Stalker
6:35.11: 99M 128G 21E 51/ 52S - Build Probe
6:42.00: 191M 158G 25E 52/ 52S - Chrono Nexus
6:48.31: 324M 185G 4E 52/ 60S - Build Zealot
6:48.31: 224M 185G 4E 54/ 60S - Build Stalker
6:55.31: 250M 166G 7E 56/ 68S - Build Zealot
6:55.31: 150M 166G 7E 58/ 68S - Build Pylon
6:57.69: 100M 176G 9E 58/ 68S - Build Zealot
7:02.43: 100M 197G 11E 60/ 68S - Build Zealot
7:02.43: 0M 197G 11E 62/ 68S - Move Probe To Gas
7:16.31: 291M 265G 19E 62/ 68S - Build Stalker
7:20.31: 251M 235G 22E 64/ 76S - Build Stalker
7:20.31: 126M 185G 22E 66/ 76S - Move Probe To Gas
7:23.31: 187M 201G 23E 66/ 76S - Build Zealot
7:23.95: 100M 205G 24E 68/ 76S - Build Pylon
7:29.01: 100M 232G 26E 68/ 76S - Build Zealot
7:34.05: 100M 260G 29E 70/ 76S - Build Zealot
7:48.31: 292M 338G 37E 72/ 76S - Build Stalker
7:51.31: 228M 305G 39E 74/ 84S - Build Zealot
7:52.31: 148M 310G 40E 76/ 84S - Build Sentry
7:52.39: 100M 211G 40E 78/ 84S - Build Pylon
7:57.44: 100M 238G 42E 78/ 84S - Build Zealot
8:03.71: 125M 273G 46E 80/ 84S - Build Stalker
8:03.71: 0M 223G 46E 82/ 84S - Chrono Warp Gate
8:19.31: 319M 308G 55E 82/ 92S - Build Stalker
8:20.31: 215M 264G 55E 84/ 92S - Build Stalker
8:24.31: 171M 236G 58E 86/ 92S - Build Sentry
8:25.44: 144M 142G 58E 88/ 92S - Build Stalker
8:26.94: 50M 100G 59E 90/ 92S - Build Sentry
Waypoint 3 satisfied:
8:31.94: 102M 27G 62E 92/ 92S
Income: 1227M 329G
Buildings: 2 Nexus 3 Assimilator 9 Pylon 5 Warp Gate 1 Cybernetics Core
Units: 38 Probe 10 Zealot 10 Stalker 7 Sentry
Upgrades: Warp Gate Transformation
|
On November 19 2010 03:32 croupier wrote:
5.2 seems to converge on builds much, much faster. And it seems to be actually using chronoboost now (maybe due to converging on builds faster?).
In any case, here's a 2-base 5-gate push
8:30
2 nexus
5 gate
10 zealot
10 stalker
7 sentry
Seems like that expansion might be pretty vulnerable early on, but it's a very strong build considering the army size at 8:30. I might give it a try, but I really suck at holding off early pressure so I think I'd just end up losing my expansion.
Right now I'm trying to get builds that give me a good sized army off 1 base 7-8 minutes in, with a chance to expand as I make my first push. Fits my limited skillset much better and provides me with a large enough army to feel comfortable against early pressure.
Also finding that the closer builds get to that mark, the more likely they are to get totally screwed up by your opponent.
|
Thanks a lot for the new version - Love it!
Here's some feedback:
I found something which looks like a bug:
* It seems like it sometimes puts 4 probes on 1 gas geyser. Try entering target time 300, sentries 10, probes 25, for example, and watch it run. Sometimes, a fourth gas guy appears (a total of 7 probes on 2 geysers), sometimes he disappears.
After trying out some build orders in practice, I've realized that the biggest weakness of these kinds of build orders is that they are too perfect. Or rather, they don't account for the required probe movement and human readability, often making one new action on each food count (such as transferring one probe at a time to a gas geyser).
One "simple" solution to both these problems would be to issue a "punishment" for each new series of actions taken at a specific time, except on probe production. This would encourage the program to group series of actions together, such as building 3 gateways at once, moving 3 probes to gas at once, build 3 units at once and so on, instead of splitting them up on different but very close food counts.
This would definitely make the build orders much easier to execute, and might even create some more optimal build orders because you in practice won't have to go back and forth to the mineral line with your probe as often when placing new building. Of course, this would require some fine tuning to decide how much perfection to sacrifice for usability, and would preferably be possible to configure under Settings.
Thanks again for the new version!
|
No matter what I do, I can't seem to get within 30 seconds of these builds in the real game. Maybe just me? Maybe more than that... not sure.
|
Aneon, from page 2 (read the middle paragraph):
On November 12 2010 11:53 CarbonTwelve wrote:Show nested quote +On November 12 2010 11:38 Impeccable wrote:
Norton claims that "this file risk is medium" and that "there are many indications that this file is untrustworthy and therefore not safe." Personally I think the first word there is your problem. /end Norton rant. Anyway, it's fine, the app won't infect your system or anything. But, if you're still concerned, don't run it - totally up to you. Show nested quote +On November 12 2010 11:39 Phenrei wrote:I'm also having a funky bug. I have it DT rush (fastest possible single DT) and it's putting 7 probes into two gasses (after 45mil games). It did this over multiple restarts. After about 10mil games they'd all converge to this: + Show Spoiler + 124.28: 51M 0G 20E 13/ 18S - Move Probe To Gas
124.28: 51M 0G 20E 13/ 18S - Move Probe To Gas
124.28: 51M 0G 20E 13/ 18S - Move Probe To Gas
139.59: 156M 29G 29E 13/ 18S - Build Cybernetics Core
139.59: 6M 29G 29E 13/ 18S - Move Probe To Gas
139.59: 6M 29G 29E 13/ 18S - Move Probe To Gas
139.59: 6M 29G 29E 13/ 18S - Move Probe To Gas
149.86: 50M 63G 34E 13/ 18S - Build Probe
149.86: 0M 63G 34E 14/ 18S - Move Probe To Gas That's not a bug, I took my income calculations from Piousflea's measurements: http://www.teamliquid.net/forum/viewmessage.php?topic_id=140055According to him, some geysers only need 3 workers, while some can benefit from 4. I've made the assumption that your base has 1 of each, so for gas heavy builds (like DTs/HTs/sentries) it will likely put 7 workers on gas, but most builds will probably only see 3/6. Show nested quote +On November 12 2010 11:46 pxds wrote:
hmm does it really uses the probe input number or it gets the best probe number to get your army input ASAP? i've tried putting 0 probes 2 stalkers and 10 probes 2 stalker and the results were the same. All inputs are basically a minimum. If you have less than that, it failed its target. More than that is a bonus, and it will actually prefer builds that give you more than you asked for in the same time (hence why you often see a Probe being built right near the end of the BO - it did that to get a bit of a boost to the income before the units finished building).
|
On November 19 2010 04:18 boberto wrote:Show nested quote +On November 19 2010 03:32 croupier wrote:
5.2 seems to converge on builds much, much faster. And it seems to be actually using chronoboost now (maybe due to converging on builds faster?).
In any case, here's a 2-base 5-gate push
8:30
2 nexus
5 gate
10 zealot
10 stalker
7 sentry Seems like that expansion might be pretty vulnerable early on, but it's a very strong build considering the army size at 8:30. I might give it a try, but I really suck at holding off early pressure so I think I'd just end up losing my expansion. Right now I'm trying to get builds that give me a good sized army off 1 base 7-8 minutes in, with a chance to expand as I make my first push. Fits my limited skillset much better and provides me with a large enough army to feel comfortable against early pressure. Also finding that the closer builds get to that mark, the more likely they are to get totally screwed up by your opponent.
Agreed this looks particularly weak at 5:49 you have 1 zealot and a Sentry and 2 nexus that is not enough to defend a expansion against normal early build pressure from any of the races. 6 min is like cut off for 4 gate you could be getting crushed by lings also. If you could go back in and maybe cut probes somewhere say around 17-18 and see what you come up with to get more units out then this has potential. That many units at 8:30 is juicy against a Hatch first zerg and will surely crush them if they are going mutaling. Even if we cut say 2 or 3 sentries out of that. This would hit before mutas pop at 9 min mark and 10 stalkers should be able to handle intial mutas. Even if this has to be delayed a bit to say 8:50-9:10 its still devastating it just needs a few more combat units out earlier at 5:49 id say 3 zealots 2 stalkers would suffice.
|
On November 19 2010 06:43 croupier wrote:Aneon, from page 2 (read the middle paragraph): Show nested quote +On November 12 2010 11:53 CarbonTwelve wrote:That's not a bug, I took my income calculations from Piousflea's measurements: http://www.teamliquid.net/forum/viewmessage.php?topic_id=140055According to him, some geysers only need 3 workers, while some can benefit from 4. I've made the assumption that your base has 1 of each, so for gas heavy builds (like DTs/HTs/sentries) it will likely put 7 workers on gas, but most builds will probably only see 3/6.
Thanks for citing, croupier.
I'm not sure the current calculations are the most realistic. According to http://wiki.teamliquid.net/starcraft2/Mining_Minerals the far-off patches are an exception rather than the norm, and the difference between 3 and 4 workers on those is marginal in terms of gas collection rate (-11 gas/min according to the link).
I do believe that loosing a probe to a geyser that doesn't give any gain that early in the game is pretty bad, however, so I think I'd prefer if it sticked to 3 workers per gas as default, unless there are some better references out there stating otherwise. Or maybe you could add a checkbox for it under Settings?
Note that I'm definitely no expert on this, and I haven't done any research on it myself.
|
On November 19 2010 06:30 VorKosigan wrote:
No matter what I do, I can't seem to get within 30 seconds of these builds in the real game. Maybe just me? Maybe more than that... not sure.
The trouble is ideal timings and no probe movements accounted for (or at least that's how I understand it). Take for example the very first pylon built at 9 supply. This build will consistently tell you to build that at 44 seconds into the game. Even pros with absolutely perfect early-game splits wont have 100 minerals until roughly 48 seconds + and the first pylon usually doesn't go down the -instant- they have 100 minerals either (usually drops around 50 seconds in).
Thats 4-6 seconds off -that- early into the game, and it compounds from there. It might be possible for the OP to tweak things to include probe walk-times (or simply add a small fraction of time to every single thing done, to slow down the estimated build just a hair) which would give more accurate in-game reportings.
Alternatively, he could just add an "estimated real-game time" that adds 5 seconds per minute to the estimate... I haven't sat down and worked out exactly how far off the builds are from reality but that would get you pretty close...
|
On November 19 2010 08:51 Aneon wrote:I'm not sure the current calculations are the most realistic. According to http://wiki.teamliquid.net/starcraft2/Mining_Minerals the far-off patches are an exception rather than the norm, and the difference between 3 and 4 workers on those is marginal in terms of gas collection rate (-11 gas/min according to the link).
My code handles the marginal difference (and indeed only gives an extra 12 gas/min for that extra worker). Far patches being an exception is probably true, however I figured the results of the algorithm are already hard enough to follow time wise, so it's probably best to account for worst case scenario. I might make this configurable at some point though.
I do believe that loosing a probe to a geyser that doesn't give any gain that early in the game is pretty bad, however, so I think I'd prefer if it sticked to 3 workers per gas as default, unless there are some better references out there stating otherwise.
It might be pretty bad in terms of mineral income, but if you're using the app to get 3 DTs as fast as possible then that's exactly what the algorithm gave you.
|
On November 19 2010 09:01 Ncinerate wrote:
The trouble is ideal timings and no probe movements accounted for (or at least that's how I understand it). Take for example the very first pylon built at 9 supply. This build will consistently tell you to build that at 44 seconds into the game. Even pros with absolutely perfect early-game splits wont have 100 minerals until roughly 48 seconds + and the first pylon usually doesn't go down the -instant- they have 100 minerals either (usually drops around 50 seconds in).
Thats 4-6 seconds off -that- early into the game, and it compounds from there. It might be possible for the OP to tweak things to include probe walk-times (or simply add a small fraction of time to every single thing done, to slow down the estimated build just a hair) which would give more accurate in-game reportings.
My code does handle probe movements - you get a penalty of 10s mining time for most buildings (I think 4s for assimilators and 30s for nexi). Unfortunately though I have to make it take that penalty after it builds the building rather than before. It wouldn't be easy to fix this, and for simplicity sake I'll probably leave it in. I might make the exact numbers configurable, or at least tweak them a bit based on in game measurements.
I think the main reason it takes a few seconds longer in the game itself is because of imperfect mining income rates. Because my code assumes a constant income rate (eg, something like 4.36 minerals per second for 6 probes, rather than 5 minerals every 10s or so) it will never be the same as actually playing the game. Also, I added a 2s delay at the start before the income starts & you can build anything, but I'm thinking I should increase that to maybe 3 or 4s.
|
On November 18 2010 22:41 phrame_ wrote:
Great work with the project so far.
A couple of anomalies that I've noticed so far:
1. Forge cost is listed as 200 instead of 150.
2. Dark Shrine is listed as 150/250 instead of 100/250.
Hope to see these fixed in the next release. : )
Thanks for those. I thought I'd already fixed the forge one. Dark Shrine I guess I just copied down incorrectly.
|
Great update! Don't know if it has been mention, anyway; it seems like the "Constant Probes" isn't working properly. I did a search for the fastest possible 4 warp-gate, with constant probe production.
The beginning of the output:
0:02.00: 50M 0G 0E 6/ 10S - Build Probe
0:19.00: 73M 0G 10E 7/ 10S - Build Probe
0:36.00: 106M 0G 19E 8/ 10S - Build Probe
0:44.10: 100M 0G 24E 9/ 10S - Build Pylon
1:10.03: 150M 0G 38E 9/ 18S - Build Gateway
1:18.96: 50M 0G 43E 9/ 18S - Build Probe
1:35.96: 107M 0G 53E 10/ 18S - Build Probe
1:38.69: 75M 0G 54E 11/ 18S - Build Assimilator
1:52.96: 98M 0G 62E 11/ 18S - Build Probe
2:09.96: 180M 0G 72E 12/ 18S - Build Probe
2:15.03: 172M 0G 75E 13/ 18S - Build Cybernetics Core
2:26.96: 117M 0G 82E 13/ 18S - Build Probe
I can't see how you'd possible could get that to work with constant worker production. At first it went for a 7 gateway, then I checked "Constant Probes" in every waypoint, not only the "Target" one and got the output quoted earlier in my post.
Great program anyway, won my fair share of games due to it 
And also, feature idea for us macro-nerds: "Only chrono nexus until:"
|
There are a lot of people who are saying that the 'constant probes' feature doesn't work. I think it's just that the definition I implemented for constant probes isn't producing the results that they expect, however I'm not sure that there is any better definition that can be implemented. I tried putting in a measurement of how much idle time the nexus has and seeing that as a negative, however this lead to scenarios where it would avoid doing a chrono on the nexus and having idle time, where that was clearly better than just letting the probes build normally (and you could see this by just specifying the same number of probes to be built without 'constant probes' ticked and you'd end up with a faster build).
If someone can come up with a definition that works better than the one I'm using atm (calculate the number of probes that could be produced at a rate of 11s each and add a 3s penalty for each one you're short), I'd gladly do it (and I'm not trying to be dismissive or anything - I genuinely would like to find an implementation that works better). I think part of the problem is, how would you actually define 'constant probe production'? Does it actually mean that the nexus shouldn't be idle? Does it mean it should just make as many probes as it possibly can (all chrono spent on nexus)? Does it mean you should keep up with Terran's SCV production? Very difficult to say for Protoss and kind of depends on what build you're actually going for.
|
IMO, it should be renamed to "Economic", or something to that effect, and be re-purposed to favor builds with better income(within reason).
|
On November 19 2010 11:55 CarbonTwelve wrote:
There are a lot of people who are saying that the 'constant probes' feature doesn't work. I think it's just that the definition I implemented for constant probes isn't producing the results that they expect, however I'm not sure that there is any better definition that can be implemented. I tried putting in a measurement of how much idle time the nexus has and seeing that as a negative, however this lead to scenarios where it would avoid doing a chrono on the nexus and having idle time, where that was clearly better than just letting the probes build normally (and you could see this by just specifying the same number of probes to be built without 'constant probes' ticked and you'd end up with a faster build).
If someone can come up with a definition that works better than the one I'm using atm (calculate the number of probes that could be produced at a rate of 11s each and add a 3s penalty for each one you're short), I'd gladly do it (and I'm not trying to be dismissive or anything - I genuinely would like to find an implementation that works better). I think part of the problem is, how would you actually define 'constant probe production'? Does it actually mean that the nexus shouldn't be idle? Does it mean it should just make as many probes as it possibly can (all chrono spent on nexus)? Does it mean you should keep up with Terran's SCV production? Very difficult to say for Protoss and kind of depends on what build you're actually going for.
For me constant probe-producing is the nexus never being idle. In other words, it should add a new probe every 17(?) second. If the system could check before building a pylon/gateway how much time there's left until a probe is finished and check if it will have 50 minerals at that time, even if it puts down the pylon/gateway. That'd be constant probe production for me.
Tho, that might very well been what you meant by your first solution that didn't work properly.
|
On November 19 2010 12:01 Serisium wrote:
IMO, it should be renamed to "Economic", or something to that effect, and be re-purposed to favor builds with better income(within reason).
"better income within reason" is very hard to program though  Needs to be a clear cut rule.
On November 19 2010 12:34 ribboo wrote:
For me constant probe-producing is the nexus never being idle. In other words, it should add a new probe every 17(?) second. If the system could check before building a pylon/gateway how much time there's left until a probe is finished and check if it will have 50 minerals at that time, even if it puts down the pylon/gateway. That'd be constant probe production for me.
Tho, that might very well been what you meant by your first solution that didn't work properly.
Nup, it can't check when things will happen ahead of time or do any kind of prediction for what it should do. The build orders are generated randomly by the GA. The only thing I can control is to tell it how good a BO is by giving it a score that it can sort & breed them based on. So I need a clear cut rule as to how it should value the result, based on what happened. This can include nexus idle time, but as I said above, this isn't always best as chronoing two probes followed by idle time is better than building 2 probes without chrono.
|
I'm kind of at a loss here, doubt this would work anyway:
What about creating some sort of list including the timing of let's say the 60 first probes. 60 probes should be finished after 17 minutes if you're on one base. Let's say 15 with full-chrono. I'm sure specific timings could be worked out.
Then score the BO after how many probes it has at the time it's finished. If it has 27 probes after 6 minutes and the list has a value for minute 6 that say's 29 is the maximum amount of probes you could have at this time(with full chrono). Then that's a quite good score. If it says 20 probes, well, that's a bad score. Cutting maximum one probe for every minute the BO runs could be considered as "good".
Ah, i donnu, I'll leave it to someone who knows what he's talking about.
|
damn carbontwelve awesome work on this! stoked to see if your zerg version is an improvement over EC, and I can't frickin wait for terran. its actually best you're building it last becasue youll have the most experience then 
as for the liquipedia mining page, im positive their numbers are inaccurate. ive done more work on scv mining times than anything else, and the 30 seconds they used is far from enough. if i remember right it takes more than 33 game-minutes for one scv to drain the closes mineral fields, but closer to 40+ for the farthest ones, and the minerals/second get more and more accurate over those 30ish minutes. 30 seconds would give you an super-innacurate result, and unless they tested and averaged every field it wouldnt even give you a reasonable average. Averaging them all together i got 1 scv mining an average of .970011533 minerals per second, and im sure i can get even more accurate than that (this is relevant assuming scvs mine at the same rate as probes/drones).
|
On November 19 2010 13:17 calculator wrote:
as for the liquipedia mining page, im positive their numbers are inaccurate. ive done more work on scv mining times than anything else, and the 30 seconds they used is far from enough. if i remember right it takes more than 33 game-minutes for one scv to drain the closes mineral fields, but closer to 40+ for the farthest ones, and the minerals/second get more and more accurate over those 30ish minutes. 30 seconds would give you an super-innacurate result, and unless they tested and averaged every field it wouldnt even give you a reasonable average. Averaging them all together i got 1 scv mining an average of .970011533 minerals per second, and im sure i can get even more accurate than that (this is relevant assuming scvs mine at the same rate as probes/drones).
Yeah, I suspected the same thing actually, and I was planning to do a lot more measurements myself to determine exactly what benefit you get for 1, 2, or 3 miners, independently at each mineral patch at each base for a balanced map like Lost Temple. Would be a complete bitch to work out, but I was planning on doing it in the map editor by deleting the mineral patches that I'm not paying attention to at the time (so the workers don't move to the others) then letting it run for 5 to 10 mins. I'd run it with 8 players and remove the AI, then have text run commands to start all mining together, then come back and get them all to stop at the same time, and check the resources for each player. This way I'd get accurate numbers that I can average for each base, and it'd only take 24 such tests to do all the bases for minerals, and another 16 for all the bases for gas (up to 4 per geyser). Still, even at 5 mins per test that's already over 3 hours of testing, plus the time to set it all up and write down the numbers. Hence it's not something I've jumped into straight away.
|
On November 19 2010 09:22 CarbonTwelve wrote:Show nested quote +On November 19 2010 09:01 Ncinerate wrote:
The trouble is ideal timings and no probe movements accounted for (or at least that's how I understand it). Take for example the very first pylon built at 9 supply. This build will consistently tell you to build that at 44 seconds into the game. Even pros with absolutely perfect early-game splits wont have 100 minerals until roughly 48 seconds + and the first pylon usually doesn't go down the -instant- they have 100 minerals either (usually drops around 50 seconds in).
Thats 4-6 seconds off -that- early into the game, and it compounds from there. It might be possible for the OP to tweak things to include probe walk-times (or simply add a small fraction of time to every single thing done, to slow down the estimated build just a hair) which would give more accurate in-game reportings. My code does handle probe movements - you get a penalty of 10s mining time for most buildings (I think 4s for assimilators and 30s for nexi). Unfortunately though I have to make it take that penalty after it builds the building rather than before. It wouldn't be easy to fix this, and for simplicity sake I'll probably leave it in. I might make the exact numbers configurable, or at least tweak them a bit based on in game measurements. I think the main reason it takes a few seconds longer in the game itself is because of imperfect mining income rates. Because my code assumes a constant income rate (eg, something like 4.36 minerals per second for 6 probes, rather than 5 minerals every 10s or so) it will never be the same as actually playing the game. Also, I added a 2s delay at the start before the income starts & you can build anything, but I'm thinking I should increase that to maybe 3 or 4s.
Ahh, that explains it! I apologize for the misunderstanding, it appeared that it wasn't taking into account probe movements due to times for building - that makes sense in light of the penalty happening -after- the building is planted!
You've got an awesome program here - if it ends up keeping a few little flaws it's really no big deal. Thanks for all your efforts.
|
|
|
|
|
|
EPT
