ElWanderer

Woo! Pity I missed most of that and lost all sound on the stream I was watching.

Ooops, sorry, that's my mistake. I was thinking about two things at once and thought you were after the boot file path!

I don't see that suffix in the documentation for a craft template: https://ksp-kos.github.io/KOS/structures/vessels/crafttemplate.html#structure:CRAFTTEMPLATE

This weirdness rings a bell, but I may be thinking of something else. I could've sworn I read once that the other ships' positions are not calculated super-accurately until you get close enough to them, which can cause them to appear to jump. Will have to Google it. Edit: first Google result: Are you using time warp?

It could suggest you're doing too much in one loop or that your final approach velocity is a bit high... For comparison, my loop ends when the docking port changes to any state that isn't ready, and I've never noticed this kind of problem. Then again, my loop is fairly simple, especially compared to the initial route calculation before approach. My final approach velocity is 0.2m/s once within a few metres. I guess one goto-like approach would be to stick the loop contents into a function and load it with checks that can return early if the target becomes invalid midway through.

If you've already put the ship on the launchpad, you can right-click on each CPU part and open a terminal. In each terminal, you'd then copy over and run one program. e.g. you might type COPYPATH("0:/test.ks","1:/"). RUNPATH("1:/test.ks"). in one terminal. In general, its easier to set these up as boot programs that get loaded and run automatically. You do that in the ship editor (VAB/SPH) by right-clicking on the part and selecting a boot script. Note that first you need to have a folder named Boot within your Ships/Script directory, and have the programs you want to run in there, as it's that directory that is scanned when the VAB/SPH build editor starts. Note also that this choice of boot file(s) will be saved against the particular ship design so would need to be repeated for new designs. https://ksp-kos.github.io/KOS/general/volumes.html#special-handling-of-files-in-the-boot-directory

Instead of "SET TARGET TO port." do "SET my_variable TO port." In my case I do something like "LOCAL target_port IS pickTargetPort(TARGET)." where the function loops through the ports on the input vessel and picks the "best" one. Actually I store the target in a variable too in case the player accidentally deselects or changes it during docking.

Do you have the same problem if you store the port in your own variable rather than using TARGET? That's what I do, and I've never had this problem, though my rendezvous is usually less than 100m out. Also, I imagine that if you are far enough away that the target ship hasn't been properly unpacked/loaded (I forget which one is which right now), you may not be able to do anything as KSP won't know where the port is. You could carefully play with the various load distances if that turns out to be a problem.

"lock steering to prograde." Literally, what's inside the quotes is what you would type in the terminal (or into a script) to lock the steering to orbital prograde (surface prograde would need srfprograde instead of prograde). Is there more to your question than that?

You can have two separate CPU parts with two different boot scripts, yes. Each CPU would run its own program.

No, but the local hard drives retain their state. So you can save commands to a file on the local hard drive that put you into the right state to resume after a reload. My approach is fairly simple most of the time, saving "SET run_mode TO x." to a file that can be run during start-up to get the current run-mode. You can store quite a few variables if needed, though. The complicated bit is writing the main program in such a way that it can recover gracefully from a restart using this data. Edit: you would need the craft to run the mission from a boot file to do this automatically, else you'd need to run the program manually on switching back.

Hmmm. My shared boot script does have this first, so possibly: WAIT UNTIL SHIP:UNPACKED.

You can get one to open automatically if you stick the following in a boot file: CORE:DOEVENT("Open Terminal").

That looks right to me. A note on VECDRAW (as it's much easier to talk about with a diagram): vectors A and C originate at the ship's current position, or V(0,0,0), so the origin parameter of the vecdraw would be V(0,0,0). Vector B originates at the central body, so you would need to pass in BODY:POSITION as the origin parameter.

@FloppyRocket It looks like you are mixing up two different vectors. SHIP:BODY:POSITION will give you a vector from your ship's current position to the middle of the central body (e.g. Kerbin). POSITIONAT(SHIP,t) will give you a vector from your ship's current position to where it will be at time t. (aside: the good news is that if your orbit is elliptical, both vectors are relative to the central body, so you don't have to take into account the motion of the central body in the meantime). That is, it'll be a vector between two points on your orbit. You want both vectors to be to (or from) the central body to be able to compare them. To convert between the two, you need to need to add/subtract the BODY:POSITION vector (note the SHIP: at the beginning is optional). I'm not great at explaining this bit, sadly. I think to get the predicted vector pointing towards the central body, you would need to use BODY:POSITION - POSITIONAT(SHIP,t). Printing out the angles is good debugging practice, but I would also advise you to try drawing the vectors on the screen using VECDRAW(). I found it easier to keep track of what was happening that way. Of course, drawing vectors that don't originate at your current position is a learning curve in of itself...

Blimey, I had no idea. I only checked the precise launch pad co-ordinates in one version when testing a kOS script, and it never occurred to me that it could change from version to version.

Is this definitely a change? From checking in the past, I thought the runway was at 0 and the launchpad slightly to the South of the equator, but I could be remembering incorrectly. Duplicate

[BUFFERING...]

Sounds like you are missing the sphere of influence altogether. You can't capture if you don't get close enough. The two grey markers indicate closest approach. You want to plot a manoeuvre and tweak it in all directions until you find which way (or ways) causes the markers to get closer and closer together. If you change your trajectory such that you will go into the planet's sphere of influence, the display will change to show a periapsis at the target. You can keep tweaking until this periapsis is nice and low, then burn the manoeuvre.

Choo Choo! Will there be hooks so a mod can query how much delta-v a ship/stage has?

I don't think that's possible. Would be nice to have. I would say I'd use it if it were... but actually I generally need my CPUs to run on the launchpad to download all the scripts they need when there is a guaranteed connection, in case there is no signal when they're run up "for real" later in the mission.

Give it a boot script that checks the vessel's status and turns off the processor if it is pre-launch, IF(SHIP:STATUS = "PRELAUNCH"), or whatever condition you want to check for. That way it'll stay running if powered up after launch. Turning off a script's own processor is as simple as: CORE:DOEVENT("Toggle Power"). Turning other CPUs on or off is a bit more complicated, and probably involves part tags to identify things.

If it is available as an option on the part action window (i.e. what pops up when you right-click on a part), it should be available as an event. As you've seen, the availability of actions is a bit hit and miss, and depends on what the KSP devs decided to make actionable.

My Bible: http://www.braeunig.us/space/orbmech.htm#position The game data files/wiki should contain each planet's mean anomaly at game start. The time elapsed divided by the orbit period gives you the number of orbits. Multiply by 2π to get that in terms of mean anomaly and add to the first part. (if the answer is over 2π, keep subtracting 2π until it's in the 0-2π range). Now convert mean anomaly to true anomaly (via eccentric anomaly). You will need the orbits eccentricity for this (again, this should be available from the wiki or possibly even in-game). Edit: ah, actually it may be that converting mean anomaly to eccentric anomaly and then true anomaly requires iteration (e.g. Newton-Raphson method) rather than a single calculation. I did write a bit of a Java program to work out where all the planets would be given a time point from a save, but that was many months ago and I seem to keep forgetting important details. At least I can link to it: https://github.com/ElWanderer/kOS_scripts/blob/MissionBuilder-draft/src/com/elwanderer/missionbuilder/OrbitUtils.java If you have the true anomaly, you can plug this into an equation that gives the orbital radius at that point, if you already have the semimajor axis and eccentricity (equation 4.43 in the link above).

By@Luovahulluus You can pass parameters into a program. In the past it was a case of RUN filename(param1, param2, etc.). I imagine you can do something similar with RUNPATH, though I've not checked the syntax. Edit: yes, this is valid e.g. RUNPATH(filename, param1, param2, etc). The program you call needs to declare the parameters you'll be passing in. I believe a program can RETURN, so you'd have something of the form MYVARIABLE = RUN(X,Y). Again, I've not checked that in the docs yet. If it doesn't work, you could always set-up a global in your outer program then get the inner program to alter it.