-
Notifications
You must be signed in to change notification settings - Fork 230
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
Fixes #2545. Adds control locking from rp-1. #2546
Conversation
Added control lock read for RP0 avionics
@@ -394,6 +394,11 @@ private void CheckRehookAutopilot() | |||
/// <param name="c"></param> | |||
private void UpdateAutopilot(FlightCtrlState c) | |||
{ | |||
// Lock out controls if insufficient avionics in RP-0. | |||
ControlTypes RP0Lock = InputLockManager.GetControlLock("RP0ControlLocker"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Is this "RP0ControlLocker" lock still named that in RP-1? (DId they plan to change the name to "RP1ControlLocker"?) From the standpoint of mod compatibility, I'm not sure having the version number in the name of the lock is such a good idea, as it seems like the sort of thing someone will come along and "fix" some day, thus breaking the kOS code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name is taken directly from the current rp-1 source.
That said it's entirely possible someone could unknowingly change it in the future. I might restructure the way this works so that kOS provides a function for rp-1 to call to lock controls. That way it is obvious that there is an external interaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got a reply in the RP-0 Github about this - they claim it will remain "RP0" forever and it's safe to use this name.
@RCrockford This looks like it might have the effect of locking kOS's inputs to whatever they were before when the avionics support goes away. Can you test what happens if you lose avionics control WHILE KSP was in the midst of moving the controls? Do they get stuck in the moved position? (i.e. imagine a decoupling makes a probe core go away and what's left is not sufficient to allow Avionics to work on the mass that remains. If kOS was in the middle of, say, pushing YAW 30% left just when that happened, will the controls keep on pushing 30% left from then on? A way to test this would be to lock steering to some new value, wait 0, then stage. The steering should still be deflected from the lock steering that didn't finish turning yet if you do it in quick succession like that. |
I have tested this (it's actually very easy as controls are unlocked on the pad then lock as you launch). Raw steering controls return to 0 when control is locked. As soon as control unlocks they return to their previously set values. In the case of cooked steering, controls return to zero and then cooked steering resumes on unlock. |
Fixes #2545.
Adds a read of the rp-1 control locking mechanism so that craft with insufficient avionics are uncontrollable. No effect for non rp-1 games (as the lock will not exist).