What poot means could be summarised in this way:
when using the function on a location a small area of 32x32 is affected.
(Compare the panels in the world editor below.)
So... let say wou want it to affect this rect with the size 512x512 what you would do is, like poot said, using two loops, one inner loop determinating the x coordinate and the other loop determinating the y coordinate.
In Gui this would be something like this:
-
WalkabilityRectOff
-
Events
-
Conditions
-
Actions
-
-------- RectExample is just creating a rect which I will use in the trigger --------
-
Set RectExample = (Region(-256.00, -256.00, 256.00, 256.00))
-
-------- --------
-
Set minX = (Integer((Min X of RectExample)))
-
Set minY = (Integer((Min Y of RectExample)))
-
Set maxX = (Integer((Max X of RectExample)))
-
Set maxY = (Integer((Max Y of RectExample)))
-
For each (Integer A) from (minX / 32) to (maxX / 32), do (Actions)
-
Loop - Actions
-
For each (Integer B) from (minY / 32) to (maxY / 32), do (Actions)
-
Loop - Actions
-
Set temppoint = (Point((16.00 + ((Real((Integer A))) x 32.00)), (16.00 + ((Real((Integer B))) x 32.00))))
-
Environment - Set terrain pathing at temppoint of type Walkability to Off
-
Custom script: call RemoveLocation( udg_temppoint )
Note that in Gui this trigger would be very inefficient, as
A: you cant use x and y coordinates inside the loop unless you use a custom script (which is kind of easy to fix anyhow)
B: you cant use the looping in an efficient way without doing it all in jass.
C: due to B we use a loop of integers instead of reals, which is not having the same accuracy when gaining the coordinates.
D: Loops has a threshold of an amount of loops allowed in a trigger without using wait actions (I dont know how much). If the rect would turn out to be too big, it will loop until it hits the threshold, thus failing to affect the whole rect.