|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006112||Spring engine||General||public||2019-01-03 18:53||2019-01-06 14:53|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Product Version||104.0 +git|
|Target Version||Fixed in Version||104.0 +git|
|Summary||0006112: Gunships on manoeuver ignore enemies|
Engine 104.0 maintenance 960
It seems they act just as if they were set on hold position: They refuse to move towards a target and will only autoacquire targets if the target is already inside range/can be shot at without any movement.
|Tags||No tags attached.|
|Checked infolog.txt for lua Errors|
|As you can see, this is not happening onengine 104.0.1 maintenance 886|
|Gunships act this way now because the recent fix for 0006096 added a special engine call to AllowWeaponTarget (during which both targetID and weaponNum are set to -1), confusing BA's units_targetting_priorities gadget. To allow normal auto-targetting again it should simply detect the special case and return true instead of nil.|
Thanks for the quick answer, i've been able to try fixing it now, and got it working.
It doesn't seem to be exactly that easy though, at the very least I needed to alter gadgets.lua a bit:
- The returned targetID seems to be 4294967296 and not -1.
- [Our] gadgets.lua always expected a returned targetPriority value, i had to add a nil check:
if targetPriority then
priority = math.max(priority, targetPriority)
- [Our] gadgets.lua states this at the beginning of the call:
local allowed = true
local priority = 1.0
Which means without a priority returned, it'll use "1". It seems priority, in the case of this call, serves the purpose of adjusting auto-targetting range. Meaning my gunships will target within "1" range.
I had to make sure if targetID == -1 (4294967296), it would return allowed bool only, and no priority number, which defeats the purpose of the change, which was probably to allow finetuning of the autotarget range when wanted.
To be honest, it doesn't exactly seem practical. Wouldn't it be better to have completly separate calls?
Last edited: 2019-01-06 14:52
It probably would, I was trying to avoid some extra work.
I'll handle the -1 / 2^32 bug soon, but FWIW you shouldn't have to touch gadgets.lua at all if you add these lines in units_targetting_priorities:
function gadget:AllowWeaponTarget(unitID, targetID, attackerWeaponNum, attackerWeaponDefID, defPriority)
if (targetID == 4294967296 and attackerWeaponNum == 4294967296) then
return true, defPriority -- here defPriority is never nil
-- here it might be, in which case only the "allowed" return value matters
local priority = defPriority or 1.0
let me know if anything else breaks, the comments should cover all cases.
For some reason, I didnt think of simply returning defPriority... Works fine with that! Thank you!
(Note that attackerWeaponNum = 0 , not -1 nor 2^32)
|fixed in 963-gbfc7e61 (both params are now -1 as intended)|
|2019-01-03 18:53||Doo||New Issue|
|2019-01-03 18:53||Doo||File Added: 20190103_184901_BlueBend-v01_104.0.1-960-g954562a maintenance.sdfz|
|2019-01-03 18:55||Doo||File Added: 20190103_185425_BlueBend-v01_104.0.1-886-g0b800f1 maintenance.sdfz|
|2019-01-03 18:55||Doo||Note Added: 0019638|
|2019-01-04 01:43||Kloot||Note Added: 0019639|
|2019-01-04 17:27||Doo||Note Added: 0019640|
|2019-01-04 18:55||Kloot||Note Added: 0019641|
|2019-01-04 19:14||Kloot||Note Edited: 0019641||View Revisions|
|2019-01-04 19:21||Kloot||Note Edited: 0019641||View Revisions|
|2019-01-04 19:39||Doo||Note Added: 0019642|
|2019-01-06 14:52||Kloot||Note Edited: 0019641||View Revisions|
|2019-01-06 14:53||Kloot||Assigned To||=> Kloot|
|2019-01-06 14:53||Kloot||Status||new => resolved|
|2019-01-06 14:53||Kloot||Resolution||open => fixed|
|2019-01-06 14:53||Kloot||Fixed in Version||=> 104.0 +git|
|2019-01-06 14:53||Kloot||Note Added: 0019643|