Author Topic: AI target overload?  (Read 1626 times)

0 Members and 1 Guest are viewing this topic.

Offline dukka

  • 24
  • literally terrible
    • Steam
So I managed to run myself into a situation that I didn't think was possible. I have a capital vessel that puts out 12 bombs in 1.5 seconds every 15 seconds. Whenever I have another ship engage this one the second ship refuses despite having the means to do so (weapons with plenty of range and proper flags). Instead the second ship (or even ships it seems) just engages the bombs as they enter the range of whatever other weapons it has (flak, short range turrets, etc).

I went through a number of cases to ensure that it was (more than likely) the bombs causing the problem:
  • Created a new blank test mission with a simple replication of the situation, second ship still fails to engage through the bomb screen. Okay, it isn't some problem with the mission/SEXPs then.
  • Swapped the first ships (the ones with the bombs) for ones without. Everything worked fine, no ships had problems engaging any other.
  • Reverted the first ships and emptied the turrets with the apparently problematic bombs. Everything once again worked fine, so something is up with the bombs.
  • Removed the bomb flag from the bombs. Hey, the ships are engaging with no problem!
  • Replaced the bomb flag on the bombs with interceptable, just to see. Original problem returned.
I also performed all of these tests both in the latest stable (3.7.4) as well as the nightly build from the 21st, just as an extra check.

So, I suppose the simple question is if too many bombs (or targets in general for that matter) can in some way mess up a ship's ability to engage valid targets as you would expect. Also, if for some reason seeing my tables entries or anything else would help in resolving this issue, just let me know.
« Last Edit: September 24, 2016, 07:36:49 pm by dukka »

 

Offline niffiwan

  • 211
  • Eluder Class
IIRC, the default AI targeting policy puts bombs before anything else. So if there's a bomb to shoot at they'll always prefer to target that, which could be the cause of what you're seeing.  Try playing with the subsystem/turret $Target_Priority
http://www.hard-light.net/wiki/index.php/Subsystem#.24Target_Priority:

Only problem being that I can't seem to find documentation on what the valid values are here  :hopping: 

From a look at Diaspora, you seem to need something like this in an objecttypes table:

Code: [Select]
$Name:                          AllBombs
+Weapon Class:                  ( "GBU-102 Tercio"
                                  "GBU-102 Tercio#Weak"
                                  "N4 Nessus"
                                  "N3 Kratos"
                                  "MRT-HE 1.0 Scythe"
                                  "MRT-HE 1.0 Scythe#Weak"
                                  "MRT-N 2.3 Mangonel"
                                  "MRT-N 2.3 Mangonel#Weak"
                                  "Cylon Torpedo"
                                  "Cylon Torpedo#6 Pack"
                                  "Cylon Torpedo#Weak"
                                  "Cylon Torpedo#1 Pack Weak"
                                  "Cylon Heavy Torpedo"
                                  "Cylon Heavy Torpedo#2 Pack"
                                  "Cylon Heavy Torpedo#Weak"
                                  "Cylon Nuclear Torpedo"
                                  "Cylon Nuclear Torpedo#Weak"  )

And then something like this on your ship turrets:

Code: [Select]
$Subsystem:                             Gunturret-04a,   4.0, 1.0
        $Alt Subsystem Name:            CIWS
        $Armor Type:                    Frigate_Guns
        $Default PBanks:                ( "Colonial Heavy CIWS" )
...
        $Target Priority:               ( "AllBombs" "SmallShips" )
...

Except you want to remove bombs from the priority list, or at least put it lower than other targets.
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Code: [Select]
$Name:                          AllBombs
+Weapon Class:                  ( "GBU-102 Tercio"
                                  "GBU-102 Tercio#Weak"
                                  "N4 Nessus"
                                  "N3 Kratos"
                                  "MRT-HE 1.0 Scythe"
                                  "MRT-HE 1.0 Scythe#Weak"
                                  "MRT-N 2.3 Mangonel"
                                  "MRT-N 2.3 Mangonel#Weak"
                                  "Cylon Torpedo"
                                  "Cylon Torpedo#6 Pack"
                                  "Cylon Torpedo#Weak"
                                  "Cylon Torpedo#1 Pack Weak"
                                  "Cylon Heavy Torpedo"
                                  "Cylon Heavy Torpedo#2 Pack"
                                  "Cylon Heavy Torpedo#Weak"
                                  "Cylon Nuclear Torpedo"
                                  "Cylon Nuclear Torpedo#Weak"  )
It would be a lot simpler to just do this:
Code: [Select]
$Name: AllBombs
+Weapon Class Flags: ( "bomb" )
If you just want to make certain turrets prioritize ships over bombs, however, all you need is the "turret-set-target-order" SEXP.

(Confusingly, there doesn't appear to be a way to change the target order by default; I guess you need to use target priority groups if you don't want to SEXP it for every single mission.)
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Spoon

  • 212
  • ヾ(´︶`♡)ノ
Urutorahappī!!

[02:42] <@Axem> spoon somethings wrong
[02:42] <@Axem> critically wrong
[02:42] <@Axem> im happy with these missions now
[02:44] <@Axem> well
[02:44] <@Axem> with 2 of them

 

Offline dukka

  • 24
  • literally terrible
    • Steam
So, I went through and gave some of these suggestions a shot (granted, stuff like actually defining object types is a good idea regardless) and ended up in a perhaps much stranger place. First off, in the mission that first started to give me this problem, the issue still persists. Second, I cranked my semi-replicated test case up to a whole new level by increasing the volume of bomb fire and hey, the second ship keeps firing its main guns at the bomb-armed capitals just fine. That is ummmm, good maybe? Finally, back the the problem mission, if I once again remove the bomb flag from the weapon everything operates just fine and all the ships continue to fire their long range main weapons rather than suddenly deciding to stop almost immediately after the bombs start flying out.

I don't even know how this makes sense anymore. If I can trust myself on these tests I have somehow dismissed the problem from being caused by the weapons, targeting orders, and rouge SEXPs taking a dump on the mission. Yet at the same time the problem I was originally having only presents itself in the case of bombs having either the bomb or an interceptable flag.

 

Offline niffiwan

  • 211
  • Eluder Class
Do you mind posting your missions & tables?
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline dukka

  • 24
  • literally terrible
    • Steam
Anddddd I think I solved it. Did some more jiggling of flags, target orders, etc and now the ships are all behaving as they should. I still don't know how to explain some of the oddities that I encountered (like the test mission working fine while the real one broke down quite hard), but I'll just live with such for now. The problem I guess is technically solved, though if it manages to crop up again I'll share the relevant tables and mission(s) right away.