Bug #11438

CfgSFX sound fails to delete when its trigger is deleted, but inconsistently.

Added by CarlGustaffa about 7 years ago. Updated over 5 years ago.

Status:Expired Start date:06/24/2010
Priority:Normal Due date:12/01/2011
Assignee:CarlGustaffa % Done:


Target version:-
Affected ArmA II version:1.59.79384 First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:


I have been struggling with this problem for a while now, and not been able to find a workable solution. It affects todays beta, and have caused brain damage since many many betas, probably forever.

The sounds I'm using are configured in description.ext like this (only showing the needed stuff):

class CfgSFX
    class fx_generator
        name = "fx_generator";
        sound1[]={"soundfx\fx_generator.wss",1,1,45,1,0,0,0}; //One of the default factory sounds.
        empty[]= {"",0,0,0,0,0,0,0};
    class fx_enginenoise
        name = "fx_enginenoise";
        sound1[]={"soundfx\fx_enginenoise.wss",1,1,30,1,0,0,0}; //One of the default factory sounds
        empty[]= {"",0,0,0,0,0,0,0};

The sounds originate from "AddOns\sounds\sfx".

These are placed using triggers with triggerText in editor set to "generator" and "engine noise", and placed on/near an AntiAirRadar object (class RU_WarfareBAntiAirRadar, with some preset damage to make it easier to destroy). This object has a Killed EH that is execVM'ed and goes something like (again, deleted unneeded stuff):

switch (_killedtype) do {
    case "RU_WarfareBAntiAirRadar" : {
        "EH-Killed - RU_WarfareBAntiAirRadar was killed" call debugChat;
        _list = (getPos _killed) nearObjects ["EmptyDetector",8];
        format ["EH-Killed - list = %1", _list] call debugChat;
        for "_i" from 0 to count _list - 1 do {
            _trigger = _list select _i;
            if (triggerText _trigger == "enginenoise") exitWith {}; //No need to check more
        [_trigger] spawn fnx_DeleteSoundTrigger;
        "EH-Killed - 'engine noise' trigger deleted" call debugChat;
        for "_i" from 0 to count _list - 1 do {
            _trigger = _list select _i;
            if (triggerText _trigger == "generator") exitWith {}; //No need to check more
        [_trigger] spawn fnx_DeleteSoundTrigger;
        "EH-Killed - 'generator' trigger deleted" call debugChat;
        if (_killed == uObjAntiAirRadar) then { /*'Stuff deleted, but it has and needs sleeps, hence execVM'*/ };
//Everything else not shown

fnx_DeleteSoundTrigger is defined by (I use x since it executes something, not a function call):

fnx_DeleteSoundTrigger = {
    private ["_trigger"];
    _trigger = _this select 0;
    format ["fnx_DeleteSoundTrigger - %1 trigger deleted", triggerText _trigger] call debugChat;
    _trigger setPos [0,0,1000]; //Has no effect when it fails, but shows that sound source does not move with it when it fails.
    sleep 10.567; //Make DAMN sure the DAMN sound source object gets deleted with it!!! Just an attempt.
    deleteVehicle _trigger;

The output in my .rpt from my debugChat shows up like:

"DEBUG: EH-Killed - RU_WarfareBAntiAirRadar was killed" 
"DEBUG: EH-Killed - list = [17886: <no shape>,17888: <no shape>]" 
"DEBUG: EH-Killed - 'engine noise' trigger deleted" 
"DEBUG: EH-Killed - 'generator' trigger deleted" 
"DEBUG: fnx_DeleteSoundTrigger - generator trigger deleted" 
"DEBUG: fnx_DeleteSoundTrigger - enginenoise trigger deleted" 

And the .rpt shows no signs of any errors.

It correctly lists the two triggers, it shows the triggerText of the triggers are correct, and using the debug dialog (triggerText nearestObject [player,"EmptyDetector"]) it shows no triggers when I'm close to their position...

BUT, and here is the kicker:
The sound source is still playing. Sometimes, but not always. And it is playing the sound in a very odd fashion:
There is no spatial updating going on (you can't tell where the source is by moving around), and the source will not fade with distance but rather suddenly silence when you're outside its reach. If I hit ESC twice, the sound will maximize in sound level and stay there. If I'm near a working sound source, the sound will maximize briefly when ESC is hit twice, then return to normal.

When I try to reproduce this in a "clean mission", it never fails. Sound source is then deleted every time the trigger is deleted.

Ref description part of: http://community.bistudio.com/wiki/setSoundEffect
"SoundDet (only for triggers) creates a dynamic sound object attached to a trigger defined in CfgSFX."

Something tells me that something weird happens to this sound object. Is it destroyed? Does it get covered up by the remains of the radar? Is it affected by the explosion (sometimes SMAW, sometimes M136, sometimes satchels) causing it to fly out of map or something?

Could be related, I don't know: Mission has a small cutscene at the start (basic zoom, nothing special), but during this cutscene I sometimes hear cows etc placed far away as anonymous soundsource (full volume, no spatial, just like my trigger sounds when they fail). I expect these cows to use the same CfgSFX principle, and I suspect it uses say instead of say3D (probably not a good idea to change that).

Observed behavior (sometimes): Mysterious sound object fails to be deleted with the trigger it is child of.
Expected behavior: Sound object needs to be deleted efficiently with parent trigger at any cost. Whatever is done now, is not sufficient.

Any workarounds for the problem would be appreciated. I've tried _trigger setSoundEffect ["", "", "", ""]; without success. I set ticket to "Category: Sound", since "Category: Lurking deep within the engine" was missing from the list :)

Sorry, there are no .rpts (no errors, just debug output) or dump files on this one, and I'm not really able to reproduce it in a clean mission either. But I'm hoping the devs will recognize from the description of the problem, and knowing their engine in and out, what could be a possible cause and have it dealt with. As it is now, it makes CfgSFX very hard to use, and can break immersion more than it adds to it.


Updated by kju about 7 years ago

  • Status changed from New to Feedback

Any chance for a small and simple demo mission.
I bet this would up chances BI looking into it a lot.

Updated by CarlGustaffa about 7 years ago

Not really, no. Sorry :) As I said, when I try this in a clean mission (small and simple) it never fails. I'll check the latest beta now, and later tonight try with fresh memory and no program swapping, to see if that influences something.

Updated by kju almost 7 years ago

  • Due date set to 09/01/2010

Updated by CarlGustaffa almost 7 years ago

This is still sort of a problem. Although the sound doesn't go crazy anymore in OA as it did in Arma2, the "object" is still subject to damage. So if we have objects using allowDamage false and create a sound for it using trigger effects, the sound will not survive the damage. If it had infinite armor, at least we could ourselves control when to delete it or not.

I've managed to use setSoundEffect for triggers, but it requires a weird workaround; In order to use the last "" (trigger sounds from cfgSFX defined in description.ext), the first "" has to be defined with a dummy sound (silence). Is this worthy of a ticket of its own, or is this by weird design?

Updated by Fireball almost 7 years ago

If you don't give a way to reproduce this easily (mission), this won't be looked into, I'm pretty sure.

Updated by Fireball almost 7 years ago

  • Due date changed from 09/01/2010 to 09/18/2010

Updated by kju over 6 years ago

  • Affected ArmA II version set to 1.52.71816

Updated by CarlGustaffa over 6 years ago

It's actually so whacky I don't know how do describe it. Typically sounds that are there when I die and respawn, are often not there anymore when I get back there. But I've also have sounds disappear on my while they're being played (or on loop), while I'm in the play radius. So, again, not the same kind of weirdness that was present in Arma2, but still a major pain. Maybe the issue is that cfgSFX was never properly documented?

Updated by kju over 6 years ago

  • Due date changed from 09/18/2010 to 04/01/2011

Any difference? Any chance for a more simple demo mission with repro steps?

Updated by zGuba almost 6 years ago

  • Due date changed from 04/01/2011 to 09/01/2011
  • Assignee set to CarlGustaffa

Updated by kju almost 6 years ago

  • Due date changed from 09/01/2011 to 12/01/2011
  • Operating system deleted (WinXP 32 bit)
  • Affected ArmA II version changed from 1.52.71816 to 1.59.79384
  • CPU deleted (Please specify!)
  • Audio card deleted (Please specify!)
  • Size of OS swap file deleted (Please specify!)
  • Reproducible for you changed from No to Yes

Updated by zGuba over 5 years ago

  • Status changed from Feedback to Expired

Also available in: Atom PDF