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.

Sign up for GitHub

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
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions src/order.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,9 @@
/** The maximum distance allowed to a droid to move out of the path if already attacking a target on a patrol/scout. */
#define SCOUT_ATTACK_DIST (TILE_UNITS * 5)

/** The maximum number of units a repair facility can handle before units start crowding and interfering with each other. */
#define REPAIR_FACILITY_MAX_CAPACITY 8

static void orderClearDroidList(DROID *psDroid);

/** Whether an order effect has been displayed
Expand Down Expand Up @@ -3374,6 +3377,23 @@ static inline RtrBestResult decideWhereToRepairAndBalance(DROID *psDroid)
{
continue; // cannot reach position
}
uint32_t droidsAtRepair = 0;
for (DROID *psOtherDroid : apsDroidLists[psDroid->player])
{
if (psDroid == psOtherDroid)
{
continue;
}
/* Search for droids within a radius of 2 tiles */
if (psOtherDroid->isDamaged() && droidSqDist(psOtherDroid, psStruct) < TILE_WIDTH * TILE_WIDTH * 4)
{
droidsAtRepair++;
}
}
if (droidsAtRepair > REPAIR_FACILITY_MAX_CAPACITY)
{
continue;
Copy link
Member

@past-due past-due Mar 20, 2024 •
edited
Loading

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 •
edited
Loading

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

@Monsterovich Monsterovich Mar 20, 2024 •
edited
Loading

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

@Monsterovich Monsterovich Mar 20, 2024 •
edited
Loading

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.

}
vFacilityPos.push_back(psStruct->pos);
vFacility.push_back(psStruct);
if (bestDistToRepairFac > thisDistToRepair)
Expand Down