[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Camacha]

The ship starts to spin towards retrograde, but when the antennas deactivate, it just spins past retrograde. When the antennas come back, the lock works again, and the ship steers to retrograde.

Btw, I tried this with kOS 0.10 and 1.11.1RC and both have the same behaviour. Oh, and it's RemoteTech2 1.3.3.

Alright, that pretty much excludes external forces. I am not sure what is going on there, I guess it is for the technical boys to look at

For example, automated steering:

You "tell" the ship, with a single command, to change the heading to a specific rotation and internally the "optimal path" to this rotation gets calculated and applied.

Is this cheating in a broader sense? I think it's not, since you don't simply change the rotation in one step by telling the underlying engine to do so, but instead you use a multiude of commands on a higher level to achieve this rotation.

I feel I already explicitly stated and explained that cheating in a single player game is pretty much impossible, so I think that discussion is one that does not need to be had. The insistence to talk about what is cheating or not will not help us, as it can only lead to unpleasant conversations between people who play with a different approach to the game.

Now. To me, lock steering is magic (not cheating) because it provides 'free' automated help with a task that is usually reserved for the player. When you manually launch and control a rocket, you will need to keep your eye on the navball to make corrections to steer to the correct heading. By providing a system that automates that and reduces workload, kOS - to me - is an external party that provides the necessary values to keep your rocket on track. If you write your own control logic, however, it can no longer be considered external. Writing my own control logic also coincides with the goal to learn as much as possible about what is needed to perform these kinds of operations.

Now please, I ask you all not to make more of this than it is. I think we have bigger and better issues to discuss.

[kaesekuchen]

I didn't mean to sound offensive, if i did, i apologize.

My reply to this discussion was motivated by seeing it as an interesting thought, where to draw the line between "fun, gameplay enhancing feature" and simply "getting everything handed on a platter".

But it is clear to me now, that your ideal scenario of kOS would be, that it just hands you generic tools and you have to assemble them into a working program

The other day i was working with the kOS sources and scripts to create a program, that would analyze vessels in regard to multiple variables (thrust, isp, drag and so on) and i realized that i had to stop myself from putting too much logic in the c# sources, because it would have been possible to do this in kOS scripts as well.

[Dunbaratu]

I guess you are referring to the discussion in the development thread I was talking about how commands in degrees are translated into direct input commands. I would consider that magic, as it takes a part of the workload that is usually reserved for the player and transfers that to the computer without user input. In this case, the external party is kOS, which provides the input numbers needed for the desired result.

I think the database discussion is best reserved for the development thread

Fair enough. I agree with you about "lock steering to" being magic (but in the past there was no choice as no other mechanism existed), but not about the body database being magic.

[Camacha]

I didn't mean to sound offensive, if i did, i apologize.

You did not, I just desperately wanted this discussion to remain constructive, instead of degenerating into the nasty type of discussion we have seen in the past when if comes to other subjects than kOS Seems my worries were unfounded, you guys are a great bunch.

But it is clear to me now, that your ideal scenario of kOS would be, that it just hands you generic tools and you have to assemble them into a working program

Yes, very much so. That is a good way of putting it. In my mind, kOS has always been about providing tools - but never solutions. Without the proper tools people are powerless, but by providing them solutions you are making them useless

[...](but in the past there was no choice as no other mechanism existed)[...]

I agree, the lack of other solutions limited the kOS user's options severely - you pretty much had no choice. It never sat quite right with me though. And, of course, I am the first to admit that is does make life easy sometimes.

[togfox]

What is the range of kos from ksc if I want to copy from archive and is there an In game means to extend that?

[Camacha]

What is the range of kos from ksc if I want to copy from archive and is there an In game means to extend that?

Under Kevin antennea were the answer, I am not sure about the current situation, especially when combined with RemoteTech.

[Joe32320]

There's a 100km range without any antenna, and range can increase by putting more antenna on it according to the formula here:

http://kos.wikia.com/wiki/Remote_Updates

which seems to be correct as far as I know.

[togfox]

K - thanks. The table is wrong (doesn't match the formula) but it's the formula that's important - and knowing if that formula is still enforced would also be good. Easy to test I guess. Put a kos with an antenna at 110km orbit and see if it can copy from archive.

Edit: table is right. Still not sure if its enforced in the latest version.

Edit: So I'm near Mun orbit (8000 km) with a single long antenna (retracted) and I can copy files from archive no problem. I'm guessing either the range limits were removed or the formula in the wiki is no longer relevant.

Edited March 2, 2014 by togfox

[Dunbaratu]

K - thanks. The table is wrong (doesn't match the formula) but it's the formula that's important - and knowing if that formula is still enforced would also be good. Easy to test I guess. Put a kos with an antenna at 110km orbit and see if it can copy from archive.

Edit: table is right. Still not sure if its enforced in the latest version.

Edit: So I'm near Mun orbit (8000 km) with a single long antenna (retracted) and I can copy files from archive no problem. I'm guessing either the range limits were removed or the formula in the wiki is no longer relevant.

Many of the things on the wiki are becoming wronger and wronger as kOS evolves.

The wiki originally became a place where basic functionality got documented by the users because Kevin's was quite incomplete. erendrake is more proactive about documentation so I don't know if the Wiki will keep being updated a the original reason for it isn't as strong.

[togfox]

I've been half tempted to trawl through the source code and look for little gems like this. Has anyone else had the same crazy idea and then reconsidered it?

[Camacha]

I've been half tempted to trawl through the source code and look for little gems like this. Has anyone else had the same crazy idea and then reconsidered it?

I know Bizz Keryear did some pretty good work back in the Kevin era. He found quite some undocumented stuff in there.

[Dunbaratu]

Whether or not the antennae are extended used to be relevant but its not anymore. The check for whether or not they're extended had to be removed when SQUAD added science points because now when you transmit science the antenna will retract, whether you want it to or not, at the end of the transmission. Since the intent was to someday maybe make it so that you have to have communication with the probe to do anything at all on an unmanned craft (like extend antenna), that inability to stop KSP from retracting the antenna could ruin the whole mission, so the check for extended-ness of antennae was removed.

[togfox]

MechJeb can access the biome name the vessel is in. Does/can KOS access this as well? I haven't tried it but Vessel:Biome or something would be great for automated science missions.

[Camacha]

A little webcrawler type bot that scours the planet in search of new biomes sounds pretty attractive to me.

[kaesekuchen]

Sounds like a good idea, you probably should open a feature request on the github's "issues" page for that.

erendrake stated that kOS is currently in "feature stop" until the upcoming parser enhancements/rewrites will be implemented and merged, but if this is just a simple suffix made available via "ship:biome" your chances are good that he might sneak that in

[erendrake]

MechJeb can access the biome name the vessel is in. Does/can KOS access this as well? I haven't tried it but Vessel:Biome or something would be great for automated science missions.

I have a branch that displays the biome you are currently in and the biome you would be in if you were landed. I am trying to figure out a good Science API (gathering, reporting, storing, biomes) otherwise it would have been in 0.11.

[Camacha]

erendrake stated that kOS is currently in "feature stop" until the upcoming parser enhancements/rewrites will be implemented and merged

I am all for that, a good basis is more important than fancy - albeit nice - gimmicks.

[GRAleX]

There is an information about 0.11.1 version at github here. Where i can download it?

[Logris]

There is an information about 0.11.1 version at github here. Where i can download it?

There's a download link on the releases page on github.

Edit: It seems there's a few issues with this release, which is why it never got formally released on spaceport.

See the development thread for details.

[CaptainKipard]

How do I point retrograde in target mode?

i.e. How do I orient to cancel velocity relative to target ship.

[kaesekuchen]

That should be something like this:

//target retrograde
lock steering to target:velocity:orbit - ship:velocity:orbit.
//target prograde 
lock steering to ship:velocity:orbit - target:velocity:orbit.

[goldenpeach]

I think I have found a bug(version 11): I have a ship consisting(with some others stages) of a manned pod(to dock with my space station) and a probe core on the last stage that boost the rocket into orbit(to deorbit it after being in orbit).

After I detach them, I open the terminal from the probe core(I modified the .cfg to include KOS in the probe core) but the LOCK STEERING TO and LOCK THROTTLE TO doesn't seem to work(I tried others commands and they seem to work).

However, when I switch to the command pod(which was also modified to include KOS) these two commands work(after I rebooted the terminal).

I tried to use the version 11.1 but the problem persist.

EDIT: I can provide the craft file if it help or a video of the bug(I could upload it on youtube but they could be some problems because I never did that before).

Edited March 9, 2014 by goldenpeach

[kaesekuchen]

I encountered this behaviour as well. It is due to the fact, that in the "FlightControlManager.cs" Update function, the lockable control of throttle, wheelthrottle, steering and wheelsteering get detached from the current vessel, but the new one doesnt get attached to the updated vessel.

tl;dr : Without recompiling the kos.dll yourself, you can only circumvent this by reloading the scene (i.e. switch to another vessel and back to your vessel or quicksaving and quickloading)

[goldenpeach]

Ok,thank you for your help!

[Dunbaratu]

I encountered this behaviour as well. It is due to the fact, that in the "FlightControlManager.cs" Update function, the lockable control of throttle, wheelthrottle, steering and wheelsteering get detached from the current vessel, but the new one doesnt get attached to the updated vessel.

tl;dr : Without recompiling the kos.dll yourself, you can only circumvent this by reloading the scene (i.e. switch to another vessel and back to your vessel or quicksaving and quickloading)

This may be related to a bug I've found when a vessel is designed in two equal halves in a stack facing each other like so:

Engine (A) upside down.

Fuel (A) upside down.

Decoupler (A) upside down.

kOS SCS part (A) upside down.

Command Core (A) upside down.

Docking Port (A) upside down.

Docking Port (

Command Core (

kOS SCS part (

Decoupler (

Fuel (

Engine (

After decoupling the two halves into separate crafts, A and B, issuing the "stage" command from kOS SCS part A causes the other craft's decoupler, decoupler B, to stage instead of its own decoupler, decoupler A. This is even though kOS SCS part A isn't even connected to the vessel containing decoupler B.

When decoupling, something isn't being updated about which vessel the CPU is associated with, I think.

This is a bug I discovered a long time ago back in 0.7 but it might still be there if it never got addressed.