[bug] list element access fails unexpectedly

[baloan]

Happens when a WHEN clause is called while a subprogram incnode is executed from kamc3. Please note that only the WHEN clause for 2nd stage is affected. 1st stage WHEN monitoring and staging work without issues. The main script continues to operate but the WHEN clause having failed screws staging. Checking parts and resources after stopping the scripts shows that the causing resource is still present in the craft (ps[12]:resource[0]:amount). How to reproduce

1. Download scripts and craft from http://ksp.baldev.de/kos/mtkv4/ and install.
2. From Space Center load "Minmus Lander 2c" and Launch
3. Press "9" to open terminal then type run kamc3..
4. run resfind. to dump parts with resources.

[abenkovskii]

In kOS vector is a math vector. The container is called list.

[abenkovskii]

Strange. From your code it looks like ps is list. I'll try reproducing it. May be some advanced kOS hacks I know will help me find the cause of the problem.

[hvacengi]

I think you have a variable collision going on. ps is defined as the parts list in kamc3, but it is redefined as ship:position-body:position in incnode.

If you're open to it, I'd also suggest potentially using ship:availablethrust or ship:maxthrust to determine staging. We're working on pushing an update that makes it work correctly (right now it doesn't account for the atmospheric isp changes) but I'm partial to this code:

    // stage control
    set stagemaxthrust to ship:maxthrust.
    when (ship:maxthrust < stagemaxthrust or not (ship:maxthrust>0)) then {
        if stage:ready {
            print "Stage!".
            stage.
            set stagemaxthrust to ship:maxthrust.
        }
        if ( stage:number > 0 ) { preserve. }
    }

When the update comes out it would change to ship:maxthrustat(0). But this code will work for asparagus stages, booster stages, and single engine stages alike.

[abenkovskii]

Why are you using so short names? And why aren't you using functions with local variables?

[hvacengi]

@abenkovskii he is working on migrating old code to operate with the current version of kOS. For those of us who used kOS with remote tech before the disk sizes were increased (which may be you too for all I know), every byte counted. My earliest scripts replaced every \r\n (carriage return-line feed, windows style return) with \n (line feed, linux style) to save a few bytes. And I had to delete all of my comments once I got a script running smoothly.

I don't think that functions are necessarily the answer either, though local variables would certainly help. Personally, I only use functions as utilities, for things that need to be repeated frequently, but don't provide direct control output. The only reason is that's how my brain organizes it. I'm sure that as @baloan dives deeper into the newer features, he will find more ways to "optimize" his code. Looking at that mission toolkit (which I used as a reference when I started with kOS) it's intricate enough that getting it running is probably the first priority.

[baloan]

Doh. Thanks, that helps. And yes, after getting it to run, I want to clean up and use the shiny new language features.

[hvacengi]

np. Like I said, your scripts are near the foundation of where I started with kOS, so anything I can do to return the favor is great. I'm just happy that kOS wasn't some how returning a vector in the place of the list... that might have been a bear to find.

[baloan]

@hvacengi My current setup allows for different staging behavior for each stage (which I use). With 0.23.5 aerodynamics the injection stage would have to be jettisoned while descending to Mun. That only works if throttle is cut before staging. Then, I was trying to find a workaround for the broken stage:liquidfuel.

[baloan]

Issue resolved - may be closed.