|
On December 07 2010 05:33 insectoceanx wrote:
There are a lot of posts in this thread so sorry if I missed the answer to my question but i cannot figure out how to do this or if it is possible. Say I knew i wanted to push out with 2 dt and a warp prism at 7:30 game time, but i also want to maximize my production of stalkers that i can get out but still have 2 dt and 1 warp prism at 7:30. Is there any way to do this without me playing around with how many zealots + stalkers to build as well.
If you cannot do this it would seem like an extremely useful function but probably hard to program and take longer to calculate. A way maybe to be able to do this is unit ratios.
Say I want my 2 dt and 1 warp prism and a ratio of 3 stalkers to 1 zealot. Then it figures out what the most stalkers + zealots it can make at that ratio while still fulfilling my requirement of 2dt and 1 warp prism.
It might be possible at some point to set a target time and have it get as many of a particular unit as possible by that time, however the ratio thing would be very difficult to both implement and have the user specify, so I'm not sure if that will happen.
I havnt looked at all the fixes yet, but it seems like you didn't recompile after fixing some of them ( constant probes is still constant probes for me) unless i am the changlog wrong.
The released missed a fix for Nitro packs, but I'm fairly sure everything else is there. I just got 7.3 from GoogleCode and tested the constant probes, and sure enough it's working as intended. You can see this by comparing something like a 5 stalker build both with and without constant probes, and you'll see that with it it prevents the nexus from ever being idle (except when supply capped at 10 for a short period - unavoidable).
And the implementation with sc2gears seems like a really great idea. Since SC2Gears can share and import replays from around the world now. A really great tool and perhaps the easiest way to use both tools together was if you could compare the builds recorded side by side in terms of units/buildings/upgrades. That way you can have a better idea how your build will stack up against any opening your opponent might do.
It'll mostly be up to them I think. They'll need to add a way to import build orders into their app. Once that's done, then I should be able to get an output from my app to match the input for theirs.
Take in mind i know very little (nothing) about programming. If they have some kind of standard for importing builds into program or you could simulate a replay file that just contains the orders necessary for the build.
Simulating a replay file is not going to happen unfortunately. There's way too much detail in there that just doesn't match what my program is telling you. What might be a better approach is to have the YABOT format be an output in my app (working on it atm) and then have YABOT use the AI to perform the build, and then you could use a replay of that to import into SC2 Gears.
For PvP I have included a picture of Ddoro's build that he beat me down with(and me a poor little platinum) when in played him in a tourney. ![[image loading]](http://files.shroomery.org/files/10-49/167313011-Untitled.jpg)
Hmm... I'm at work atm, and our filter is blocking that from me saying that the category 'Illegal Drugs' is not permitted 
|
On December 07 2010 07:13 Black Gun wrote:
what does the target field mean? game time in seconds?
Yes.
and where can we control how many tries the algorithm performs?
You can't. I might add a way for it to stop processing once it reaches a certain completion percentage though (something like 80%).
also, is there a way to include expansions? (probably not, but would be super cool^^)
Every extra Nexus/Hatchery/Command Center that's built is presumed to be at an expansion, and it will adjust the income rates assuming that's the case.
and could u maybe explain what the effect of the mutation rate is? ie, what are the pros and cons of for example increasing it from the default 0.3 to 0.5?
Mutation rate affects the way the genetic algorithm works. Every evolution the previous generation mutates. If it mutates faster, it'll likely get to something useful a lot quicker, however at the same time it will struggle to make the finer adjustments that are needed once you're close to the right build order. It's mainly there for my own tweaking, so I suggest leaving it at the default.
|
On December 07 2010 07:27 CarbonTwelve wrote:Show nested quote +On December 07 2010 07:13 Black Gun wrote:
what does the target field mean? game time in seconds? Yes. You can't. I might add a way for it to stop processing once it reaches a certain completion percentage though (something like 80%). Show nested quote +also, is there a way to include expansions? (probably not, but would be super cool^^) Every extra Nexus/Hatchery/Command Center that's built is presumed to be at an expansion, and it will adjust the income rates assuming that's the case. Show nested quote +and could u maybe explain what the effect of the mutation rate is? ie, what are the pros and cons of for example increasing it from the default 0.3 to 0.5? Mutation rate affects the way the genetic algorithm works. Every evolution the previous generation mutates. If it mutates faster, it'll likely get to something useful a lot quicker, however at the same time it will struggle to make the finer adjustments that are needed once you're close to the right build order. It's mainly there for my own tweaking, so I suggest leaving it at the default.
thanks for the answers and thx again for the awesome prog. i guess certain subtleties are not accounted for, like for example the income loss while maynarding workers to the expo?
btw what does the field "target" in the settings menu stand for? it defaults at 1200 while the target field in the target menu defaults at 1500.
|
On December 07 2010 07:36 Black Gun wrote:
thanks for the answers and thx again for the awesome prog. i guess certain subtleties are not accounted for, like for example the income loss while maynarding workers to the expo?
Most little things like that are (ie, travel time for building buildings), but maynarding workers to expos isn't because atm it doesn't track the number of workers at each expansion. I plan to fix that up sometime soon though.
btw what does the field "target" in the settings menu stand for? it defaults at 1200 while the target field in the target menu defaults at 1500.
The target time for the waypoints is when it needs to achieve that waypoint by (with the last waypoint just being as fast as possible). The time in the settings is a limit such that it will stop processing build orders if they go longer than that time.
|
hmm, an idea i just had: imho it would be great if u could implement a feature to let us, the users, perform specific mutations. this way, we could help the algorithm out when it has obviously become stuck and its also obvious where it got stuck.
for example, i just had the script compute the optimal build order for 6 thors, 2 ghosts and 30 marines with constant scvs and 2 orbitals. the second cc gets built quite early on, but the 2nd orbital gets ordered just moments before the bo is finished. now, i had a quick look at the current bo and immediately saw that it was mineral bound at some point in time. there was a delay with constructing the final thor which was due to mineral shortage. it is obvious that constructing the 2nd orbital earlier would help, but it took the algorithm almost 10 minutes to figure this out.
|
On December 07 2010 10:24 Black Gun wrote:
hmm, an idea i just had: imho it would be great if u could implement a feature to let us, the users, perform specific mutations. this way, we could help the algorithm out when it has obviously become stuck and its also obvious where it got stuck.
for example, i just had the script compute the optimal build order for 6 thors, 2 ghosts and 30 marines with constant scvs and 2 orbitals. the second cc gets built quite early on, but the 2nd orbital gets ordered just moments before the bo is finished. now, i had a quick look at the current bo and immediately saw that it was mineral bound at some point in time. there was a delay with constructing the final thor which was due to mineral shortage. it is obvious that constructing the 2nd orbital earlier would help, but it took the algorithm almost 10 minutes to figure this out.
from reading the description and using it.. it sounds like it uses a system of sorting methods to place the best possible *thing* first, followed by second best, etc....
so thats probably why it took 10 minutes to realize "Oh, this should go here" kinda thing
|
On December 07 2010 10:24 Black Gun wrote:
hmm, an idea i just had: imho it would be great if u could implement a feature to let us, the users, perform specific mutations. this way, we could help the algorithm out when it has obviously become stuck and its also obvious where it got stuck.
for example, i just had the script compute the optimal build order for 6 thors, 2 ghosts and 30 marines with constant scvs and 2 orbitals. the second cc gets built quite early on, but the 2nd orbital gets ordered just moments before the bo is finished. now, i had a quick look at the current bo and immediately saw that it was mineral bound at some point in time. there was a delay with constructing the final thor which was due to mineral shortage. it is obvious that constructing the 2nd orbital earlier would help, but it took the algorithm almost 10 minutes to figure this out.
It's very difficult to implement a way in the GUI to allow this to happen, especially while the algorithm is running. Instead it just suggests to me that I need to tweak the incentives for things like orbital commands, queens, warpgates, etc. (which is something I've known I need to do and have plans for doing soon).
|
On December 07 2010 11:23 CarbonTwelve wrote:Show nested quote +On December 07 2010 10:24 Black Gun wrote:
hmm, an idea i just had: imho it would be great if u could implement a feature to let us, the users, perform specific mutations. this way, we could help the algorithm out when it has obviously become stuck and its also obvious where it got stuck.
for example, i just had the script compute the optimal build order for 6 thors, 2 ghosts and 30 marines with constant scvs and 2 orbitals. the second cc gets built quite early on, but the 2nd orbital gets ordered just moments before the bo is finished. now, i had a quick look at the current bo and immediately saw that it was mineral bound at some point in time. there was a delay with constructing the final thor which was due to mineral shortage. it is obvious that constructing the 2nd orbital earlier would help, but it took the algorithm almost 10 minutes to figure this out. It's very difficult to implement a way in the GUI to allow this to happen, especially while the algorithm is running. Instead it just suggests to me that I need to tweak the incentives for things like orbital commands, queens, warpgates, etc. (which is something I've known I need to do and have plans for doing soon).
some other thing u really need to work on imho is to allow the user to specify the maximum number of bases. i was just letting it search for the best bo to get to 8 thors, 2 ghosts and 30 marines. the moment i removed the constant scv production requirement, it came up with a 16 orbital 16 cc 18 cc build... ie double expanding off of zero marines while cutting scvs to do so. a completely unfeasible build.
so in other words, the only thing that prevents it from coming up with such "stupid" builds when searching for bos that are quite long is the constant scv production.
it would be even better if we could specify timing windows in which cutting scv production is allowed. its very complicated to get a manual work around with exact worker numbers on different waypoints. 
|
On December 07 2010 13:12 Black Gun wrote:
some other thing u really need to work on imho is to allow the user to specify the maximum number of bases. i was just letting it search for the best bo to get to 8 thors, 2 ghosts and 30 marines. the moment i removed the constant scv production requirement, it came up with a 16 orbital 16 cc 18 cc build... ie double expanding off of zero marines while cutting scvs to do so. a completely unfeasible build.
I'm planning to implement maximums for all buildings and units. It's a couple of versions away though (will probably switch to a cross platform GUI before then).
so in other words, the only thing that prevents it from coming up with such "stupid" builds when searching for bos that are quite long is the constant scv production.
I don't think that's the only thing. There's no way for the algorithm to magically know how much defense you need at any particular point, so if you know what you need, you should specify it with waypoints.
it would be even better if we could specify timing windows in which cutting scv production is allowed. its very complicated to get a manual work around with exact worker numbers on different waypoints.
Again, this is something that's rather difficult to implement a GUI for, as well as for the algorithm to achieve it. I also odn't think it would eliminate manual work arounds as you'd instead have to start tweaking the timing windows to get the result you're after. I don't think you're ever going to be able to do what you're after, which is basically plug in numbers of what you want to end up with and have it somehow know what the best times to get them are along the way so you've got enough defense.
|
On December 07 2010 13:45 CarbonTwelve wrote:
Again, this is something that's rather difficult to implement a GUI for, as well as for the algorithm to achieve it. I also odn't think it would eliminate manual work arounds as you'd instead have to start tweaking the timing windows to get the result you're after. I don't think you're ever going to be able to do what you're after, which is basically plug in numbers of what you want to end up with and have it somehow know what the best times to get them are along the way so you've got enough defense.
i agree that most of the stuff i was asking for might not be possible, but i think u misunderstood me on the timing windows for cutting scvs. for any bo that goes beyond the ~8 minute mark, there is a world of a difference between constant scv production and none. if u dont require constant scv production, the build then usually comes up with some 17-24 scv builds which optimize the time till the desired unit comp is reached, but are all-in in the sense that if the attack fails, ur eco will be way way behind because of all the scv cutting.
on the other hand, it might be very nice for many builds to allow temporary scv cutting. like for example after the orbital is in construction, cut scvs to put down a 16 cc at ur natural or something like that. the requirement of constant scv production can be very restrictive, but at the same time, the algorithm`s strong tendecy to fall into "mass worker cutting "-all-ins if we dont require constant scvs makes it very very hard to lessen the restrictiveness of this constant scv production while still maintaining an economically stable bo.
but i guess im just an extremely demanding customer and should be satisfied with the (nonetheless really great) tool u provided us.
|
On December 07 2010 14:17 Black Gun wrote:
i agree that most of the stuff i was asking for might not be possible, but i think u misunderstood me on the timing windows for cutting scvs. for any bo that goes beyond the ~8 minute mark, there is a world of a difference between constant scv production and none. if u dont require constant scv production, the build then usually comes up with some 17-24 scv builds which optimize the time till the desired unit comp is reached, but are all-in in the sense that if the attack fails, ur eco will be way way behind because of all the scv cutting.
on the other hand, it might be very nice for many builds to allow temporary scv cutting. like for example after the orbital is in construction, cut scvs to put down a 16 cc at ur natural or something like that. the requirement of constant scv production can be very restrictive, but at the same time, the algorithm`s strong tendecy to fall into "mass worker cutting "-all-ins if we dont require constant scvs makes it very very hard to lessen the restrictiveness of this constant scv production while still maintaining an economically stable bo.
Again, I'm not sure how to implement what you're asking for (actually, I'm not even sure what you're asking for atm). To put it simply, what would you expect to type in for the GUI, and where would you put it?
|
On December 07 2010 14:36 CarbonTwelve wrote:Show nested quote +On December 07 2010 14:17 Black Gun wrote:
i agree that most of the stuff i was asking for might not be possible, but i think u misunderstood me on the timing windows for cutting scvs. for any bo that goes beyond the ~8 minute mark, there is a world of a difference between constant scv production and none. if u dont require constant scv production, the build then usually comes up with some 17-24 scv builds which optimize the time till the desired unit comp is reached, but are all-in in the sense that if the attack fails, ur eco will be way way behind because of all the scv cutting.
on the other hand, it might be very nice for many builds to allow temporary scv cutting. like for example after the orbital is in construction, cut scvs to put down a 16 cc at ur natural or something like that. the requirement of constant scv production can be very restrictive, but at the same time, the algorithm`s strong tendecy to fall into "mass worker cutting "-all-ins if we dont require constant scvs makes it very very hard to lessen the restrictiveness of this constant scv production while still maintaining an economically stable bo. Again, I'm not sure how to implement what you're asking for (actually, I'm not even sure what you're asking for atm). To put it simply, what would you expect to type in for the GUI, and where would you put it?
the waypoints are having a field to specify the time of that waypoint and their own constant worker production field. it would be nice to have the "constant scvs"-field on the waypoint´s menus replaced with "constant scvs from last waypoint until this waypoint". this way, it would be easy to allow for some scv cutting early on to achieve certain FE or fast tech goals, but have a reasonably strong economy later on. its very hard to get the same results by manually specifying scv counts for these later stages, in particular as they are problematic when the algorithm compares for example 2 base vs 3 base.
but plz dont consider my suggestions or ideas as criticism, it isnt meant like that. i absolutely understand that those longer, more sophisticated bo´s im trying out have a drastically higher complexity both in the runtime and in the gui. at least when compared to the rather simple tasks most other users are porbably using this prog for, like "whats the fasted i can get out a bc" or "how many roaches can i get out by the 8 minute mark".
|
|
|
On December 07 2010 15:00 Black Gun wrote:
the waypoints are having a field to specify the time of that waypoint and their own constant worker production field. it would be nice to have the "constant scvs"-field on the waypoint´s menus replaced with "constant scvs from last waypoint until this waypoint". this way, it would be easy to allow for some scv cutting early on to achieve certain FE or fast tech goals, but have a reasonably strong economy later on. its very hard to get the same results by manually specifying scv counts for these later stages, in particular as they are problematic when the algorithm compares for example 2 base vs 3 base.
Ah, ok, yes, that can be easily done, and I was planning to do that Doesn't really make sense to have constant SCVs on each waypoint if specifying the option differently for each one doesn't change anything
but plz dont consider my suggestions or ideas as criticism, it isnt meant like that. i absolutely understand that those longer, more sophisticated bo´s im trying out have a drastically higher complexity both in the runtime and in the gui. at least when compared to the rather simple tasks most other users are porbably using this prog for, like "whats the fasted i can get out a bc" or "how many roaches can i get out by the 8 minute mark".
Nah, not at all - I welcome all suggestions, just that (and please don't take offence, and that goes for anyone making suggestions) as a programmer you regularly find that users have an idea of what they want the program to do, but don't really think through how it would actually work, or (naturally) don't understand what programming is like and hence what is feasible and what isn't. As such it always pays to discuss requests in detail before trying to go ahead with something and find out what they were actually after is something completely different.
As above though, I get what you're after (constant workers should apply from the previous waypoint onwards, not from the start onwards), and I'll try to get onto that soon.
|
|
|
On December 07 2010 15:18 CarbonTwelve wrote:
Then select the race you want, enter what units you want it to get, click start and it will start running and give you the build order to get you what you asked for as fast as possible. Depending on how complicated it is, it may take a while to get to the best build order - use the Completion Likelihood percentage as an indicator (once it gets to 80+% you can feel pretty confident that it's got the best result).
hmmm.... a minor suggestion: u should write "completion likelihood" instead of "completion" in the gui. until i read the quoted explanation of yours, i thought the completion field in the gui was a (deterministic) countdown until a preset maximum number of iterations without improvement has passed. (although.... would any1 besides me even care about this distinction? XD)
|
On December 07 2010 15:22 Black Gun wrote:Show nested quote +On December 07 2010 15:18 CarbonTwelve wrote:
Then select the race you want, enter what units you want it to get, click start and it will start running and give you the build order to get you what you asked for as fast as possible. Depending on how complicated it is, it may take a while to get to the best build order - use the Completion Likelihood percentage as an indicator (once it gets to 80+% you can feel pretty confident that it's got the best result). hmmm.... a minor suggestion: u should write "completion likelihood" instead of "completion" in the gui. until i read the quoted explanation of yours, i thought the completion field in the gui was a (deterministic) countdown until a preset maximum number of iterations without improvement has passed. (although.... would any1 besides me even care about this distinction? XD)
Umm, the GUI does say "Completion likelihood"
|
I was looking at what the fastest 3 warpgate, 3 dt build would be and the program came up with the following build. I am going to try the build out after the GSL tonight and see how bad my macro/micro butchers the directions. However, the following caught my eye. 7 probes on 2 gasses with no probes being pulled from gas.
+ 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
0:54.04: 50M 0G 4E 9/ 10S - Build Probe
1:16.58: 150M 0G 17E 10/ 18S - Build Gateway
1:24.45: 50M 0G 21E 10/ 18S - Build Probe
1:30.89: 44M 0G 25E 11/ 18S - Chrono Nexus
1:35.24: 75M 0G 2E 11/ 18S - Build Assimilator
1:42.44: 50M 0G 6E 11/ 18S - Build Probe
1:52.00: 75M 0G 12E 12/ 18S - Build Assimilator
1:58.61: 50M 0G 16E 12/ 18S - Build Probe
2:05.24: 57M 0G 19E 13/ 18S - Move Probe To Gas
2:05.24: 57M 0G 19E 13/ 18S - Move Probe To Gas
2:05.24: 57M 0G 19E 13/ 18S - Move Probe To Gas
2:21.58: 164M 27G 29E 13/ 18S - Build Cybernetics Core
2:21.58: 14M 27G 29E 13/ 18S - Move Probe To Gas
2:21.58: 14M 27G 29E 13/ 18S - Move Probe To Gas
2:21.58: 14M 27G 29E 13/ 18S - Move Probe To Gas
2:30.02: 50M 54G 33E 13/ 18S - Build Probe
2:30.02: 0M 54G 33E 14/ 18S - Chrono Nexus
2:41.35: 55M 95G 15E 14/ 18S - Build Probe
2:54.02: 75M 140G 22E 15/ 18S - Build Probe
2:59.78: 60M 161G 25E 16/ 18S - Chrono Nexus
3:13.49: 150M 210G 8E 16/ 18S - Build Twilight Council
3:13.49: 0M 110G 8E 16/ 18S - Move Probe To Gas
3:22.41: 50M 143G 13E 16/ 18S - Build Probe
3:30.41: 50M 174G 17E 17/ 18S - Research Warp Gate Transformation
4:03.63: 228M 250G 36E 17/ 18S - Build Dark Shrine
4:07.16: 150M 13G 38E 17/ 18S - Build Gateway
4:30.03: 150M 100G 51E 17/ 18S - Build Gateway
4:37.90: 50M 130G 55E 17/ 18S - Build Probe
4:37.90: 0M 130G 55E 18/ 18S - Chrono Cybernetics Core
4:52.21: 100M 185G 38E 18/ 18S - Build Pylon
4:57.90: 37M 206G 41E 18/ 18S - Chrono Cybernetics Core
5:30.41: 289M 330G 35E 18/ 26S - Convert Gateway To Warp Gate
5:30.41: 289M 330G 35E 18/ 26S - Convert Gateway To Warp Gate
5:30.41: 289M 330G 35E 18/ 26S - Move Probe To Minerals
5:35.03: 327M 346G 37E 18/ 26S - Convert Gateway To Warp Gate
5:35.03: 327M 346G 37E 18/ 26S - Chrono Gateway
5:43.63: 401M 377G 17E 18/ 26S - Build Dark Templar
5:43.63: 276M 252G 17E 20/ 26S - Build Dark Templar
5:43.63: 151M 127G 17E 22/ 26S - Build Dark Templar
---edit--- I looked at my post and don't want to come off as an ungrateful freeloader...
Your build order/optimizer is amazing. Thanks for the hard work!
|
On December 07 2010 07:27 CarbonTwelve wrote:
Every extra Nexus/Hatchery/Command Center that's built is presumed to be at an expansion, and it will adjust the income rates assuming that's the case.
Can you set up an option for having the extra nexus/hatchery/command center inside your own base? That is to say, that all the building can do is call down mule/chrono boost/spawn larvae?
|
On December 07 2010 17:47 conboy31 wrote:
I was looking at what the fastest 3 warpgate, 3 dt build would be and the program came up with the following build. I am going to try the build out after the GSL tonight and see how bad my macro/micro butchers the directions. However, the following caught my eye. 7 probes on 2 gasses with no probes being pulled from gas.
This is expected. My income rates are based on Piousflea's measurements: http://www.teamliquid.net/forum/viewmessage.php?topic_id=140055
According to that, some geysers require 4 workers. At the moment my code assumes your base has 1 close geyser and 1 far away, so for build orders that are very heavy on gas (such as DTs) you'll find it will choose to put 7 workers on gas.
---edit--- I looked at my post and don't want to come off as an ungrateful freeloader...
Your build order/optimizer is amazing. Thanks for the hard work!
Nah, honestly, every post I get makes me feel good, especially those that are reporting issues as it means people are using my app
On December 07 2010 18:09 ThrustVectoring wrote:
Can you set up an option for having the extra nexus/hatchery/command center inside your own base? That is to say, that all the building can do is call down mule/chrono boost/spawn larvae?
I can probably set something like that up. It would have to be specifically requested though as the algorithm is never going to choose to do it on its own (as far as its concerned, why build in your own base when you can get an expo for extra income?).
|
|
|
|
|
|
EPT
