Add prograde/retrograde for other reference systems

[xZise]

Hi, add prograde and retrograde vectors for all three reference systems:

• ORBIT:PROGRADE (are the same as current PROGRADE)
• ORBIT:RETROGRADE (are the same as current RETROGRADE)
• SURFACE:PROGRADE
• SURFACE:RETROGRADE
• TARGET:PROGRADE
• TARGET:RETROGRADE

Maybe the current PROGRADE and RETROGRADE use the same reference system as the navball is using at the moment.

An additional proposal would be to have those vectors for any other object and not only the current target. So for example when there are three objects in orbit (A, B and Z). When the script is running on Z, it then would allow something like 'A':prograde and 'B':prograde without changing the target every time.

[Dunbaratu]

I second this. It's almost impossible to do anything related to landing without access to surface reference system information.

[CoreyJ87]

I third this. +1

[Dunbaratu]

I agree BUT I don't think that last line is a good idea where you said:

"Maybe the current PROGRADE and RETROGRADE use the same reference system as the navball is using at the moment."

That would break older scripts that were written to presume 'prograde' and 'retrograde' meant orbital at all times. I think backward compatibility would require that saying just "prograde" and "retrograde" as bare words would be identical to saying surface:prograde and surface:retrotgrade.

[tambo1]

To hell with backwards compatibility at this stage. One of the annoying things about languages is how they develop esoteric rules and defaults to accommodate changes in direction. I'd say just keep to a new logical standard. People are intelligent enough to adjust their scripts.

[Dunbaratu]

Okay I could see the argument that this is still too early in development to start trying to support backward compatibility, I do. But that doesn't mean that I think the original suggestion was a good way to do it.

Making it so that "prograde" and "retrograde" refer to whatever mode the navball happens to be in at the moment makes it impossible for the script to control its own behavior because the navball mode is often automatically changed by the game without the user doing it (which I've complained about on the KSP forums before. I don't think that was a good UI decision by Squad, by that's another topic for another time.) The point is that tying it to the navball makes it depend on a thing that the script cannot control, and even the player only has limited control over. The player can change the mode back again after the game automatically changes it but can't stop those few moments from happening where the game switched the mode and the player had to see that it happened, and then switch it back. If a script does something stupid in those few moments because the meaning of prograde and retrograde changed for a bit, the player really doesn't have a lot of control to prevent that, and the script has zero control to prevent that.

Either the script would need to be able to read and/or control the navball mode itself, or it would have to have its own internal concept of a mode it can set that can differ from the navball's idea of the mode. One of those two things would be necessary in order for it to be practical for the naked words "prograde" and "retrograde" to mean "whatever mode it's in now".

[xZise]

Hi, I only wanted to prevent an arbitrary PROGRADE and RETROGRADE. Why should is stay orbital when somebody is only interested in the surface vectors.

Another solution (except from don't changing it) would be to remove both vectors in a future version and let the user decide what they are:

LOCK prograde TO orbital:prograde.
LOCK retrograde TO surface:retrograde.

(Or add those locks by default, so if you want surface vectors, overwrite them, or add a command like SET referencesystem TO surface)

In theory it is also possible to get vectors for any other object and not only one target. So for example when you have three objects in orbit (A, B and Z). The script is running on Z it then would allow something like 'A':prograde and 'B':prograde without changing the target value every time.

Fabian

[xZise]

Okay I was thinking about the target prograde. And there are actually two “pro/retrogrades”:

• the orbital prograde of the target (which are afaik the violet markers on the navball)
• the vector to the target (which are afaik the yellow/green markers on the navball)

Maybe a program needs both. Although as I'm writing this, maybe to get the vectors of the target itself (the violet ones) use instead target:orbit:prograde. This would also allow surface (or target?) vectors if possible or even useful.

Fabian

[Dunbaratu]

You've misunderstood what the navball violet markers are, I think. They have nothing to do with the target's velocity. They show which way you'd have to point your ship to point it at the target (or away from it). It's simply "the target is in this direction from you". This is why when docking the goal is to get the prograde marker and the violet marker lined up with each other - so you're moving toward the target (yellow prograde marker matches violet direction-to-target marker.).

[xZise]

Oh yeah I clearly wasn't thinking enough ;) Of course the violet markers point directly at/away from the target.

[fibonatic]

But this vector would still be needed to be able to do a successful docking. It would actually also require you to do a "control from here" on a docking port of your on ship and be able to target a docking port of the target ship to do a fully autonomous docking.

By the way will a script keep running if you switch craft, using that it remains within the physics distance (2.2km) of the other craft. And if it would enter the physics distance, would it resume its script? So you would be able to control both ships while docking.

[charliegreen]

I just discovered kOS a couple of days ago, and one of the first things I tried doing was making a program that could automatically land a spacecraft. I succeeded for the most part, but the craft can't have any lateral velocity, as I didn't know the surface prograde/retrograde vectors. I'd love to have access to them!

(off topic: another thing that would be great for my landing code would be to be able to get values from the sensors under the "science" tab, especially the accelerometer; is there a way to do this?)

[Dunbaratu]

There are surface velocity vectors but they are next to useless for landing because you can't figure out what they mean as they are expressed in a coordinate system you know next to nothing about. They are given in the game's internal spacial coordinate grid and without any other points of reference for that grid and no ability to get your position in that grid, the numbers don't mean anything to you. Okay, so you're going in direction X=30, Y=-10, Z=-3.... Is that towards the planet or away from it? Are you drifting northward? westward? Dunno. It depends on which side of the planet you're on - which quadrant of the coordinate grid you're in. And the position information to tell you that is missing.

BUT, I did work out a crude method to figure it out by what is contained inside the "up" rotational tuple. I made a thing that will translate XYZ coordinates, like velocity:surface, into the surface-relative coordinates in an East,North,Up system:

See here: http://kos.wikia.com/wiki/Tutorial_-_KOS_0.61_and_above:_Finding_surface_dynamic_information