For T, is there any way for the program to do a tech-lab switch?
For example, putting in 1 banshee does a refinery - barracks - factory - starport - tech lab - banshee build at 5:38 Building a tech lab at the factory and doing a tech lab switch should be faster.
Also, my system is getting a game rate of 28,000 overall, is this very slow?
On January 12 2011 13:43 falcoiii wrote: Awesome tool, just found it!
For T, is there any way for the program to do a tech-lab switch?
For example, putting in 1 banshee does a refinery - barracks - factory - starport - tech lab - banshee build at 5:38 Building a tech lab at the factory and doing a tech lab switch should be faster.
Not at the moment. It will be available in the next version though. Incidentally it only saves about 10s for the banshee build:
8 Refinery 8 Supply Depot 8 Barracks (Naked) 8 Move SCV To Gas 8 Move SCV To Gas 9 Move SCV To Gas 9 Factory (Naked) 10 Starport (Naked) 12 Barracks Tech Lab 13 Lift Starport (Naked) 13 Lift Barracks (Tech Lab) 13 Land Starport (Tech Lab) 13 Banshee 16 Orbital Command 16 Calldown MULE
Edit: Hmm, I wonder if it's not considering building the tech lab earlier, lifting off, then building the starport at the tech lab. Will need to look into that...
Edit 2: Yep, it wasn't considering building on an available tech lab. New build order for fast banshee:
8 Refinery 8 Supply Depot 8 Barracks (Naked) 8 Move SCV To Gas 8 Move SCV To Gas 8 Move SCV To Gas 9 Factory (Naked) 9 Barracks Tech Lab 9 Lift Barracks (Tech Lab) 9 Starport (on Tech Lab) 10 Banshee 13 Move SCV To Minerals 13 Move SCV To Minerals 13 Orbital Command 13 Move SCV To Gas 13 Move SCV To Gas
Thanks for the info - scary to know that banshees can be flying at 5:16 - at least it would only be on 19 supply. I look forward to the update.
My computer has Intel Core 2 Duo CPU T9550 @ 2.66 GHz. It has been running CPU intensive apps very slowly since the holidays, I think something is up with the OS.
On January 12 2011 22:30 falcoiii wrote: My computer has Intel Core 2 Duo CPU T9550 @ 2.66 GHz. It has been running CPU intensive apps very slowly since the holidays, I think something is up with the OS.
Yeah, definitely sounds like something is up. My laptop has a T9400 and gets ~200,000 games per second for most build orders.
But, for example, when doing 11 pool, the fastest I can get is around 1:45, and your program spits out 1:33. I don't have perfect micro, but I can't imagine I'm really 12 seconds slow less than 2 minutes into the game.
The build orders themselves have been incredibly useful, especially in refining my own ideas. However, I usually have to add 10-15 seconds to each build just because of the unfeasible pool timing.
I can imagine the build orders being 2-3s out, but based on personal testing I usually find that it's a lot closer than 10-15s, especially on something like the first building. Try testing on Very Slow so that your skill level doesn't affect the timings as much, and see if you can get it closer to the output's time.
The first is that even from the 2nd drone, there is a ~3 second lag time. I think if you factor reaction time and click accuracy time + divide the remainder among 3 drones on the far patches (travel distance) that roughly accounts for this time.
The second though is that it seems like your ETD doesn't stop mining, or travel time isn't factored, or something. It takes about a second for a cancel to give you drone control back, plus travel time both ways. (I notice in the build it waits for 75minerals to execute "ETD". In practice you'll send a drone about 65 minerals so as the extractor starts, you get 50 minerals to make drone instantly.)
The first error is probably just the standard CPU>Human lag, but the second seems like it should be amendable. Anything overpool timing past 1:20 I accept as being faster play human error on my part.
For gas income it assumes one geyser is close and one is far away.
But, for example, when doing 11 pool, the fastest I can get is around 1:45, and your program spits out 1:33. I don't have perfect micro, but I can't imagine I'm really 12 seconds slow less than 2 minutes into the game.
The build orders themselves have been incredibly useful, especially in refining my own ideas. However, I usually have to add 10-15 seconds to each build just because of the unfeasible pool timing.
I can imagine the build orders being 2-3s out, but based on personal testing I usually find that it's a lot closer than 10-15s, especially on something like the first building. Try testing on Very Slow so that your skill level doesn't affect the timings as much, and see if you can get it closer to the output's time.
I'll test it out at lunch. Won't be able to watch these replays though as I don't have the new version on my laptop yet :/
The first is that even from the 2nd drone, there is a ~3 second lag time. I think if you factor reaction time and click accuracy time + divide the remainder among 3 drones on the far patches (travel distance) that roughly accounts for this time.
The code does account for near/far patches in resource income rates.
The second though is that it seems like your ETD doesn't stop mining, or travel time isn't factored, or something. It takes about a second for a cancel to give you drone control back, plus travel time both ways. (I notice in the build it waits for 75minerals to execute "ETD". In practice you'll send a drone about 65 minerals so as the extractor starts, you get 50 minerals to make drone instantly.)
The code also does simulate the travel time, wait time while building the drone, and time travelling back to mining.
I'm trying to install this, but I'm getting an error mfc100u.dll is missing, though when I look in my registry it is right there. Anyone else get this?
I cant get this thing working, I had to download 2 DLL but I still have problems with second one, error message says (its right after I try to run app I downloaded):
The entrance point of procedure wmemcpy_s could not be found in associated MSVCR100.dll
(its my translation as I have located czech version of WinXP)
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.
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
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.
Is there anyway you can build in a "macro style" optimizer, at least for terran and protoss, where it's default that you will always be continuously building workers from all cc's/nexi till you hit saturation for 'n' bases, and the left over resources is what is used to calculate any other production?
It could just be a box that you check so that you can still use it for a fast as "all in" BO or macro style BO.
On January 13 2011 20:30 Qibla wrote: Is there anyway you can build in a "macro style" optimizer, at least for terran and protoss, where it's default that you will always be continuously building workers from all cc's/nexi till you hit saturation for 'n' bases, and the left over resources is what is used to calculate any other production?
It could just be a box that you check so that you can still use it for a fast as "all in" BO or macro style BO.
You can already check the 'constant probe/scvs' checkbox and it will make sure that it avoids nexus/command center idle time. There's a constant drone checkbox as well, but that doesn't do anything atm (still haven't decided how I want to implement that).
Thanks for making this software. Already served me well in optimizing an early push opening build.
It would be nice to have the Nydus Worm as a building option next to the Nydus Network. Would help in knowing how to fastest enter the enemy base by underground with a certain unit composition.
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.
Hi Carbon thanks for making this cool program it's pretty interesting to see what builds the algorithm can find. I'm trying to do a evolving AI for BW so I know it's pretty difficult to do this sort of stuff.