Jump to content

During a kill event in MP, unable to get outSoundForGroup/outTextForGroup to function.


Recommended Posts

Posted (edited)

Good day,

(All of my work is done in Lua scripting here.)

I've been working on our server creating a specific feature involving outTextForGroup and outSoundForGroup firing off when a Kill Event occurs. In single player, everything works as intended. outTextForGroup and outSoundForGroup messages fire off perfectly in single player and if I create a new server as the host.  However, in multiplayer as a client, this kill event does NOT fire off outSoundForGroup nor outTextForGroup. It's also important to note that you can not test this as a server host. I ran my tests as a client and had these issues.

 

At first I had a suspicion that these events do not fire off due to the fact that the event must fire after the object has been destroyed, thus eliminating groupID (I suspected), but after researching the documentation on Hoggit, it appears kill events do indeed fire off before aircraft object has been destroyed. I do not receive script errors and I'm lead to believe that getID() is the culprit here. Does anyone else have trouble with getID() in their recent scripting experience? 


Edited by ghostsp3ctre

Flanker CFI - 107th JAS

TTI Frontlines Developer - Through the Inferno

Through the Inferno Discord - Check it out

Coordinator - Thursday Night Throwdown

Link to comment
Share on other sites

  • ghostsp3ctre changed the title to During a kill event in MP, unable to get outSoundForGroup/outTextForGroup to function.
Posted (edited)
9 hours ago, Sedlo said:

Hey @ghostsp3ctre! Are the clients set to invulnerable? I had experienced a similar thing with the EVENT_HIT handler. 
 

might be related?

 

 

 

I am just re-reading what I wrote. Obviously, if they’re set to invulnerable, they won’t get killed. Stupid me 😉

Hey thanks for the response @Sedlo,

 

That's correct, I don't have them set to invulnerable. Just to sort of repeat and hone in on my situation...In my example my tests, I would use scripting to parse my kill event to my client aircraft, which was as an A-10A. Then I'd task a ship such as the Ticondaroga with firing on the A-10A to shoot it down it, causing the Kill event to fire off (occured generally as the aircraft hit the water, so a crash event also happened simultaneously, but as stated before, the kill event always fires first.) From there in my kill event scripting, I have the line of code below execute, which doesn't generate an error, but just pretends to run like normal when checking it in the DCS log. However it flat out doesn't outText anything lol.

tti.outTextForGroup(tgtGroup:getID(), "*************** !ATTENTION! **************"30) 

Edited by ghostsp3ctre

Flanker CFI - 107th JAS

TTI Frontlines Developer - Through the Inferno

Through the Inferno Discord - Check it out

Coordinator - Thursday Night Throwdown

Link to comment
Share on other sites

Posted (edited)

For those who view this thread...fortunately in the scripting I need to do, I solved this problem by just using Event Hit and setting a boolean value to prevent the hit event from firing multiple times (since it fires off every single time anything hits the object). For my specific purposes, I need this event to fire off once at some point to display a specific message, not necessarily when they're dead. That is the workaround I have come to thus far.


Edited by ghostsp3ctre

Flanker CFI - 107th JAS

TTI Frontlines Developer - Through the Inferno

Through the Inferno Discord - Check it out

Coordinator - Thursday Night Throwdown

Link to comment
Share on other sites

7 hours ago, ghostsp3ctre said:

For those who view this thread...fortunately in the scripting I need to do, I solved this problem by just using Event Hit and setting a boolean value to prevent the hit event from firing multiple times (since it fires off every single time anything hits the object). For my specific purposes, I need this event to fire off once at some point to display a specific message, not necessarily when they're dead. That is the workaround I have come to thus far.

 

 

Hey, @ghostsp3ctrecool!  Can you share what you've come up with, I'm always interested in seeing how this might be done.

Link to comment
Share on other sites

Posted (edited)
On 5/19/2021 at 3:29 AM, ghostsp3ctre said:

Hey thanks for the response @Sedlo,

 

That's correct, I don't have them set to invulnerable. Just to sort of repeat and hone in on my situation...In my example my tests, I would use scripting to parse my kill event to my client aircraft, which was as an A-10A. Then I'd task a ship such as the Ticondaroga with firing on the A-10A to shoot it down it, causing the Kill event to fire off (occured generally as the aircraft hit the water, so a crash event also happened simultaneously, but as stated before, the kill event always fires first.) From there in my kill event scripting, I have the line of code below execute, which doesn't generate an error, but just pretends to run like normal when checking it in the DCS log. However it flat out doesn't outText anything lol.

tti.outTextForGroup(tgtGroup:getID(), "*************** !ATTENTION! **************"30) 

 

 

There's an small, but infuriating (if you don't know about it) oddity I observed when a callback is initiated from an F10 command: your callback is invoked with debugging and errors disabled. The result is that if you have any script error in the entire callback life cycle, it fails silently and looks as if it works, but doesn't do anything.

 

My workaround was to redirect: schedule a call to the "real" processing function during callback. When the scheduled (redirected) call happens, debugging is enabled, and the errors will cause the error dialog to appear and allow you to add the one period that you forgot (or similar). 

 

Now, to my knowledge world event callbacks aren't affected by this, but you never know. It may help if you tried this re-direct once to see if there was a tiny remaining error in that code.

 


Edited by cfrag
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...