Skip to content
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

Added an algorithm for distributing damaged units between free repair stations #3686

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Monsterovich
Copy link
Contributor

When building repair stations, there is a problem that units are looking for the closest structure, because of this, stations can not be placed, for example, parallel to the flow of damaged units and need to be placed perpendicularly and preferably next to each other.

The only way to get around it so far is to build the line perpendicular to the flow, or like this, if you want to cover the flow from all angles:

hexagon!

This PR adds an additional check so that a lot of damaged units do not crowd near the closest station in large numbers and go directly to a available one.

}
if (droidsAtRepair > REPAIR_FACILITY_MAX_CAPACITY)
{
continue;
Copy link
Member

@past-due past-due Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eliminating these repair facilities from contention altogether (which is what this does) seems like it could have other potentially-undesirable drawbacks.

(For example, with this change, if all repair facilities are crowded - by the metric - then none of them are candidates to even move towards. This then triggers the fallback behavior, and could (if there are no repair droids) lead to droids up for repair going all the way to the HQ. Whereas someone might want all the droids to head towards repair facilities, even if they are currently crowded.)

Did you not find the existing behavior that already "randomly" distributes droids amongst multiple nearby repair facilities sufficient? (See where there's int32_t which = gameRand(vFacilityCloseEnough.size()); - perhaps we could try increasing MAGIC_SUITABLE_REPAIR_AREA as an alternative?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This then triggers the fallback behavior, and could (if there are no repair droids) lead to droids up for repair going all the way to the HQ.

First of all, this most likely won't happen, because if units are normally distributed to repair facilities, they will be faster to repair (at most we can increase the limit from 8 to 12, but I think it's fine as it is).
Second, as a last resort, let them go to HQ instead of crowding around the repair facilities. It can happen that a lot of damaged units will be repairing and crowding around, but suddenly an enemy comes (ex. VTOL bombers) and kills them all.
The situation can be improved by utilizing the droid repairers additionality as you've already mentioned.

Did you not find the existing behavior that already "randomly" distributes droids amongst multiple nearby repair facilities sufficient?

No, it doesn't work well in practice, no matter how you do it you still have to make the stations close together and perpendicular to the flow for greater efficiency.

Copy link
Member

@past-due past-due Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you not find the existing behavior that already "randomly" distributes droids amongst multiple nearby repair facilities sufficient?

No, it doesn't work well in practice, no matter how you do it you still have to make the stations close together and perpendicular to the flow for greater efficiency.

But that's based on the current way the code selects which facilities are "close enough", which seems like something we could alternatively change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which seems like something we could alternatively change.

That's what I'm suggesting...

You can make any algorithm you want, but it still has to take into account that some units are already "queued" for repair in a certain repair facility and this facility should be skipped after the queue overflows and another nearby should be picked instead. Then the repairing structures can essentially be positioned however you want.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

triangle

Here is the most basic example showing the problem. Making repair facilities next to each other creates another problem, but it solves the problem on the screenshot.

The other problem is that repaired units accumulate closer to the center of the certain facility, and damaged units can't get any closer due to the large amount of already repaired units. This PR completely eliminates this problem too as it limits the size of the unit group next to the structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants