Loading...
  OR  Zero-K Name:    Password:   

Idle Cons Patrol

14 posts, 1456 views
Post comment
Filter:    Player:  
sort
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 GBrankdyth68. 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.
+9 / -0


2 years ago
quote:
area repair command followed by an area reclaim command followed by a patrol command

I'm unconvinced by this order. It should select whether to reclaim or repair depending on whether energy is low or metal is full.
+1 / -0
2 years ago
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.
+3 / -0

2 years ago
Pretty neat, exactly what I wanted. I will test that!
+0 / -0

2 years ago
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.
+0 / -0
quote:
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.
Yes, I thought about that. Then I thought if I already do it, I can do it even better from scratch.

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.
+2 / -0

2 years ago
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.
+2 / -0
2 years ago
I currently have a widget in late alpha that includes checks if energy reclaim is in range. It typically does it once per second for one builder and only if it has nothing better to do. Auto patrol nanos updates each builder every 4s which becomes more expensive when you have many builders. Also, as soon as my widget has found an energy feature, it stops checking the remaining area. So performance should be fine. Players on potatoes can increase the update time. It could still be optimized by recycling previous feature knowledge or directly storing the energy reclaim positions for different maps, though.

At some point, you may even want to have your own reclaim command rather than standard area reclaim because your widget can solve the travelling salesman problem more efficiently than the engine. One of my missing features to reach beta is to check if allies have free storage so that reclaim excess is no problem but that's easy.
+1 / -0
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]
+6 / -0
15 months ago
I updated Smartest Builders to version 3.2 which I publish hereby under the terms of the GNU GPL v2.

Performance Improvements
- Getting units and features in range is the most critical performance factor for the widget. By reusing previous knowledge about units and features in range, the needed computation power is reduced by ~60% without any loss of accuracy.
- Builder updates are now anticyclic to updates of other widgets in the hope of improving performance further.
- Some unnecessary variables have been cleaned up.

Feature Improvements
- A part of the gained performance is used to double the update frequency. Builders react faster but the widget still has better performance.
- The action "build own" is replaced by the action "build own unit or allied mex". Assisting allied mexes is paid back now after all.
- Nanoframes at a wait command are excluded from being built automatically. This applies mostly to defenses, not to factories.
- If you have metal excess and energy deficit, the action "reclaim metal only if no team metal excess" is now done at a higher priority than building own units. Not doing this before was a relic from the time were allied resources were not considered yet.

Bugfixes
- Fixed a bug where air cons didn't go to their factory waypoint after being built even though the factory was not set to assist
- Fixed a bug in the capture progress priority consideration
- Fixed a potential bug with capturing and other unit transfers
- Fixed a potential crash

[Spoiler]
+4 / -0
15 months ago
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...
+0 / -0

15 months ago
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.
+0 / -0


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

14 days ago
This should be in base game indeed...
+0 / -0