You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My thought is that you essentially create a virtual queue of SCV production and MULE calldowns at the earliest possible times (given the players CCs and Orbital production). Then when new production is added you ignore this virtual queue for purposes of ordering, but you still calculate the minerals and supply available based on it. Then finding the timing for the new production should be basically the same, just find the earliest time after the last non-virtual action that has the correct resources, but you need an extra check to make sure that this won't delay SCV production. If that check fails, then move the new production after the next SCV production. I hope that explanation makes sense.
You also would have to consider if/when to stop virtual SCV production. 16 per base would probably be reasonable, and resume virtual production if a new base finishes (if that doesn't make it too complicated).
This would be useful for planning macro builds to ensure that worker production is not getting delayed without having to fiddle with the timeline.
I'm not sure if Chronoboost would be a useful feature here, so I don't know if typical Protoss builds are constantly Chronoboosting worker production (I don't play Protoss).
I may try to take a crack at this, at least for the Terran side, but my JS/TS is rusty.
The text was updated successfully, but these errors were encountered:
I agree that automatic worker production is probably one of the top features to allow the package to be more easily useable. From a practical standpoint, most all builds constantly produce workers until full saturation, and it's a little frustrating to keep putting in workers in while experimenting.
Wish I could help, really not that familiar with typescript.
Problem is, trial and error has a price here since simulations can take up to a second to run (each and every frame is simulated!)
So we can't run too many simulations when the user adds an item: it'd make the interface unresponsive and painful to use.
So the solution I'm working on is adding buttons you can click to optimize certain things in your build. So far I only have an "Add as many workers as possible as long as the BO ends at the same time as before" button (check it out here)
And I plan on having other buttons like "Use as many MULE/Inject/Chronos as possible and as early as possible, as long as the BO ends at the same time".
There isn't much to change to play with optimization now that I added a button for it. Feel free to tweak some code and share it ^^
My thought is that you essentially create a virtual queue of SCV production and MULE calldowns at the earliest possible times (given the players CCs and Orbital production). Then when new production is added you ignore this virtual queue for purposes of ordering, but you still calculate the minerals and supply available based on it. Then finding the timing for the new production should be basically the same, just find the earliest time after the last non-virtual action that has the correct resources, but you need an extra check to make sure that this won't delay SCV production. If that check fails, then move the new production after the next SCV production. I hope that explanation makes sense.
You also would have to consider if/when to stop virtual SCV production. 16 per base would probably be reasonable, and resume virtual production if a new base finishes (if that doesn't make it too complicated).
This would be useful for planning macro builds to ensure that worker production is not getting delayed without having to fiddle with the timeline.
I'm not sure if Chronoboost would be a useful feature here, so I don't know if typical Protoss builds are constantly Chronoboosting worker production (I don't play Protoss).
I may try to take a crack at this, at least for the Terran side, but my JS/TS is rusty.
The text was updated successfully, but these errors were encountered: