[1.3] kOS Scriptable Autopilot System v1.1.3.0

[madlemur]

I would argue semantics around the word "expectation". If there is useful data about craft and parts that isnt exposed no one is more serious than Steven and I about exposing it to you guys. From skips last few posts I cannot tell what he wants let alone what data is missing for him to accomplish his goal. I am seriously asking him for more information so we can resolve his issues.

From all I've seen, I agree with you. It just seems to me (a neophyte at best) that a lot of what skips is asking for is theoretically available either via the existing implementation, or via the KSP API. The rest is a mass of suppositions and unknowns that will take some experimentation to determine, such as do engines always thrust opposite of their facing? For VTOL engines that rotate, does the part facing rotate as well? Is it possible to calculate the expected thrust from a given throttle setting if you know the ISP, max thrust and altitude of the engine, and the atmospheric information for the body?

Then you get into the questions of what do you surface, and what do you let the end user calculate? It would be possible to have kOS calculate a large number of data points, but at what point does that end? Hyperbole says there would lead to :

set SHIP:TRAVELDEST to Duna. 
set SHIP:TRAVELSTART to 1.

And then wait for kOS to perform the ascent, transit burns, and orbital insertion at the destination...

[undercoveryankee]

The typical VTOL that I see has two banks of engines: one for "forward" thrust and one for lift when the forward axis is horizontal, with at least one "control from" part aligned with each bank of engines.

Things you might want to do with kOS:

Programmatically switch control parts. Don't know if we have that yet, but it will be possible at the same time as any other command that's in a part's context menu.

Programmatically activate one bank of engines while deactivating the other. Do it with action groups now; do it without action groups once we can fire context menu events directly.

Programmatically detect which engines are aligned with which control parts so a family of VTOLs can share a script. Try looping over the parts and comparing orientations in your code. If you find that you need something specific that's not in kOS to support a particular ship, you'll be close enough to offer a targeted proposal.

Have several banks of engines running at the same time at different throttle settings. While MAINTHROTTLE is always going to control all active engines at once like the stock throttle does, throttling of individual engines might be possible through exposing their thrust limiters or whatever Davon Throttle Control uses.

Carry out maneuvers using engines that don't have a corresponding control part. Takes one or two extra lines of code to calculate an orientation for the control part that points another group of engines the way you want. Commanding a pitch of 0 and firing lift engines is no harder than commanding a pitch of 90 and firing forward engines.

Temporarily make kOS use a control axis that doesn't correspond to the physical control part, e.g. so you can call a script that assumes that all engines fire along the control axis. I can see where that might be useful if you're a big code reuser, but it also seems like enough of a pain in the neck to implement that I won't be surprised or disappointed not to get it.

Calculate the net thrust vector of a list of engines. You should be able to do in kerboscript everything that RCS Build Aid does in C#. We have the vector types and operations; if you find that a variable that kOS doesn't expose affects your result, let us know what variable you wish you had.

[skips]

I would argue semantics around the word "expectation". If there is useful data about craft and parts that isnt exposed no one is more serious than Steven and I about exposing it to you guys. From skips last few posts I cannot tell what he wants let alone what data is missing for him to accomplish his goal. I am seriously asking him for more information so we can resolve his issues.

All right already. You have "shamed" me into discussing this topic of "expectations."

But first, you should understand a bit from whence I am coming. My job is maintaining software that is flying on an active NASA spacecraft. Further, I wrote my first operating system as an undergraduate and, as a graduate student, wrote the software that automated the control of the instrumentation, with which I collected the data for my thesis.

As I see kOS, it is primarily a programming language and secondarily a mechanism for controlling vehicles in KSP. As such, it should meet the expectations of a programming language and hopefully provide an abstract model for vehicle control that is compatible with the model that is provided by KSP. Meeting these goals allows the users of kOS to concentrate on building the vehicle and providing "software" that makes the vehicle do "useful" things.

So what does all of this "vision" mean? Well I have written three scripts that I use.

mission() - describes a mission. Currently it supports missions of the type, "activate this part between altitude s0 and s1 and speeds v0 and v1." To use it for different missions of this type, the user must edit the script (i.e., "wire the rocket's controller"). This script uses two other scripts.

ascent( min_altitude, min_speed, action, max_altitude, max_speed, ascent_policy ) - controls the rocket from liftoff to completion of the upward and downward goals. The goals relate to the vertical speed's sign and being within the max_ and min_ limits.

landing( landing_height, landing_speed ) - attempts to land the rocket by arriving at the landing_height with a vertical speed no more negative than minus the value of the landing_speed. The script then maintains the vertical speed as minus the landing_speed value until the rocket is in the LANDED state. To achieve this goal the script must calculate the latest time at which it can burn and still arrive at the landing_height and meeting the landing_speed constraint.

Which brings me back to my original comment about the information about engine thrust. To implement the landing() script it is necessary to answer the question "what thrust (both direction and magnitude) does the vehicle provide if the throttle is set at 1?" With this fundamental information, the script can make decisions about how to achieve its goal of arriving at the landing_height with the desired landing_speed. In the "real world" the software controller is given this information about the thrust magnitude and direction by the designer of the vehicle. The software does not iterate over the parts of the "real hardware" and assemble the information. I guess that I an expecting the abstract vehicle model within kOS to provide the same level of abstraction.

As relates to the programming aspect, I believe that the kOS team should take a hard look at what the language currently provides and determine whether it meets all of the implied requirements of its current implementation. I, for one, believe that it does not. The discussion of "null type" is a primary example of a missing requirement. The language currently automatically assigns dynamic types (i.e., the type of a variable can change during the execution of the program). This characteristic generates an implicit requirement that the language provide a mechanism for testing the type of a variable. If such a capability is provided, the whole discussion of "null type" is mute.

Well I have rambled more than I should have. If you wish to discuss these issues further, lets move the discussion to your developer thread.

skips

[undercoveryankee]

Which brings me back to my original comment about the information about engine thrust. To implement the landing() script it is necessary to answer the question "what thrust (both direction and magnitude) does the vehicle provide if the throttle is set at 1?" With this fundamental information, the script can make decisions about how to achieve its goal of arriving at the landing_height with the desired landing_speed. In the "real world" the software controller is given this information about the thrust magnitude and direction by the designer of the vehicle. The software does not iterate over the parts of the "real hardware" and assemble the information. I guess that I an expecting the abstract vehicle model within kOS to provide the same level of abstraction.

Since in KSP, the player is the designer of the vehicle, I think it would be more fun to make sure the player has access to exact coordinates and all of the necessary performance figures for the engines and let the player calculate the vehicle parameters that need to go into the script than for kOS to automagically give everyone a generic useful set of data. I don't think anyone who's using kOS at this level is going to be scared away by the prospect of doing some math in a spreadsheet or in a separate "vessel analyzer" kOS script that's run from the archive.

[madlemur]

OK, now I'm confused. First, it's a problem that kOS doesn't automatically provide certain information, but then the basic design philosophy is that the information in question is provided by the programmer...

I see where the language design might be a little... suboptimal for modeling the ship's controls. But I also see where kOS is not only an indirect language construct, but also a rescued project, for a game, no less. I have high hopes that kerbscript will continue to develop to a more fully realized programming platform, but I also enjoy it as a simple automation tool.

[Drew Kerman]

Since the kOS repository thing never took off, I just released my latest script here in the forums. Just FYI in case you guys want to link to it in the OP or anything.

[erendrake]

All right already. You have "shamed" me into discussing this topic of "expectations."

We are not about shaming here. Steven and I were honestly confused about what you wanted to do that you couldn't.

Which brings me back to my original comment about the information about engine thrust. To implement the landing() script it is necessary to answer the question "what thrust (both direction and magnitude) does the vehicle provide if the throttle is set at 1?" With this fundamental information, the script can make decisions about how to achieve its goal of arriving at the landing_height with the desired landing_speed. In the "real world" the software controller is given this information about the thrust magnitude and direction by the designer of the vehicle. The software does not iterate over the parts of the "real hardware" and assemble the information. I guess that I an expecting the abstract vehicle model within kOS to provide the same level of abstraction.

It sounds like the real world abstracts this calculation behind a person doing the calculation rather than the flight operating system giving it to you. There is no requirement in kOS that the user iterate over the engines, you as the designer could input these variables the same way they do in the real world.

That being said i do think that because the stock game provides some of these aggregate values for mass, thrust and lift it makes sense for kOS to expose them too. Ill look to see if the KSP API has public state were i can fetch these . If not it shouldn't be that hard to add.

thank you for your feedback and I welcome you to send us pull requests if the mood strikes you to help out.

[Lexx Thai]

@erendrake: Dude, may be you could slight change of kOS programming "concept" and make it a little "visually". I mean an ability of ID assignation to vehicle parts in editor scene and use them in code like variables. For example, at vehicle design process, I'll can assign name for 'landing engines' and control them in script like MYLANDINGENGINES:<useful fields>

[Dunbaratu]

@erendrake: Dude, may be you could slight change of kOS programming "concept" and make it a little "visually". I mean an ability of ID assignation to vehicle parts in editor scene and use them in code like variables. For example, at vehicle design process, I'll can assign name for 'landing engines' and control them in script like MYLANDINGENGINES:<useful fields>

This makes for a good user interface, but has one technical difficulty: It requires adding a module to each and every part in the game (to make the tweakable menu allow you to name it), and that means using something like the ModuleManager mod, which is a PITA to work with and not break things.

[Lexx Thai]

I think, MM config to all things (Engines, RCS, Tanks, may be something else) is a "lesser evil" in comparison with current monstrous methods.

[erendrake]

This makes for a good user interface, but has one technical difficulty: It requires adding a module to each and every part in the game (to make the tweakable menu allow you to name it), and that means using something like the ModuleManager mod, which is a PITA to work with and not break things.

I am also not excited about adding a module to every part

I think, MM config to all things (Engines, RCS, Tanks, may be something else) is a "lesser evil" in comparison with current monstrous methods.

There are also assignment issues. We could auto assign each part an incrementing integer or even a Guid but i honestly dont know much about the editor and how it deals with copying and re-snapping parts. If it behaves like I think it does we would end up with either

* Parts getting the same Id

* A ton of constant Id changes whenever you touch the craft

I am sure that both of these would also be "monstrous".

I think it would make the most sense for it to be a textbox that the scripter would control. You can type in whatever you like, it gets copied on part clone or whatever you do and you can keep it up to date and reference it in code. That would solve a lot of problems (other than the every part needs a new kOS module, which sucks). That would of course require a tweakable textbox that the stock game doesnt have . I think we can get it with the KSPAPIExtensions but i honestly havent confirmed that. It would also be pretty useless if we didnt also have more string manipulation tools in the language (starts with, contains, ends with, trim , ........) which is non-trivial.

The solution that Steven and I have been tossing around for some kind of part query language is the one I like the best. It requires the most design as i dont think anyone would be happy if we are redoing the syntax every release and breaking everyone's scripts.

This is a complicated problem and it will require a lot of design and thought. I thank you for your input

[madlemur]

XPath for KSP? The vessel is sort of a hierarchy...

[Dunbaratu]

XPath for KSP? The vessel is sort of a hierarchy...

We've been tossing around the idea of some generic where-clause to trim sublists down: Get a sublist of a list where the sublist consists of all the elements in which (condition you write about an element) is true.

something vaguely like:

LIST PARTS IN mylist WHERE (some boolean condition you can make up as you wish).

Thus you could get all engines where engine type is blarg, or get all parts where their type is WideAngleLight (or whatever the type name for that is called - I can't really look it up at the moment, but you get the idea.)

I'd like this to be something not limited to just getting parts. I'd like it to work on *anything* of type LIST().

It may be possible to also write some code that activates inside the VAB/SPH editor to let you name parts yourself, but it definitely shouldn't work with the tweakables menus, as that requires adding a module to every part and that's an ugly messy bug-likely approach. When more than one mod tries doing that at the same time they can end up stepping on each others' toes.

It may be possible to have the SCS part's kOS Module add a general UI button to the editor screen (so you can't access it until after you've added an SCS part to the craft, and therefore it's not something we have to do to every part in the game). Clicking the general UI button would then let you subsequently click on a part of your craft somewhere, and it would pop up a name to give the part. Thus the module code we write isn't attached to all the parts. It's module code attached to just the SCS part saying "point at another part and tell me what you want me to call it". This, given the way KSP modding works, should be doable without having to use modulemanager to add our code to every part. KSP allows parts that exist on the craft being built in the editor to run code right away while still in the editor screen. (Thus why kerbal engineer can show you the dV readouts during building), and that code can do things like read the mouse to see what part of the craft is currently highlighted under the cursor.

I'm not saying I want to rush off and do it right now, as it's a nontrivial bit of work, but from what I've seen, that approach is possible.

Ideally both could exist eventually - WHERE clauses for lists, and also being able to give parts kOS identifier names in the VAB (and save those names in the craft definition file).

Not promising anything - just saying these things seem, in principle, to be possible.

It's all just a matter of what is it worth spending the limited amout of free time on, since there's not enough time to implement every idea that's possible to implement.

It's a matter of doing triage of programmer time.

Edited September 9, 2014 by Steven Mading

[Lexx Thai]

It may be possible to also write some code that activates inside the VAB/SPH editor to let you name parts yourself, but it definitely shouldn't work with the tweakables menus, as that requires adding a module to every part and that's an ugly messy bug-likely approach.

Moduleless part name editor is good idea, I forgot about that. BUT even simple part module (added to every part) with simple function: showing small dialog with edit field and two buttons - I think, it can't cause mod interaction bugs.

It may be possible to have the SCS part's kOS Module add a general UI button to the editor screen (so you can't access it until after you've added an SCS part to the craft, and therefore it's not something we have to do to every part in the game). Clicking the general UI button would then let you subsequently click on a part of your craft somewhere, and it would pop up a name to give the part. Thus the module code we write isn't attached to all the parts. It's module code attached to just the SCS part saying "point at another part and tell me what you want me to call it". This, given the way KSP modding works, should be doable without having to use modulemanager to add our code to every part. KSP allows parts that exist on the craft being built in the editor to run code right away while still in the editor screen.

1. Editor must be independent from the SCS part on the craft. Imagine a dock of the automated vehicle to a passive engine compartment in orbit, or vice versa.

2. Name can be assigned directly to part. I tried using the Part.partName - it works. In addition, you can assign unique names for every parts in symmetry (thrust control of multiple engines, hehe).

[Dunbaratu]

1. Editor must be independent from the SCS part on the craft. Imagine a dock of the automated vehicle to a passive engine compartment in orbit, or vice versa.

The craft file would store the name, not the SCS part. The part just has to be there because there's no code running at all from the mod if the part containing the PartModule isn't present yet. You could add the SCS part, name bits of the craft, and then throw the SCS part away again and the craft should still have the names on it that get saved.

[erendrake]

NEW RELEASE

WARNING: Because of a change that had to be done for this patch, it is Highly recommended that you increase your InstructionsPerUpdate setting in config.xml to 150% as much as it was before (i.e. from 100 to 150, or if it was 200, make it 300.).

New Hotness

* Updated fonts, Thanks @MrOnak
* Now runtime errors show source location and call stack trace (Github issues #186 and #210).  Example:
~~~
    Tried To push Infinity into the stack.
    At MyProgramFile2 on Archive, line 12
        PRINT var1/var2.
                  ^
    Called from MyProgramFile1 on Archive, line 213
    RUN MyProgramFIle2("hello").
    ^
    Called from StartMission on Archive, line 2.
    RUN MyProgramFile1.
    ^
    _
~~~
* (WHEN and ON) Triggers that are taking longer than an Update is meant to take, and thus can freeze KSP are caught and reported (Github issue #104).  Gives the user an explanatory message about the problem.
  * WARNING: Because of a change that had to be done for this, it is **_Highly_ recommended that you increase your *InstructionsPerUpdate* setting in config.xml to 150% as much** as it was before (i.e. from 100 to 150, or if it was 200, make it 300.).
* Multiple Terminal Windows - possible to have one open per CPU part.  (Github issue #158) 

Old and Busted ( now fixed )

* "rename" was deleting files instead of moving them. (Github issue #220).
* Was parsing array index brakets "[..]" incorrectly when they were on the lefthand side of an assignment.  (Github issue #219)
* SHIP:SENSORS were reading the wrong ship's sensors sometimes in multi-ship scenarios.  (GIthub issue #218 )
* Integer and Floating point numbers were not quite properly interchangable like they were meant to be. (Github issue #209) 

Edited September 11, 2014 by erendrake
fixed the big warning about IPU

[Drew Kerman]

hurray for more informative error messages!

[madlemur]

Yay!

Is there a Github issue for the "kOS module in the root part is a Bad Thing" bug? I had heard it mentioned in furtive whispers and in dark alleys, but it wasn't until I decided to MM a kOSProcessor module into each command module that I was formally introduced to the damned thing... Thankfully, I'm still in my "Stranded a kerbal in space because I brain spazzed the dV calculations? Just start a new career!" mode. So it only set me back a couple of sub-orbital launches.

[erendrake]

Yay!

Is there a Github issue for the "kOS module in the root part is a Bad Thing" bug? I had heard it mentioned in furtive whispers and in dark alleys, but it wasn't until I decided to MM a kOSProcessor module into each command module that I was formally introduced to the damned thing... Thankfully, I'm still in my "Stranded a kerbal in space because I brain spazzed the dV calculations? Just start a new career!" mode. So it only set me back a couple of sub-orbital launches.

was this in the new release?

[madlemur]

was this in the new release?

Don't know yet. I know it was in the last release. I MM'd a kOSProcessor into all the command pods, and when I tried to return to a vessel in orbit, there was nothing else there. No parachute, no US science layer, no propulsion... Just a lonesome Mk-1 pod spinning slowly in orbit. It was supposed to be a "rescue" mission to get Jeb, who I had stranded in a polar orbit around Minmus by not properly managing my dV.

[Dunbaratu]

Don't know yet. I know it was in the last release. I MM'd a kOSProcessor into all the command pods, and when I tried to return to a vessel in orbit, there was nothing else there. No parachute, no US science layer, no propulsion... Just a lonesome Mk-1 pod spinning slowly in orbit. It was supposed to be a "rescue" mission to get Jeb, who I had stranded in a polar orbit around Minmus by not properly managing my dV.

I get the same effect sometimes and I never use MM to put kOS into a main pod. Something is crashing during the reloading of the vessel from on-rails to full-physics and the code SQUAD uses to reload the vessel is very VERY fragile. If *any* part's module code throws *any* exception during the reloading process, then KSP aborts the loading of the *entire* remainder of the vessel from that point onward and you end up with a vessel with only some of its parts having been brought into existence. This is why truncated craft is a very common effect of a large number of different bugs from different mods. I don't suppose you happen to have the KSP logfile from that event? (Probably not because it overwrites each time you run, but I can hope).

[madlemur]

I get the same effect sometimes and I never use MM to put kOS into a main pod. Something is crashing during the reloading of the vessel from on-rails to full-physics and the code SQUAD uses to reload the vessel is very VERY fragile. If *any* part's module code throws *any* exception during the reloading process, then KSP aborts the loading of the *entire* remainder of the vessel from that point onward and you end up with a vessel with only some of its parts having been brought into existence. This is why truncated craft is a very common effect of a large number of different bugs from different mods. I don't suppose you happen to have the KSP logfile from that event? (Probably not because it overwrites each time you run, but I can hope).

Nope...But if it happens again, I'll be sure to get a log posted. At the least, I'll give you my MM config. I may have horribly borked something up in that...

// Add a beefed-up kOS system to all manned command modules.
// Any Part that has a ModuleCommand Module, no kOSProcessor already, and doesn't have a CrewCapacity of 0


@PART
[*]:HAS[@MODULE[ModuleCommand],!@MODULE[kOSProcessor]]:FINAL
{
  MODULE
  {
    name = kOSProcessor
    diskSpace = 20000
  }
}

I had tried using ...,!#CrewCapacity[0] as part of the :HAS[] block, in an attempt to bypass probe cores, but it wasn't working. And for a brief time I even tried to add a nominal EC drain as a price for having the kOSProc onboard.

[Horus]

Yay! kOS update! Thanks for your efforts!

[Dunbaratu]

I want to highlight an important aspect of the update that was boldfaced, but the boldfacing got lost in how it was pasted into the forums.

It's quite important:

Because of a change that had to be done for this, it is _Highly_ recommended that you increase your *InstructionsPerUpdate* setting in config.xml to 150% as much as it was before (i.e. from 100 to 150, or if it was 200, make it 300.).

The usual setting in the past was 100. But that was 100 when counting ONLY the mainline code and never counting any work done by WHEN,ON, and LOCK. Now that these are being counted, you need a slightly higher setting to get roughly the same performance as you had before, under the assumption that in a typical program about half the execution work is done in WHEN and ON and thus wasn't being counted before.

The reason we couldn't just automatically increase the number in the mod's update code is that whenever you run the mod, the config file is written, and once the config file is written, its values are taken as gospel and override whatever the mod's defaults are. So even though we changed the default from 100 to 150, that change won't take effect for anyone who had already run the mod in the past and thus already had a config file.

[TDW]

Multiple windows is going to be fun:).

On the subject of identifying parts without writing a MM module to every part could this work;

Create a surface attachable part (preferably small and discreet) call it a KOM port:rolleyes:,

It can then identify the part it is attached to and right clicking on it brings up a text box that lets you input a variable name for that part?

Would also have the added "advantage" of making the player think in advance about what they wanted kos to have right-click access to.

Edited September 11, 2014 by TDW