It's entirely up to how the devs coded the mechanic to work. I'd assume it's done using coordinates so Points aren't even involved, but even if they were, assuming that they "probably leak" seems wrong to me. The code ain't perfect, but the good majority of functions are
leakless.
Nothing "needs" a Point either, you're just pushed to use them in GUI because the devs figured it was an easier concept to follow. Everything position based in this game is handled with x, y, and z coordinates. A Point is simply a container of those meant to simplify the process (although, often adding extra steps). Points are almost entirely unnecessary outside of GUI.
So I think I'll add through another trigger this event and trigger it by regions.
I'm not too sure I understand. You're going to use the same Event but in another Trigger? Why would that change anything? Or do you mean you'll rely on Region Events instead of this "Within Range" Event?
Anyway, dealing with Point based memory leaks is really simple:
-
Set Variable Point = somewhere
-
-------- Use the Point variable --------
-
Custom script: call RemoveLocation( udg_Point )
It's a basic rule: Set, Use, Remove.
If you ever Set the same Point variable again before Removing the previous one, you've created a memory leak.
Also, if your initial Conditions block can't reference a Point variable since it happens before the Actions have a chance to Set any, that just means that you should be relying on an If Then Else instead. That would give you a new Condition block to work with, and one that can be ordered before or after you've Set your variables.
