TriggerRegisterEnterRectSimple(t, GetPlayableMapRect())

[ZiBitheWand3r3r]

What is wrong with this event call TriggerRegisterEnterRectSimple( gg_trg_t1, GetPlayableMapRect() ). Personaly I have not experienced problems but recently two users reported strange units behavior
[Solved] - Desync & Weird unit behaviour
[code=jass] - too many "Enters Region" events?
it may (or may not) be related to event feature
this trigger freezes game (task manager to close is required):

• enters
  • Events
    • Unit - A unit enters (Playable map area)
  • Conditions
  • Actions
    • Trigger - Turn off (This trigger)
    • Unit - Create 1 Footman for Player 1 (Red) at (Random point in (Playable map area)) facing Default building facing degrees
    • Trigger - Turn on (This trigger)

but this ver works fine:

• enters1
  • Events
    • Unit - A unit enters (Playable map area)
  • Conditions
  • Actions
    • Trigger - Turn off (This trigger)
    • Unit - Create 1 Footman for Player 1 (Red) at (Random point in (Playable map area)) facing Default building facing degrees
    • Countdown Timer - Start timerT1 as a One-shot timer that will expire in 0.00 seconds

• timer
  • Events
    • Time - timerT1 expires
  • Conditions
  • Actions
    • Trigger - Turn on enters1 <gen>

I hope we gather some info about this event here

 

[Aniki]

What is wrong with this event call TriggerRegisterEnterRectSimple( gg_trg_t1, GetPlayableMapRect() ). Personaly I have not experienced problems but recently two users reported strange units behavior

function Trig_enter_Actions takes nothing returns nothing
    call DisableTrigger(GetTriggeringTrigger())
    call CreateNUnitsAtLoc( 1, 'hfoo', Player(0), GetRectCenter(GetPlayableMapRect()), bj_UNIT_FACING )
    // call TriggerSleepAction(0.0)
    call EnableTrigger(GetTriggeringTrigger())
endfunction

My guess is that the "Enter/Leave rect" events are dispatched at the end of the frame or something... but by then EnableTrigger has been called, so we get an infinite recursion?

 

[Wietlol]

Bribe has analyzed this when he made his Unit Indexer.
It turns out that the filter used in the native RegisterEvent function runs at the moment that the unit is created, but the trigger is added to the queue to execute at the end of the current stack.
Which essentially means, that your trigger is enabled again by that time for the footman.

 

[Emm-A-]

@
ZiBitheWand3r3r: good idea to analyze this. The unit behavior in my case was exactly the same as in SpasMaster's video by the way.
Does it make a difference, if you specify a rect in your example, or does it only bug out if using the whole map?

 

[ZiBitheWand3r3r]

Bug (game freeze) occurs in all map sizes (from 32x32 to 480x480).

if you specify a rect in your example, or does it only bug out if using the whole map?

It depends on rectangle size:
1. rectangle is smaller then playable map area --> no freeze, but game generates about ~1000 footmans (each time I run a test quantity varies)
2. rectangle is equal to playable map area (or bigger: it covers part of a shadowed map border) --> game freezes

It must be enabling trigger when footman is created like Wietlol said. For case 1: it is not infinite loop, game ends this loop (after created few hundrets ..to.. ~1000 units)

for case 2
game not crash but freeze

 

[Wietlol]

So you say it is stuck in a loop but gets out of that "infinite" loop by some unknown cause?
I cannot see a thread crash nor op limit thoug.

 

[IcemanBo]

Might it be because you create a unit at <Random Point> ?

 

[ZiBitheWand3r3r]

So you say it is stuck in a loop but gets out of that "infinite" loop by some unknown cause?

for case 1: yes, it looks like you said
game generates once:1205 footmans, other time 1134, diffrent quantities

Might it be because you create a unit at <Random Point> ?

Dont think so, because I cleaned leaks (location) if that is what you mean. Nothing changed

 

[Wietlol]

random point as in... invalid point?

If the game is caught in a semi-infinite loop, it will freeze for quite a long time until it leaves that loop.
there has to be a reason it stopped.

EDIT:
Turns out the "infinite" loop did end.
When a unit is created, it is first checked for a correct pathable position.
So a unit might have a slight offset to the actual position given as parameter to create it.
If that offset is away from the center of the region and the random point was close enough to the edge, it would not run that trigger again, thus causing it to stop the "infinite" loop.

But that doesnt exclude the problem of the actual loop.

In JASS, it works fine as you can choose a filter on the event instead of an action/condition on the trigger, in which case, it does run immediately instead of after the current stack.

In GUI... good luck with that.
A workaround could be made.
Aka, when a unit enters the map, create the footman and set a boolean to true, if that boolean is true, you do not create the footman and instead set the boolean to false again.
The same could be done with integers to have a set amount of units be created.

Another way is to check the unit type of the entered unit... but then it gets slightly out of hand with configuration.

 

[ZiBitheWand3r3r]

Turns out the "infinite" loop did end.
When a unit is created, it is first checked for a correct pathable position.
So a unit might have a slight offset to the actual position given as parameter to create it.
If that offset is away from the center of the region and the random point was close enough to the edge, it would not run that trigger again, thus causing it to stop the "infinite" loop.

Brillant! Now I understood why it happends.
So can I say this event TriggerRegisterEnterRectSimple is not quite save for GUI use

 

[Wietlol]

Ofcourse it is safe, but you can run it again by creating a unit inside the region that is monitored.
If you think that is unsafe, then you better get rid of pretty much 90% of the entire GUI API.
I mean, all down to "Trigger - Run (This trigger)" is able to create an infinite loop.