Unit Auto Repair Widget

[ginekolog]

nice if u fix it, i ll use it. ATM i cant as i order cons to build antinuke and he start reparing stuff first.. wtf

Imo only idle const should repair stuff nearby... not even moving ones. (or put that as variable in widget file so we can easily change it?)

[thesleepless]

nice if u fix it, i ll use it. ATM i cant as i order cons to build antinuke and he start reparing stuff first.. wtf

Imo only idle const should repair stuff nearby... not even moving ones. (or put that as variable in widget file so we can easily change it?)

yep, it'd be best they didn't stop building to repair stuff,
but it was intentional that they repair while moving
that's so you can grab a bunch of cons + combat units and move them at the enemy base and any combat units that get damaged will get repaired by the cons on the way, unfortunately it seems its not easy to order a con to repair something and keep moving while it does it

ideally it should work the same way as attacking, if a combat unit encounters an enemy while it's moving then it'll attack it, if a repair unit encounters a damaged friendly while moving it should repair it

IMO nanospray should just a weapon like every other weapon, but target friendlies by default rather than enemies

[CarRepairer]

nice if u fix it, i ll use it. ATM i cant as i order cons to build antinuke and he start reparing stuff first.. wtf

Imo only idle const should repair stuff nearby... not even moving ones. (or put that as variable in widget file so we can easily change it?)

yep, it'd be best they didn't stop building to repair stuff,
but it was intentional that they repair while moving
that's so you can grab a bunch of cons + combat units and move them at the enemy base and any combat units that get damaged will get repaired by the cons on the way, unfortunately it seems its not easy to order a con to repair something and keep moving while it does it

Edit: Still bugged, will need more testing.
ideally it should work the same way as attacking, if a combat unit encounters an enemy while it's moving then it'll attack it, if a repair unit encounters a damaged friendly while moving it should repair it

IMO nanospray should just a weapon like every other weapon, but target friendlies by default rather than enemies

Okay, fixed here http://trac.caspring.org/changeset/3896

Only truly idle cons will autorepair now. I think you were confusing getfullbuildqueue, it's something you only use for factories.

I added a leash so that if they began the auto repair but start moving too far from where they began, they will stop repairing and go back. det pointed this out to me since a damaged plane might fly over a con in your base, then fly across the map and the con will follow that plane into his doom until the plane is healed or is dead.

Tip: If you really want cons to be moving along with your mobile army and heal them as they travel, issue a fight command to the cons (or just select all the combat units and cons and issue a fight command to the whole lot)! Autorepair is for cons to be in a single spot of safety and they won't stray too far from it.

Edit: still bugged, will need more testing.

[klapmongool]

I have been using this widget recently. It still suffers from bugs.

Worst is that builders that aren't really idle decide to go repair stuff. I think this is caused by the intended function in this widget that allows moving repair units in a moving front to repair. The problem is that this overrides genuine move commands (fe to get ur comm out of danger by moving him away). Also repairunits still follow air that passes over them.

Can someone remove that part of the widget please;

1. repairing while moving doesn't work for most repair units anyway.
2. i dont need that part anyway :)

[thesleepless]

yeah this widget is broken and i don't have time to fix it sorry.
shouldn't be hard to modify though, even with minimal coding ability

[klapmongool]

I am afraid I have less than minimal coding ability. But I gave it a try anyway.

I started out by identifying the way to determine whether a potential repair unit is idle. Next I looked at another widget (idlebuilders) for comparison. Both seem to beat around the bush. Autorepair checks for all units that have repair capability (right?), then eliminating all units that arenÔÇÖt available for various reasons while idlebuilder checks for units that can have build queues without build queues but donÔÇÖt have em.

What script is behind ctrl-b, and why isnÔÇÖt it used in these scripts? For the purpose of improving this script for my needs this seems the fastest way to go. Would it work if this part below gets replaced for the ctrl-b way of determining idle builders?

Code from Autorepairunit widget:

local function isIdleRepairer(unitID)
local udef = spGetUnitDefID(unitID)
local ud = UnitDefs[udef]
if not ud.canRepair then
return false
end
local _, _, _, _, buildProg = spGetUnitHealth(unitID)
if buildProg < 1 then
return false
end

local cQueue = spGetCommandQueue(unitID)
if cQueue[1] then
return false
end
return true
end

Code from Idlebuilder widget:

local function IsIdleBuilder(unitID)
local udef = Spring.GetUnitDefID(unitID)
local ud = UnitDefs[udef]
local qCount = 0
if ud.buildSpeed > 0 then --- can build
local bQueue = Spring.GetFullBuildQueue(unitID)
if not bQueue[1] then --- has no build queue
local _, _, _, _, buildProg = Spring.GetUnitHealth(unitID)
if buildProg == 1 then --- isnt under construction
if ud.isFactory then
return true
else
local cQueue = Spring.GetCommandQueue(unitID)
if not cQueue[1] then
return true
end
end
end
elseif ud.isFactory then
for _, thing in ipairs(bQueue) do
for _, count in pairs(thing) do
qCount = qCount + count
end
end
if qCount <= NEAR_IDLE then
QCount[unitID] = qCount
return true
end
end
end
return false
end

[CarRepairer]

I have the feeling you're not using the updated version from CA which has some fixes.

[klapmongool]

I have the feeling you're not using the updated version from CA which has some fixes.

hmmm, and where would I find those? This widget I found on http://widgets.springrts.de/index.php#76.

[manolo_]

the problem is, that ca-devs dont update the widgets in the wdb (if they just modified them)

[SirMaverick]

the problem is, that ca-devs dont update the widgets in the wdb (if they just modified them)

We work and update on our repository. And it's not only ca-devs that put widget in wdb. A simple solution might be to put a link in to ca's repository in description if you add a widget in wdb.

[very_bad_soldier]

the problem is, that ca-devs dont update the widgets in the wdb (if they just modified them)

Car updates CCC quite regularly.

the problem is, that ca-devs dont update the widgets in the wdb (if they just modified them)

We work and update on our repository. And it's not only ca-devs that put widget in wdb. A simple solution might be to put a link in to ca's repository in description if you add a widget in wdb.

Hm, that would make it impossible to use most of SD's widgets features. (One-click install, auto-updating, version tracking, etc.)

How about this: When you update a widget you send a PM to me or manolo (with a changelog) and we will do the DB updates for you? Please understand it is a bit hard to keep track of the CA-widgets if you are not a CA-dev.

[CarRepairer]

Car updates CCC quite regularly.

Nope...

How about this: When you update a widget you send a PM to me or manolo (with a changelog) and we will do the DB updates for you?

This is what I do. He has more patience than me with the wdb app.

Back to topic though, even with some fixes in CA the widget still had issues and we had to disable it. We should probably remove it to prevent newbies from using it by accident.

[klapmongool]

Car updates CCC quite regularly.

Nope...

How about this: When you update a widget you send a PM to me or manolo (with a changelog) and we will do the DB updates for you?

This is what I do. He has more patience than me with the wdb app.

Back to topic though, even with some fixes in CA the widget still had issues and we had to disable it. We should probably remove it to prevent newbies from using it by accident.

This widget has potential for specific use for me. I was using the latest version i think, since there is nothing newer than the one posted in this topic by you (http://trac.caspring.org/changeset/3896)

Although the widget might not fulfil its intended goal it still has its uses. Atm I am using it but have to switch it off in certain situations because of its buggyness. For my purposes it would be fixed if the ┬┤idle┬┤ cons could be identified better. (ctrl-b would be great) I don't need walking cons to be identified.

[manolo_]

car is the only one who is sending me pms atmo and i look from time toi time at tthe ca-widget-source, but sometimes i forget it or i dont even recognize it, coz i think the changes are just ca-related

[klapmongool]

Sooo.. would anyone know how to adjust this widget's method of selecting idle builders?

[Hobo Joe]

Have a look at the idlebuilders widget and see how it identifies them and copy the code appropriately?