kOS Autopilot

[Alchemist]

An interesting thing I stumbled upon: ENGINE doesn't handle Rapier correctly - it always references the air-breathing mode. So, if the Rapier is in closed-cycle mode, you can't shut it down, but you can activate the air-breathing mode as well... Everything else most likely also references air-breathing mode.

P.S. There are 2 PartModules with the same name on Rapier. And I don't see a way to access the second if the only function that returns modules does this by their names.

Edited October 18, 2015 by Alchemist

[Overland]

Greetings everyone

A simple question thats been floating around my mind in regards to kos

Is it possible somehow to have the wheelthrottle linked with the engine power with say a 1-2 second lag between turbine state and wheelthrottle?

Ive been having some power curve vs underpowered states issues lately on my locomotives diesel electric drive system with multiple wheels on a locomotive going underpowered in low rpms of turbine throttle

Typicly I use my steering wheel accelerator fully depressed at all times ala deadman pedal and control the train with engine generation to modified wheels . Its worked for 2 years but since the update im having to shut down atleast 2 wheels out of 10 due to drag

Thus id like to use kos to create a more civilised controller where the electric generation of the turbine follows a similar wheelthrottle progression..

Fail that.. What would be the best approach to linking action groups 1 2 and 3 to wheelthrottle +1.0(forward), neutral (off) and -1.0 ,(reverse) to create a simple reverser switch so I dont need to use pedals?

Thanks.. Sorry.if its rather long too

[pellinor]

Are there any known problems with a larger stack depth? I seem to run into lots of strange issues when running functions in a call depth of 5-6 and more. When I try to reproduce them in a simpler situation they vanish. And often when I touch something in a meaningless way, things break slightly differently.

As I recall this started after I had set "lazyglobal off" and used local variables where possible.

I found some hints of such problems here. Is this still the case?
https://github.com/xeger/kos-ramp/blob/master/README.md

"WARNING: notice the control flow between programs is fairly flat. I try never to call more than 2-3 programs deep. This is because the kOS VM seems to have bugs with programs and functions calling one another. Specifically: 1) Local variables from inner programs sometimes overwrite same-named variables from the outer program 2) Function libraries don't seem to work when they are compiled code"

Edited January 10, 2016 by pellinor

[Dunbaratu]

The stack should be able to go several hundred nested calls deep.  The test case we use in our programs gets to about 990 before bombing out.  If there is a stack issue, it does actually give you a stack exhausted error message.

Quote

1) Local variables from inner programs sometimes overwrite same-named variables from the outer program

There is no such thing as a file-level scope in kerboscript.  Things can be local to a brace section, but all things stated at the outermost level outside all braces are in the same scope.  This had to be done to grandfather in old scripts written before there *were* local variables.  These scripts expected to be able to set a variable in a sub-program that the parent program would then read.

If you want to make a file-level scope, then add "unnecessary" braces around your main code to give them a scope level.  Note, that any functions you want to be callable from other programs (if you're running a library) should be at global scope in order for the other programs to be able to see their identifiers.

 

[pellinor]

Thanks for the explanation, seems like I had a few misconceptions over the details of the scope system. Which naturally leads to errors that correlate with nested calls and the use of local variables.

Especially locks of Steering and Throttle can be hard to debug if they live longer than intended, end up pointing to invalid variables and throw anonymous errors at seemingly random times.

[troyfawkes]

Hey guys

Two questions.

First, I was reading thoughts on HASFILE here (https://github.com/KSP-KOS/KOS/issues/1105). Has that been implemented in any way yet?

Second, I'm having huge issues with the docking ports helper functions. E.g., ship:dockingports[0]:undock(). It doesn't always work as expected. You can recreate my issue exactly by creating a ship that has 2 docking ports attached to each other and trying to undock() them on the pad. I got around the issue by writing out this function:

FUNCTION decouple {
    PARAMETER tag.

    SET my_part TO SHIP:PARTSTAGGED(tag)[0].
    SET my_mod TO my_part:getmodule("ModuleDockingNode").
    IF my_mod:HASEVENT("decouple node") {
        my_mod:DOEVENT("decouple node").
    } ELSE {
        SET docked_node TO my_part:CHILDREN[0].
        IF my_part:PARENT:name = my_part:name {
            SET docked_node TO my_part:PARENT.
        }
        SET docked_mod TO docked_node:GETMODULE("ModuleDockingNode").    
        IF docked_mod:HASACTION("undock node") {
            docked_mod:DOACTION("undock node", 1).
        }
    }
}

This works fairly flawlessly. Am I just doing something horribly wrong with dockingports? Maybe something like this would work to resolve the dockingports issue? Obv. you could refactor to make the function more general.

[Dunbaratu]

1 hour ago, troyfawkes said:

Hey guys

Two questions.

First, I was reading thoughts on HASFILE here (https://github.com/KSP-KOS/KOS/issues/1105). Has that been implemented in any way yet?

Second, I'm having huge issues with the docking ports helper functions. E.g., ship:dockingports[0]:undock(). It doesn't always work as expected. You can recreate my issue exactly by creating a ship that has 2 docking ports attached to each other and trying to undock() them on the pad. I got around the issue by writing out this function:

FUNCTION decouple {
    PARAMETER tag.

    SET my_part TO SHIP:PARTSTAGGED(tag)[0].
    SET my_mod TO my_part:getmodule("ModuleDockingNode").
    IF my_mod:HASEVENT("decouple node") {
        my_mod:DOEVENT("decouple node").
    } ELSE {
        SET docked_node TO my_part:CHILDREN[0].
        IF my_part:PARENT:name = my_part:name {
            SET docked_node TO my_part:PARENT.
        }
        SET docked_mod TO docked_node:GETMODULE("ModuleDockingNode").    
        IF docked_mod:HASACTION("undock node") {
            docked_mod:DOACTION("undock node", 1).
        }
    }
}

This works fairly flawlessly. Am I just doing something horribly wrong with dockingports? Maybe something like this would work to resolve the dockingports issue? Obv. you could refactor to make the function more general.

This is inherited from SQUAD. For some reason I cannot fathom, they decided to make it so that when two docking ports connect, only one of them gets to have the event called "decouple node" on it, and the conditions for which one ends up being which are esoteric and impossible to predict.  It's connected to deciding which of the two vessels got to remain and which got deleted when they merged, but the criteria for that decision are not really explained either.

I have no clue why they didn't just make both ports have the same button label on them.  The user doesn't give a toss one way or the other (and can't even tell, really) which side is the parent and which is the child of the docking.

 

[icedown]

I don't know if this is a new bug, but I've noticed that if you stage off the kOS controller while a program is still running, the controls on the ship remain locked.  I run my programs from a putty telnet session and even though I staged off the controller, it still attempts to control the active vessel using data from the staged off part that it is still attached to.  I can't control the ship again until I either kill the program or it goes out of draw range.

[hvacengi]

6 hours ago, icedown said:

I don't know if this is a new bug, but I've noticed that if you stage off the kOS controller while a program is still running, the controls on the ship remain locked.  I run my programs from a putty telnet session and even though I staged off the controller, it still attempts to control the active vessel using data from the staged off part that it is still attached to.  I can't control the ship again until I either kill the program or it goes out of draw range.

Not a new problem, and honestly it's one that I've allowed to persist for too long.  It should be fixed in the next release via this PR: https://github.com/KSP-KOS/KOS/pull/1544

If you could actually compile and test that yourself, that would be great.  It's a rather uncommon condition that it takes to get kOS to loose track like that, so I want to make sure I've hit as many fringe cases as possible. 

On 1/25/2016 at 4:47 PM, troyfawkes said:

Second, I'm having huge issues with the docking ports helper functions. E.g., ship:dockingports[0]:undock(). It doesn't always work as expected. You can recreate my issue exactly by creating a ship that has 2 docking ports attached to each other and trying to undock() them on the pad. I got around the issue by writing out this function:

...

This works fairly flawlessly. Am I just doing something horribly wrong with dockingports? Maybe something like this would work to resolve the dockingports issue? Obv. you could refactor to make the function more general.

On 1/25/2016 at 6:05 PM, Steven Mading said:

This is inherited from SQUAD. For some reason I cannot fathom, they decided to make it so that when two docking ports connect, only one of them gets to have the event called "decouple node" on it, and the conditions for which one ends up being which are esoteric and impossible to predict.  It's connected to deciding which of the two vessels got to remain and which got deleted when they merged, but the criteria for that decision are not really explained either.

I have no clue why they didn't just make both ports have the same button label on them.  The user doesn't give a toss one way or the other (and can't even tell, really) which side is the parent and which is the child of the docking.

 

With changes to the way that `dockingport:undock()` works now, you can call it on either of the ports.  If it turns out that you call it on the one without a "decouple node" event, it will automatically call the event on the other port.

[icedown]

22 minutes ago, hvacengi said:

Not a new problem, and honestly it's one that I've allowed to persist for too long.  It should be fixed in the next release via this PR: https://github.com/KSP-KOS/KOS/pull/1544

If you could actually compile and test that yourself, that would be great.  It's a rather uncommon condition that it takes to get kOS to loose track like that, so I want to make sure I've hit as many fringe cases as possible. 

I'll pull it in and test it out.  It's definitely not a normal thing to do but I had a couple early in my new career that I did at the top of the atmosphere and the poor probe ended up really dizzy before I figured out what was going on.  I've done it a couple times so reproducing it won't be a problem.

Edited May 2, 2016 by icedown
Clarification

[icedown]

I'm not sure this is the same problem as issue #1942.  I have installed the latest pull and it still happens.  I'm still working on further isolating the issue but I'm at work now so it's going much slower.  Here is what I have so far. 

I have not used more than 1 kOS part on a ship.  I attempted to duplicate my issue using stock parts + kOS but was not able to.  I then added in RemoteTech and was able to duplicate it.

Mods installed:

• KAC
• Kerbal Engineer
• RemoteTech Dev build 522
• kOS built from current fork with no modifications

Duplication info:

Ship:

• Stock parts, unmanned, single and multiple probe cores tested
• 1 kOS controller onboard, I built mine into the second of 3 stages
• Antenna is on stage 3, antenna on 2nd stage did not help but I did not have probe core on second stage either. 

Process

• Launched ship and climbed to ~50km for testing purposes
• Shutdown main engine on second stage to prevent a runaway stage
• Staged manually

After staging off the section with the kOS part, it continues to control the first stage of the until the program is killed or it falls out of draw range. 

The script I'm running is a self written launch script that limits acceleration to 18m/s/s and flies a 65% launch curve.  It gives the kOS autopilot pitch, heading, and throttle commands via LOCKs.  I have not tested this with any manned craft since introduction of RT. 

Output log: https://dl.dropboxusercontent.com/u/79622787/output_log.txt

I'll try to look into it further myself when I'm off work tomorrow night but it will be my first close look at the code.

 

[Waz]

How do the autotests work? I did a desperate port to KSP 1.2 because I'm too lazy to handhold 20 tourists into orbit and back, but now I'm feeling guilty for not even trying to contribute my changes back. Some design work/discussion is needed for the new resource flows, but otherwise it seemed pretty straight forward.