ElWanderer

Members
  • Content Count

    369
  • Joined

  • Last visited

Community Reputation

145 Excellent

2 Followers

About ElWanderer

  • Rank
    Spacecraft Software Engineer

Recent Profile Visitors

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

  1. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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?
  2. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  3. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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
  4. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  5. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  6. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    "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?
  7. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

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

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  9. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

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

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

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

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  12. ElWanderer

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    @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...
  13. 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.
  14. 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
  15. ElWanderer

    New Horizons

    [BUFFERING...]