2024-04-16 20:18 CEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006112Spring engineGeneralpublic2019-01-03 18:532019-01-06 14:53
ReporterDoo 
Assigned ToKloot 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusresolvedResolutionfixed 
Product Version104.0 +git 
Target VersionFixed in Version104.0 +git 
Summary0006112: Gunships on manoeuver ignore enemies
DescriptionBA 10.20
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.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0019638

Doo (reporter)

2019-01-03 18:55

 As you can see, this is not happening onengine 104.0.1 maintenance 886

~0019639

Kloot (developer)

2019-01-04 01:43

 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.

~0019640

Doo (reporter)

2019-01-04 17:27

 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)
    end
- [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?

~0019641

Kloot (developer)

2019-01-04 18:55

Last edited: 2019-01-06 14:52

View 4 revisions

 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
  end
  ...
  -- here it might be, in which case only the "allowed" return value matters
  local priority = defPriority or 1.0
  ...
end

let me know if anything else breaks, the comments should cover all cases.

~0019642

Doo (reporter)

2019-01-04 19:39

 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)

~0019643

Kloot (developer)

2019-01-06 14:53

 fixed in 963-gbfc7e61 (both params are now -1 as intended)
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History