Closed SRL-Nebula closed 12 years ago
Why switch from degrees to radians?
Also I can't commit this because it will break any script that calls PercentColorMMEx since you changed the parameters.
Radians makes a lot more sense mathematically, but right now this would break too many scripts and utilities. I'm all in for the idea though!
You could make a separate radians functions if you wanted.
PercentColorMMEx requires vars StartRadial and EndRadial to be in radians. PercentColorMM uses PercentColorMMEx, but not in the correct way. PercentColorMM searches from 0 to 360, which is not a radian measure. This flaws PercentColorMM, making it ignore a piece of the minimap. -pi and pi are the correct values. Radians are typically extended values, because 6.28 radians = 360 degrees; which requires the StartRadial and EndRadial paramaters of PercentColorMMEx to be changed to extended. When those paramaters are integers as they currently are, the search can only be changed in 57 degree increments (1 radian = 57 degrees).
I didn't change any functions from using degrees to using radians. PercentColorMMEx is setup to use radians, but PercentColorMM inputs degrees not radians, making a chunk of the minimap not used.
I know, you're right, but it would still break scripts. You're right that it needs to be fixed, though. You should open an issue in the SRL-6 repo. stating the problem so we're sure to fix it then.
I could be wrong but i don't think the functions are wrong.
FilterPointsPie actually uses degree rather than radian, which means PercentColorMMEx should indeed use Degree. Rather, the parameter names are wrong: StartRadial, EndRadial should be changed to StartAngle, EndAngle. (but maybe they do intend it to be 'radial': radial != Radian) Everything else is correct i think. If you want you can create a request to change the parameter names (which won't break the scripts)
Fixed not using radians.