ElWanderer

My (work in progress) precision landing script requires the target latitude and longitude (plus a maximum allowed slope angle, if the slope at the target point is higher, it goes looking for somewhere flatter) to be edited into the boot script before launch. You can get the latitude and longitude of contract waypoints. I believe KerbNet allows you to drop a new waypoint, which you could then use as an aiming point, but I've not tried that. Or you could ask for the target coordinates to be typed into the terminal, or even set-up a GUI to get this. Of course most of these methods are somewhat blind unless you have a good map of the area!

Yes, to the first part, though with high inclination orbits the plane of your orbit won't be aligned nicely with the prograde/retrograde motion of the body you're orbiting most of the time. Whereas an equatorial orbit has an escape burn position every orbit, you could have to wait days to get an efficient return from a polar orbit. There is a good video Steven Mading / Dunbaratu put together about the axes on YouTube somewhere. The short version is that the Y axis always points to the universe's up direction, but the X and Z axes are constantly rotating around it and so can't be trusted to be pointing in any particular direction, except that they'll be orthogonal to the Y axis and to eachother. As such, I'm always very wary of solutions with R() rotations in them and prefer to have things rotated relative to other tangible things rather than the raw axes.

I would expect small discrepancies unless your orbit has very low eccentricity and inclination. Try using the orbit editor to put those values at something tiny (or even zero, though I find 0 ECC can cause problems) and see if it is more accurate. Also, I think R(0,angle,0) would only be 100% correct for 0-inclination orbits around bodies whose own inclination is 0. If you have a polar orbit around Minmus, for example, you need to bear in mind that neither ship nor planet velocity is in the plane defined by the universe's Y-axis.

Have you used SET THROTTLE TO X anywhere in your script (as opposed to LOCK THROTTLE TO X)? I think I've heard other people report that behaviour, though I've not done a search yet to check that. I assume you've not lost connection or anything... Edit - I did a search: Erm, didn't really want that embedded, as you can't see the replies without going to the link itself. https://www.reddit.com/r/Kos/comments/7q6oia/control_throttle_after_program_ends/

LOCAL moon_vel IS VELOCITYAT(moon,c_time):ORBIT. I then get my ship's position vector (from the centre of moon to where the ship will be i.e. POSITIONAT(SHIP,c_time)-BODY:POSITION, flattened into the appropriate plane with a vector exclude) and get the angle between it and -moon_vel. Then iteration/calculations (for ages I simply incremented at 15s intervals) follow to find out when we will be at the point with the right angle to retrograde.

Computer says no

What Snark said for why it doesn't work. I had a lot of trouble getting inclination corrections right. My interim solution involved the following: LOCAL dv_pro IS -1 * ABS(dv * SIN(ang / 2)). LOCAL dv_norm IS dv * COS(ang / 2). Note that doesn't work accurately if you're burning at a point in your orbit where your flight angle is non-zero (as you need a radial component to the burn too). That's not a problem in this specific case of burning at apoapsis (flight angle is 0 at an apsis or if eccentricity is 0). My current implementation is more complicated - I calculate the desired final velocity vector, then the difference from the initial velocity vector at the node... then convert that difference vector into pro/radial/normal components.

Boot scripts run on load, any load (i.e. on loading a save, on putting a vessel on the launchpad, on coming within physics range or switching to a vessel that had been unloaded), if the processor is powered. I've not done much with multiple CPUs per craft to separate out launcher code from payload code. One exception is my equivalent of an Apollo lander. That boots up on the launchpad, stores a bit of state (so the next time it boots, it acts differently), then turns its own CPU off, to be reawoken later (manually, but it could be automated) in Mun orbit. As KSP limits some actions to the active vessel, I try to avoid having more than one vessel actively doing things at once (though this may be excessively cautious). You don't want the mothership time warping to the next satellite release while the last one is still manoeuvring, either. You could use inter-CPU/vessel messaging to pass control back and forth.

Yes (though with caveats - see below) and no respectively. If the vessel gets unloaded, kOS will stop running on it (and even if it kept running somehow, it would have nothing to control). The caveats are that KSP itself limits certain abilities (e.g. adding a manoeuvre node) to the active vessel under player control. Edit: one solution would be to make your script switch focus to the satellite, then have the satellite run a circularisation program that switches back to the mothership on completion. The script on the mothership would need to cope with its running being interrupted if it goes out of physics range while you're controlling the satellite.

Which version of kOS? There was a problem in the past where if you logged out a vessel's object (e.g. to store the current target so that a rendezvous script doesn't break if the target gets unset midway through) it would be recorded as "SHIP('Kerbal X')" instead of "VESSEL('Kerbal X')", which then causes an error on trying to read it back in. I don't know if that error was 'Undefined variable ship', though, but it's the first thing that came to my mind. https://github.com/KSP-KOS/KOS/issues/1776

https://github.com/KSP-KOS/KOS/issues/2191 The button callback function is a trigger, so it blocks the triggers that update the steering and throttle whilst it is executing. Unless/until this behaviour gets changed, I would recommend that button callbacks should be short, simple functions. I'd implement this as a run mode loop and have button prrsses try to change the run mode.

I've noticed this too, but haven't tried doing similar steps without kOS to see if it is a plain KSP issue first and foremost. I have read posts where people say there are KSP memory leaks associated with certain actions that reload scenes. There was a worry about a potential memory leak a year ago, but the Devs couldn't recreate the problem: https://github.com/KSP-KOS/KOS/issues/1960

You could disable the reaction wheels in some of the pods, which avoids needing a new design. If kOS is not expecting so much torque, then playing with the steering manager settings would be one solution for that vessel. Usually, though, kOS is confused by ultra-low-torque designs (e.g. realism overhaul rockets and plane designs), so it's a bit of a punt on my side that it is not working well with lots of wheel torque.

Are you locking the steering outside the loop or inside? From what you're saying, I think you're doing it outside, but if you were to lock it inside the loop, it'd reset all the terms of the PID loop each tick, which would not help the steering settle. It may be just that you have a lot more torque (from all those pods) than kOS's steering manager is expecting/optimised for.

Yes. kOS's steering manager is a separate steering mechanism, implemented differently to KSP's SAS. For certain designs, one or the other may steer "better" because of this. That said, are you steering to RETROGRADE or to SRFRETROGRADE? The former would differ from the latter more and more as you slow during descent. SAS steers to the surface or orbital retrograde according to the navball, which automatically switches to surface mode during descent.

Are the versions compatible, though? Last I heard, v2 Trajectories and kOS aren't compatible yet: https://github.com/KSP-KOS/KOS/issues/2254

The funny thing with descent is that you can start with fairly poor TWR (even less than 1, for a constant altitude style approach), as long as it rises to something respectable by the time you're primarily fighting gravity rather than bleeding off horizontal velocity. This is where nuclear engines struggle, as they burn off fuel mass too slowly (on top of being weak and heavy)! That is based on my spreadsheet simulation rather than actual experience, mind.

Well, angleaxis is to rotate the steering vector, the lookdirup I wrote was to keep a plane the right way up. To keep a rocket from rotating unnecessarily, I'd put a FACING:TOPVECTOR as the second lookdirup argument instead. As to the general idea of doing it more easily - there probably are shorter solutions if you know how to rotate directions. I do not, so tend to use angleaxis - the idea of rotating a vector around the axis formed of a second one is something my brain *can* grasp!

Yes, I could've been clearer about that (though the post I was quoting did reference the ascent stage). For descent, you can get away with fairly low thrust to weight ratios, but if you're flying manaully it's a rather risky proposition. It is comforting to have a high TWR in case you need it.

Hmmm. As you decelerate horizontally, your retrograde vector will want to pitch up... if you can control your vertical velocity (i.e. keep it at zero) then it'll counter that and keep the retrograde horizontal, so the assumptions should hold true. If you lose control, it'll rapidly become an incorrect solution, I fear. It sounds worryingly circular... Personally, I switched to a controlled altitude descent a while back - I no longer zero out v-speed but let it drop such that my final suicide burn will be very near the ground (I have to scan ahead to work out the minimum safe v-speed). That does require knowing at what angle above the horizon to pitch.

Depends what you're trying to achieve. Do you want a certain pitch relative to the horizon, or to the pro/retrograde vector? Using the starboard facing vector as an axis of rotation for pitch will only work when your pro/retrograde vector and facing forevector are aligned (i.e. along the same compass bearing). If they're not aligned, you'd get increasingly weird results.

I remember reading threads where people ran some of the numbers on this, and the conclusion generally seemed to be that beyond a TWR of 2.5, the delta-v savings were tiny.

So go to that craft, kill the boot script when it fires up, then enter this in the terminal? COPYPATH("1:/boot/my_script.ks","0:/boot/my_script.backup.ks"). It's possible you accidentally created a folder named "1" on the archive at some point. PS. It can be good practice to use some kind of code versioning/change management set-up. I put my scripts on GitHub so I can track changes and keep online backups.

"0" is the archive (ship/scripts), "1" is the local hard drive for the active CPU, in the game, so would get baked into your savefile.

I wrote an Excel spreadsheet to calculate how TWR would affect delta-v and burn distance, when performing a zero-descent burn. My designs with nuclear engines tend to end up with such poor TWR that the extra delta-v and distance required shoots up. https://github.com/ElWanderer/kOS_scripts/tree/v1.1_draft_changes/misc Note that the spreadsheet doesn't include calculation of a deorbit burn (50m/s roughly for Tylo) or the final suicide/landing burn (allow 250m/s, I guess, though the more the merrier if doing it manually). My kOS lander script has made it down on target using about 2500m/s, but it isn't consistent and sometimes wants 3200m/s+