| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0004800 | Spring engine | General | public | 2015-06-08 22:41 | 2015-06-12 21:27 | ||||
| Reporter | lhog | ||||||||
| Assigned To | hokomoko | ||||||||
| Priority | normal | Severity | feature | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 98.0.1+git | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0004800: gadget:AllowWeaponTarget is not called for staionary units | ||||||||
| Description | Zero-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 Reproduce | Not 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 Information | code 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>) end where <unit_id_you_want_to_block> is the closest "hoverassault" | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Google_Frog (reporter) 2015-06-09 08:40 |
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) 2015-06-09 17:14 |
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) 2015-06-10 12:28 |
https://github.com/spring/spring/commit/a8e8380a57ef92e395a6722b6f8ddf1bb47240ba 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) 2015-06-12 19:06 |
Latest patches from @hokomoko (available in -769) are likely to resolve that |
| Notes |
| 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 |