ElWanderer

What exactly do you mean by this? Do you have an example?

Judging from the navball, your control point is facing directly upwards (as opposed to forwards, in-line with the wheels). Have you taken that into account when steering? If not, try putting a probe core or docking port on the front and set it as the "control from here" point (kOS can access that, if you want to do it in a script, but worth doing manually to see if it fixes the issue first).

If you do start one for kOS in the Challenges sub-forum, it might be an idea to let people know here and on the kOS Reddit. Most players looking at the Challenges won't be using kOS. Separately, I did wonder how easy the current "official" KSP challenge of flying through a Mun arch would be to automate with kOS. The official challenge is stock-only, mind, but most people's attempts are very hit and miss as a result. If only I had some spare time!

Ah, the smallest things can be so destructive... That particular one was hard to spot as it is valid syntax to end the IF statement with a . and you can surround blocks of code with curly brackets as much as you like (and occasionally this is useful for limiting the scope of local variables).

I can't see anything obvious, though there are a couple of things to say that I can see: 1. you could do with a "WAIT 0." inside that UNTIL loop, so that it doesn't go through the contents more than once per tick. 2. You're giving your velocity magnitude a 2m/s window to hit each time. That would probably work, but towards the end of a stage you might have such high TWR (>5) that it could skip right past it (i.e. go from speed plus 18.9 to speed plus 21.1 in one tick) Those two points wouldn't explain why your rocket is immediately trying to pivot over to 10 degrees pitch angle. Can you add a bunch of display lines to print out the values for surface velocity magnitude, "speed" and z, and to indicate whether it's going inside the IF blocks or not? That might help track down what's going on.

This behaviour is true of almost all languages. You can't test for X < Y < Z, you have to test for (X < Y) AND (Y < Z).

You appear to be checking for the equality of a floating point number (ETA:APOAPSIS) with either another float (or an integer, it doesn't really matter). This will almost never work. Instead, you need to check to see if the floating point value falls within a range. Note: if an IF check doesn't seem to be working, it can help to debug it by printing out the values being compared.

Where you have PARTSTAGGED() the return is not a single part, but a LIST of parts, even if there is only one part in the list. If you will only ever give one part that particular tag, you can stick [0] on the end to get the first object from the list. e.g. SET mypart TO SHIP:PARTSTAGGED("mytag")[0]. Edit: if you have multiple parts sharing a tag, you would need to loop through them (e.g. if you wanted to total their mass).

Ah, okay. I could've sworn it worked like that (and this had caused a bunch of Question threads), but I'm happy to be wrong!

How many antennae do you have on the mothership? As I understand it (incorrectly, it seems. Ignore what follows): To act as a relay, the mothership needs two antennae: any antenna (or antennae) that can connect back to Kerbin, and a specifically-described-as-a-relay antenna (or antennae) that can connect to your probe. It sounds like the mothership is using (both?) the "relay" antennae to talk to Kerbin, so it's unable to relay anything from the probe.

I'll second the reference to OhioBob's page. I wrote up my solution to launching into an inclined plane here (specifically the etaToOrbitPlane function): https://github.com/ElWanderer/kOS_scripts/blob/master/documentation/lib_launch_geo_readme.md The hard part was finding out where the orbit plane would be, as opposed to the ground track of whatever's in the orbit plane. The latter seems a lot more common in the results of Google searches. The kOS code I've written and am still writing is available if you want to go exploring from that link. My rendezvous code isn't too bad, though it's not very realistic. The approach I take is to make sure the orbits intersect then set-up a phasing orbit of the right period so that the two craft meet at the intersection some number of orbits later. The maths of that was a headache to figure out, particularly trying to account for all the combinations of being ahead of/behind the target and in a shorter/longer orbit. In real life, I'm pretty sure they go through a series of phasing orbits that are entirely below the altitude of the station so that in the event of loss of control, there is no collision risk. Effectively, intersection occurs very late on in the process.

UP and FACING are directions, the addition and subtraction of which is a bit of a mystery to me. It might work better if you take their vectors e.g. LOCK diff_vector TO UP:VECTOR - FACING:VECTOR. Edit: but this doesn't answer your question about differential throttling, sorry.

The Turtle moves, though I'm not sure in which direction!

I prefer "turnwards" (plus other directions noted by "widdershins", "hubwards" and "rimwards").

You're only comparing the desired filename to the first file in the list, then immediately returning true or false depending on whether that file is the one you were after or not (so it's probably always returning false). Move the bit that sets the volume to 1 and returns false outside of the for loop, so it is only executed if you've looped through every file and didn't find what you want. Alternatively, the EXISTS(file_path) function exists so that you don't have to loop through the files yourself.

The concept of not checking further parts of an expression once we definitely know the overall result is called short-circuiting. kOS does this: http://ksp-kos.github.io/KOS_DOC/language/features.html#short-circuiting-booleans This means it is useful to order checks within expressions, so that simple checks are done first that can prevent something complicated being checked unnecessarily. It can also be used as a safety measure, to avoid doing something potentially crashy (though this is less obvious to someone reading the code, so it's not necessarily best practice). The two comparisons in your example are both on the simple end. I'd just go for whatever seems more readable to being with, though I'd later viciously reduce it in size to the minimum possible as I am always running out of hard disk space until the KAL-9000 is available.

Apologies for quoting the whole thing, but on a mobile device, it's hard to edit properly. I'm guessing you have more than one engine, in which case the until loop you've added will... loop, repeatedly. LIST ENGINES IN xxx will list *every* engine on the vessel, active and inactive. It should still stage when the stage empties, but it can't do anything else until there is only one engine left.

If you lock the throttle or steering within a script, those will only last as long as the script is running. They'll unlock once your script ends, which is happening immediately in your case. If you put something like WAIT UNTIL FALSE. at the end of your script, it'll keep running until manually cancelled (Ctrl-C, typically).

Is the data worthless? Try it without the m:dump that you've currently got before calling m: reset. From memory, dumping the data will leave goo & science juniors inoperative and you have no protection that checks that ahead of the m:deploy in that section. Resetting dumps the data anyway, I believe. It'd be interesting to know for sure which commands it is trying (and the one it falls over on). Some debug print statements might help. Edit: my reset function does this: m:RESET(). WAIT UNTIL NOT (m:DEPLOYED OR m:HASDATA).

You need to supply both paths, where typically the copy-to path starts with "1:". That's the default volume name for the active CPU. Copypath("0:/file_name.ks","1:") There are a bunch of copypath examples here: http://ksp-kos.github.io/KOS_DOC/commands/files.html#paths-and-bareword-arguments @maculator

Rereading old threads, it seems to be the case that this is required for Remote Tech+kOS, because RemoteTech only allows remote control of those parts with a certain control module (that RT adds to most probe cores). I guess stock+kOS probably doesn't have this requirement. https://www.reddit.com/r/Kos/comments/5q1yuj/kos_no_signal_when_remote_tech_signal_mode_is/ https://github.com/KSP-KOS/KOS/issues/1538

I remember reading something similar, but it wasn't about Remote Tech. With KSP's CommNet and the difficulty option that disables all control if there is no connection aactive, KSP won't let kOS control a vessel if there is no connection. That wasn't meant to happen (KSP was meant to allow autopilot mods to control vessels even when there is no signal) but appears to be a KSP bug/oversight. As to Remote Tech, I would've thought it would be completely independent of the CommNet behaviour. I don't remember hearing of a similar issue.

I don't use remote tech, but this seems to come up a lot: you need either a probe core or a part modded to contain the probe core module (e.g. combining the kOS CPU and probe core into one part). I don't think you need the connection unless trying to access the archive, or to enter commands without local control. I don't use remote tech and may be wrong.

kOS+RT requires a probe core (and a connection?) to do anything. Bear in mind the kOS CPU is a computer that tells the probe core what to do, it isn't able to order around (or be ordered around by) Kerbals. In reply to stargateat77: Can't get the referencing to work on my phone, but is it possible you ran out of electric charge? That would cause the CPU to die, then reboot on power being restored. This would be unusual during a launch, but not impossible. @stargateat77

I wouldn't expect POSITIONAT to work for anything landed. Landed vessels have an orbital velocity based on the body's rotation, but their trajectory does not follow the Keplerian orbit that corresponds to this velocity (e.g. a 175m/s orbital velocity at Kerbin's equator corresponds roughly to a 0m by -598500m orbit, but the vessel can't fall through the planet towards periapsis). For the same reasons, VELOCITYAT is likely not to predict their future velocity. At least body rotation is predictable. Can you rotate the landed craft's current position vector (converted to be from the body's centre to the craft) around the body's axis of rotation by the angle the body will rotate over the time that will elapse? That could then be converted back to be relative to the active vessel. I've not done any accurate landings yet, so I don't really have anything useful to share, I'm afraid.