correct as-is HARM fired in pre briefed mode does not trigger an event_shot event

[pcoud]

See attached tracks. I am running a short script that detects fired missiles at an ennemy EWR and shuts down said EWR. Detection is based on the event_shot event.

 

Track1: I fire my HARM in TOO mode: a message appears proving detection and EWR going dark

Track2: I fire my HARM in PB mode: nothing happens. Shortly after I fire another HARM in TOO: it is detected (message appears)

 

100% reproduceable.

HARMs fired in SP mode are also detected.

 

Only those fired in PB do not trigger the event_shot event.

pb no event shot1.trk pb no event shot2.trk

[NineLine]

Reported, thanks!

[NineLine]

Update, this is correct as is based on how PB works.

[BarTzi]

2 hours ago, NineLine said:

Update, this is correct as is based on how PB works.

 

Hi NineLine, do you mind if I add a request to that?

Think about it from a SAM/Radar operator's prespective. If the missile is detected in flight, the operator makes the decision to shut down the system if he/she thinks the missile is inbound for the site's position. 
This is how some IADS scripts work in DCS. Can you please consider changing event_shot or the command Weapon.getTarget(Weapon self) to return the designated target for the HARM (coordinate, or coordinate and the type of radar the HARM is searching for) when launched in all of the RANGE KNOWN modes? This is to help script makers try and adjust their IADS scripts to those modes. 

Thanks!

Edited October 1, 2021 by BarTzi

[NineLine]

Grimes is taking a closer look at this one, will get back to you.

[Grimes]

Ok lets clear some things up. 

 

1. The tracks that pcoud posted do not show any bug with the shot event. This is primarily because they used a do script with the following code: assert(loadfile("D:\\Eclipse\\workspace\\Mes missions\\Missions test\\RDR detect.lua"))(). I can't speak for Nineline, but I don't have that file in that directory on my PC, so the script doesn't load. 

 

2. Using a script to display any event that occurs you can clearly see in the screenshot below that a shot event did in fact occur when firing off the HARM in PB mode. In the future for any event related functionality that is the preferred way to go about it. Displaying a message of the event is a whole lot better at showing an event is broken than using an event to cause an AI do to something because any link in the chain from that event to the AI could be the part that is broken. 

 

3. getTarget doesn't appear to return anything in PB mode, but it does with other modes. I would hazard a guess that getTarget is also like that with other weapons that have autonomous modes or just go for coordinates. For example an AI dropping a JDAM or LGB a target, but dropped from a player might not. The SLAM and Harpoon might have similar behavior as the HARM. So perhaps there is a mix of needing a getTargetCoord function and getTarget not changing. 

 

 

 

[pcoud]

Hi @Grimes, @NineLine, I am sorry, I just noticed your replies.

@Grimes:

1- My mistake, I am using the assert(bla bla) when I'm testing, I forgot to join the actual script when I sent the tracks.

2- You are absolutely right. I have made additionnal tests and I confirm what you said: the event.shot  is triggered by a harm in PB mode. You also made me understand why I did not see it before. It is because the event.shot was only triggered when a certain target was shot at (I am using the Moose event handlers and subscription  system and I had something like:

EW_radars:HandleEvent (EVENTS.Shot)
function EW_radars:OnEventShot (EventData) etc..

But EW_radars being a target and a harm fired in PB mode not "generating" a target, the event was not captured by this handler. I have made a "generic" handler (not through an object subscription, but capturing ALL events, as you said), and it works.

3- I think it makes sense that getTarget does not work in that case. A harm fired in PB mode does not have a target, it is fired towards coordinates where the target is roughly supposed to be, then search for its actual target in flight.

My apologies to NineLine for the fake bug.

My thanks to Grimes: I think I would have had a hard time figuring this out without your insight.

 

[Grimes]

I did end up reporting that Weapon.getTarget never changes once it does start acquiring a target. Only got it to occur with the HARM in PB in F-18 and POS submodes in F-16, and Harpoon in RB/L. So that aspect of it is bugged. Also did request the addition of Weapon.getTargetCoord. Unknown when either of those will be addressed. 

[pcoud]

Many thanks.

Actually, I now don't understand why you say an aspect of it is bugged (?). You said that getTarget wasn't returning anything (for a harm in PB mode). Now you say "Weapon.getTarget never changes once it does start acquiring a target". I don't get that last statement: what should be the correct behaviour? And why would getTarget change once it acquired a target?

Also:

Quote

Only got it to occur with the HARM in PB in F-18

I am not sure I understand: what exactly did you get to occur with the HARM in PB in F-18?

[Grimes]

The shot event doesn't have a target because the missile is guiding to a point and the seeker isn't active when shot. For air to air missiles like the AIM-120 the value returned with Weapon.getTarget can change between nil and returning something depending on what is happening with the guidance. It can acquire, lose track, and reacquire, lose track, and acquire a different target for instance. There is no event for that so it requires constantly rechecking the value. So for the HARM fired in PB modes that value never changed even if the target it was guiding to was destroyed and it switched to another nearby target, it was always just nil. IIRC in SP and TOO the returned value could switch targets if the missile did. 

So I reproduced the bug that Weapon.getTarget doesn't change in PB modes with the HARM. 

[pcoud]

Got it, thanks for your help !

[Pikey]

With weapons getting their own brains, it would be nice to see a coordinate returned where applicable, we could do a lot with that.