Issue with locking steering and throttle when out of RT2 range

[jordansinn1994]

My program is copied to a local volume and then executed while still in range. It waits untill 60 seconds before ETA:APOAPSIS before turning off SAS and locking steering to prograde. Then 30 seconds before ETA:APOAPSIS it turns SAS on and locks throttle to 1. For some reason neither of the lock commands seem to work while out of range. SAS is toggled just fine and a visual aspect of the program continues to work.

[erendrake]

Thank you for your bug submission. Im going to be out for the next few days but when i get back this will be my top ticket!

[erendrake]

I am going to work on this tonight and this weekend. Too many are blocked from using the mod till we get this fixed. :P

[erendrake]

@marianoapp I have noticed we have a cfg file that we are trying to load from and i cant seem to find a copy of it for inclusion with the installer. Do you have this file?

[marianoapp]

There's no need, the config file is automatically generated with default values on the first run.

[erendrake]

Groovy, Found it! thanks

BTW do you use RemoteTech?

[marianoapp]

Not yet, but I'm planning to in the future. I have a separated install of KSP with RT just to test the integration with kOS.

[erendrake]

@marianoapp cool. It feels pretty good when it works.

@jwvanderbeck Did you have a good way to reproduce the remote tech bug we were having way back when?

[erendrake]

This bug is pretty evil. It exposes the fact that we really have two steering systems and if you try and use both they fight like two cats in a bag.

The fix i have here makes it work but you can get into a bad state where you LOCK STEERING and then try to SET SHIP:CONTROL:ROLL TO -1. the fine control gets overwritten by the steering

im tempted to ship this to see how it goes

[Dunbaratu]

The solution might be to force the user to explicitly toggle which technique is in charge of the vessel, with a command, and put the two methods in an exclusive lockout relationship with each other, where they both share the same setting to decide "am I allowed to fly this thing?".

Imagine this:

When you issue this command:
SET SHIP:RAWCONTROL to TRUE.
Then the LOCK STEERING code stops trying to fly that ship, and the SHIP:CONTROL code starts trying to fly that ship.

When you issue this command:
SET SHIP:RAWCONTROL to FALSE.
Then the SHIP:CONTROL code stops trying to fly that ship, and the LOCK STEERING code starts trying to fly that ship.

A user could still mix and match the two techniques in the same program, but only by explicitly toggling between them, never by trying to have both on simultaneously.

[jwvanderbeck]

This is strange. The code that controls whether a program continues
executing or not when out of range has nothing to do with the steering.

• John Vanderbeck
• http://www.johnvanderbeck.com

On Sun, Apr 27, 2014 at 6:12 AM, Steven Mading notifications@github.comwrote:

The solution might be to force the user to explicitly toggle which
technique is in charge of the vessel, with a command, and put the two
methods in an exclusive lockout relationship with each other, where they
both share the same setting to decide "am I allowed to fly this thing?".

Imagine this:

When you issue this command:
SET SHIP:RAWCONTROL to TRUE.
Then the LOCK STEERING code stops trying to fly that ship, and the
SHIP:CONTROL code starts trying to fly that ship.

When you issue this command:
SET SHIP:RAWCONTROL to FALSE.
Then the SHIP:CONTROL code stops trying to fly that ship, and the LOCK
STEERING code starts trying to fly that ship.

Such a technique would ensure that exactly one of the two methods would be
in control at any given time, and prevent the user from trying to mix and
match the two at the same time.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-41496179
.

[marianoapp]

@erendrake I think that solution is right as it would behave as if the user were pressing the steering keys.

@jwvanderbeck The program executes just fine even when it's out of range but all the commands it gives to the craft are then overturned by RemoteTech. The steering issue is just something @erendrake found while fixing this.

[erendrake]

@jwvanderbeck sorry for the confusion i meant the bug where the RemoteTech API stuff was causing most of vessels to disappear. I couldn't find the original bug

[jwvanderbeck]

Ok so yeah this bug happens when RT2 is allowed to take over the vessel
control. I had disabled that because of the vessel parts vanishing bug. I
can't recall the exact code off the top of my head, as I haven't looked at
it in a while, but its the section where a sanctioned pilot is added by
RT. I had comments in the code to identify the parts,

• John Vanderbeck
• http://www.johnvanderbeck.com

On Mon, Apr 28, 2014 at 9:15 PM, Chris Woerz notifications@github.comwrote:

@jwvanderbeck https://github.com/jwvanderbeck sorry for the confusion i
meant the bug where the RemoteTech API stuff was causing most of vessels to
disappear. I couldn't find the original bug

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-41640284
.