Help with vector calculations

[[FRL]Myke]

Hi all,

as i'm really no good in vector calulations *cough*....means i really don't understand those, i would need some help from a math guru with a very special vector calculating problem.

Situation:
I have 2 known positions, POS1 and POS2. These are connected with a imaginary line, same way as waypoints in editor are presented. I'm not talking of editorwaypoints here, just for easier imagination.
As last reference point, i have my own position which might be somewhere but probably not on the imaginary line.

The formula (not script, once i have the formula i might be able to wrap myself a script around it) i need is how do i determine on which side of the imaginary line my actual position is.
Say i'm looking from POS1 along the line to POS2, is the investigated position left or right of the imaginary line and how far away from it.

And as a second formula, how is the formula to determine my relative heading to this line. So let's assume the line has a compass heading straight north, also i am looking straight north so relative difference in heading would be +-0. How would a formuly for this purpose look like?


As said, i don't need it scripted "ready-to-use", just a formula which ArmA 2 will understand and which i can wrap a script around it.
And please, keep your explanation as simple as possible, as you would explain it to a 3 year old child.

[CarlGustaffa]

I'm not very much into maths, and vectors are beyond me. but I would solve problem one using a new cartesian coordinate (all lookups being polar) system placed on one of the points (the southern one for easiness), and rotated so that its north is pointing towards the second point. Figuring out your own position relative to the line would be checking if new x coordinate is positive (right of) or negative (left of).

I'm using the same principle to check if a point is located within a rotated elliptical marker at a given point. Hard to do without rotating my point and ellipse to zero degrees around ellipse center, and moving everything from ellipse center to [0,0]. See last thread here for actual code. Some new functions in Arma2 I assume does something similar in insideTrigger function, but I haven't checked.

The second one should be easy (without vectors at least ). Two points on the line create an angle using atan2. Point at your position and an arbitrary point along your view direction also create an angle. Subtract the angles and there is your difference.

That's how I would think for solving the problem, with no respect to method used. It might be easier ways though. Again, I'm not very much into maths. If you're only interested in solving by vectors, then ignore this post

[blakeace]

Bear in mind it has been a long time since doing a lot of these types of things.

Possibly look at this page on Linear Equations.

Specifically the section on two point form.

Basically the formulae has three sets of x and y.
x1,y1
x2,y2
These would be the two points that define the line.

then x,y would be your location.

Instead of the equals sign, determine if the result to the left greater or less than the result to the right.

Assuming [0,0] is the bottom left of the map then.


If the right side is greater than the left then you are above the line.
If the right side is less than the left you are below the line.
If the two sides are equal you are on the line.

Note it is required you have different values for x1 and x2 meaning you cannot check for a vertical line meaning you would have to have an exception an check that a more easy of comparing the relative x values only.

I derived my information from here.
http://en.wikipedia.org/wiki/Linear_equation

Hope this helps, but bear in mind I am very rusty at this maths stuff.

[ruebe]

For your first problem, you can use the ccw algorithm (as described here, though in german, it does offer a good illustration):

private ["_ccw"];

// p0, p1, p2 => scalar, where
//  _ccw < 0  == clockwise
//  _ccw == 0 == collinear
//  _ccw > 0  == counter-clockwise
_ccw = {
   ( 
      (((_this select 1) select 0) - ((_this select 0) select 0)) *
      (((_this select 2) select 1) - ((_this select 0) select 1)) -
      (((_this select 1) select 1) - ((_this select 0) select 1)) *
      (((_this select 2) select 0) - ((_this select 0) select 0))
   )
};

In your case p1 refers to your position and you need to sort/swap p0 and p2 (sort by y) to be able to determine a "left" or "right".


As for your second problem, you can retrieve the "heading" of the line easily with the BIS function library/module, since this is the relative direction from p0 to p2:

   _lineHeading = [_p0, _p2] call BIS_fnc_dirTo;

Now you can easily compute the difference to your angle, though there most likely are two, a smaller and a larger one. You probably wanna opt for the smaller one.. Though, I don't quite see, what you're gonna do with this difference in angle. Aren't you more interested in a direction from p1 (player) to a point on the line, be it p0, p2 or the intersection point where the normal (90 angle onto the line) from p1 hits the line (which is the smallest distance between point and line)?

[[FRL]Myke]

I have to read through those answers after i got some sleep, right now i can't follow it pretty far but i'm sure it probably lacks of my knowledge rather than on the explanations.

To give an idea what the purpose is, it is about to fill this gauge with more or less sensefull life:


The compass itself is just a regular compass, not involved in this problem here.

The part with the 4 dots horizontally and the pointer which points to the N on the pic does rotate depending on the set curse (waypoints-like but not from actual position but from WP to WP). And finally the vertical line which on the pic is on the far left and which indicates where the Flightpath relative to the plane is located. This line rotates along with the underlying curse indicator and moves only in a transitional path. The plane symbol in the middle is fixed and doesn't rotate nor move at all, indicating actual heading of the plane.

The far goal is to simulate VOR/ILS functionality, more than ArmA 2 actually provides as usable data. Also flight path (waypoint-like) should be displayed with this gauge with data provided from avionics system of the plane.

[Evil_Echo]

There are a bunch of routines buried in the BI functions library and more in the CBA mod. And then I have some code that does even more - tensor routines make vector manipulation easy.

[blakeace]

I have to read through those answers after i got some sleep, right now i can't follow it pretty far but i'm sure it probably lacks of my knowledge rather than on the explanations.

To give an idea what the purpose is, it is about to fill this gauge with more or less sensefull life:


The compass itself is just a regular compass, not involved in this problem here.

The part with the 4 dots horizontally and the pointer which points to the N on the pic does rotate depending on the set curse (waypoints-like but not from actual position but from WP to WP). And finally the vertical line which on the pic is on the far left and which indicates where the Flightpath relative to the plane is located. This line rotates along with the underlying curse indicator and moves only in a transitional path. The plane symbol in the middle is fixed and doesn't rotate nor move at all, indicating actual heading of the plane.

The far goal is to simulate VOR/ILS functionality, more than ArmA 2 actually provides as usable data. Also flight path (waypoint-like) should be displayed with this gauge with data provided from avionics system of the plane.

Ok emulating a VOR is fairly easy, basically all aVOR gauge does is track how many degrees you are off your desired track that you entered into the gauge.

As such a VOR gauge is more sensitive the closer you get to the vor station.

So all you need to do is enter the desired beaing, then check that against the aircrafts actual direction to the vor station. The needle deflection is then calulated relative to the amount of difference between the two values.

Here is a quick script I used for my own testing. Note you would need further code when checking the 360-0 mark one when one value is on one sid and the other is on the other side of 0 degrees.

_point2 = getmarkerpos "w2";
_pointA = position player;
private ["_Left","_Right","_offset","_lineHeading"];

while {true} do
{
_lineHeading = 327;
_lineHeadingP = [_pointA, _point2] call BIS_fnc_dirTo;
if (_lineHeadingP < 0) then
	{
		_lineHeadingP = 360 + _lineHeadingP ;
	};


_diff = _lineHeading - _lineHeadingP;

If (_diff < 0) then
	{
		hint format [" Track %1 Left of Track %2",abs(floor(_lineHeading)),abs(floor(_diff))];
	}
	else
	{
		hint format ["Track %1 Right of Track %2", abs(floor(_lineHeading)),abs(floor(_diff))];
	};

	
sleep 2;
_point1 = getmarkerpos "w1";
_point2 = getmarkerpos "w2";
_pointA = position player;

};

Now if you emulating a gps you might have to go complicated like this to calculated the distance off track. So the below script checks the distance of the line perpendicular to the desired track. Not the angle. It's a bit rough but I mocked it up to test my theories validity.
This one is based one my first posts theory, and doesn't include the special case of a N-S S-N tracks where x1 and x2 are equal.

_point1 = getmarkerpos "w1";
_point2 = getmarkerpos "w2";
_pointA = position player;
private ["_Left","_Right","_offset","_lineHeading"];

while {true} do
{
	//Left and Right represent the formulae sides as per the two point form in the link.
	// http://en.wikipedia.org/wiki/Linear_equation

	If (_point1 select 0 != _point2 select 0) then
	{
		_Left = ((_pointA select 1) - (_point1 select 1));
		_Right = ((_point2 select 1) - (_point1 select 1))/((_point2 select 0) - (_point1 select 0) )*((_pointA select 0) - (_point1 select 0));
	};

	//Obtain line direction and convert to 0-360 format.

	_lineHeading = [_point1, _point2] call BIS_fnc_dirTo;
	if (_lineHeading < 0) then
	{
		_lineHeading = 360 + _lineHeading ;
	};

	//Need to check direction of the line to determine if being above or below means to the left or to the right.
	_dist = abs(floor(_Left - _Right)) * sin _lineHeading;
	if (_lineHeading < 180) then
	{
		if (_Left < _Right) then
		{
			_offset = format ["Right of track %1" ,_dist];
		}
		else
		{
			_offset = format ["Left of track %1" ,_dist];
		};
	}	
	else
	{
	if (_Left < _Right) then
		{
			_offset = format ["Left of track %1" ,_dist];
		}
		else
		{
			_offset = format ["Right of track %1" ,_dist];
		};
	};
	//_dist = abs(floor(_Left - _Right)) * sin _lineHeading;

	hint format ["Dir %1 : %2", floor(_lineHeading),_offset];
	//hint format ["Dir %1 : %2", floor(_lineHeading),_dist];
sleep 3;
_point1 = getmarkerpos "w1";
_point2 = getmarkerpos "w2";
_pointA = position player;
};

[[FRL]Myke]

@blackace

Thanks a lot mate. Your second script provides exactly the data i need. With this i'm able to apply correct (nearly as) anims to the gauge. I have to adapt some small things for my needs but this isn't much of a hassle. Really appreciate your help on this.

Also thanks to all others that replied here. Always thankfull for all input, ever.

[CarlGustaffa]

Omfg, I guess that HSI/EHSI would be nice for the flyboys As an old flight sim fanatic involved in panel/gauge design, I know the kind of work you're up against I made a "near full implementation" (some impossible ones were replaced with artificial functions, such as holding entry display) of the Sandel SN4500 EHSI for flightsim, but that of course has much better support for gauge modelling.

How do you plan on implementing VORs and radio frequencies? Do they exist in the game? The "ILS" in ACE seems a bit weird to me, hopefully this HSI will give a better representation.

[[FRL]Myke]

To be honest, the VOR implementation will be artificial and i doubt that hardcore-flightsim-players will be 100% happy with it. At least it will be generic (works on all islands/terrains with correct ILS config settings) and help to line up for landing at bad weather conditions.

I've not put it down in each detail but general idea is to have 1 VOR straight lined up with the ILS/runway in XXX meters (have to test what fits best here) and another one in 45degree off this imaginary line so you'll get a rounded approach. Hope you get what i mean.

Besides that, the HSI shall also show waypoints, be it editorplaced WP's or WP's defined by the Pilot itself during preflight preparations.