RegionAddRect or why RectContainsUnit may fail onEnter

[WaterKnight]

When asked why

• Events
  • Unit - A unit enters Region <gen>
• Conditions
  • (Region <gen> contains (Triggering unit)) Equal To True
• Actions

the condition in this trigger can fail although related to the same region, I usually answered that the GUI rect is not directly applied on the event internally but imitated by a jass region and that checking the coordinates is marginal because the game could fire the enter event before setting the unit's coordinates.

Well, now I noticed that it is not such a matter but that the region created is slightly bigger than the original rect. Regions consist of cells of the size 32*32. When you use RegionAddCell, the coordinates given are reduced to a multiple of 32 (like pathing cells). So the coordinates are those of the lower left corner. A cell at 0;0 stretches from 0;0 to 32;32. What I have not known until now is that RegionAddRect, which is used in the GUI event, takes the max coordinates of the rect to form another row of cells. If the rect goes from 0:0 to 128;128, the resulting region will contain 0;0 to 160;160. Sounds most likely like another Blizzard inaccuracy.

 

[Dr Super Good]

Sounds like an "off by 1" error that is common in programming. It can happen for something as stupid as using <= as the exit condition for a loop instead of just <.

Too bad the error is in the Blizzard source code so no one can fix it. What you could do is compensate for it by cloning the rect, shrinking it appropiatly and then making the region from that (A custom version of RegionAddRect). You could probably even use the same rect if you restore it to the same condition as at the start of the function.

 

[Troll-Brain]

Hmm, iirc it's true, but even with a region sized with multiple of 32 this bug still happen (should be confirmed, it's just my old memory) :

For the enter event, at least, depends where the unit come from (west,east,north,south), when the event will fire, the unit will be out or in. (check X/Y of unit on event fire), also IsUnitInRegion.
I don't think this bug occurs if the unit is moved by trigger, seems that at each unit move with a native function, region events are checked.
That can even lead to lame situations when you play with SetUnitXY, instead of SetUnitPosition.