[Solved] Help whive lag on a trigger

[Naadrezine]

Hello,

I just joined this comunity to ask for your help whive a new map i made.
In this map i have this trigger :

• attaqueud
  • Events
    • Unit - A unit enters Chateau ud <gen>
  • Conditions
    • ((Triggering unit) is in (Units owned by Player 2 (Blue))) Equal to True
  • Actions
    • Wait 2.00 seconds
    • Set tempgroupud = (Units in Chateau ud <gen> owned by Player 2 (Blue))
    • Set necropole = (Position of Black Citadel 0001 <gen>)
    • Unit Group - Pick every unit in tempgroupud and do (Actions)
      • Loop - Actions
        • Unit Group - Pick every unit in tempgroupud and do (Unit - Order (Triggering unit) to Attack-Move To necropole)
    • Custom script: call DestroyGroup (udg_tempgroupud)
    • Custom script: call RemoveLocation (udg_necropole)

The goal is to summon units whive an other trigger, then order them to attack the player.
So there is 2 problems whive this trigger :
-not all units are taken to the group who is attacking. Some stay on the spawn point and whive some time, create a big bunch of useless units.
-Even when there is a lot of units who move at the same time, the game don't lag. Thanks to the nice leaks topic i read on this forum. But, if another unit come into the spawn point (not a blue one), the game lag a lot, and could even crash.

At first, i though the problem was coming from one of the blue unit in spawn, who have the ability to resurect ally. But even if i removed it, the game lag.
There is also, some blue turrets in the spawn point, i tried to remove them. It cause less lag but its still lagging.

Do you have any idea?

 

[Rahko]

You are picking the units twice creating two loops, which can get quite hefty. That's probably the reason. For example, if the player has 100 units, it first picks all the 100 units, then it picks all the 100 units again - 100 times again. That's a lot of picking. And you should use (Picked Unit), not (Triggering Unit), on the Pick Units action.

Also, you're leaking a unit group on the condition. This is what the trigger should look like:

• attaqueud
  • Events
    • Unit - A unit enters Chateau ud <gen>
  • Conditions
    • (Owner of (Triggering unit)) Equal to Player 2 (Blue)
  • Actions
    • Wait 2.00 seconds
    • Set tempgroupud = (Units in Chateau ud <gen> owned by Player 2 (Blue))
    • Set necropole = (Position of Black Citadel 0001 <gen>)
    • Unit Group - Pick every unit in tempgroupud and do (Actions)
      • Loop - Actions
        • Unit - Order (Picked unit) to Attack-Move To necropole
    • Custom script: call DestroyGroup (udg_tempgroupud)
    • Custom script: call RemoveLocation (udg_necropole)

Also, I would recommend not using waits. It might work, but it is usually better to try to find a way to do things without waits. Or if they are a must, then find a way to use timers and then you also have to take into consideration the trigger being MUI (meaning that many units can fire it without messing it up). For example, imagine what now would happen if two units entered the region just one second apart from each other? (It might work in this case, but just something to think about.)

 

[Naadrezine]

Thanks a lot this is way better!
English isn't my native language so i don't really understand the difference between triggering and picking.
So triggering unit define the unit affected by the trigger and picked unit is the unit affected by the "pick every unit" right? But my unit is affected by both of them so why picking is the best choice?

 

[Rahko]

Triggering unit is the unit that fires the trigger. For example "Unit - A unit enters Region", the A unit is the Triggering unit. Or "Unit - 'A unit' dies", Triggering unit is the "a unit" that dies, i.e. dying unit. Etc. Or the "A unit Sells a unit" is a good example. Here, just like in the other events, the first A unit is the Triggering Unit, i.e. in this case the building, a shop or mercenary camp (buildings are units too), is the Triggering Unit. And if you want to refer to the second a unit, you have to use the "Sold Unit" from the list where you would choose the Triggering unit as well.

If I've not rambled on long enough, in short: Triggering unit is the first "a unit".

Picked unit is the unit you literally pick. For example: if you pick units in a region, and there are 10 units in it. The game then will pick all those 10 units and run the code for every one of those units, so 10 times in total. Imagine it like this: you have two lists. First list the is the names of each of the units you pick with the action. Second list is all the actions you put under the Pick Units action. Then you start to go through the Picked Units one by one and run all the things on the second list for each unit on the first list over and over again, until you have gone through all the picked units.

This is how you can filter the picked units: if you put an If-then-else right at the start of the actions, the first thing the game will check is the if. Like, you could pick all units in the map and then put an if: If (Picked Unit) equal to Footman then Kill (Picked Unit). This would mean that it would put all the units on the map on the first list and then put the action "Kill (Picked unit)" on the second list. Then it will start to go through the picked units and ask: is it Footman? If it is, then it will read what is on the second list. If not, it will just move to the next unit.

And that is exactly how the Unit Group in your example is created: "Units Owned by Player 2 (Blue)" means that the game has gone through all the units in the game and on each unit's turn it asked: "is it owned by Player 2?" If it was, then it was added to the unit group, if not, then the game just moved on to the next unit.

..
Heh, sorry for the long post. Got a bit carried away... xP Hopefully this answered your question.

 

[Uncle]

This is something I just learned after all of these years. It turns out that Regions are bugged and have the incorrect size. So when working with A unit leaves/enters region you'll encounter problems that logically shouldn't happen.

The trigger below fixed this issue.

It also fixed any problems with situations like: "A unit enters Region 1" -> "If triggering unit is in Region 1 = True" -> "Do stuff". The condition returns False despite the fact that it should clearly be True. The game doesn't find the triggering unit in Region 1 even though that the unit just fired the Event. This is because the size of the rect (region) is off and needs to be fixed.

Furthermore, the size of the region seems to be correct when determining "A unit Enters/Leaves Region" but incorrect when doing something like "Pick every unit in region" or "Is unit in region = true/false". So the size is correct in one instance but incorrect in the other. This inconsistency would explain why it has problems.

• Region Setup
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Custom script: local rect r
    • Set TotalRegions = 3
    • Set Region[1] = Region 001 <gen>
    • Set Region[2] = Region 002 <gen>
    • Set Region[3] = Region 003 <gen>
    • For each (Integer A) from 1 to TotalRegions, do (Actions)
      • Loop - Actions
        • Custom script: set r = udg_Region[bj_forLoopAIndex]
        • Custom script: call SetRect(r, GetRectMinX(r) - 32., GetRectMinY(r) - 32., GetRectMaxX(r) + 32., GetRectMaxY(r) + 32.)
        • Custom script: set r = null

This will correct the sizes of Region[1], Region[2], and Region[3]. Modify/add more of these Variables for each Region you use in your map. Set TotalRegions to be equal to the total number of Regions you use in this trigger.

Maybe someone can correct me if I did this wrong or if it leaks, but my Region-related triggers started working after doing this.

 

[Naadrezine]

Very interestings answerds !
So now i understand why picked unit was better than trigering unit in this situation, thanks a lot Sabe.
I suppose this region bug is the reason why not all the units are taken in the issue order, thanks Uncle. I have to make a lot of tests to adapt your trigger to mine.