Looks good! new beta working flawlessly for $onpoly(). I haven't been able to break it so far. The only one I've been able to break is $inpoly()
I still get a blue dot if the point is on one of the line segments defining the polygon. Picture a piece of paper cut out in the shape of that polygon. the edges of our piece of paper is stained (symbolizing our drawline outline) Points on this "stained" edge aren't considered "inside" the polygon, as if this very edge is considered a container, and not part of the surface of our polygon definition.
I do know it's rather difficult to get the blue dot to show depending on your mouse's set sensitivity to get small enough movement increments to get this to show.
$onpoly() catches these edge cases and is highlighting the line fine, just $inpoly() is not catching the line segment endpoint.
it does however catch it if I adjust the points to be 1 extra pixel away from the origin [0,0] using $inpoly() so I know it's due to the outline not being considered part of the surface.
=========================================================
Edit:
=========================================================
Further testing outside of this mouse test shows $inpoly() returning true for any random point picked from the polygon definition, so this turns out to be some sort of precision error using a point on a line inbetween the two endpoints on this last screenshot.
Not sure about if it's mSL's limitation of 6 decimal positions causing mine to return differently than mIRC's or not, but I can't ever seem to get a green dot from mIRC when getting a non-axis-aligned linesegment to fall perfectly on a point, so maybe mIRC's $inpoly() epsilon for error adjustment is too fine, and never considering any points between linesegment ends on the same plane from returning true, or it's mSL's precision limit of 6 causing mine to falsely return true.
It's going to take a bit of re-working on the onpolytest because I need to find the linsegment now in the mouse poly that caused $onpoly() to be true, but not $inpoly() for a specific endpoint from a linsegment test.
I can use this simple "equasion ax + by + c = 0" plugging in my endpoint for the x,y and solving. if the return is 0, it's on the line, if it's negative or positive it's on one side or the other of the line and not truely on the line.
Either way this should give me the epsilon threshold between the two methods and see why one returns differently than the other.
My running theory is a point is treated as an INT and not a FLOAT or DOUBLE so there's no decimal places, rounding definately ensures the point's not on the linesegment, since it lost any half-space data (decimal values)
I'll post back my findings and probably make a simpler test just for this specific case.
