I had explained that before: due to OFP bugs, the stored result will be considered "null" (using our debug method of hint format, it will return the known and strange string - "0xdede......" or something like this. Besides, it will spare OFP's memory management as you don't have to store variables. Just check a few posts before and you'll understand me.
Never heard about the null bug before? You mean a variable given the address of an object by the nearestobject, command will/can be set to null by mistake?
Now, about your method: have you tested it? Will the area calculation be easier than Spinor's method? Such is important as the game will lag due to excessive calculation.
No testing yet, I do need a terrain scanner for my observer, although for different requirements, so I will give my idea a try.
To be honest it depends on lots of factors, like the relative overheads of using nearestobject, the in command on larger arrays and multiple if statements. It may not even be so bad, having duplicate objects in the final arrays, if it speeds up the initial processing.
hope you understood. I'd explain better in portuguese but... you know
Nope, still none the wiser. But it's no big deal, and my portuguese is a little rusty