|
On November 15 2010 13:28 Chronicle wrote:
That bug I mentioned earlier I can now replicate. Happens everytime I attempt to use the 3rd waypoint. I submitted the details to the googlecode page.
Yeah I saw that, I posted a reply comment - I'm fairly certain it's just due to the warpgate you've chosen in waypoint 2. Assuming it is, it'll be fixed in the next version.
|
Its not. See my replay / other report. This version is crashing for me a hell of a lot while all the previous versions were stable.
|
On November 15 2010 14:10 Chronicle wrote:
Its not. See my replay / other report. This version is crashing for me a hell of a lot while all the previous versions were stable.
Hmm, just been playing around with it more and it looks like this version is suffering the same fate as the last one with respect to build orders just growing in size over time...
Sorry, I'll make sure to get it fixed in the next version.
|
I noticed if you force it to build more probes or production buildings sometimes it can force it to get to a faster completion time. Kind of just pointing it in the right direction.
Like I tried 4 carriers, left it on for like 15mins, got to 9:02 but it only built 1 stargate. So I was like hmm lemme see if building 4 carriers really is slower with 2 stargates.
It's at 8:56 right now with 2 stargates and it's only been like 3mins 
EDIT: 8:53!
EDIT (suggestion): I imagine this would be a lot of work, but what would be amazing is if you could have it run a real time simulation showing a completion% bar and an icon for whats currently in production, kinda like the GUI for the "Production" tab in sc2 replays.
Would help understand when it stops building probes etc, making it easier to reproduce the build orders ingame.
Love this damn program btw.
Already lost two games tho using the "fastest 2 zealots possible" build lol. Kinda worked but I couldnt keep up with opponents zealot production (both pvps).
|
Hmm. Mothership, an observer, 2 phoenixes and 8 stalkers out by 9 minutes.
As a suggestion though Carbon, it'd be nice if you could remove useless commands in the displayed build orders. Just try removing each action from the build order and see if it gets the same fitness - would take no time to compute and would remove useless "Build Forge" etc at the end of build orders quicker than the GA can.
|
On November 15 2010 15:47 Almania wrote:
Hmm. Mothership, an observer, 2 phoenixes and 8 stalkers out by 9 minutes.
As a suggestion though Carbon, it'd be nice if you could remove useless commands in the displayed build orders. Just try removing each action from the build order and see if it gets the same fitness - would take no time to compute and would remove useless "Build Forge" etc at the end of build orders quicker than the GA can.
What????? I am a zerg player powering drones until the very last moment :-D
When i see a Mothership and 8 stalkers at 9 min i`ll start powering drones again... in the next game :-))
|
I am having a little problem with this GA programs...
If i use the pen and paper and work backwards a BO i am able to come up with a build that i know for sure it is optimal. For an easy BO it might take me about 2h.
It seems to me that a deterministic algorithm would be much better since you know exactly what you want... Ex 5 Stalker ASAP.
I think GA should be used to find other things, like only give him some general info and let a fitness function to decide what to build.
An ex. would be something like:
I want a BO for 12 min, scout on 10, have at least 300 value army by 5 min.
Another would be to give him a BO for zerg and have him to find the best counter to that.
But all this i think require a lot mire programming :-(
|
On November 15 2010 15:36 Mios wrote:I imagine this would be a lot of work, but what would be amazing is if you could have it run a real time simulation showing a completion% bar and an icon for whats currently in production, kinda like the GUI for the "Production" tab in sc2 replays. Would help understand when it stops building probes etc, making it easier to reproduce the build orders ingame.
That's not actually how the algorithm works - even though it only displays one build order, it's actually considering over a thousand games at a time. Each of these has random changes made to it to see whether they actually help or not.
Edit: Doh, just re-read what you're saying, and I completely misunderstood the first time. Yeah, that's something that's possible, although it'd be better still to be able for a custom map to be able to do it for you. Ie, enter a BO and have the AI run it for you, then you can watch and see everything as it happens. I'd like to achieve this at some point (or better still I'd have hoped something like YABOT could do it), but it's probably a fair way down the track.
Edit 2: Incidentally, if there are any mappers out there I'd love some assistance in achieving something like this. I've played with the map editor myself, but now that I'm working on this project I just don't have anywhere near enough time to even learn how to achieve what I need from it, let alone actually writing the map. PM me or post here or on the project page if you think you could help.
Love this damn program btw.
Already lost two games tho using the "fastest 2 zealots possible" build lol. Kinda worked but I couldnt keep up with opponents zealot production (both pvps).
Forgot to add the disclaimer: the author of this program makes no guarantees as to usefulness of any of the results, and takes no responsibility for using said results 
On November 15 2010 15:47 Almania wrote:
As a suggestion though Carbon, it'd be nice if you could remove useless commands in the displayed build orders. Just try removing each action from the build order and see if it gets the same fitness - would take no time to compute and would remove useless "Build Forge" etc at the end of build orders quicker than the GA can.
Yeah, that's one change I'll be making sometime soon (probably not next version but the one after). Basically I'll be adding the ability to set a maximum number of certain buildings / units. If I can be certain something isn't actually required / won't help, then it'll set the maximum for it to 0. Then when setting the list of commands available it will completely ignore commands for building those units. This should greatly increase the speed with which it gets to the right build order, and should eliminate most of those bizarre builds that make no sense (it won't eliminate them completely though - when everything changes by random chance, sometimes it adds something useless in when it also makes a significant improvement, then takes a while to consider removing it).
|
I love these bo optimizers, nice job / thanks a lot carbontwelve. Can't wait for a terran one :D
edit:Question though: I'm looking at a build it provided for fastest 1 dark templar. The end result has 11 probes, and 250 minerals. It doesn't make any probes for nearly 4 minutes, but has 250 minerals in the end, isn't that obviously not optimal? Shouldn't the program note that it could have more probes by that time without sacrificing time?
It just changed to a new build, and the end result might be a little faster, not sure, barely if at all, but it has fewer minerals and more gas. That's not really desireable, is there a way where I can indicate I want it to optimize for probes over minerals over gas, without wanting any specific number? Program just seems to have weird priorities. I realize I've asked it to optimize primarily for time, but its secondary priorities seem off.
Also, it's chronoing nexus at 9/10 supply, but not making another probe for quite some time, thus wasting half the chrono. I'd also like an option to force it to construct the build around optimizing chrono use.
|
On November 15 2010 17:41 icezar wrote:
I am having a little problem with this GA programs...
If i use the pen and paper and work backwards a BO i am able to come up with a build that i know for sure it is optimal. For an easy BO it might take me about 2h.
It seems to me that a deterministic algorithm would be much better since you know exactly what you want... Ex 5 Stalker ASAP.
This is the key advantage of using something like a GA - because it's not deterministic it considers things that someone might never have thought of. An example is the double overlord in the 7RR found by Lomilar's app. This isn't something that people normally think of because it's always been considered a bad idea to build supply when you're not near the cap.
I think GA should be used to find other things, like only give him some general info and let a fitness function to decide what to build.
An ex. would be something like:
I want a BO for 12 min, scout on 10, have at least 300 value army by 5 min.
Another would be to give him a BO for zerg and have him to find the best counter to that.
Yeah, that's a good idea, and certainly something that GAs would be suited for. With the design I've taken it'd be very easy to substitute a different fitness function to suit that. I'd say it'll be a while before I can start on something like that though.
Edit: I've just created this issue for this idea: http://code.google.com/p/scbuildorder/issues/detail?id=11. Feel free to add discussion to that if you want.
|
|
|
Thanks for that. What I might do is add an option in the settings tab at some point to specify what sort of geysers you want per base. For the moment I might leave as is, as there's already trouble keeping up with a BO due to its approximations and how it instantly executes commands.
|
On November 15 2010 17:50 Nightmarjoo wrote:
Question though: I'm looking at a build it provided for fastest 1 dark templar. The end result has 11 probes, and 250 minerals. It doesn't make any probes for nearly 4 minutes, but has 250 minerals in the end, isn't that obviously not optimal? Shouldn't the program note that it could have more probes by that time without sacrificing time?
I just ran that build myself and here are the results:
+ 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:46.44: 12M 0G 25E 9/ 10S - Chrono Nexus
1:09.79: 150M 0G 13E 9/ 18S - Build Gateway
1:22.79: 75M 0G 20E 9/ 18S - Build Assimilator
1:31.13: 50M 0G 25E 9/ 18S - Build Probe
1:31.13: 0M 0G 25E 10/ 18S - Chrono Nexus
1:42.47: 72M 0G 7E 10/ 18S - Build Probe
1:50.15: 75M 0G 11E 11/ 18S - Build Assimilator
1:52.79: 17M 0G 12E 11/ 18S - Move Probe To Gas
1:52.79: 17M 0G 12E 11/ 18S - Move Probe To Gas
1:52.79: 17M 0G 12E 11/ 18S - Move Probe To Gas
2:17.24: 150M 46G 26E 11/ 18S - Build Cybernetics Core
2:17.24: 0M 46G 26E 11/ 18S - Move Probe To Gas
2:17.24: 0M 46G 26E 11/ 18S - Move Probe To Gas
2:17.24: 0M 46G 26E 11/ 18S - Move Probe To Gas
3:07.24: 176M 221G 54E 11/ 18S - Build Twilight Council
3:15.24: 50M 149G 59E 11/ 18S - Research Warpgate
3:57.27: 152M 250G 82E 11/ 18S - Build Dark Shrine
3:57.27: 2M 0G 82E 11/ 18S - Chrono Cybernetics Core
4:12.17: 50M 53G 66E 11/ 18S - Build Probe
4:12.17: 0M 53G 66E 12/ 18S - Chrono Nexus
4:25.82: 50M 102G 48E 12/ 18S - Build Probe
4:32.17: 27M 125G 52E 13/ 18S - Chrono Nexus
4:37.44: 50M 144G 30E 13/ 18S - Build Probe
4:48.78: 55M 185G 36E 14/ 18S - Build Probe
4:52.17: 23M 197G 38E 15/ 18S - Chrono Nexus
5:00.11: 67M 225G 18E 15/ 18S - Build Probe
5:25.24: 184M 315G 32E 16/ 18S - Convert Gateway To Warpgate
5:37.27: 269M 358G 39E 16/ 18S - Build Dark Templar
Waypoint 1 satisfied:
5:42.27: 180M 251G 41E 18/ 18S
Buildings: 1 Nexus 2 Assimilator 1 Pylon 1 Warpgate 1 Cybernetics Core 1 Twilight Council 1 Dark Shrine
Units: 16 Probe 1 Dark Templar
Upgrades: Warpgate
Even though it had spare minerals at the end, it couldn't build any earlier on because it was mineral capped trying to get the production facilities built as fast as possible (in order to get the DT out as fast as possible). Once those production facilities were done and it was no longer mineral capped, then it started spamming probes and chronoing the nexus. So basically, it did maximise probes while minimising build order time.
It just changed to a new build, and the end result might be a little faster, not sure, barely if at all, but it has fewer minerals and more gas.
The algorithm considers gas more valuable than minerals (twice as much). Most real games that you play that's also the case.
That's not really desireable, is there a way where I can indicate I want it to optimize for probes over minerals over gas, without wanting any specific number? Program just seems to have weird priorities. I realize I've asked it to optimize primarily for time, but its secondary priorities seem off.
I might add a feature at some point to tweak these figures so you can specify which one you prioritise more. Will add it to the ToDo list.
Also, it's chronoing nexus at 9/10 supply, but not making another probe for quite some time, thus wasting half the chrono. I'd also like an option to force it to construct the build around optimizing chrono use.
It uses chrono then because there's no reason not to - it gets up to 100 anyway, so even though there's little gain in using it early on, there's at least some gain so it takes it. Again, changing resource values would be something I might add later.
|
A Mothership, 15 Stalkers, and an Observer (just in case) at 10:01. o.O. HuK, take note. XD
And it leaves you with a decent econ at 27 probes. Not to bad.
|
So while attempting to find a trivial bug, I might have stumbled upon a more important one.
Messing around with a different quick Dark Templar build I noticed that the following actions were nicely synced up.
4:12.35: 189M 254G 41E 16/ 18S - Build Dark Shrine
5:42.35: 248M 226G 16E 23/ 26S - Convert Gateway To Warpgate
5:52.35: 340M 262G 22E 23/ 26S - Build Dark Templar
I remembered accidentally chrono boosting a gateway once and realizing it sped up the 10second Convert to Warpgate action, and I thought your code might consider it a hard set 10 seconds. So I set out to prove it. I failed, and indeed the above build is limited by the Dark Shrine instead.
The failed test consisted of, demanding getting the fastest possible Warpgate, and then 2 more Warpgates.
Waypoint 1: Target Time = 270s, Warpgate: 1
Target: Warpgate: 3
This is the build it gave me after some 200million games.
0:13.63: 100M 0G 7E 6/ 10S - Build Pylon
0:50.02: 150M 0G 27E 6/ 18S - Build Gateway
1:03.16: 50M 0G 34E 6/ 18S - Build Probe
1:20.60: 75M 0G 44E 7/ 18S - Build Assimilator
1:55.02: 167M 0G 64E 7/ 18S - Build Cybernetics Core
2:02.75: 50M 0G 68E 7/ 18S - Build Probe
2:02.75: 0M 0G 68E 8/ 18S - Move Probe To Gas
2:02.75: 0M 0G 68E 8/ 18S - Move Probe To Gas
2:19.75: 61M 24G 77E 8/ 18S - Build Probe
2:45.02: 122M 59G 92E 9/ 18S - Chrono Cybernetics Core
2:45.02: 122M 59G 67E 9/ 18S - Research Warpgate
3:00.78: 150M 31G 76E 9/ 18S - Build Gateway
3:05.02: 18M 37G 78E 9/ 18S - Chrono Cybernetics Core
3:25.02: 114M 65G 64E 9/ 18S - Chrono Cybernetics Core
3:32.40: 150M 75G 43E 9/ 18S - Build Gateway
3:32.40: 0M 75G 43E 9/ 18S - Move Probe To Gas
3:45.02: 48M 99G 50E 9/ 18S - Chrono Cybernetics Core
3:45.53: 50M 100G 26E 9/ 18S - Build Probe
4:02.53: 73M 133G 35E 10/ 18S - Build Probe
4:05.02: 34M 137G 37E 11/ 18S - Chrono Cybernetics Core
4:18.36: 100M 163G 19E 11/ 18S - Convert Gateway To Warpgate
4:19.53: 106M 165G 20E 11/ 18S - Build Probe
Waypoint 1 satisfied:
4:28.36: 104M 182G 25E 12/ 18S
Buildings: 1 Nexus 1 Assimilator 1 Pylon 1 Gateway 1 Warpgate 1 Cybernetics Core
Units: 11 Probe
Upgrades: Warpgate
4:28.36: 104M 182G 25E 12/ 18S - Convert Gateway To Warpgate
4:38.36: 160M 201G 30E 12/ 18S - Convert Gateway To Warpgate
4:38.36: 160M 201G 30E 12/ 18S - Chrono Gateway
Waypoint 2 satisfied:
4:45.02: 202M 213G 9E 12/ 18S
Buildings: 1 Nexus 1 Assimilator 1 Pylon 3 Warpgate 1 Cybernetics Core
Units: 12 Probe
Upgrades: Warpgate
You can see the Chrono used on that last Gateway, to speed up the conversion to Warpgate. So my attempt to find flaw in your code failed. Well done.
However, upon closer inspection trace back that final Gateway that is determining the end time.
3:32.40: 150M 75G 43E 9/ 18S - Build Gateway
4:38.36: 160M 201G 30E 12/ 18S - Convert Gateway To Warpgate
4:38.36: 160M 201G 30E 12/ 18S - Chrono Gateway
Waypoint 2 satisfied:
4:45.02: 202M 213G 9E 12/ 18S
So tracing back, 4:45.02-4:38.36 = 6.66 seconds, chrono boosted convert = good.
4:38.36 - 3:32.40 = 65.96, gateway takes 65 seconds to build, sits there idle for 0.96 seconds = bad.
(It also delays gateway #2 but that isnt slowing the final time down, so no problem)
TLDR; In quest to find trivial flaw in code, found a different trivial flaw in code: or why is my gateway idle for 0.96 seconds?
Anyways, great work, I love this so much, thx!
|
hmm i tried to save a build (got 4 carriers in like 8:30 lol, took 15mins), but when i opened it it just shows it as blank :[
I guess from now on ill just copy/paste the text to notepad or something.
|
It still gives some weird build orders sometime though. It wanted me to build 5 assimilators on 2 bases, and an other time it wanted 2 cybernetic cores..
Also, when I put in that I want 5 zealots and 16 probes in 240 secs, its possible. However, if I give up other way points, it pretty much stays on 16 probes the entire time! I'd like to see a way that it makes probes whenever possible, since I don't want a build that still has 16 probes after 10 minutes :p.
It's still an awesome program though!
Also, +1 forge upgrade would be awesome if included :D.
|
If it could output to YABOT format just like Evolution Chamber does I'd love you long time.
|
Hi all,
Firstly, thanks for continuing to follow the project, it's what's keeping me going with the coding
Anyway, I've got a new version out, and I think this is something of a big one. Upgrades are finally done!! I've done a quick test of them all and they appear to be working as expected, but with so many changes at once I wouldn't be surprised if I've missed something. Please let me know if I have.
There are also a few other changes in there, one of which is a list control to view what each of the city/village threads are doing, which kinda makes it interesting and helps see when something was last changed (before you ask, I do plan to implement an actual timer too ). More feature requests are always welcome though.
v4 release
Changelog:
Upgrades!
More GUI changes (primarily seeing city/village stats)
More core algorithm tweaks
Hopefully massive build order crash finally resolved
- Carbon
|
WOW!!!!! The progress you make is incredible both in quality and speed of new release.
I would like to ask againf for zerg :D evolutionchamber is "evolving" much much slower :D
|
|
|
|
|
|
EPT
