KevinLaity

Whoops! I did set it to public after uploading but I guess it didn't register? It should be viewable on my channel now.

This is mostly fixed in 0.6. I've been working on this mod since 0.18, which is why it started out in that structure. I hadn't realized by the time I released the mod that the official structure had changed, and afterward it seemed like there were a lot more important things to take care of.

This will be implemented later on and will be an optional part of the same statement.

This is one of the big reasons I wanted a new way of steering, because a lot of people would like to navigate using the numbers on the navball as a reference. 0.6 is released with the new style of navigation now, see the release video for details. LOCK STEERING TO HEADING 90 BY 40. // 90 degree heading (east), 40 degrees above the horizon, just like on the navball

I don't think I'll implement that. It may be realistic, but I would get bug reports from people saying "copying files to duna lags like 90 seconds!"

Not yet but there will be

The stack version took me, frankly way too long for me to make. I'm hoping someone will step forward to help me with modelling new parts. Does a radial version make sense? Maybe for rovers... EDIT: The part I did make even has some weird interactions with physics if it touches the ground directly, even though it's a simple cylinder!

Okay, I'll check over the error checking in the next release. I think this is specifically a problem when running a script, because I've definitely gotten errors recently in immediate mode.

There are a couple things that may cause flips. One is the fact that I can't make the ship ignore roll, the math is unexpectedly problematic. All ships start flipped 180 degrees (KSP default) and the UP vector has zero roll, so your ship may flip around wildly trying to meet that roll. Another thing is if you don't have enough torque, this happened during the Squad interview until we both realized he didn't have enough torque, and this was making his ship go crazy during the gravity turn.

If you want to freeze the lock so that it doesn't adjust to the changing prograde vector, do this: SET x TO prograde. LOCK steering TO x.

This is probably a good idea.

They're stored internally with more places but values get rounded to two places when converted to a string (when you print). Maybe I'll revert that change, I may have been preparing for a problem that didn't exist.

Okay I just downloaded and installed it to check and it does seem to have the right number... is this the first version you've downloaded or are you updating from a previous one? Is anybody else having this problem?

Does COBOL use periods? I've never seen any COBOL code before.. I must Google this

It looks like you've got some spaces in there, try removing them. I saw this before and haven't gotten to fixing it. But I'll double check the version when I can.

The system uses quaternions internally but I have to build those quaternions somehow. Putting in pitch, yaw and roll is the only reasonable way I could think of for a user to input that rotation. Inputting the quaternion directly would require users to input a certain number of degrees around a vector... it might be easier for some but not for everybody. Maybe this can be an optional Q(x,y,z,w) thing. For the people who are having a tough time with R() though, I think having a statement that works on a simple heading & pitch is what's needed, and Q() might just confuse them more.

You're right, which is why I said it's way too complicated and a solution is needed. See my blog post. The example I gave you should equate to a heading of 45 and a pitch of 30. Although I may have some of the dimensions wrong, again I can't test right now.

You're right, it is inadequate. Not being able to hit 45 degrees (easily) is a result of gimbal lock. The reason gimbal lock is a problem is because I knew having the user input matrices was asking way too much, yet I wanted to give them full freedom to rotate to any arbitrary direction, regardless of the planet. In theory you could do something like UP + R(-90,0,0) + R(0,45,0) + R(30,0,0) I don't have KSP at work to test that but in theory that would start with the up vector, point it toward the horizon, yaw 45 degrees to the NE, and then pitch back up 30 degrees. If you can imagine that we're turning an imaginary vessel in those directions by those steps and then asking the real vessel to point in that final direction. However that's WAY TOO COMPLICATED and I'm realizing more every day that people need to be able to just call out the degrees that are on the navball. Plus R(,,) is very programmerish for a language that tries to be accessible. So now I'm thinking what should the syntax for that be? I'm thinking something like LOCK STEERING TO heading BY pitch_from_horizon.

Sorry, then I'm not sure what you're asking for, you talked about locking to the surface prograde vector. Now you're saying that you want to lock to a heading, which is it? Maybe you're thinking of locking to the prograde vector for pitch only. But if that's the case your pitch will drift too. Edit: I re-read your post, I think your confusion is that you're thinking of R() structures as being absolute. They're not, they're relative, that's why you use a + with them. It's UP + a relative rotation. That's why the numbers seem crazy to you. Maybe what you're really looking for is something that will let you just input an absolute heading and pitch. That's something that's been asked for and may occur yes. Edit2: It's R(Pitch, Yaw, Roll) and those are applied in the order of Roll, then Yaw, then Pitch. There is no such thing as pitching north. Pitching and yawing are relative terms, the direction they take you depend on the direction you're facing. The 'sometimes' here makes me think you're running into a gimbal lock problem.

Another reason for this is because during a launch the ship is going to naturally veer off. If you say "always steer in the direction you're already moving", then there will be no correction for that drift. This is also a problem in orbit, but the problem is less pronounced because you're moving at orbital velocity and any drift will be negligible compared to that velocity. EDIT: And yes I really should add that in.. I have a surface velocity scalar but no vector at the moment, I'll make sure it's in the next update

Not yet, this is a planned feature though

Hey guys, just wanted to quickly say, let's try to keep this thread positive and avoid making things personal.

The example you've got there should be fine, I'll look into it.

A fix for this bug will be in the next update

Yes if you're in a space craft you can point at a target using LOCK STEERING TO TARGET:DIRECTION.