-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vector/direction conversion routines #106
Comments
Should we also include functions to change vectors/rotations between the global frame of reference and the local one? Not that is too difficult to do it now, but it requires calculating the unit vectors and then a dot product which can be a bit too much for a beginner. |
What is the global frame of reference you had in mind? "global" in its computer meaning as "the same everywhere" or as in geography: "the globe - the SOI Body".. There sort of isn't a global (in the computer sense) coordinate system in KSP. The world coordinate system is ever changing. |
What I meant was to be able to convert from the KSP coordinate system (XYZ, whatever its origin may be) to a "local" frame of reference centered in the vessel (on the surface this would be expressed as North, East and Up). As I said its already possible to do this with some vector math, but that is not too beginner friendly. The same with rotations, the way they are expressed now makes them difficult to understand and work with. For example a direction expressed in the current system is a lot harder to grasp than if it were expressed in degrees from north and elevation. I know that once you are in space the coordinates origin moves near your ship, so my suggestion would really apply when on the surface / lower atmosphere. |
I'd still like the coordinates that are soi body-related to be something you can convert into but are not the universal for everything - because they move too much are are not static. the positions of things already are being translated to a ship-origin system, but aren't being rotated to a navball-oriented system. I'd like there to be a vector suffix for coordinate system like this: set v to ship:velocity:orbit. |
@marianoapp and @erendrake - what do you think of this proposal? First off, as I thought about this more and contemplated how to make the syntax look to the user, it became hard to hide the complexity from the user unless we make our vector and rotation objects smarter and aware of what frame of reference they're stored in. If we don't store the frame of reference in the vector objects, then we end up making the user have to remember it and understand which routines expect the directions and vectors in which reference frame. This could be a complex large change affecting a lot of little bits of code, but might be worth it to make things more sane to the user. Okay, with that aside, let me explain it:
( * ) - In all the above cases where I say "vessel", what I mean is not neccessarily the ActiveVessel, but rather the vessel containing the kOS CPU part that is running the code. A bit of code running on a vessel that is within 2.5 km and thus loaded, but not the current vessel, needs to see things relative to its OWN position, not the vessel the camera is looking at. Otherwise moving the camera to the next vessel with '[' or ']' will change how the code steers the vessel that was just left from. Okay, with that aside, here's some code snippet examples I'm picturing that all that work would allow users to do:
|
@Dunbaratu it looks like most of this is done but there is still a bit to do. I think we should break down the rest into some new tickets. |
Can some of this features be implemented in the KSLib instead? |
@abenkovskii Not the way it was suggested, where vectors have methods for changing context. First we'd have to make the library capable of more object-oriented code style, which in current kOS it really can't. I am unsure whether to leave this open or not. It's not implemented, but it's unlikely to be addressed any time soon. There's other stuff on the more nearby to-do list. |
(This is mostly a to-do list for myself. I'd like to implement these.)
Doing docking operations (and other stuff) would be a lot easier if the system supported conversions and applications of vectors with rotation directions.
Apply a rotation to a vector
V(100,0,0) + R(45,0,0)
should return a vector equal to the original vector rotated 45 degrees.
Convert to and from vectors and rotations:
Either with a pair of function calls or with suffixes. (i.e. make the :vector of a Direction always work by calculating a unit vector in that direction, and make a vector have a suffix of :direction that returns a R() direction in the direction of the vector). (problem: have to decide what default to pick for the "lost" information of roll direction with the conversion).
The text was updated successfully, but these errors were encountered: