Idle Cons Patrol

Today, under GNU GPL v2, I share with you my little widget Idle Cons Patrol 1.3. When they become idle, unselected builders get an area repair command followed by an area reclaim command followed by a patrol command. It's the 2nd most simple way to make a builder widget. It is certainly possible to make a better one by considering the current ressource situation and more and I also have a plan to do so. But this one at least obeys my design principle of not doing anything unexpected. What follows this principle even more is version 1.2 which is the 1st most simple way to do it, namely by only issuing a patrol command.

It is intentional that idle unselected cloaked mobile builders decloak to reclaim/repair. Coms and nanos are also builders. It avoids patrol commands to outside of the map so that units don't get stuck at the map edge.

The behavior is similar to the default Auto Reclaim/Heal/Assist by dyth68. My widget does it with less code and computation power but therefore also without regular updates. The main problem with previous widgets including Auto Reclaim/Heal/Assist is that units are limited to their small build range. My widget extends the repair/reclaim range of mobile builders by the customizable parameter buildRadiusExtension which is set to 200 elmo by default. The final patrol command ensures that builders return close to their original position if there is nothing more to do.

Update 1.4: The widget does no longer give commands to area cloaked area cloakers (Conjurers or coms with area cloak module that are area cloaked by own or external field). Area cloakers with only personal cloak active will still decloak to reclaim/repair. I may publish future widgets under the same link as Idle Cons Patrol 1.4.

Yes, I have a whole table of ideal action order in dependency of ressource situation that considers much more. I even have an algorithm that implements it. But this is for a future version.

Sounds cool. Perhaps you can integrate it into https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaUI/Widgets/unit_auto_patrol_nanos_v2.lua, which already takes current eco into account.

quote: One problem is that there seems to be no command to reclaim energy. There's only reclaim metal and reclaim everything. I will probably replace reclaim energy by reclaim everything. In a later version, maybe I have to write my own area reclaim energy command.

Yes. auto patrol nanos gives a general reclaim command when it wants to reclaim energy. Sometimes this leads to bad behavior and it ends up reclaiming metal when what you want is energy, so you might end up excessing even more. It's relatively rare though, partially because in general play energy it's less common to need to reclaim energy.

My plan for "some day" is to track why the widget issued the "reclaim" command, and then if it later sees that metal is reclaimed while we want energy, then just tell that caretaker to do nothing for a little while.

I'd love for there to be a reclaim energy command in the engine. It would be hard to write something as a widget that efficiently reclaims energy, because it requires looking at all the objects in range, which is expensive. But you can possibly do it occasionally and the amortized time should be reasonable.

Deactivate all your other builder widgets! I made the ultimate widget! Smartest Builders implements an action priority list in dependency of resource situation as a multidimensional table of functions. I publish it under GNU GPL v2. Here is the table:

	Metal deficit	Metal normal	Metal excess
Energy deficit	1. Reclaim enemy nanoframes, 2. Reclaim metal, 3. Reclaim energy, 4. Repair ally, 5. Build own, 6. Return to original position	1. Reclaim enemy nanoframes, 2. Reclaim energy, 3. Reclaim metal, 4. Build own, 5. Repair ally, 6. Return to original position	1. Reclaim enemy nanoframes, 2. Reclaim energy, 3. Build own, 4. Repair ally, 5. Reclaim metal only if no team metal excess, 6. Return to original position
Energy normal	1. Reclaim enemy nanoframes, 2. Repair ally, 3. Reclaim metal, 4. Reclaim energy, 5. Build own, 6. Return to original position	1. Reclaim enemy nanoframes, 2. Repair ally, 3. Build own, 4. Reclaim metal, 5. Reclaim energy, 6. Return to original position	1. Reclaim enemy nanoframes, 2. Build own, 3. Repair ally, 4. Reclaim energy, 5. Reclaim metal only if no team metal excess, 6. Return to original position
Energy excess	1. Reclaim enemy nanoframes, 2. Repair ally, 3. Reclaim metal, 4. Build own, 5. Reclaim energy only if no team energy excess, . Return to original position	1. Reclaim enemy nanoframes, 2. Repair ally, 3. Build own, 4. Reclaim metal, 5. Reclaim energy only if no team energy excess, 6. Return to original position	1. Reclaim enemy nanoframes, 2. Build own, 3. Repair ally, 4. Reclaim metal only if no team metal excess, 5. Reclaim energy only if no team energy excess, 6. Return to original position

[Spoiler]
Here is my favorite line of code where the function is called from the table:

noActionFound = orderTable[status.metal][status.energy][orderTableIdx](unitID, x, z, range, mobile, bp, busy, rateChange)

Remarks:
- Priority is given to manual commands.
- The widget never repairs/builds/reclaims units that are more than half captured.
- The widget never repairs/builds/reclaims Lamp/Claw/Glint/Firefly/Viper/Gull even though it would be possible to repair Lamp.
- The widget handles all units that can build including Caretaker/Strider Hub/Athena/Funnelweb but excluding area cloaked area cloakers.
- When reclaiming enemy nanoframes, choose target according to the following priority list:

• 1. Minimum capture progress
• 2. Maximum build progress

- When repairing, choose target according to the following priority list:

• 1. Finish current repair target (if exists) before going to next one except if resource situation has changed such that other action is better than repairing or repair target went too far away or repair target has been more than half captured or repair target has been partially reclaimed by somebody
• 2. Minimum capture progress
• 3. Minimum relative health

- When building, choose target according to the following priority list:

• 1. Minimum capture progress
• 2. Immobile > mobile
• 3. Maximum build progress

- Usually, mobile builders extend their build range by the customizable parameter buildRadiusExtension. But for reclaiming enemy nanoframes, builders only use their basic build range without walking to the enemy.
[Spoiler]

This should be by default, would help many players, who sometimes can be seen having idle cons next to huge reclaim fields.
If the widget already exists...

https://github.com/ZeroK-RTS/Zero-K/tree/master/LuaUI/Widgets
This still not here?

quote: I don't know about that widget exactly, but I have played against some who suicide their cons constantly, perhaps under the influence of such a widget.

If you're worried about that, you can change the line

local buildRadiusExtension = 201

to

local buildRadiusExtension = 0

This parameter controls by how much mobile builders extend their build range by walking. It can be changed by the user to any number >= -38.

The only other number that is supposed to be changed by the user is

local updateFrameDistance = 15

It controls how fast builders are updated. If you want to improve your performance by slower updates, you can increase the number, for example to 60. Lowering the number can result in bad FPS. It must be a positive integer.

You can also change the order of the functions in the orderTable.

quote: https://github.com/ZeroK-RTS/Zero-K/tree/master/LuaUI/Widgets This still not here?

No, but you can put it there if you like.

I updated Smartest Builders to version 3.5 which I publish hereby under the terms of the GNU GPL v2. Compared to version 3.2, it has the following improvements:
- Generalized com detection: Coms no longer stop being updated after being morphed in Future Wars.
- Previously, minimum relative health was the third priority for repair target determination. Now, it is a combination of minimum relative health and minimum walk time that chooses the repair target which maximizes the formula

q²*cost / (q*cost/bp + dist/speed) = q / (1/bp + dist/(speed*q*cost)) = expectation value of resources saved by repairing / (repair time + walk time)

with the builder parameters speed and bp (buildpower), the potential repair target parameters cost,

q = 1 - relative health = missing relative health

and dist the distance between builder and potential repair target.
Some effects considered by the formula:

• Walk time per repair time should be minimized.
• Walking is worse if builders have low speed per bp.
• Prioritizing low health targets is extra important to increase the chance to keep them alive.
• Walking to units with a high repair cost is more worth the walk.