"brakes or deccelerate?"

Both gkinterface.GKProcessCommand('+accelerate 0') and gkinterface.GKProcessCommand('+brakes') do not work.

However, you can still decelerate with Game.SetDesiredSpeed(0) because they forgot to remove it, I guess. Now, I am sure it is going to get removed in the next update.

+accelerate 0 stops acceleration. +decelerate decelerates.

And you cannot call any of them via LUA anymore, right?

I can still do it with an alias.

/alias acc '+accelerate;wait 5 +accelerate 0'

None of my relatives play this game, so relative positions would be useless to me.

"I can still do it with an alias."

Erm, do what? I thought you were serious. Well, my fault.

This is going to nowhere, bye all.

Let r = the radial distance to your target.
Let x = the horizontal distance to your target
Let y = the vertical distance to your target
Let z = (r^2-(x^2+y^2))^(1/2)

Lua gives you r. Now solve for x, y, and z using data for four different points in time. In the case of an imaginary solution, assume 0 instead. Cycle data points one hundred times a second, and you'll get your position accurate within a meter or so, except on targets with the exact same vector as you. (e.g. you're both holding still.) Good enough for reference, but sloppier than eyeballing a shot.

With some hacking about you can get your position, and using the changes in your position you can subtract your motion from the motion of your target. I have no idea what you mean by "using data for four different points in time," but I can't think of any system that could be used to determine the position of a dynamically moving object from your distance alone.

Intersecting n-spheres establish the position of dynamically moving objects. Fortunately, the formula for n-spheres are the result of coordinates, and distances. There's a few different ways to get coordinates accurate within a millimeter in the game, and GetDistance() gets distances. Using data for four different points in time means you have to get four distances, and they must be from different points in time. Also they must be different distances, or from different coordinates.

If you have a stationary object, and you know its distances from four distinct coordinates, then you more or less know its position. This can let you roughly map out a sector, for something like autopilot. I helped write a prototype of such an autopilot many months ago, in fact.

The current desire is to be able to get the positions of other ships, which will be moving around quickly and unpredictably. If you had three friends and a previously mapped-out sector or capship you could theoretically get the positions of everyone around you, assuming your fighting didn't take you away from the mapped section, and assuming your data points (friends) don't die. I admit that this is a possible temporary hackish solution to the problem, but its drawbacks are fairly significant. Something that doesn't rely on such a perfect situation would be infinitely preferable.

Erm, how do you get angles relative to where you are facing? The whole thing is pointless without that.

I wouldn't say entirely pointless, but you do bring up a very good point. As far as I know there's no current way to get the direction you're facing, so that would also have to be added. Thanks.

Imagine you had one eye, and you're throwing a ball at something that is stationary. You don't know how large it is, so you don't how far it is. But if you pay attention to your movements, and look at it from enough different vantage points, you can work out where it is. That's the concept I used above, except maybe you're tracking a moving target and it's the shape of a sphere instead of a dot; no biggy--it's just slightly inaccurate. If you still don't get it, whatever--I'd be happy to work out the math and logic if you want to code it.

Angles are a devil to work out. You could get your position in relation to the capital's facing by paying attention to where its turrets are at least. There's another trick though--GetDistance() returns the distance from your arbitrary center, to the surface of your target. So very hypothetically speaking, if four players were all linked together sharing their coordinates, and the exact shape of each ship was known, each ship's facing could be winkled out. The only issue is latency--with a ~.1 second delay, knowing a ship's facing couldn't really be any better than eyeballing it, even for a novice.

Now... working out a ship's velocity vector would be as easy as subtracting its last two known coordinates.

Maalik: Isn't the ship's velocity vector projected onto a 2D plane perpendicular to the axis connecting the target and the origin (i.e. your ship) by the ITTS indicator? Is that extractable in the form of a variable? Of course, that only works when the object is in the area of your main screen, obviously.

Mynt, the problem is that its position is changing fast enough in general that you don't have time to look at it from enough vantage points to work out where it is. I recognize that for some purposes what you're talking about can be useful; as I said before, I already did the math for it. But when you have a dozen targets that are quickly and erratically moving your data becomes entirely meaningless. There is no way to distinguish between a stationary object on one side of you and a moving object on the other side of you that just happens to be moving in roughly the right way to be about matching the distance of the stationary object. Add to this the fact that in a combat situation you don't have the luxury of marking out widely different vantage points, and the distance difference of even stationary points isn't going to be very big on a short enough time scale.

I admit, I haven't worked out the full math required to show that such a system would be infeasible. This is because I don't think it's worth the time to write something that would only be of use in relatively peaceful situations, where everything is fairly static. All the distances you get from combat ships are going to be essentially chaotic, as their relative movement with respect to you will most likely equal or exceed your relative movement with respect to your other vantage points. What you are saying is theoretically true for certain situations, but it is basically useless in the cases in which it is most needed.

Well, you're using your faith that it's too inaccurate for your purposes as a premise to prove that it's too inaccurate for your purposes. And maybe you're right--but you name a value which is too much in meters, I'll write out the math later tonight, and then we'll see if we can't get it to cycle 1000 times a second instead.