* But there must be a better way than running a frame callback and a timer...
I agree, just could not think of one. One would need an event to be triggered when the hud is restored by an OXP. That could be done by Sniper scope and any other OXP that borrows the hud. Are there any other oxps to be considered by the way?
I'm thinking youse can't replicate it because you've got more RAM than me. ("First, obtain one wimpy laptop...") Yesterday, when it was filling my log with exception warnings, but not crashing (before I started attacking buoys), it was causing a 10 FPS drop in my frame rate. Without a check for compassTarget being null it could have done that any time I jumped to interstellar space. So it might not be one particular calculation causing an exception, just a general spike in resource use...??? (I'm well out of my depth here, it would help if I actually understood this script. )
spara wrote:
Are there any other oxps to be considered by the way?
Try it with the photo-record feature in (the very popular) Explorers' Club OXP. MilHUD always messes that up.
var vVelPtoT = vPtoT.multiply(player.ship.velocity.dot(vPtoT) / (vPtoT.dot(vPtoT)));
But, "vPtoT.dot(vPtoT)" will always return 1. Calculating a dot product with itself makes no sense because it returns 1 by definition.
On the other hand, dot product should be used on normalised vectors, and these are not normalised.
var vVelPtoT = vPtoT.multiply(player.ship.velocity.dot(vPtoT) / (vPtoT.dot(vPtoT)));
But, "vPtoT.dot(vPtoT)" will always return 1. Calculating a dot product with itself makes no sense because it returns 1 by definition.
On the other hand, dot product should be used on normalised vectors, and these are not normalised.
Nope. It returns the magnitude of the vector power two. If it's done with normalised vectors, then it's naturally 1. Hope this makes sense, my english in math is propably terrible .
Edit. But I could use the in-built magnitude function instead. If that would make it more lightweight.
You are not alone. At the start I had also problems understanding all. Specially the 'normal'. In Holland I was used to call the vector pointing perpendicular out of a plane, the normal-vector. In English it is apparently the cross-vector. And normal is used for normalised-vector.
will be positive when pointing towards the target and negative when pointing away. At least it is true when working with normalised vectors. So probably you can skip the angle calculation.
You are not alone. At the start I had also problems understanding all. Specially the 'normal'. In Holland I was used to call the vector pointing perpendicular out of a plane, the normal-vector. In English it is apparently the cross-vector. And normal is used for normalised-vector.
I'm not sure about this. To my understanding normal vector IS a vector perpendicular to another vector or plane. This cross-vector is a new concept to me (and google too ). But I'm familiar with the cross-product, which will result a normal vector to two other vectors.
will be positive when pointing towards the target and negative when pointing away. At least it is true when working with normalised vectors. So probably you can skip the angle calculation.
This is clever, why didn't I think of that . Vectors don't need to be normalised. As long as the angle in rads between them is between 0-pi/2, it will give a positive result. The code just keeps getting better.