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

Forum index  > General discussion   > Development   >

Area Repair Priority

26 posts, 1660 views
Post comment
Filter:    Player:  
Page of 2 (26 records)
sort
PRrankScrangos
11 years ago
I'd find it very helpful if there was a way change the priorities of area repair between unit repair and construction assist. I also find once they touch the construction assist they get stuck on assisting (if its a factory). Im not sure the engine makes a difference between repairs and construction assists though... so it might go all the way to separating the commands altogether.
+7 / -0
GBrankKyubey
11 years ago
+1
+3 / -3
PLrank[Sprung]
11 years ago
According to Kloot, the engine doesn't make a difference:
quote:
"assisting building" (adding buildpower) is implemented via CMD_REPAIR
+0 / -0
ROrankRed_Lemon
11 years ago
Perhaps detecting if it is a nanoframe or a finished unit would be enough to allow the right thing to be prioritized.

Would something like this be feasible?
+1 / -0
PRrankScrangos
11 years ago
So cant be done then? =o
+0 / -0


AUrankAdminGoogleFrog
11 years ago
It's possible to give repair commands with a widget. I don't think there is a nicer way to change repair behaviour.
+0 / -0
AUrankjseah
11 years ago
What do you want to prioritize? Repair?

I can make a widget that will hardcode it... I guess.
+0 / -0
GBrankTheSponge
11 years ago
I widget that allowed you to select what you wanted prioritized at the time would be great. For example, if I wanted to have my cobra done quick, I could select it to be one in some way without removing the patrol order. Would that be possible?
+0 / -0
PRrankScrangos
11 years ago
(edited 11 years ago)
Yeah, I would like repairs prioritized where if a con in "area repair" is assisting a building, itd either break off and repair when a damaged unit comes into range, or finish what its doing and repair before constructing anything else (including factories and buildings).

Though in theory I'd have liked a on the fly customizable (which i have no idea how it would look like ui wise) buttons like the holdfire/defensive/aggressive that swapped order priorities between reclaim/repair/construct in a persistent area command (sorta like patrol, fight) and units broke what their doing if a higher priority thing came into their range (or close to).
+0 / -0
GBrankKyubey
11 years ago
curent ui for builders:

when you switch move state it determines if it will assist allies or not
hold pos: only builds when ordered
manuver: only builds own units
roam: builds/assists both allie and own units/structures

something similar for repair priorotisation could be done:
state 0: dose not repair units at all
state 1: repairs units, but only if there are no nano-frames in the area to build
state 2: repairs units, but only if there are no nano-frames that it can assist due to no metal in reserve/low income
state 3: repairs units, takes priority over all construction. will resum presious build when repair complete

idealy if such a toggle should be made (state 2 should probably be the defaullt)

notes: there has been a gadget like this made in the past for BA, but was not used due to poor implementation (cons would run off chasing units into death). to avoid this, the gadget NEEDS to memorize the cons original position and prevent the con from running more then a LLT range from that poin, then return to that point (unless con is set to roam)

also a seperate assist ally nanoframes/repair toggle would be needed (sometimes you want to just let a con roam, but most of the time you want it to fix your shit first)
+1 / -0
AUrankjseah
11 years ago
(edited 11 years ago)
Under construction now.

I can't insert new unit states with a widget, needs a gadget for that. Still, I can hardcode behaviour, so here's my thinking.

With this widget on:
1. Constructors will repair within zone if possible, construction is second.
2. Constructors will interrupt construction to repair.
3. No distinction is made between allied and self.
4. Hold position constructors will repair units (and repair after construction finished) only if the units are inside the repair area.
5. Maneuver constructors will repair whatever they can reach now + will not exit the zone (nanoturrets on maneuver stop repairing once target leaves max range)
6. Roam constructors will chase their target units down and repair them


EDIT:
Widget will also only work if the first order in their queue is area repair (or a command given by the widget).
+2 / -0
PRrankScrangos
11 years ago
Sounds good, how about the widget also adding a new area command that does repair/reclaim hybrid in the same priority style as your current repair/construct area repair? (So having both commands available, and split your cons between them.)
+0 / -0
AUrankjseah
11 years ago
(edited 11 years ago)
You can't insert new commands with a widget either.

EDIT: actually maybe you can. I haven't... looked that up.
+0 / -0
MYrankxponen
11 years ago
cmd_retreat.lua widget can insert retreat command.

Each time you select unit it add a retreat-zone button or retreat-state button.

Its the Chicken icon and the Wrench command you see on the command menu.
+0 / -0
DErankNeonSturm
11 years ago
How about:

1. Do orders within circle.
2. Repair - whenever possible, abbort building
3a. Build - as long as there is enough metal energy available.
3b. Reclaim - if there is no metal/energy available.
+0 / -0
GBrankKyubey
11 years ago
AUrankjseah yea that actualy seems a pretty good setup
+0 / -0
AUrankjseah
11 years ago
Currently meeting... technical difficulties. Let's see if anyone has any bright ideas.

Inelegance 1:
- Lag causes widget to issue multiple orders to insert repair in front of the queue (issue once, nothing happens; few frames later, widget detects con still needs new order, issues again)
- This behaviour is invisible to the user but makes the widget not detect it (normal detection: first order

single target repair, second order

area repair)
- Current workaround: If first order is repair with single target, ignore all duplicate orders in queue until the next non-same repair order; if this is area repair, activate widget behaviour on this con


There's still a few other bugs regarding move state behaviour that will take some time to work through. I can polish up and release a "repair first, interrupt construction to repair" widget that ignores unit state now though.
If you guys want it, just let me know.
+0 / -0
PRrankScrangos
11 years ago
I would like to try that part if you have a file i can put in =o
+0 / -0
AUrankjseah
11 years ago
http://www.mediafire.com/?042xl6061yuk961
Here you go. All it does is make repair go before construction. (I hope)

Not extensively tested. Not recommended for use outside laboratory conditions. If you experience strange or unexpected behaviour, please cease application by deactivation and contact this thread immediately.

----------------


Parodies aside, you can also activate the (currently buggy) move-state detection of the widget by un-commenting everything in the CheckUnits function. Leave the echo-es alone though unless you want to debug too.

If you have any idea how to get the desired behaviour (which I still cannot trace why it does what it does), do feel free to build on this.
+0 / -0
DErankkaracho
11 years ago
(edited 11 years ago)
its all to complicate

just make a nano for repair and one for build assist.
i would also add one nano just for reclaim.

give them nice names and it will be more easy, more clear and nice for base build.
+0 / -0
Page of 2 (26 records)