|
On January 17 2011 07:04 CarbonTwelve wrote:
I have just uploaded v9.0 alpha 2 which supports YABOT format for all races as well as utilising addon swapping for Terran (as well as a couple of other minor changes). If anyone wants to test it out and let me know of any issues that'd be appreciated. I'll probably release 9.0 final tonight.
Sweet!
|
After a fairly long wait, v9.0 is out.
Release notes:
Added YABOT output format
Terran addon swapping enabled
Lair upgrades can be upgraded from hatcheries/hives
Warp gates will always be upgraded when possible
Greater spire units no longer cause extra spire to be built
Patch 1.2 changes applied
|
Keep up the good work!
I just solved a few problems for myself:
-If you don't want the program to use extra supplies, just look how much supply you need to fulfill your build and set the right amount of supply depots as target.
-To get an easy, common Terran start set first waypoint to:
1 Refinery, 1 Barracks, 1 Orbital Command, 1 Marine, Constant SCVs and 190 sec.
You will end up with:
+ Show Spoiler +10 Supply Depot
12 Barracks (Naked)
14 Refinery
15 Orbital Command
15 Marine
Always good to have an early Marine to kill scouts.
For most of the builds, it doesn't delay it for more than a few seconds; but it's just a great beginning I think.
Another problem I can't solve is that I want to have always exactly 3 workers in my Refinery. Can you add an option for that so that we can perform the build more easily? 
// edit: found a little typo at YABOT output: "Build order developed by SCBuildOder"
|
|
|
Carbon! Thanks for this awesome update. I also really appreciate the YABOT output.
|
Thanks for another release, Carbon. Like the add-on swapping.
Keep it up!
|
Thanks a lot for your work on this. It seems really great so far! What about the possibility for generating "micro friendly" builds? For example, one build I'm working on has me taking 3 SCVs off of gas for one mining cycle and then putting them back. I imagine this results in the build being a second or two faster, but the tradeoff isn't worth it if you don't have the micro to pull it off perfectly.
|
On January 18 2011 05:07 Corwin wrote:
Thanks a lot for your work on this. It seems really great so far! What about the possibility for generating "micro friendly" builds? For example, one build I'm working on has me taking 3 SCVs off of gas for one mining cycle and then putting them back. I imagine this results in the build being a second or two faster, but the tradeoff isn't worth it if you don't have the micro to pull it off perfectly.
Another problem I can't solve is that I want to have always exactly 3 workers in my Refinery. Can you add an option for that so that we can perform the build more easily?
Yes, there's an item to add a setting for gas micro options. The way I'll do it is in the settings you'll be able to specify if you want to leave it as is (will probably be the default), only move all 3 at a time (either 3 on gas or none at all), or move 3 once geyser is ready then never take them off.
// edit: found a little typo at YABOT output: "Build order developed by SCBuildOder"
Thanks for that, I found another typo plus a couple of other little things with the YABOT format that needs to be fixed up, so I'll probably do a small release tonight to fix those.
|
Hi,
Great job on your program, which I'm trying to make us of since yesterday. I have a few problems/questions though.
- After hours of computation (overnight=~300M games), I don't get "realistic" BOs. For example i ask for : WP1 2z at 240s, target 48 speedlings/24speedroach/44drones. What i get is 3 hatch 1 extractor, no units before 51 pop.
I guess I could add waypoints, but i fear waypoints will cut the creativity of the GA to much. Will it be possible in the future to choose the main criteria ? For example, i prefer 2 hatches 24roach at 9:16 than 3 hatches 24roach at 9:10. So a low number of hatches may be a criteria to say a BO is "good". Maybe there could also be a tweak to maintain an eco/army ratio during the build, to avoid mass drones -> 50+ and then mass units, which is not viable in game conditions.
- The second issue is computing speed. I get an average of 10000games/sec which seems to be low, when compared to the numbers i've read above (400000+). I have a laptop with a c2d T2300E (1.66*2), which i know is not very fast, but i'd like to know if the order of magnitude is OK here.
- still on speed, I realized that i can launch 2 or 3 builds at the same time, and that i get 10k/s for each. Why is that ? If it can do 5*10k games/sec, why not do 50k/s on a single BO. Is there something i get wrong here ? Is cache the limiting factor ? Or RAM ? Or the way the GA works ?
Thanks for your great work.
FKZ
|
No release tonight guys, sorry, just haven't quite got as much done for it as I wanted. Hopefully tomorrow
On January 18 2011 18:15 FKeyserSoze wrote:
Hi,
Great job on your program, which I'm trying to make us of since yesterday. I have a few problems/questions though.
- After hours of computation (overnight=~300M games), I don't get "realistic" BOs. For example i ask for : WP1 2z at 240s, target 48 speedlings/24speedroach/44drones. What i get is 3 hatch 1 extractor, no units before 51 pop.
I guess I could add waypoints, but i fear waypoints will cut the creativity of the GA to much. Will it be possible in the future to choose the main criteria ? For example, i prefer 2 hatches 24roach at 9:16 than 3 hatches 24roach at 9:10. So a low number of hatches may be a criteria to say a BO is "good".
I plan to add maximums soon after the new GUI is finished. With that you'll be able to specify that you don't want any more than 2 bases.
Maybe there could also be a tweak to maintain an eco/army ratio during the build, to avoid mass drones -> 50+ and then mass units, which is not viable in game conditions.
Hmm, I really don't think that's going to be that useful. It's very difficult to actually specify to the app what you mean by having a good eco/army ratio, without actually specifying the units you want by when. I think you'll have to make do with waypoints, which IMO don't really restrict the creativity of the GA because the whole point is to get what you want and if you need X units by time Y then you may as well specify that.
- The second issue is computing speed. I get an average of 10000games/sec which seems to be low, when compared to the numbers i've read above (400000+). I have a laptop with a c2d T2300E (1.66*2), which i know is not very fast, but i'd like to know if the order of magnitude is OK here.
- still on speed, I realized that i can launch 2 or 3 builds at the same time, and that i get 10k/s for each. Why is that ? If it can do 5*10k games/sec, why not do 50k/s on a single BO. Is there something i get wrong here ? Is cache the limiting factor ? Or RAM ? Or the way the GA works ?
That does sound a bit low, however the speed is dependant on the size of the resulting build order, so if you're specifying something that ends up getting 3 bases then it's probably a long BO and hence will run a bit slower (which might explain why adding another small BO also gets 10k/s). The app is multithreaded so it should be maxing out your CPU with just 1 BO running. Cache shouldn't affect the speed, and RAM should be somewhat irrelevant (I don't think I've seen it get much above 20MB per BO).
|
Would it be possible to make an option to have production facilities always working?
|
Is the phoenix build time off? It seems like I can't seem to get a phoenix to pump out in less than 30 seconds with CB.
|
On January 18 2011 21:29 graNite wrote:
Would it be possible to make an option to have production facilities always working?
I guess that'd be possible. Not sure how useful the results would be, but I suppose I'd need to implement it to find out
On January 18 2011 22:09 Treehead wrote:
Is the phoenix build time off? It seems like I can't seem to get a phoenix to pump out in less than 30 seconds with CB.
I don't think so. I just tested a 1 phoenix build and this is what it comes up with:
+ Show Spoiler + 0:02.00: 50M 0G 0E 6/ 10S - Build Probe
0:19.00: 73M 0G 10E 7/ 10S - Build Probe
0:34.80: 100M 0G 18E 8/ 10S - Build Pylon
1:03.12: 150M 0G 34E 8/ 18S - Build Gateway
1:13.21: 50M 0G 40E 8/ 18S - Build Probe
1:13.21: 0M 0G 40E 9/ 18S - Chrono Nexus
1:26.59: 75M 0G 23E 9/ 18S - Build Assimilator
1:38.87: 75M 0G 29E 9/ 18S - Build Assimilator
1:56.59: 109M 0G 39E 9/ 18S - Move Probe To Gas
1:56.59: 109M 0G 39E 9/ 18S - Move Probe To Gas
2:08.12: 167M 12G 46E 9/ 18S - Build Cybernetics Core
2:08.12: 17M 12G 46E 9/ 18S - Move Probe To Gas
2:08.12: 17M 12G 46E 9/ 18S - Move Probe To Gas
2:08.12: 17M 12G 46E 9/ 18S - Move Probe To Gas
2:58.12: 159M 159G 74E 9/ 18S - Build Stargate
3:14.27: 50M 58G 83E 9/ 18S - Build Probe
3:14.27: 0M 58G 83E 10/ 18S - Chrono Nexus
3:58.12: 151M 190G 83E 10/ 18S - Chrono Stargate
3:58.12: 151M 190G 58E 10/ 18S - Build Phoenix
3:58.12: 1M 90G 58E 12/ 18S - Move Probe To Gas
4:18.12: 61M 161G 69E 12/ 18S - Chrono Stargate
Waypoint 1 satisfied:
4:21.45: 71M 173G 46E 12/ 18S
Income: 180M 215G
Buildings: 1 Nexus 2 Assimilator 1 Pylon 1 Gateway 1 Cybernetics Core 1 Stargate
Units: 10 Probe 1 Phoenix
Upgrades:
As you can see the phoenix starts at 3:58.12, finishes at 4:21.45, meaning a build time of 23.33s, exactly 35/1.5.
|
Thanks for your quick answer.
Indeed i launched a smaller BO just now, and it computes at 100k/s, which is much better.
I look forward to see the limitation tweak, which is gonna be very useful for all three races I think, since the number of bases is the biggest ingame tactical limitation to the "normal" unfold of the BO.
By the way, since I was talking about speed, has anyone tried to run the program on some crazy ass super comp ? I guess that with something like $5 we could get some nice build orders with amazon EC2 for example.
just a thought
EDIT : I forgot to say that it would be nice if we could pause/save a computation (so when i want to ladder, i don't have to lose my 5-hours-worth-of-CPU-time BO because my laptop can't handle both)
|
On January 19 2011 05:33 FKeyserSoze wrote:
EDIT : I forgot to say that it would be nice if we could pause/save a computation (so when i want to ladder, i don't have to lose my 5-hours-worth-of-CPU-time BO because my laptop can't handle both)
If you stop the optimiser it will remember the best build and use that as a seed for the next time you run it, so you won't lose everything.
|
On January 19 2011 06:49 CarbonTwelve wrote:
If you stop the optimiser it will remember the best build and use that as a seed for the next time you run it, so you won't lose everything.
It seemed to me that it did not. My bad.
|
May be a silly question, but what exactly does "mutation rate" change?
Nice tool btw, thanks. 
|
Hey I was wondering if you could fix the scouting worker feature... I'm trying to optimize protoss b/o's, and I set the scouting worker field to 9 and checked "dies" at 50. For some reason, the build order sends the scout out at 7 and kills it at 7 (evident when you look at the "Full" build order). I'd absolutely appreciate it if you could fix this!
Thanks in advance =)
|
On January 19 2011 10:11 sansalvador wrote:
May be a silly question, but what exactly does "mutation rate" change?
It's a function of the genetic algorithm that the program uses. Mutation rate affects how many changes it makes to each build order between each evolution. Basically it's just for me to play with and change the default - you shouldn't need to change it
On January 19 2011 10:25 funky247 wrote:
Hey I was wondering if you could fix the scouting worker feature... I'm trying to optimize protoss b/o's, and I set the scouting worker field to 9 and checked "dies" at 50. For some reason, the build order sends the scout out at 7 and kills it at 7 (evident when you look at the "Full" build order). I'd absolutely appreciate it if you could fix this!
Thanks in advance =)
The scouting worker is based on time, not supply. If you set it to go at 9 and die at 50 that means it'll move out at 9s and die at 50s.
|
On January 13 2011 15:18 CarbonTwelve wrote:Show nested quote +On January 13 2011 14:58 mlbrandow wrote:On January 13 2011 12:06 CarbonTwelve wrote:mlbrandow: here's a replay of a test I just did (again, apologies that it's on the older patch version): http://www.sc2replayed.com/replays/127175-1v1-terran-zerg-xelnaga-caverns#rd:buildorder* Drone 00:00:01 * Drone 00:00:15 * Drone 00:00:27 * Drone 00:00:36 * Extractor 00:00:46 * Drone 00:00:48 * Spawning Pool 00:01:16 You can see from the build order there that the pool was done at 1:16, only 2s behind what the app suggests, and in fact I had the minerals to build it a second earlier, just misplaced my drone a little. Compared to the app's timings, the first drone was 1s early, second drone 1.5s late, third drone 2s late, 4th drone 1s late, 5th drone same time, pool 2s late. I think the timings for that are close enough to be reasonably used. K i'll watch this. Must be something egregious I'm doing wrong. edit: wow, this is pretty enlightening. Can't believe how non-drone micro really can set you back so early. thanks for the reply, and glad to know it's me, not your program It's still only 4-5s, which really isn't much in the grand scheme of things, but certainly it's worth microing your drones if you can. Also note that I probably saved a second or two at the start because I could react faster to the game starting. I'm thinking about increasing the initial delay because I noticed a while ago that even in the GSL it still takes most pros ~4s to get the initial mining & worker build started.
I think I discovered why my pools are so much later.
More specifically than "drone micro", when i send my drones out, they will often just take any patch, and most often 2 of the 4 closest patches are on the edges. This means that at most I'm mining from only 2 "close" patches. Then, every mineral trip 2 of my workers take delays my extractor trick drone / pool by about 1.5-2 seconds from the added travel time. This ends up requiring an extra trip by the time I get to my pool.
Not that any of this pertains to your program, but I thought it would be interesting to note.
|
|
|
|
|
|
EPT
