SCFusion - WoL, HotS & LotV Build Order Optimizer - Page 32

On December 08 2010 14:51 Tiutababo wrote:
Awesome program.

Is it possible to add inbase OC as an addtional terran building, so that the program will consider building those for extra income (mules) and extra supply?

It already does that. Most buildings built cause a probe to be pulled off the mineral line for 10s (I think assimilators it's 4s, and nexi 30s).

On December 09 2010 11:06 Fuchsia.tude wrote:
The new output formats are nice. It makes the duplicate lines even more stark, though -- instead of printing

52 Move Probe to Gas
52 Move Probe to Gas
52 Move Probe to Gas

or

36 Stalker
38 Stalker

why not just say 52 Move Probe to Gas x3, or 36 Stalker (x2)?

Also, it might be nice to have some disambiguation between multiples of structures, like

50 Stargate (1)
50 Stargate (2)
...
50 Carrier (Stargate 1)
56 Carrier (Stargate 2)
...
67 Chrono Stargate (1)
67 Chrono Stargate (2)
70 Chrono Stargate (1)

On December 09 2010 11:22 CarbonTwelve wrote:


I'd like to do that, and probably will, just that it's actually a little more complicated than you might think :/ Might look into it more after the GUI change.

On December 09 2010 13:17 Bartlett wrote:
It might be something you only do at the log/display level as I can appreciate that its all individual lines so that the app can mutate and optimise away (when it moves a single probe to gas/minerals).

Having the log parser recognise duplicate lines and add a x multiplier I am thinking would make for the simplest of changes and as such it would probably only work for simple format. Detail and Full can sometimes have a vary slight differentiation in time that would throw a basic comparison out of whack.

On December 09 2010 19:49 icezar wrote:
0:02.00: 50M 0G 3L 0L 0L 0E 6/ 10S - Build Drone
0:02.00: 0M 0G 2L 0L 0L 0E 7/ 10S - (Larva Spawned)
0:13.63: 50M 0G 3L 0L 0L 0E 7/ 10S - Build Drone
0:19.00: 23M 0G 2L 0L 0L 0E 8/ 10S - (Drone Completed)
0:24.83: 50M 0G 2L 0L 0L 0E 8/ 10S - Build Drone
0:28.63: 19M 0G 1L 0L 0L 0E 9/ 10S - (Larva Spawned)
0:30.63: 29M 0G 2L 0L 0L 0E 9/ 10S - (Drone Completed)
0:34.78: 50M 0G 2L 0L 0L 0E 9/ 10S - Build Drone
0:41.83: 39M 0G 1L 0L 0L 0E 10/ 10S - (Drone Completed)
0:43.63: 50M 0G 1L 0L 0L 0E 10/ 10S - (Larva Spawned)
0:47.78: 75M 0G 2L 0L 0L 0E 10/ 10S - Extractor Trick Drone
0:49.78: 11M 0G 1L 0L 0L 0E 10/ 10S - (Extractor Trick Finished)
0:51.78: 41M 0G 1L 0L 0L 0E 11/ 10S - (Drone Completed)
0:58.63: 88M 0G 1L 0L 0L 0E 11/ 10S - (Larva Spawned)
1:00.35: 100M 0G 2L 0L 0L 0E 11/ 10S - Build Overlord
1:05.78: 39M 0G 1L 0L 0L 0E 11/ 10S - (Drone Completed)
1:13.63: 98M 0G 1L 0L 0L 0E 11/ 10S - (Larva Spawned)
1:25.35: 190M 0G 2L 0L 0L 0E 11/ 10S - (Overlord Completed)

Larva is a little off, larva starts after you drop below 3 and takes 15 sec and it is delayed as long as you have over 3 larvae again.
So first larva will be at 17 sec, but at 13.63 you already have 3 larva again
The second one should be at 32 sec but it seems you have it 4 sec faster.

Also, maybe you could adjust the beginning of the BO to reflect the ingame time.
For the above the best i could get is:
0 sec Drone
15 sec Drone
28 Drone
35 Drone
49 Extractor trick drone - this drone finishes exactly as in your BO!
1:02 Overlord

This small seconds might influence the BO later.

On December 08 2010 15:39 TheFirstOne wrote:
This is phenomenal. May I suggest some features:

1. Add a "Constant Units" button that requires every building to always be making a unit/add-on.
2. Allow minerals and gas to be set in a waypoint.
3. Allow the starting point to be changed (for instance, I want to see the optimal build to get to some waypoint starting from when I already have 3 rax, 1, fact, 2 starports, 2 orb command)
4. Keeping in mind point 1, allow food, minerals spent and gas spent to be set in a waypoint.
5. Mostly benefiting the toss players: allow energy to be set as a waypoint (sentry).

Also, since you're changing the GUI anyway, I think one improvement is having an "add waypoint" button, rather then 5 automatic ones.

On December 10 2010 02:30 TheDrill wrote:
What a great tool! Great job OP!

I have to agree with points 1 and 3.

On December 09 2010 22:21 icezar wrote:
Obviously the difference is in how you estimate minerals.
The estimate is accurate but not for the first minute. In game you have a delay when you send the drones to mine and also they do not return minerals constant, like you have 45 minerals and then you have 60 because 3 drones bring minerals simultaneous so there is no middle time where you have 50 to build that drone.
I think you have to add a delay in mining but this can only be found out with testing.

Another nice feature would be a "generate noob BO" :-)) where every action is delayed by 2 sec for example.
This way you can see what is the best BO that you can actually use if you do not have the apm to do the perfect BO.

On December 10 2010 02:30 TheDrill wrote:
As a terran player I want to say that I want to arrive at a certain safe scenario based completely on the protoss opener, if the protoss opens 4gate, I want to cut scv production and add a barracks for example, and only then expand. If a protoss opens a 1gaterobo, then I want to aggressively expand with only two barracks. What this program needs to do in order to be useful in this case is to let the user set the starting scenario (2 ocs, 26 scvs, 2 barracks, depots, etc...) and then generate the fastest path to target from there. This will also increase the speed at which meaningful results are generated. Like if I want to open 10depot 12barracks 13refinery 15oc every game and completely discard the possibility of 10depot 11refinery for example.

Another great feature would be the ability to designate a building as in constant production, and set the units that it constantly produces. (e.g. siege tanks) Maybe if you're really baller, you could also let the user designate a building output as 'flexible' and let a techlab barracks produce unit X (e.g. marine, reaper) every one to five cycles instead of a marauder to save money, while still producing usable army units.

On December 10 2010 03:54 calculator wrote:
I knew I wasn't the only one. Forcing an intro would be a pretty sweet next addition. Also tagging buildings (rax1, rax2, rax3 etc) and telling certain ones (rax1, factory3, etc) to "constant produce unit X" and, as a corollary, not to build a building until an economy can handle constant production out of it (which you could calculate beforehand, therefore improving calculation speeds). I would give the "constant" part something like a 3 seconds leeway so if it helps the build to delay constant production 3 seconds here and there then thats ok. But not when it delays constant production by more than 3 seconds.

On December 10 2010 08:49 calculator wrote:
Is it really that hard to say "Start with A, B, C, X, and Y"? I don't know anything about your code but if it's that hard to implement some (seemingly basic) defaults then maybe you should consider rewriting some of it before you get too deep into things...

What good will a calculator be that doesn't do what users need it to do, say, a year from now? I think the most valuable thing you can do right now, both for the users as well as to save yourself a lot of time down the road, will be to take some time out to write code that will allow users to enforce custom restrictions (triggers/actions). Just the most basic if/then stuff; you can get an idea based on the triggers and actions in the map editor. Don't you think that would be easier to code than even whatever you've done so far, and save you from having to add who knows how many random/arbitrary features in the future, which still won't accomplish everything that triggers could?

I do like the idea to maximize units, but it could be even more powerful if you don't underestimate the potential value of tagging buildings, which in turn could be even more powerful (read: making the program actually useful to a wide range of people, also time saving, i do realize its still in beta and respect for working on it in the first place) when combined with basic triggers.

On December 10 2010 07:01 CarbonTwelve wrote:

Incidentally, one thing I've noticed with the GSL is that even pros take 3-4s before they send their workers mining, and it's another second or two before they're actually at the minerals collecting, so I'm thinking I need to increase the initial delay.

On December 09 2010 13:29 CarbonTwelve wrote:


I know you'd only do it at the display point, but even then it really isn't the 'simplest of changes'. I won't go into a full explanation of why as it's kinda drawn out and not really important, but if you look at the code you'll see the display is done in a generic way that basically needs to have a separate line for each command. I'm not saying it'll stay that way - as above, I do plan to change it at some point - just trying to point out that it's not that simple.