Destroying Sounds That Are Played More Than Once?

I have heard that sounds leak. However I have some sounds that are played as needed on a regular basis and when i destroy them to prevent leaks they never play again...

so what do i do to be able to always call on that sound yet have no leaks from it?

Are we talking about sounds created in the sound editor here or trigger-generated sound objects?

It's lame to destroy sounds, just reuse them.

If you're reusing an object, it's not a leak; it still takes up memory, but for a useful purpose, and does not increase over time the amount of memory used.

an imported sound that i give a sound variable to in the sound editor and then call on via a trigger


I hope it's like you say.

I do this a lot. I have about 100 sounds that are reused so much and i was worried that each time a sound was called on it would remember duplicate instances of itself and stack up in the memory.

I'm also concerned of float text and timers doing this as well.

It depends on how you do it...

So the sound won't be played you try to play it when is not finished, but it won't leak because you never create it.
The sound editor create one time for you in the map script and set to the global.

If you want to be sure the sound will be played every time, you can create the sound each time you need to play it and use the function KillSoundWhenDone, or make a system which recycle sounds.

For float text there is an action LifeSpan or something like that (available in gui as well).

For timers you should give an example of using them.

Well, what is the way to avoid and which is the safe route?


Well, making a timer variable and then using the
And then starting that timer again and again before it finishes. So example: I start timer for 30 seconds but then 2 seconds later i run Start timer for xx seconds again before it finishes. Would that leave something resident in the systems memory? Like an unfinished process?

I use a lot of timers in my maps and I have corrected much of my leaks but there is still lag after playing for extended periods of time and a black screen for often several seconds after game is finished... so I am trying to figure out what causes this when I have destroyed pretty much every player group, position, position offset, special effect, Ini triggers that aren't used anymore, setting unit groups and destroying, dynamic all-pick units, and i am always having every dying unit added to a unit group (which is destroyed) and then removing the units from the game..

I just dont know what else it could be. I thought I had everything covered. I know i use a LOT of timers and a LOT of temporary float-texts and repeating sounds so i figured that is the only thing it could be.

I use that, but i didn't know if that lifespan truely destroyed it or not. just like when a unit dies, it is still there.

Knowing and UNDERSTANDING what you are doing.

works very weird...

and also don't get sound duration... it's async in some (also) weird way... and caused desyncs in first TcX versions (in case what all sound were custom... and idsabling sound doesnt change the result of return value) aka it seems to depend on your system...

What if i have a timer set to the duration of a sound.

Hmm can you explain more about that, as far i tested it works fine.

this exactly caused the desyncs xD ...
in may cases after i call this func sounds didn't played sometimes. (the order of calls is important) + anyway afaik sounds does leak KillWhenDone doesnt prevent it... (not handles... memory) thats why i uses systemysed stack to store allready played sound and reuse it. but ofc it may not matter.

For the leak that's easy to solve you can null the handle juster after run the function KillSoundWhenDone, i had tested and it doesn't leak.

For the order of call is there one safe and which ?

If you make a timer variable in GUI the map script will automatically create a timer and store it to that variable when the map starts; so, the game will only create one handle and it doesn't matter how many times you reuse that handle, it's still the same, you're not generating a leak, at least not a handle leak. As far as we know, there's no problems with restarting a time rthat's already running.