-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Issue #35 "Improve mineral saturation" #50
Fix Issue #35 "Improve mineral saturation" #50
Conversation
I'm intending to do a proper evenly-redistribute-workers-among-bases when doing the decide-when-to-automatically-expand logic. Should I make a separate Issue for that, or include it with this one tomorrow? |
It is ok to continue work in the same issue. |
Linter has failed:
|
8603d8a
to
61c91f6
Compare
Extended Expansion class and polished some places. Works pretty well now. I changed the MarinePush strategy a bit to reflect that it can't use Stim or Reactors correctly yet. |
61c91f6
to
b4ee0a7
Compare
Linter errors:
|
0b18a9e
to
ea8ee37
Compare
ea8ee37
to
07c0811
Compare
I re-wrote a couple sections. Works really well to keep pumping workers on 3 base. Thank you for taking the time to review and comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much better, thank you!
Please, take a look at the remaining issues. This is not critical changes, but could be better to do them now.
07c0811
to
5b2b604
Compare
I believe I have made requested changes now. Two of the Expansion/Owner questions I believe are best resolved within issue #53, "Secure/Defend new expansions" when there will be military actions to enable testing. |
Can this pull request be accepted now? |
I need to review it and since the request is relatively large it'll take some time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Several minor fixes left.
This will send new/idle workers to a non-saturated townhall. Townhalls will build an extra worker over Ideal and it will go to a new non-saturated townhall upon creation, so each townhall will continually build workers if there are any townhalls that are not yet saturated (until 80 total). After constructing a building, workers will go to an unsaturated townhall instead of the closest/starting one.
5b2b604
to
b724594
Compare
Question: Should I have been just adding normal commits to resolve change-requests, and only doing a squash+force-push at the end after it's been reviewed successfully? I think perhaps the constant force-pushing is making looking at past change-requests more difficult. |
There are different ways of doing it. I prefer clean history without intermediate commits, however, you could have split the whole patch into several commits according to particular idea. To me it is ok in both ways. |
@@ -145,6 +145,16 @@ void Dispatcher::OnUpgradeCompleted(sc2::UpgradeID id_) { | |||
i->OnUpgradeCompleted(id_); | |||
} | |||
|
|||
void Dispatcher::OnUnitEnterVision(const sc2::Unit* unit_) { | |||
// gHistory.info() << sc2::UnitTypeToName(unit_->unit_type) << |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this part was commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's triggered too often during big fights and slows the game. It's not just first time seen, but every time. If thought to leave it in commented out, so authors can easily uncomment it of they need to use for debugging, but maybe that isn't needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think better to remove it, but ok.
@@ -12,14 +12,14 @@ IsUnit::IsUnit(sc2::UNIT_TYPEID type_): m_type(type_) { | |||
} | |||
|
|||
bool IsUnit::operator()(const sc2::Unit& unit_) const { | |||
return unit_.unit_type == m_type && unit_.build_progress >= 1.0f; | |||
return unit_.unit_type == m_type && unit_.build_progress >= BUILD_FINISHED; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems that we need to add it to the api e.g. unit_.isBuildFinished().
Very good job! Thank you! |
This will send new/idle workers to a non-saturated townhall. Townhalls will build an extra worker over Ideal and it will go to a new non-saturated townhall upon creation, so each townhall will continually build workers if there are any townhalls that are not yet saturated (until 80 total). After constructing a building, workers will go to an unsaturated townhall instead of the closest/starting one.