I am pretty certain i'm right in thinking that this kind of code is meant to retrieve a direction which points towards a given object:
{
//The mouse is the object we're pointing at
-always
+anglevalue=ArcTan(ydistancevalue/istancevalue)
+istancevalue=xmouse-x(active)
+ydistancevalue=ymouse-y(active)
}
This is simply following an idea behind a method of finding the angle between two points on a linear set of cartesian co-ordiantes. If you get yourself a scientific calculator and type in the values in the code, you can retrieve the angle between two spots by using Arc Tangent and the points x and y positions.
The clickteam software doesn't want to behave the same way. I find that when I use this code the andgle angle value comes out very obsurely. Roughly between the angles 80-110, 250-290 (the angles being between the active object and the mouse) I retrieve something which looks roughly like a proper value. Anything outside those appoximate values are either rounded to a pretty random value, or are 0.
I'm thinking its going to be pretty hard for someone to find a solution, but if anyone else actually works with clickteam products and much raw trig, could they give me an idea into why this could be happening?
its because clickteam doesnt like to use floating point numbers. those bastards.
use an extension to do it. advanced direction object (gets you your angle easy) or advanced math object (lets you set the decimal offset and use maths)
Yah, you'll need the advanced math object and some mathematical trickery to work around it. Just assume that your numbers are being rounded to integers at every single possible operation in each expression.
Advertisement
Post Reply
istancevalue)
> than object 
