EPTSCFusion - WoL, HotS & LotV Build Order Optimizer - Page 61
| Forum Index > SC2 General |
|
pwei
United States62 Posts
| ||
|
Szei
United States10 Posts
| ||
|
SlyBeetle
Belarus38 Posts
Reaper needs 2 food. | ||
|
CarbonTwelve
Australia525 Posts
Enhancements: Saving/loading: build orders (along with their settings & requirements) can now be saved & loaded as XML files. Bug Fixes: Gas Micro option "Three when geyser ready" now works. Creep Tumors no longer cause an infinite loop. Starport Tech Lab research for WoL fixed. Reapers now require 1 supply, rather than 2. Waypoints that are already complete no longer require an intermediate command or event to be marked complete. | ||
|
FlyingBeer
United States262 Posts
A few simple things: Defaulting to a maximum of 1 for certain buildings at all stages (baneling nest, roach warren, twilight council, dark shrine, fusion core) Defaulting to a maximum of 2 for other buildings (spire, engineering bay, cybernetics core) Setting the gas to be no more than 2b+2 where b is the number of bases Something more complex: A group of build orders with lots of waypoints and targets that you use for benchmarking whether a change in the algorithm improves search times. You then run these up to say, 20,000,000 games and see if the new algorithm gets you a faster time than the older algorithm. Taking whatever requirements are met in the last 5 seconds of the build order, and searching for ways to get that to finish earlier first Targeted items that take longer to construct/research (like +1 attack) should be preferred over things that take less time to construct (like units) Targeted items that are required for a lot of later targeted items should be preferred over items that are required for fewer items (So if I'm trying to get to 3-3, it should know to get double upgrades going as early as possible) | ||
|
CarbonTwelve
Australia525 Posts
On April 15 2013 05:24 FlyingBeer wrote: Defaulting to a maximum of 1 for certain buildings at all stages (baneling nest, roach warren, twilight council, dark shrine, fusion core) Defaulting to a maximum of 2 for other buildings (spire, engineering bay, cybernetics core) Setting the gas to be no more than 2b+2 where b is the number of bases The older version used to do this sort of thing, but the problem is that with each requirement added it directly affects the performance of the app (almost linearly). A group of build orders with lots of waypoints and targets that you use for benchmarking whether a change in the algorithm improves search times. You then run these up to say, 20,000,000 games and see if the new algorithm gets you a faster time than the older algorithm. It already effectively does this via the villages. Taking whatever requirements are met in the last 5 seconds of the build order, and searching for ways to get that to finish earlier first Again, it already does this by optimising the value of the first waypoint it fails. Targeted items that take longer to construct/research (like +1 attack) should be preferred over things that take less time to construct (like units) I intend to be able to customise the 'value' of each target, but as a default I think either the cost of the target or the time required for it could be good choices. Targeted items that are required for a lot of later targeted items should be preferred over items that are required for fewer items (So if I'm trying to get to 3-3, it should know to get double upgrades going as early as possible) Unfortunately it is very difficult to implement this sort of calculation in a generic way. | ||
|
Lizarb
Denmark307 Posts
| ||
|
Lucy1nTheSky
39 Posts
| ||
|
natee
4 Posts
I have one question about completion % - The builds that I get from your program work well for me, but even when I let it run overnight I can rarely get a % above 30-40, with 80% being the highest ive ever gotten. Is this just because there are too many variables to consider, or what? | ||
|
CarbonTwelve
Australia525 Posts
On April 16 2013 14:22 natee wrote: I have one question about completion % - The builds that I get from your program work well for me, but even when I let it run overnight I can rarely get a % above 30-40, with 80% being the highest ive ever gotten. Is this just because there are too many variables to consider, or what? The "completion %" is actually "completion likelihood". This is not a deterministic / optimum-finding algorithm, so there is no way to guarantee that all possible builds have been tested to know that the build presented is the best. The "completion likelihood" is just a rough estimate for whether it thinks it has probably found the optimal build, and this is based on how long it has been since it found an improvement, compared to the total time spent looking for an improvement. Basically it should just be used as a guide, not a strict figure to follow. Besides, it caps out at "> 90%" to indicate that it will never be 100% complete. | ||
|
graNite
Germany4434 Posts
when i set the target "supply: minimum 50" he gets 45 scvs (builds 39+6 starting scvs), no other units and tells me he is on 50 supply?! //edit: found the problem the unit counter doesnt show what is still in production, but units that are being built count as supply. | ||
|
CarbonTwelve
Australia525 Posts
On April 16 2013 14:41 graNite wrote: there is something wrong with the supply. when i set the target "supply: minimum 50" he gets 45 scvs (builds 39+6 starting scvs), no other units and tells me he is on 50 supply?! The supply requirement is tied to the supply as displayed in-game (top right). So as soon as you start building something the supply is consumed, and included in that calculation. I think you'll find the build order actually starts building 44 scvs, and just doesn't wait for them all to be completed before stating the build order is complete (and it does indicate that 50 supply is consumed): + Show Spoiler + 0:02.00: 50M 0G 6/ 11S - Build SCV 0:19.00: 73M 0G 7/ 11S - Build SCV 0:36.00: 106M 0G 8/ 11S - Build SCV 0:53.00: 150M 0G 9/ 11S - Build SCV 0:53.03: 100M 0G 10/ 11S - Build Supply Depot 1:10.00: 91M 0G 10/ 11S - Build SCV 1:27.00: 147M 0G 11/ 19S - Build SCV 1:44.00: 228M 0G 12/ 19S - Build SCV 2:01.00: 323M 0G 13/ 19S - Build SCV 2:14.89: 400M 0G 14/ 19S - Build Command Center 2:21.15: 50M 0G 14/ 19S - Build SCV 2:38.15: 146M 0G 15/ 19S - Build SCV 2:55.15: 259M 0G 16/ 19S - Build SCV 3:12.15: 387M 0G 17/ 19S - Build SCV 3:29.15: 526M 0G 18/ 19S - Build SCV 3:29.15: 476M 0G 19/ 19S - Build Macro Command Center 3:54.89: 351M 0G 19/ 30S - Build SCV 3:54.89: 301M 0G 20/ 30S - Build SCV 4:07.20: 400M 0G 21/ 30S - Build Command Center 4:11.89: 53M 0G 21/ 30S - Build SCV 4:15.86: 50M 0G 22/ 30S - Build SCV 4:28.89: 165M 0G 23/ 30S - Build SCV 4:32.86: 167M 0G 24/ 30S - Build SCV 4:45.89: 307M 0G 25/ 30S - Build SCV 4:49.86: 318M 0G 26/ 30S - Build SCV 4:57.96: 400M 0G 27/ 30S - Build Command Center 5:02.89: 74M 0G 27/ 30S - Build SCV 5:06.86: 85M 0G 28/ 30S - Build SCV 5:09.15: 71M 0G 29/ 41S - Build SCV 5:19.89: 202M 0G 30/ 41S - Build SCV 5:23.86: 221M 0G 31/ 41S - Build SCV 5:26.15: 212M 0G 32/ 41S - Build SCV 5:36.89: 372M 0G 33/ 41S - Build SCV 5:40.86: 402M 0G 34/ 41S - Build SCV 5:43.15: 399M 0G 35/ 41S - Build SCV 5:47.20: 436M 0G 36/ 52S - Build SCV 5:53.89: 535M 0G 37/ 52S - Build SCV 5:57.86: 577M 0G 38/ 52S - Build SCV 6:00.15: 581M 0G 39/ 52S - Build SCV 6:04.20: 631M 0G 40/ 52S - Build SCV 6:10.89: 752M 0G 41/ 52S - Build SCV 6:14.86: 806M 0G 42/ 52S - Build SCV 6:17.15: 817M 0G 43/ 52S - Build SCV 6:21.20: 878M 0G 44/ 52S - Build SCV 6:27.89: 1016M 0G 45/ 52S - Build SCV 6:31.86: 1080M 0G 46/ 52S - Build SCV 6:34.15: 1097M 0G 47/ 52S - Build SCV 6:37.96: 1162M 0G 48/ 63S - Build SCV 6:38.20: 1119M 0G 49/ 63S - Build SCV Waypoint 1 satisfied: 6:38.20: 1069M 0G 50/ 63S Income: 1839M 0G Buildings: 5 Command Center 1 Supply Depot Units: 45 SCV Research: | ||
|
TexSC
United States195 Posts
Here is a bit of my input.
Thank you again, I'll be checking back regularly! | ||
|
CarbonTwelve
Australia525 Posts
On April 18 2013 14:04 TexSC wrote: Crash - Sometimes opening a saved build order crashes the program. In general, something simple like 1 barracks saves and loads fine. But, putting in 150 for marines, starting, waiting until satisfied, stopping, saving, closing SCFusion, opening SCFusion, and loading crashes the program. I'm on windows 7 64 bit. Here is the error: + Show Spoiler + Problem signature: Problem Event Name: APPCRASH Application Name: SCFusion.exe Application Version: 1.0.12.1 Application Timestamp: 5167b444 Fault Module Name: MSVCR100.dll Fault Module Version: 10.0.40219.325 Fault Module Timestamp: 4df2be1e Exception Code: c0000005 Exception Offset: 00010a5d OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 Any chance you could upload the saved file that causes the crash when loading? Suggestion - add option to ignore lifting/landing of buildings. I often see build orders where a production facility is idle and it adds in a bunch of lift/land requests. It doesn't change the time, but it adds a lot to the build order, and can waste time in calculations. It's using this to delay something for some benefit (eg, to delay gas a bit longer). This can be avoided with the wait commands (under Settings -> Allow Wait Commands). Suggestion - add an option to use gold bases. This could be neat for tricky openings! It's certainly something I can look into. There are a lot of combinations of map differences though, and it's not easy to represent them all in the Version XML. Suggestion - add an option to include a walk time for a builder to build a building, particularly (or just a) new expansion. For example, a gold base may be a 30 second walk away. Or, getting a fast expansion timing down perfectly. Travel time is already included in the calculations. | ||
|
grigorin
Austria275 Posts
| ||
|
Moobla
United States186 Posts
| ||
|
mechengineer123
Ukraine711 Posts
| ||
|
Executerror
New Zealand28 Posts
| ||
|
graNite
Germany4434 Posts
On April 22 2013 02:12 Executerror wrote: Crashing when set to "Full Micro" or "Three back & forth" on gas micro. Could anyone explain the difference between "three to gas only" and "three when geyser ready"? Explanation for all gas micro's would be more helpful. Thanks. three to gas only means if you are mining gas, you will send three workers in and pull three workers out if you dont need to mine. three when geyser ready means you wont out them in one by one to be more efficient, but onyl three once the refinery is done. no pulling out. | ||
|
Rainman5419
United States92 Posts
Notice the first Gateway Chrono | ||
| ||
