This script returns one array of two entries carrying the [top,left] coordinates on the screen of a segment whose (arguments as follows) startTop, startLeft, length, angle are known. Accepts a 5th argument named angleIsRadians if the unit measure you're passing the angle is, for some reasons, radians instead of degrees: if so pass also such argument as number 1.
Note that an angle is mandatory, since from an origin given by startTop and startLeft coordinates there could be, stretching out at the given length, an infinite number of possible lines if no angle is known.
 
possible invocation:
foo=endPlotter(0,0,500,45)
then:
foo[0] is endTop coordinate,
foo[1] is endLeft coordinate.

Knowing a set of coordinates on two screen points (or segment edges, so arguments as follows:) startTop, startLeft, endTop, endLeft whereas has no relevance which one you consider the starting pair and the ending one, this script returns a number which is the distance (length) of the segment.
A similar script but with more complex output and more geared to be used with ULMA is distances().

Given a single segment whose (arguments as follows) startTop, startLeft, endTop, endLeft set of coordinates are known, produces the angle such segment has, following the angle convention for single segments that was outlined above (which is, by the way, a mathematical standard).
5th argument named inRadians if set to 1 produces the result in radians, for the script defaults to degrees.
Obviously, if you want to reverse the result, you can subtract 360-returned output.

As the name suggests by the number 2, this script can return the angle formed by 2 segments.
The segments must have a common origin (that is, same startTop and startLeft coordinates, or positively no actual angle would exist between the two segments!): therefore startTop and startleft (called in the script originTop originLeft) coordinates are shared. It differs instead as far as the following coordinates (give a glimpse at the script now if you wish) endTop1 endLeft1 endTop2, endLeft2 for the two segments might arguably have different ending points.
The script assumes that the segment whose ending coordinates refer to endTop2 endLeft2 is the segment revolving around the other, therefore if the first is, say, horizontal, and the second ending coordinates are, say, southwest oriented, the angle would be between (see again the convention table if you prefer) 181 and 269. If you just want the opposite, that is imagining that the situation is inverted, just subtract 360-returned value!
 
Last argument inRadians to get (if set to 1) the result in radians instead than in degrees, as usual.
anglePlotter2() requires anglePlotter() being defined in the same script in order to work!

This script has been sort of half a nightmare: alike pathMaker but without having to meddle with ULMA at all, it can plot out all the intermediate steps that a segment is made up of, fragmenting it by steps whose default measurement is half a pixel (although you can set a lower or higher amount in order to fragment your segment in bigger or smaller bits of coordinates), returning an array whose each entry is an array of two entries representing the [top,left] coordinates of the step.
You pass the arguments as follows: startTop, startLeft, endTop, endLeft, unit, reversed, approx, whereas unit defaults to 0.5 but you can lower it: remember that if you lower it, the last meaningful unit you can fragment an object with on browsers and screen pixels is just 0.5 (that is, browsers can't actually do something with fragments of whatever whose incremental unit is lower than 0.5, like moving an object along such coordinate pairs); also, the lower the unit, the most likely rounding problems can be, like two subsequent fragments carrying the same coordinate: this may happen for two reasons: one is that in order to avoid the computer "wrong" rounding given to the numerical internal representation (you may know, that annoying problem that makes a computer represent a number 1.4 like 1.39999999999998 ...!) I round by one decimal (and if you want to override this, pass the approx argument as, say, 100 if you want to round by 2 floating digits, 1000 if you want to round by 3 floating digits, or just 1 if you do not want decimal fractions at all; by default it rounds by one floating digit).
 
The other reason you could get one set of coordinates (either top or left, but not both) whose length is unsuitable to be followed by a browser when, for instance, moving an object along such coordinates, is that either the vertical top coordinates or the horizontal left coordinates are calculated as a ratio from the other: so it may happen that if the ratio (it may happen in case of wide disproportion between the x ending coordinates and the y ending coordinates such as endTop=10 and endLeft=500) is too small and also the unit is small as well, then it is unavoidable that one set of coordinates would exhibit numbers whose increase is so small to be meaningless to a browser (say: 99.997, then 99.998, then 99.999... those numbers might even appear, as a consequence of the rounding by 10, as a set of consecutive 99.9).
If you do not pass any unit argument, the script will attempt to grab the first useful incremental ratio able to exhibit a browser meaningful increase on the affected axis: on the other hand, this might cause the opposite problem: one set of coordinates (say top) incrementing by the first meaningful unit (about 0.5), and the other set increasing dramatically. If you want you can test this by setting in the test form below:

• UNIT: NONE
• EndTop = 10
• End Left = 500

and check the output array increments.
Conversely, whenever you do pass a unit argument, no such internal rearrangement will be performed, and the script will proceed using the unit amount you passed.

Argument reversed just reverses the output array if passed as 1.
Example of a simple invocation:
pathPlotter(0,0,400,-310)
Note that in themselves 5th argument unit (but with the cautions said above, sd maybe you want to consider a good idea passing it or not, depending upon the degree of pixel fragmentation you want) and 6th reverse and 7th approx are entirely optional.

The intersection of two lines is given by a comparison by two line equation both explicited by the ordinate. This script does that, namely verify if two lines cross (only case they don't is if they are parallel, and in this case the script returns false, so always check whether the output is false before attempting to read the alternate output, namely an Array which would carry the coordinates of the intersection point).
Arguments require the starting and ending coordinates of two lines, therefore: startTop1, startLeft1, endTop1, endLeft1, startTop2, startLeft2, endTop2, endLeft2: be careful not to mess up them, and for each line doesn't matter which point you consider as starting and as ending as long as you keep the consistence: first 4 arguments belong to the first line (within whose each set each coordinate must belong to the same point), last 4 arguments belong to the second line.
 
This function requires anglePlotter() to be defined in your script to work for it has to use it.
 
Please do not pass negative numbers: actually you have no reason to do so for your screen, which is your playground, can be seen as a quadrant of only positive coordinates, and so the script would work; if you pass negative numbers (that is, segments that go beyond the screen limits: and honestly I can't see reasons you can't be able to avoid this, all you have to do is to pass just positive numbers) the script would still yield the trigonometric correct result, but since on browsers top coordinates with a negative number are higher upward (yes!), this would cause your output to be sort of a reversed mirror of the screen. Do not pass negative values for the top coordinates.
 
Last but not least, the script returns either false as I said, or an array whose entries are as follows:
[TOPCoord_ofCross, LEFTcoord_ofCross, aFLAG]
So first entry [0] of the output array is the top coordinate of the crossing point, second [1] entry is the left coordinates, the third [2] entry is interesting for if it is 1 it means the segments actually cross, if it is zero, means the segments would cross only if... prolonged beyond their edges! Note that this latest feature is browser specific and would not be reliable to plot out if such circumastance (that is, checking if actual interesction or intersection only if segments are prolonged) applies in a real trigonometric cross (namely not in a mirror-reversed one like on browsers); if you do not want it browser specific, pass a 9th argument (fullTrig... onometric) as number 1, and also the third output entry will be reliable on a standard trigonometric cross.

This is a script that finds the coordinates for a point which is somewhere inside a given line, providing the length level such point must be, or the ratio: that is, if you have a segment whose origin and end points coordinates you know, you may want to calculate what the top/left coordinates of a point in within such segment would be where its length is, say, one third or two fifth or whatever value you can imagine of the current length (actually if such value, passed as argument named fragment is not actually passed, the script defaults to one half: that is: 0.5 or, in other words, the coordinates of the mid point of the segment!). If it is a ratio (such as 1/3 is), you pass such value as the actual division: so if you search for the coordinates of the point located at three fifths of the given segment, you pass 3/5 namely: 0.6
As you are soon to see, you can also pass actual length values, and not uniquely ratios.
 
So arguments as follows: first the starting and ending segment coordinates as: startTop, startLeft, endTop, endLeft, then the fragment (as a ratio or actual length), then an optional 6th argument named isLength (if passed, it implies what you have passed as the previous just mentioned fragment argument isn't a ratio but a length itself: say you want to know the coordinates where the segment's length is say 20pixels: you can pass fragment as 20 and the isLength as number 1 to flag the previous fragment argument is not meant to be handled like a ratio but like an actual length).
7th argument named opposite would provide you, if passed as number 1, the coordinates of the point calculating it in the opposite direction.
On the whole, only the first 4 arguments are mandatory, and the script assumes the fragment value as 0.5 by default (halfway the segment, that is).
Note that passing as the fragment argument a value such as zero and meaning such value must be zero indeed, would be utterly meaningless: it would mean you want to know what are the coordinates of the segment when its length is zero: but you already know such coordinates: they're the starting ones, so you wouldn't need using this function at all, correct? Therefore the function defaults the fragment argument to a positive value (ratio: 0.5) also if you don't pass it or pass it as zero.
 
If you provide length values exceeding the current length of the segment, the script would behave ina way similar to the endPlotter() function and would provide you with the coordinates of the ending point where the given segment would end if it would stretch until it reaches the provided "exceeding" length or ratio.
If the coordinates of the two points (start and end edges) are identical (a nonsense actually: two edges which are identical do not describe a line but a point, so no inclination can be deduced), the script defaults to the behavior accordingly to which the hypothetical segment inclination is vertical: would stretch upward and vertically.
Also: keep in mind that the first point coordinates you provide (startTop, startLeft arguments, those are) are considered like the referring point from where the calculations are to be performed. This does not affect the outcome if, for instance, the start set of coordinates is at a level higher than the end set of coordinates: this is legitimate. Simply, the calculations assume as the reference point the first set of provided coordinates.
 
Example: for a segment in between: [top:0, left:0] stretching to [top:0, left:15] (perchance it is horizontal since it has identical starting and ending top coordinates, just in order to simplify our example), calculate point coords for length=8:
results may yield, depending on how you pass those parameters for the edges coordinates (and also depending on whether you pass or not the opposite argument):

1. [0,0,0,15]=>[0, 8] /* horizontal line, left: 0+8=8 */
   /* if opposite=> [0, -8], for left is: 0-8=-8 */
2. [0,15,0,0]=>[0, 23] /* horizontal line, left: 15+8=23 */
   /* if opposite=> [0, 7], for left is: 15-8=7 */

Therefore the only thing you must be aware is that if the coordinates of the first point (startTop, startLeft) rest at a higher level than the coordinates of the second point (endTop, endLeft), the result might be a point outside the line (see list point 2 above), as if it were stretching beyond its edges. In these cases either you make sure the first set of coordinates belongs to a point lower that the second, or you pass the opposite argument as 1.
Feel free to test with the test Form with some trivial values of your concept, it would make you understand how to effectively use this script.
 
The script returns an array of two entries, first entry is the top and second entry is the left screen coordinates for the point that is the ending point of the given subportion of the segment.
 
In the test Form remember to check the is length checkbox if the fragment value you pass is meant to be a length and not a ratio (this case applies especially if you use the Insert Fake button to populate the form: it won't check the checkbox by itself).