[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[Dunbaratu]

kOS Scriptable Autopilot System v1.4.0.0 for KSP 1.12.x

(This is a continuation of the old thread about the kOS mod: ( 1.2.2 kOS scriptable autopilot system ).)

kOS (Kerbal Operating System) is an autopilot you script yourself. kOS is to programming, what Kerbal Space Program itself is to rocket science. You don’t have to know what you’re doing to get started, but you may find yourself learning a lot by accident as you play with it. And if you already know a lot about programming, it will still be able to hold your interest. kOS is meant to scale with the skill level of the user. You can start off doing very small simple things with it, and get more and more into using its features as you go.
 

Example:

print "Launching".
lock steering to heading(90,80).
lock throttle to 1.
stage.
wait until altitude > 5000.
lock steering to heading(90,60).
wait until altitude > 15000.
lock steering to heading(90,45).
wait until altitude > 25000.
lock steering to heading(90,30).
until apoapsis > 80000 {
  print "apoapsis is " + round(apoapsis,0).
  wait 0.
}
lock throttle to 0.
// ..etc...

What it does

kOS introduces a few new parts that each contain a simulated computer capable of running programs written in its own scripting langauge called kerboscript. The computer has powerful smarts built in to the hardware that allow it to do complex spacecraft operations in one command, thus making it possible to make complex programs with only a few lines of script text.

The intent of kOS is to be a fully in-game item that lives inside the Kerbal’s universe. The program isn’t running on your own gaming computer, but rather it’s being run in a virtual machine that is simulated in the underlying Unity engine.

History

kOS was originally begun as a mod by a single author, Kevin Laity aka Nivekk. Although the project has undergone massive changes since then and now has a very different underlying archetecture and is under active development by a different set of people, none of that would have been possible without his original vision and work.

Changelog

 

Source

 

Downloading:

From Curse

From SpaceDock

Direct from the GitHub Project

 

 

Edited February 13, 2023 by Dunbaratu
update version number to kOS 1.4.0.0

[theJesuit]

Really appreciate the work you all put into it!  Thank you! This is a great mod for simplifying repetative tasks and automating landings for cinematics. Thanks everyone for the studious work.

Peace.

Edited September 19, 2017 by theJesuit
Got released on this thread.

[erendrake]

Thank you for taking this project over Steven! I miss working on kOS a lot and its great to know it is in good hands.

[Dunbaratu]

Version  1.1.3.0 has just been released.

I don't have the patience to fight with the KSP forum editor to turn this into nice pretty bullet points, so here's the raw ascii changelog:

# v1.1.3.0 (for KSP 1.3) Bug Swatting Release

For this release we instituted a rule partway through that only bug fixes
should be allowed (some of the first few changes were enhancements rather
than bug fixes, but after that, its all bug fixes).  This was in a vain
hope that doing so would get a release out faster than normal.

### BREAKING CHANGES

(Can't think of any.)

### NEW FEATURES
* Terminal input using any Unicode character, not just ASCII.
  (Technically not a new feature, but a bug fix to a feature
  from the previous version, but since the bug made the feature
  never work *at all* in the past, it feels like a new feature).
  [pull request](https://github.com/KSP-KOS/KOS/pull/2062)
* New StartTracking suffix for "unknown objects" (asteroids).
  [pull request](https://github.com/KSP-KOS/KOS/pull/2077)

### BUG FIXES
* A large refactor of how the various flight control methods track
  which vessel they control.  This appears to have fixed a lot of
  bugs where kOS lost the ability to control the ship unless
  you reloaded the scene.  (After a docking, undocking, staging,
  vessel switch, or scene switch, this would sometimes happen,
  but not consistently enough to be easy to debug).
  [pull request](https://github.com/KSP-KOS/KOS/pull/2100)
  [pull request](https://github.com/KSP-KOS/KOS/pull/2063)
* Program aborts caused by external events such as poweroff,
  shutdown, or control-C no longer leave garbage behind in
  memory still hooked into parts of kOS.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2019)
* Documentation now more explicitly mentions how SAS and lock steering
  fight with each other.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2111)
* Documentation for GUIskin:add() was wrong.  Fixed.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2098)
* The waypoint() constructor used to fail on waypoints which
  were *not* part of a cluster yet were named as if they
  were part of a cluster anyway ("my waypoint Alpha",
  "my waypoint Beta", "my waypoint Gamma", etc).  This doesn't
  happen in stock, but does happen with several mods that use
  ContractConfigurator.  kOS will now deal with such waypoints.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2093)
* Documentation that claimed obsoleted TERMVELOCITY still
  exists has been removed or edited.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2067)
* Trying to examine the NoDelegate object no longer causes
  nullref error.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2082)
* Equality operator ( == ) when comparing a Path to a Path now
  fires off correctly.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2089)
* GUI's ONRADIOCHANGE callback hook now no longer depends
  on the existence of an ONTOGGLE hook to fire off.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2088)
* Compiler no longer creates incorrect opcodes for indexed
  collections used as arguments to a function call that's
  on the lefthand side of an assignment statement.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2079)
* Font resizing in scripts no longer causes the terminal to mangle
  its size and width/height character count
  [pull request](https://github.com/KSP-KOS/KOS/pull/2081)
* Signal delay progress bar (when using Remote Tech) will now resize
  properly when you have a nonstandard sized terminal window.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2076)
* Compile command now works properly when run from the interpreter.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2071)
* Vessel:isDead working properly now
  [pull request](https://github.com/KSP-KOS/KOS/pull/2070)
* Stretching the terminal to a large size no longer causes
  the rounded corner to obscure text in the window.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2060)
* Full unicode keyboard and file save support was getting
  mangled by wiping out the high byte leaving only the 8-bit
  ASCII part left.  Fixed.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2062)
* Toolbar Panel setting changes no longer require there to
  exist a kOS part loaded into the scene.
  [pull request](https://github.com/KSP-KOS/KOS/pull/2058)

 

[Dunbaratu]

Backward version v1.1.3.1 for KSP 1.2.2 also exists now.

Do NOT USE v1.1.3.1 on KSP 1.3.   For KSP 1.3, stick with v1.1.3.0.

Despite having a higher version number, v1.1.3.1 is actually a backward port for the older KSP version.

I had a long debate with myself over the version numbering.  Because the 1.2.2 port had to be developed *after* the KSP 1.3 modern version was ready, it should have a higher number.  But because it's for an OLDER version of KSP it should have a smaller number.   Which of these two needs wins??

In the end I went with the chronological order.  It was made later, so it gets a higher number.  But I still fear this may confuse some users It confused Spacedock for a while - it thought kOS was now an obsolete mod until I figured out how to coerce it into using the lower version number as the "official" download.

If you need the backport, I recommend using Curse or Github to get it instead of SpaceDock.   Spacedock is a bit less friendly to the idea of multiple current "correct" versions.  It works but it's harder to find them.

I hope CKAN understands the new versioning and doesn't get confused by it, but I won't know until about a day from now when CKAN updates itself.

Edited September 19, 2017 by Steven Mading

[kcs123]

@Steven Mading, CKAN use data in version file. If you restrict kOS v1.1.3.1 with min/max numbers in version file for KSP 1.2.2. only, it should not cause issue.

kOS v1.1.3.0 should have proper numbers for KSP 1.3. and should not get confused that way.

I didn't checked kOS version file, though and it does not hurt to ask @politas to confirm or deny my claim.

Edited September 19, 2017 by kcs123

[Dunbaratu]

56 minutes ago, kcs123 said:

@Steven Mading, CKAN use data in version file. If you restrict kOS v1.1.3.1 with min/max numbers in version file for KSP 1.2.2. only, it should not cause issue.

kOS v1.1.3.0 should have proper numbers for KSP 1.3. and should not get confused that way.

I didn't checked kOS version file, though and it does not hurt to ask @politas to confirm or deny my claim.

I did that in the version file, but I can't test it without putting it out there live and just waiting to see if it worked.  I have to wait for CKAN's regularly scheduled spidering to find it.

 

[kcs123]

I think that you will be fine with that, hopefully politas will be able to confirm.

[Nittany Tiger]

Shouldn't Get PART:MODULES work for an engine type part?  Been trying to debug why LES:DOACTION("Decouple", True)*. or LES:DOEVENT("Decouple")* doesn't work for this launch escape tower though it has a decouple module (it's a FASA Apollo LES).  It also says in the kOS documentation that part suffixes work for engines.  Therefore, I should be able to activate the decoupling feature of the launch escape tower even though it's an engine type.  I have tried to list the modules for the part, but I'll get "argument is out of range" errors as if there are no modules for the part I guess.

*I do have tags set properly.

Edited October 1, 2017 by Nittany Tiger

[Dunbaratu]

3 hours ago, Nittany Tiger said:

Shouldn't Get PART:MODULES work for an engine type part?  Been trying to debug why LES:DOACTION("Decouple", True)*. or LES:DOEVENT("Decouple")* doesn't work for this launch escape tower though it has a decouple module (it's a FASA Apollo LES).  It also says in the kOS documentation that part suffixes work for engines.  Therefore, I should be able to activate the decoupling feature of the launch escape tower even though it's an engine type.  I have tried to list the modules for the part, but I'll get "argument is out of range" errors as if there are no modules for the part I guess.

*I do have tags set properly.

You're missing information from your post to tell what you mean.  What is "LES" and how did you obtain it?

Is it the part or is it the module on the part or is it the list of modules on the part?  Show the code where LES is assigned into and it will make the description understandable.

[Nittany Tiger]

Sorry about that.

The line in question is in AresLaunchDisplay.ks.

ELSE IF (J2S:IGNITION = FALSE) OR ((2)*(9.8 * J2S:ISP * LN(SHIP:MASS/(SHIP:WETMASS - MSII:WETMASS))) > 2881) OR STAGE:NUMBER > 19 { //dV calculated here is 400 more than possible stage dV.
    PRINT AbMode[3] at (la,0).
    //AG27 on.
	LES:ACTIVATE.
	LES:DOACTION("Decouple",1).
  }

This is the line that, once the Saturn VB goes above 80km, it's supposed to jettison the Launch Escape System and display "II" for the abort mode.  The LES variable is the variable set in the main script, and it's the Launch Escape System given the name tag LES in the VAB.

SET LES to SHIP:PARTSTAGGED("LES")[0].

EDIT: I should mention that I used to tie the LES jettison to an action group (The AG27 on statement), but with the latest Remote Tech and AGX for KSP 1.2.2, the action group won't trigger in the script even with Remote Tech disabled in that save.  That's why I tried to trigger LES jettison directly.

Edited October 1, 2017 by Nittany Tiger

[Pand5461]

@Nittany Tiger

DOACTION is a suffix of PartModule, not Part.

So, you need to find the module that has Decouple action and call LES:GETMODULE("SomeModule"):DOACTION("Decouple", True).

And please, try to make a minimal script that show the problem and paste this, instead of a large chunk of code mostly unrelated to the question.

[Nittany Tiger]

I didn't know if I was supposed to post the whole script or part of it.  Sorry.

[Dunbaratu]

3 hours ago, Pand5461 said:

@Nittany Tiger

DOACTION is a suffix of PartModule, not Part.

So, you need to find the module that has Decouple action and call LES:GETMODULE("SomeModule"):DOACTION("Decouple", True).

And please, try to make a minimal script that show the problem and paste this, instead of a large chunk of code mostly unrelated to the question.

Actually, for questions like this I prefer too much information as opposed to to little.

Often the problem is that the person reporting doesn't *know* what's wrong but *thinks* they do, so they cut out all the parts they think are "not relevant", and in so doing, cut out the bit that shows where the real error was, preserving the part that was just fine.

For a bug report, where you *know* what's wrong already and are just trying to trim it down to a simpler example, being terse is good.  But for "this doesn't work and I don't know why" it can help to see the whole thing.

 

9 hours ago, Nittany Tiger said:

 

SET LES to SHIP:PARTSTAGGED("LES")[0].

 

PARTSTAGGED gives you a list of *parts*.  To use DOACTION you need to do it on a PartModule, not a Part. 

A single Part can have multiple PartModules on it to represent the different capabilities it has.  (i.e. a Mk1 Command Pod is a crew quarters,  it is also a resource container (for monoprop).  It can also have science experiments stored in it.  It is also a control point for your ship orientation.  It also is a battery.  etc ...  These different things are represented by having more than one PartModule on the part.

And it's the PartModules that decide what buttons appear on the panel, not the Part.

 

[Nittany Tiger]

8 hours ago, Steven Mading said:

Actually, for questions like this I prefer too much information as opposed to to little.

Often the problem is that the person reporting doesn't *know* what's wrong but *thinks* they do, so they cut out all the parts they think are "not relevant", and in so doing, cut out the bit that shows where the real error was, preserving the part that was just fine.

For a bug report, where you *know* what's wrong already and are just trying to trim it down to a simpler example, being terse is good.  But for "this doesn't work and I don't know why" it can help to see the whole thing.

 

PARTSTAGGED gives you a list of *parts*.  To use DOACTION you need to do it on a PartModule, not a Part. 

A single Part can have multiple PartModules on it to represent the different capabilities it has.  (i.e. a Mk1 Command Pod is a crew quarters,  it is also a resource container (for monoprop).  It can also have science experiments stored in it.  It is also a control point for your ship orientation.  It also is a battery.  etc ...  These different things are represented by having more than one PartModule on the part.

And it's the PartModules that decide what buttons appear on the panel, not the Part.

 

That's why I wanted to post the whole script.  To give context so you can see what my script does.

I did do a LIST PartModules for the FASA Apollo LES, and it showed something called "DecoupleModule," and I didn't see a "Decouple" in the list.  I tried both DOACTION("DecoupleModule",1) and DOEVENT("DecoupleModule"), and kOS still complained to me.  I read the kOS Wiki before this, and it mentioned the right click menu actions and actions that usually go in an action group.  The part has a decouple action in both cases, but when I use DOACTION or DOEVENT, kOS will either give me an "argument is out of range" error or "This can't be done with type Engine."  The latter shouldn't happen because a part of type Engine should be able to use structures of type Part and PartModule.

I'll try @Pand5461's solution.  The way I read the kOS Wiki, I thought that LES:DOACTION or LES:DOEVENT would work.

EDIT: Yeah, I was just using the DOACTION and DOEVENT structures improperly.  Toss that to me still learning kOS and the kind of programming it uses.  I only program as a hobby and am largely self-taught.

By the way, does kOS have the equivalent of a DO{} WHILE loop, or is that just the ON{} and WHEN THEN {} loops?

Edited October 1, 2017 by Nittany Tiger

[Dunbaratu]

7 hours ago, Nittany Tiger said:

 I read the kOS Wiki before this,

You were not reading the kOS Wiki if you saw it mention DOACTION.  There is actually an old out of date wiki for kOS on the Wikia website that we can't delete even though we'd like to.  That's why I get a little worried when users call the proper documentation site a "wiki".  (Which they do a lot, for some reason.) I don't like this terminology spreading because there really *is* a wiki out there and it's not reliable and I don't want people to end up going there due to searching google for "kos wiki".

Quote

 

and it mentioned the right click menu actions and actions that usually go in an action group.  The part has a decouple action in both cases, but when I use DOACTION or DOEVENT, kOS will either give me an "argument is out of range" error or "This can't be done with type Engine."  The latter shouldn't happen because a part of type Engine should be able to use structures of type Part and PartModule.

 

It's correct that it can't be done with Engine.  The type called Engine is a Part, not the PartModule that is attached to the engine.

Quote

By the way, does kOS have the equivalent of a DO{} WHILE loop, or is that just the ON{} and WHEN THEN {} loops?

ON{} and WHEN THEN{} aren't loops.  They're triggers.  It's a concept unique to kerboscript.  They run once (or more if you preserve them) *in the background* once the condition is met, as if on a separate thread (sort of, they still subtract from the mainline code's allotted instructions per update and will slow down the main program if you use them too much).

For loops, you have these 3 options:

UNTIL {}

FROM {} UNTIL .... STEP {} DO {}

FOR ... IN ... {}

[DerGnom]

I am trying to set up a manned rocket using KOS without a connection to KSC or another control center.

I use
Kerbal Space Program 1.3
KOS 1.1.3.0
RemoteTech 1.8.8
No other mods installed
RemoteTech Connectivity Manager
ComNet disabled

According to the KOS  documentation ( https://ksp-kos.github.io/KOS/addons/RemoteTech.html ) this should be possible. Sadly, so far I had no success. This is what I did: 

1.) 
My vessel used for testing consists out of an MK 1 Command Pod (Jebediah Kerman included), CX-4181 Scriptable Command System, Z1-K Battery Bank, MK 2 Radial Parachute and one RT1 Solid FUel Booster.  After launching the vessel (while still on the launch pad) I open the terminal of the CX-4181. Typing in anything results in the message "Signal lost. Waiting to re-acquire signal" being displayed at the bottom of the terminal. From now on no input has any effect.

2.)
I added an Probodyne OKTO2 to the vessel (still including Jebediah Kerman in his MK 1 Command Pod). Now all is fine on the launch pad. I can open the terminal, type in commands and get the results from KOS as expected (including accessing the archive volume). When I launch the rocket and move more than 3 km away from KSC (out of the 3 km reach of the OKTO2's integrated omni antenna), I get the same result as before: typing anything into the terminal results in the message "Signal lost. Waiting to re-acquire signal".

3.)
I changed my mod set up and removed RemoteTech. I enabled ComNet. I disabled the extra ComNet ground stations in the custom difficulty diaologue. I restarted the game and enabled the ComNet connectivity manager. I tried to use both vessels as described above. In both cases I was able to use KOS as expected. In the second case (some 40 km away from KSC, no connection to KSC) the terminal replied that I was not able to connect to the archive, since no connection to KSC existed (as expected). Aside from this I also had full KOS functionality.

Because of this I wanted to ask if anybody was able to use the recent version of KOS with RemoteTech Connectivity Manager without having a connection to KSC / Ground station on a manned vessel.

As I said above, according to the documentation (or at least according to my understanding of the documentation ;-) this should be possible. I would be realy glad if I could get a hint whether I am doing something wrong, or if this might be an issue with KOS / RemoteTech.

I came across an old (2015) bug report ( https://github.com/KSP-KOS/KOS/issues/580 ) that basically describes the problem I am having. Since it is marked as closed and there is also an entry in the KOS changelog (under v 0.16, "Bug Fixes") stating that this issue has been fixed, it might be that this is an issue that has resurfaced or that I am simply doing something wrong.

Any help would be very much appreciated!

Edited October 2, 2017 by DerGnom

[danielboro]

14 hours ago, DerGnom said:

Typing in anything results in the message "Signal lost. Waiting to re-acquire signal"

as intended. crew dont have accesses to the  programming of the kos computer
if you dont have a connection you cant reprogram the computer

i have automated ships that can lunch and return whit out a connection
after the script is running theirs no need for a connection unless you want to type a chinge

Edited October 3, 2017 by danielboro

[DerGnom]

9 hours ago, danielboro said:

as intended. crew dont have accesses to the  programming of the kos computer
if you dont have a connection you cant reprogram the computer

Hmmmm,

the current KOS documentation states that

"If you launch a manned craft while using RemoteTech, you are still able to input commands from the terminal even if you do not have a connection to the KSC. " (quoted from: https://ksp-kos.github.io/KOS/addons/RemoteTech.html in the section "Interaction with KOS", second paragraph, not counting the note in the beginning of the section.)

According to the documentation (as quoted above) you should be able to access the command terminal from a manned craft, even if you have no connection to KSC.

Using the terminal on a manned vessel without connection to KSC / ground station is possible when you use the ComNet connectivity manager (as described in my previous post), but not if you use the RemoteTech connectivity manager (contrary to the documentation).

[Dunbaratu]

11 hours ago, danielboro said:

as intended. crew dont have accesses to the  programming of the kos computer

This is *not* as intended.  It's a problem.  Crew are meant to be able to type in the terminal.  Inability to type a command at the terminal doesn't just prevent programming.  It also prevents even running a program.

RemoteTech may have changed their API again, or their rules again, and we didn't notice.  @DerGnom, Make an issue of this on github to remind us.  It is *not* how it's supposed to be.

Edited October 3, 2017 by Steven Mading

[hvacengi]

On 10/2/2017 at 10:29 AM, DerGnom said:

1.) 
My vessel used for testing consists out of an MK 1 Command Pod (Jebediah Kerman included), CX-4181 Scriptable Command System, Z1-K Battery Bank, MK 2 Radial Parachute and one RT1 Solid FUel Booster.  After launching the vessel (while still on the launch pad) I open the terminal of the CX-4181. Typing in anything results in the message "Signal lost. Waiting to re-acquire signal" being displayed at the bottom of the terminal. From now on no input has any effect.

I believe the problem is that you don't have a RemoteTech enabled probe core installed.  The design of RT currently requires a probe core in order to enable their functionality.  It is not clearly noted in either the kOS documentation or the RemoteTech documentation.  What's even more confusing is that RemoteTech will still draw all of the connection lines.  You can tell that this is happening if you look at the RT status indicator under the clock in the upper left hand corner.  Without a probe core it should read "N/A" (if my memory serves me).  But it will say "Local Control" if you have a manned pod and a probe core installed.

EDIT:MY MISTAKE: I ONLY READ LINE PART, EDITED RESPONSE BELOW:

Quote

2.)
I added an Probodyne OKTO2 to the vessel (still including Jebediah Kerman in his MK 1 Command Pod). Now all is fine on the launch pad. I can open the terminal, type in commands and get the results from KOS as expected (including accessing the archive volume). When I launch the rocket and move more than 3 km away from KSC (out of the 3 km reach of the OKTO2's integrated omni antenna), I get the same result as before: typing anything into the terminal results in the message "Signal lost. Waiting to re-acquire signal".

That's very strange and shouldn't happen.  We explicitly ask RemoteTech about local control in our underlying code.  When you lost signal, what the the RT status indicator say in the upper left hand corner?  It should have read "Local Control".  If it said "No Connection" or "N/A" that would be the reason.  If it does correctly show local control, then there appears to be a disconnect between what RT reports in the interface and the value returned to us in the API.  Please let me know what you find so I can use that information to narrow down what I need to test.

Edited October 3, 2017 by hvacengi

[DerGnom]

18 hours ago, Steven Mading said:

@DerGnom, Make an issue of this on github to remind us.  It is *not* how it's supposed to be.

Thanks for the reply!

I created  a new github issue.

15 hours ago, hvacengi said:

When you lost signal, what the the RT status indicator say in the upper left hand corner?  It should have read "Local Control".  If it said "No Connection" or "N/A" that would be the reason.  If it does correctly show local control, then there appears to be a disconnect between what RT reports in the interface and the value returned to us in the API.  Please let me know what you find so I can use that information to narrow down what I need to test.

It showed local control.

15 hours ago, hvacengi said:

We explicitly ask RemoteTech about local control in our underlying code.

I think that there might be a possibility that this check is missing in the current code ;-)

I have added a few thoughts on this in the github issue I created on this topic. Its #2127.

[danielboro]

 

This is *not* as intended.  It's a problem. 
RemoteTech may have changed their API again

i first installed RT on KSP 1.1 and KOS some days later
i never cold input new commands to KOS if thers no probe in the ship

i have a vague memory of some post on this problem

this bug predates comnet

Edited October 4, 2017 by danielboro

[Dunbaratu]

 

i first installed RT on KSP 1.1 and KOS some days later
i never cold input new commands to KOS if thers no probe in the ship

i have a vague memory of some post on this problem

this bug predates comnet

 

That doesn't sound like the same "bug" at all.  Ships without a control point (probe core or manned capsule) can't be controlled by kOS, and this sounds like correct behaviour.  This bug we were talking about is when both crew and probe core exist, but it ignores the crew's right to have local control and tries to insist on controlling it only through commands from KSC (thus it requires the signal home when it shouldn't require it.)

EDIT: I just realized you might have meant adding a probe core to a ship that *does* have a manned command pod.  (As opposed to having to add a probe core because the ship has neither probe core nor manned pod - a frustratingly common "bug" report from users that isn't really a bug).  If so, that's relevant to the description of the problem to mention you meant the ship was manned.  If you have to add a probe core to a ship that is already manned anyway, before you can type into the terminal, then yes that could very well be the same bug (local control not being sufficient to allow the terminal commands to work, when it should be).

Edited October 5, 2017 by Steven Mading

[danielboro]

 

 

 This bug we were talking about is when both crew and probe core exist,

 

no

 

EDIT: I just realized you might have meant adding a probe core to a ship that *does* have a manned command pod. 

yes

i have seen this bug (kos can only get typed commands if thers a prob core) from the first days i had KOS+RT in KSP 1.1
this bug predates comnet