• Content count

  • Joined

  • Last visited

Community Reputation

81 Excellent

About ElWanderer

  • Rank
    Spacecraft Software Engineer
  1. 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.
  2. The Turtle moves, though I'm not sure in which direction!
  3. I prefer "turnwards" (plus other directions noted by "widdershins", "hubwards" and "rimwards").
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. 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).
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. Launch azimuth/heading is different to the azimuth/heading of the target orbit overhead (for Minmus, the orbit azimuth would be 84°/96° at the equator) because you already have some Eastwards orbital velocity due to the rotation of the planet. http://www.orbiterwiki.org/wiki/Launch_Azimuth