Skip to content
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

Merged
merged 1 commit into from
Jun 22, 2019

Conversation

RCrockford
Copy link
Contributor

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).

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");
Copy link
Member

@Dunbaratu Dunbaratu Jun 16, 2019

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

@Dunbaratu
Copy link
Member

Dunbaratu commented Jun 21, 2019

@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.

@RCrockford
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Locked avionics state in RP-1 is ignored.
2 participants