• Content Count

  • Joined

  • Last visited

Community Reputation

146 Excellent


About ElWanderer

  • Rank
    Spacecraft Software Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Safety is also an important consideration. You can't just put yourself on a (near-)collision course with a view to matching velocities once close - what if your vehicle loses control in the meantime and can't change velocity? Approaches to the ISS are failsafe in that if the engines fail, there won't be a crash, but this means making multiple small correction burns to get close.
  2. Orbits are stored internally in that format (e.g. that's what you see inside the save file), which is why I guess the cheat menu gets you to enter those values rather than Ap/Pe and calculate the SMA/ECC for you. https://en.m.wikipedia.org/wiki/Orbital_elements (see the section on Keplerian orbital elements)
  3. Woo! Pity I missed most of that and lost all sound on the stream I was watching.
  4. Ooops, sorry, that's my mistake. I was thinking about two things at once and thought you were after the boot file path!
  5. 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
  6. 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?
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. "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?
  12. You can have two separate CPU parts with two different boot scripts, yes. Each CPU would run its own program.
  13. 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.
  14. Hmmm. My shared boot script does have this first, so possibly: WAIT UNTIL SHIP:UNPACKED.
  15. You can get one to open automatically if you stick the following in a boot file: CORE:DOEVENT("Open Terminal").