2019-12-08 14:37 CET

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0004800Spring engineGeneralpublic2015-06-12 21:27
Assigned Tohokomoko 
Product Version98.0.1+git 
Target VersionFixed in Version 
Summary0004800: gadget:AllowWeaponTarget is not called for staionary units
DescriptionZero-K uses gadget:AllowWeaponTarget to change targeting priorities according to its own rules.

I noticed that while for moving units the gadget:AllowWeaponTarget is called frequently enough allowing for fine-grained dynamic target prioritization, stationary units having targets within their fire range doesn't get such call at all. Moreover the target selection happens behind the scene and such stationary targets tend to just select nearest targets (which could be completely opposite to the logic inside gadget:AllowWeaponTarget code.

Moreover for some units that don't deal physical damage, like ZK's racketeer (shieldarty.lua) target selection is done in a such way that priority target (Cartesian nearest one) becomes a unit's "sole target". By sole target I mean that if that target is specifically blocked in script.BlockShot(num, targetID) function and other targets are available, then unit stops shooting at all.

Units moving around on move, fight or partol don't have this issue:
1. gadget:AllowWeaponTarget gets called frequently enough fro them
2. if script.BlockShot(num, targetID) returns true for certain targetID, then other targets within range are considered
Steps To ReproduceNot sure I have an easy way to reproduce that. But here is what might work.

1) Clone ZK repo, copy it to ZK.sdd <spring_dir>\games
2) uncomment "--Spring.Echo("TARGET CHECK")" in https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/unit_target_priority.lua
3) Spawn ZK game with null-ai. make /cheat, /godmode, /globallos
4) /give 10 shieldarty, order them to stop (just in case) and fire at will
5) /give 10 hoverassault 1 (nearby). Set to hold fire. Move them around the racketeers (shieldarty). Observe no "TARGET CHECK" echos appear. Observe racketeers shoot nearest target.
6) Put one or few racketeers on fight pointing nearby hoverassaults. Observe "TARGET CHECK" start to appear in a steady stream.

As for validating second claim it requires anti overkill prevention implementation for racketeer, which is currently work in progress and doesn't exist in public repos. But curious (and suspicious) mind may
1) manually block one of the hoverassault UnitID in script.BlockShot(num, targetID) function in https://github.com/ZeroK-RTS/Zero-K/blob/master/scripts/shieldarty.lua
2) Order STOP command to racketeers
3) Move that particular hoverassault closest to stationary racketeers again
4) Move other hoverassaults into the racketeers range as well.
5) Observe racketeers stopped shooting (shot is bllocked by script), however other targets are freely available!!!
Additional Informationcode to put into script.BlockShot(num, targetID) function in https://github.com/ZeroK-RTS/Zero-K/blob/master/scripts/shieldarty.lua:

function script.BlockShot(num, targetID)
  return (targetID==<unit_id_you_want_to_block>)

where <unit_id_you_want_to_block> is the closest "hoverassault"
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files




Google_Frog (reporter)

Wait I thought of something. Did you check whether the unit had given itself an attack command? That does not go through AllowWeaponTarget. You should always have some sort of show all commands widget enabled.


lhog (reporter)

It's the case. Stationary mobile units give themselves attack order and change targets voluntary.

Does knowing this help solving issues #1 and #2?


hokomoko (developer)

AllowWeaponTargetCheck is now actually usable, if you return `true, false` it will force auto target, if you return `false, false` it will disable auto target and if you return `whatever, true` it will let the engine decide whether to autotarget or not (ignoring the callback).


lhog (reporter)

Latest patches from @hokomoko (available in -769) are likely to resolve that

+Related Changesets

-Issue History
Date Modified Username Field Change
2015-06-08 22:41 lhog New Issue
2015-06-09 08:40 Google_Frog Note Added: 0014560
2015-06-09 17:14 lhog Note Added: 0014562
2015-06-10 12:28 hokomoko Note Added: 0014564
2015-06-12 18:03 hokomoko Assigned To => hokomoko
2015-06-12 18:03 hokomoko Status new => assigned
2015-06-12 18:06 hokomoko Changeset attached => spring develop 9e581a60
2015-06-12 19:06 lhog Note Added: 0014575
2015-06-12 21:27 hokomoko Status assigned => resolved
2015-06-12 21:27 hokomoko Resolution open => fixed
+Issue History