A few questions about leaks

[Shadow Fury]

I have a map of mine that apparently still seems to be leaking after ensuring that I removed all location, unit group, visibility, player group and special effect leaks. It takes me about 15 seconds to quit from the game. What remains? Many sounds and wait commands... I'm sure they are the ones causing the leaking problems. So basically here are the questions:

1- Is there any non-leaking wait command? (please don't tell me timers, it would be insane replacing all wait commands with timers).

2- Sounds can be destroyed after being played but this prevents them from being played a second time. I need to replay some sounds periodically but I cannot let them leak! What to do?

 

[Nichilus]

The standard wait command does not leak afaik, it's just inefficient. Sounds do not leak imho - at least if you're using them multiple times over the course of your game.

Lags and fps drops do not have to be caused by leaks tho. It can be inefficient trigger - like picking every unit in map every .03 second, etc.

 

[edo494]

creating unit group, enuming it and running loop on units + destroying the group at the end every 0.03 seconds can cause lag, lots and lots of lag(mainly the creation and destruction, which is funny, you would guess loops are harder operations, but apparently not)

 

[Shadow Fury]

The standard wait command does not leak afaik, it's just inefficient.

Much better if they do not leak.

Sounds do not leak imho - at least if you're using them multiple times over the course of your game.

This tutorial doesn't agree with you.

Lags and fps drops do not have to be caused by leaks tho. It can be inefficient trigger - like picking every unit in map every .03 second, etc.

I've used a lot of "pick every unit" command but I always avoided the "units of type" part because I know it's a heavy command. I used unit group variables for any picking so that I could eventually destroy it. Anything else that causes lag or FPS?

creating unit group, enuming it and running loop on units + destroying the group at the end every 0.03 seconds can cause lag, lots and lots of lag(mainly the creation and destruction, which is funny, you would guess loops are harder operations, but apparently not)

What about if I used many of these commands but not for every 0.03 seconds? I've got one that triggers every second, should be ok, right?

 

[edo494]

once per second is really unnoticable

 

[Nichilus]

This tutorial doesn't agree with you.

Actually it does agree with me. Look at this post in the very same thread you posted: http://www.hiveworkshop.com/forums/1131397-post17.html

I've used a lot of "pick every unit" command but I always avoided the "units of type" part because I know it's a heavy command. I used unit group variables for any picking so that I could eventually destroy it. Anything else that causes lag or FPS?

"Pick every unit of type" causes permanent leak and as such should be avoided. What I meant in my previous post is basically what edo494 already explained.

 

[Shadow Fury]

Never used "Pick every unit of type" because I know about its bad reputation. So if waits and sounds are not the reason, what could let me take so much to quit (note that I don't suffer from lag in single player, didn't try multiplayer though).

 

[PurgeandFire]

Describe the problem. You'll need to try to reproduce it for us to offer appropriate advice.

(1) Is the fps dropping constantly over time? Is it gradual? Or is it all of a sudden? If it is gradual, it may be a build-up of leaks. If it is sudden, then it likely involves one particular trigger.
(2) You said you didn't suffer lag in single player, so did you only have the problem in multiplayer?

What you're describing (taking 15 seconds to quit) sounds like the fps dropped down to close to 0. This usually happens with infinite loops or really, really fast timers (e.g. every 0.00 seconds).

If you can find a way to reproduce the issue, then it becomes a lot easier to find the problem!

 

[Wietlol]

1- Is there any non-leaking wait command? (please don't tell me timers, it would be insane replacing all wait commands with timers).

"Wait <real> seconds." does not leak.
However it simulates real life time so will not be equal to your gametime.
"Wait <real> seconds of gametime" leaks a timer handle index.
This wait will wait at least <real> seconds but will always be a little bit more.
Waits in multiplayer always lag very much and must be replaced by accurate timers at all cost.
For single player maps, you can use a custom command by placing this inside library tags or in the map header:

    function WaitGameTime takes real duration returns nothing
        local timer t
        local real  timeRemaining
        
        if duration > 0 then
            set t = CreateTimer()
            call TimerStart(t, duration, false, null)
            loop
                set timeRemaining = TimerGetRemaining(t)
                exitwhen timeRemaining <= 0
                
                if timeRemaining > bj_POLLED_WAIT_SKIP_THRESHOLD then
                    call TriggerSleepAction(0.1 * timeRemaining)
                else
                    call TriggerSleepAction(bj_POLLED_WAIT_INTERVAL)
                endif
            endloop
            call DestroyTimer(t)
            set t = null
        endif
    endfunction

Then you can use the command "call WaitGameTime(2.5)" to wait 2,5 seconds for example.
In GUI, place that exact same text inside the Custom Script action.

 

[RobertMKD]

I have a long trigger in my map with a lot of wait for condition actions checking every 1 second, and it does not affect the performance at all...

 

[Wietlol]

Single player or multiplayer?

 

[Shadow Fury]

It is gradual because if I wait 30 seconds and quit, it will do it instantaneously. I have a lot of periodic events but totally no timers or "every 0.00 seconds" thing. The fastest periodic event is "every 0.4 seconds" and it's just to enable black mask to the whole area and provide vision only around your hero (of course I destroy and recreate them to avoid leaks, lag and delay). It's not this one for sure because this is a trigger I only added recently and the problem was still present before implementing it. If waits do not leak and are just imprecise, then I don't think I'd have to bother myself changing them all. I'll have to try to play my map in multiplayer one day and see if there'll be lag issues. If not, I may overlook the time taken to quit the map.

 

[IcemanBo]

You can attach map or PM me to have a look at triggers. Don't be scraed I would steal something.

 

[Shadow Fury]

You can attach map or PM me to have a look at triggers. Don't be scraed I would steal something.

There is already a test map in the pastebin. Nah, I am not afraid that you'd steal my resource. (oh right I have a later version where some stupid triggers and command were fixed/removed ex. 10 triggers of visiblity condensed into one and all "destroy sounds" removed)

 

[IcemanBo]

I indeed found a lot. I hope that are major ones:

In update multiboard you leaks points periodicly. You destroy the wrong ones.

You leak all your visibility modifer periodicly, you always overwrite them, but never destroy them.

GameMechanics -> Flee succesfully -> unit group leak periodicly.

Player group leak in "Villager Dies", but I guess it isn't called very often.

Always when you make "AllPlayer matching conditon.." or "AllUnits matching conditons..." or something similar it creates group/force that needs to be destroyed after usage.

"Point with PolarOffset" creates a new point that needs to be removed properly.

"Position of Item" creates a point which needs to be removed.

Using IntegerA is not very recommended. It is a bit slower and you got this shit with custom scripts refer to it.

You make it harder than needed. You don't need these point[arrays] really. Just use a single normal point variable, or two. Same with groups.
Also code hard to read and change because you don't use the "...AndMultipleActions" for groups and If/Then/Else too much.

 

[Shadow Fury]

I indeed found a lot. I hope that are major ones:

In update multiboard you leaks points periodicly. You destroy the wrong ones.

You leak all your visibility modifer periodicly, you always overwrite them, but never destroy them.

GameMechanics -> Flee succesfully -> unit group leak periodicly.

Player group leak in "Villager Dies", but I guess it isn't called very often.

Always when you make "AllPlayer matching conditon.." or "AllUnits matching conditons..." or something similar it creates group/force that needs to be destroyed after usage.

"Point with PolarOffset" creates a new point that needs to be removed properly.

"Position of Item" creates a point which needs to be removed.

Using IntegerA is not very recommended. It is a bit slower and you got this shit with custom scripts refer to it.

You make it harder than needed. You don't need these point[arrays] really. Just use a single normal point variable, or two. Same with groups.
Also code hard to read and change because you don't use the "...AndMultipleActions" for groups and If/Then/Else too much.

The visibility thing has already been fixed as I mentioned above. About the rest... oh that's gonna be hell. I know there are some groups and points that leak but if I destroy them it'll be a disaster I thought they were few so they won't affect the game. Also, does "Add unit to group" leak because I did that for the Npc? And... what? Villager dies has player group leaks? I didn't use player group functions.

 

[IcemanBo]

Adding/removing unit does not leak, no.

Villager dies has player group leaks?

Yes, as said "All Players/units... matching condition" does create a group.

oh that's gonna be hell

Yes maybe. :/ I think most ppl had to go through it like they had to redo most of code because they learnt to do better.
But it will be better by time. You will learn much when fixing it and you will think twice before you write code in future, how to handle best and make easy structure.

 

[Shadow Fury]

Wow I've just remade the whole codes and limited the point variables to 2. I've also spotted that I set some point variables and never used them in the command below them XD. Everything works fine and it takes only about 3 seconds now to quit. Perfect! Thanks IcemanBo.

 

[IcemanBo]

Pretty cool! You're welcome.