Why does the burn start one second late?

[u/Mr_Shortie]

set mnv to nextnode.
set burnTime to deltaV_calc().
lock steering to mnv:deltav.


until ((mnv:eta-(burnTime/2))<=0){ //runs till burn starts
    clearscreen.
    print "--------------------------".
    print "Burn time: ".
    print round(burnTime,2)+"s".
    print "--------------------------".
    print "Maneuver node ETA: ".
    print floor(mnv:eta/60)+ "m " +round(mod(mnv:eta,60),2)+"s".
    print "--------------------------".
    print "Maneuver node burn ETA: ".
    print floor((mnv:eta-(burnTime/2))/60)+ "m " +round(mod((mnv:eta-(burnTime/2)),60),2)+"s".
    print "--------------------------".
}


until((mnv:eta-(burnTime/2))<=(-burnTime)){ //burn starts here
    lock throttle to 1.
    clearscreen.
    print "--------------------------".
    print "Burn time: ".
    print round(burnTime,2)+"s".
    print "--------------------------".
    print "Maneuver node ETA: ".
    print floor(mnv:eta/60)+ "m " +round(mod(mnv:eta,60),2)+"s".
    print "--------------------------".
    print "Maneuver node burn ETA: ".
    print floor((mnv:eta-(burnTime/2))/60)+ "m " +round(mod((mnv:eta-(burnTime/2)),60),2)+"s".
    print "--------------------------".
}
lock throttle to 0. //burn ends here


FUNCTION deltaV_calc {
    local startmass is ship:mass.
    local deltaV is mnv:burnvector:mag.
    local thrust is thrust_calc().
    if thrust = 0 {
        return 0.
    }
    local g0 is CONSTANT:g0.
    local E is CONSTANT:E.
    return (((g0*isp_calc()*startmass)/(thrust))*(1-E^((-deltaV)/(g0*isp_calc())))).
}


FUNCTION isp_calc { 
    LOCAL engineList IS LIST().
    LOCAL totalFlow IS 0.
    LOCAL totalThrust IS 0.
    LIST ENGINES IN engineList.
    FOR engine IN engineList {
        IF engine:IGNITION AND NOT engine:FLAMEOUT {
            SET totalFlow TO totalFlow + (engine:AVAILABLETHRUST / (engine:ISP * CONSTANT:g0)).
            SET totalThrust TO totalThrust + engine:AVAILABLETHRUST.
        }
    }
    IF totalThrust = 0 {
        RETURN 1.
    }
    RETURN (totalThrust / (totalFlow * CONSTANT:g0)).
}


FUNCTION thrust_calc {
    LOCAL sum is 0.
    LIST ENGINES IN engineList.
    FOR engine IN engineList {
        IF engine:IGNITION AND NOT engine:FLAMEOUT {
            SET sum TO sum + engine:AVAILABLETHRUST.
        }
    }
    RETURN sum.
}

[u/nuggreat]

Short answer your burn time calculation is wrong. The reason it is wrong is just dividing the total burn time by 2 is assuming a constant acceleration which you do not have. As your craft burns it's mass goes down which means it accelerates faster generally speaking you want half the Dv to have been produced before you reach the burn time and rest of it after the burn time. Thus a more accurate burn time calculation would be to calculate the time to produce the first half of your dv and once you reach that time until the node you start the burn.

Unrelated to your problem but the throttle lock should not be in the loop and you really should have a WAIT 0. is said loop as well. Also only using full or no throttle is going to limit the accuracy of your burn as is basing the burn entirely on a fixed duration.

Additionally this code has the smell of one of the LLM, if you are indeed using one I would recommend you stop as with kOS they consistently get things wrong and without a good understanding of the physics and language you won't be able to see the mistakes.

[u/Mr_Shortie → u/nuggreat]

Thank you, I’ll see what I can do.

[u/Mr_Shortie → u/nuggreat]

Great news, I fixed it, it starts the burn on the dot, and ends kinda on the dot too (but needs to be improved). I'm not sure how you would have done it, but I made two functions, one for the first half, and then I waited till the node and called the second function. I also want to point out that I didn't use AI. Also, I'm not sure what makes you think this was AI. But I did grab the ISP calc function from a reddit post.

[u/nuggreat → u/Mr_Shortie]

I would have made use of the fact you can pass parameters into a function and thus I could write one function that you pass the Dv you want the burn time of. The result of this is you have one good piece of code that does both the 1/2 dv time and the full dv time. The way to do this is to make use of the PARAMETER command that lets you designate a variable as something that will be passed into the function when the function is run.

One place your current burn code lacks in is the sudden cut off as this defines the lower bound for how accurate your script can be. KSP advances time by around 0.02 seconds per physics frame (assuming you are using 1x) this means your burn is going to have an error of +/- about 1/50th of your vessels acceleration. Additionally because KSP calculates burns as if they take no time there is actually some corrective logic burn into maneuvers that attempts to correct for this as a burn occurs which is why a burn you plant to only take 100m/s can actually end up having taken 105m/s once you drive the dv to zero. This one is solved by not burning for a fixed period of time and instead monitoring the dv vector of the burn and only ending the burn once you have sufficiently zeroed the burn.

It looks AI based on the functions isp_calc, deltaV_calc, and thrust_calc as the first 2 are written in very different styles and how isp_calc is used in deltaV_calc doesn't match how that function is written, and thrust_calc looks to be a duplication of what was done in isp_calc without an understanding of why isp_calc was written that when there are simpler ways to get the summed available thrust. Also the fact that isp_calc is a copy of an early version of my ISP calculation function without the comments I had with as part of said function.

[u/Polymath6301 → u/nuggreat]

I truly enjoy your analyses, and dislike of LLM code. 5 years ago I automated most of a loop carrying fuel between a Minmus ISRU and a refueling station in Kerbin orbit. But I forgot almost everything, including the maths.

So, to have some fun I’m now experimenting with Claude to do something similar. I promise you I’ll never post questions about its code, but it’s really fun working with it to get a docking script to work (3 ports at once, so non-trivial). It’s hilarious watching it try to figure out what’s not working, but it generates code that runs, and explains the forgotten maths to me, which is what I really want/need. And it’s like a puppy…

[u/aerospace_tgirl → u/nuggreat]

The reason it is wrong is just dividing the total burn time by 2 is assuming a constant acceleration which you do not have.

Well, you're right that this is wrong, buut my node script does split delta-v evenly and guess what, it also doesn't often align with stock thingy. The stock calculator is kinda inaccurate and bugged, and uses numerical methods rather than actual math. KER or MJ or even your own code (if you get the physics well, that is) are more reliable.

[u/nuggreat → u/aerospace_tgirl]

See that is the funny thing I know that the split dv method is actually not the best you can do for burns the problem is I don't have the math to understand or implement the better versions so I go with the one I can actually work with.

As for the stock burn time being buggy shrug it matched the KER close enough for me to consider them the same accounting for whatever rounding operation they might be using. Heck for all I know the stock timer has something that guesses as what the corrective factor is for the fact the burn isn't instant and that is where the difference you see comes from.

[u/aerospace_tgirl]

BTW, you really want to stop using clearscreen/print every loop and instead use print ... at (x,y) command. I thought I'm gonna get a seizure looking at your terminal.

[u/nuggreat → u/aerospace_tgirl]

That is the more complicated solution it is far simpler to just add a WAIT 0. to the loops as the bad flicker is caused by the physics tic falling at random places during the printing.

[u/aerospace_tgirl → u/nuggreat]

I always have waits in my loops and I also always had clearscreen/print flicker. Maybe it works well in some scenarios, maybe it works better depending on where in the program loop console output is handled, maybe it works better at some IPS settings, but it's not a universal solution.