[Trigger] Simple trigger causing huge lags.

[Hemske]

Hello everyone.

I've added this trigger to stop players from entering the enemy team's side of the map, however, it causes enormous lags if someone tries to enter the other team's side a couple of times in a row. I was hoping someone know the reason for this, as I don't get it. The builder has a 1500 range blink ability, if that is of any relevance.

Thanks.

• Team 1 wrong area
  • Events
    • Unit - A unit enters Team 2 area <gen>
  • Conditions
    • (Owner of (Entering unit)) Not equal to Player 11 (Dark Green)
    • ((Entering unit) belongs to an ally of Player 11 (Dark Green)) Equal to True
  • Actions
    • Unit - Move (Entering unit) instantly to (Center of Team 1 area <gen>)

 

[ap0calypse]

Even though this trigger contains a memory leak (which cause the game to slow down as time progresses), it shouldn't cause any serious lag in a rather short time span.
Casting it a few dozen times shouldn't be all that stressful on the system (it adds up, but nothing to worry about).

Get to know how to fix memory leaks, they're the main cause of games slowing down after some time.

Still, I am convinced that the trigger you've shown us is not the real problem.
Maybe some spawn-system with many memory leaks (those can easily eat up all your memory)?

 

[Hemske]

@Apo, It behaves just like a memory leak, however it goes from no lag to massive in just a couple of seconds, and so far I barely have any triggers at all, and it is always when you do fast blinks into the "not allowed area". Guess I should dust of that book about memory leaks and fix thos and then have another look at it again then.

Been so many years since I last made anything in the WE, forgotten practically everything.

Thanks though. Perhaps it will be enough by doing that.

 

[ap0calypse]

What you could also do is upload the map so I, or anyone else willing, can debug it and look at what goes wrong.
The first thing in my mind was an infinite loop (that the region you get teleported to fires another event), but that didn't really seem plausible.

In any case, there's nothing wrong with uploading the map. If you like privacy, then via PM is a possibility too.

 

[Hemske]

Just uploaded it to another post, as I discovered another bug. Probably easier to help me if people can check it out.

here

Feel free to have a look.

 

[ap0calypse]

Oh, sweet.
Okay, I just checked it and it is indeed an infinite loop.

You teleport to Team 2's Arena and this trigger activates:

• Team 1 wrong area
  • Events
    • Unit - A unit enters Team 2 area <gen>
  • Conditions
    • (Owner of (Triggering unit)) Not equal to Player 11 (Dark Green)
    • ((Triggering unit) belongs to an ally of Player 11 (Dark Green)) Equal to True
  • Actions
    • Unit - Move (Triggering unit) instantly to (Center of Team 1 area <gen>)

That trigger makes you teleport to "Team 1 Area", which activates this trigger:

• Team 2 wrong area
  • Events
    • Unit - A unit enters Team 1 area <gen>
  • Conditions
    • (Owner of (Entering unit)) Not equal to Player 12 (Brown)
    • ((Entering unit) belongs to an ally of Player 12 (Brown)) Equal to True
  • Actions
    • Unit - Move (Entering unit) instantly to (Center of Team 2 area <gen>)

Which makes you teleport to Team 2 Area again and the loop starts over.

This causes a massive amount of leaks in a very short timespan, thus creating a large amount of lag.
I thought this infinite loop wasn't possible because you clearly filter for allies, but the problem is that the players you check for allies are Neutral (which have some aspects of alliance).
So you either have to turn them into computers (therefore, enemies of the opposing team), or filter for allies of player 1/5.

 

[Hemske]

I thought this infinite loop wasn't possible because you clearly filter for allies, but the problem is that the players you check for allies are Neutral (which have some aspects of alliance).
So you either have to turn them into computers (therefore, enemies of the opposing team), or filter for allies of player 1/5.

Oh, I did not know this. That clears it up, thanks!

 

[Dr Super Good]

(those can easily eat up all your memory)?

No they cannot. The game will crash due to finite structure depletion ages before it hits the virtual memory allocation limit.

The main problem with leaks is that some opperations of the game engine have an O(f(n)) complexity where n is the number of allocated objects. As you are leaking objects that make up n you will degrade the performance of the engine.

 

[BloodDrunk]

No they cannot. The game will crash due to finite structure depletion ages before it hits the virtual memory allocation limit.

The main problem with leaks is that some opperations of the game engine have an O(f(n)) complexity where n is the number of allocated objects. As you are leaking objects that make up n you will degrade the performance of the engine.

so powerful knowledge

 

[edo494]

actually if you have not enough ram it can hit heap limit
I once made trigger like this:

• Events
  • Time - every 0.00 seconds of game time
• Actions
  • Set loc1 = Random Point in(Playable Map Area)
  • Unit - Create 1 footman at loc1 facing default building position

and I watched the RAM usage and it went up to 1,2 gb untill it filled the handle table up and crashed so if you dont have enough ram you may hit your ram limit

 

[Dr Super Good]

and I watched the RAM usage and it went up to 1,2 gb untill it filled the handle table up and crashed so if you dont have enough ram you may hit your ram limit

Someone clearly does not know how virtual memory works...

Each process has its own memory allocation that is done in units called a page. These pages represent a mapping between data in memory and the local process address space. Not all pages of a process need to be unique to that process, nothing stops a page being mapped multiple times in a process at different address accross multiple processes.

Inorder to allow your computer to have more pages allocated than physical memory it uses a page file to store the excess pages (generally the least used pages to avoiud page faults). The page file is not used for pages from memory mapped files as those files themselves back up the pages.

This means there are two limits to the amount of memory a process can allocate.
1. The virtual address space (range of addresses) a process can allocate (either 2 of 4 GB for 32 bit programs and a stupidly large number for 64 bit programs).
2. The total amount of storage space for pages (memory mapped files, memory and page file).

Both will cause an out of memory error.

A process allocating 1.2GB should not crash unless run on a very old system.

 

[edo494]

well yea I didnt know the thing with pages but the thing that crashed was Warcraft's handle table because it got filled to max size