ElWanderer

Members
  • Content Count

    378
  • Joined

  • Last visited

Community Reputation

147 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. If you're still trying to work out timing, I'm pretty happy with my solution. Here's a link to my documentation where I go through my launch azimuth/ETA calculations: https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_launch_geo_readme.md
  2. The display is showing two different TWRs against two stages, the first of which has no delta-v. I think it is assuming you are going to decouple the extra mass before burning, giving you a TWR over 2 and 4.2km/s delta-v, but actually your TWR is more like 1.7 and your delta-v will be correspondingly lower. It doesn't know when you intend to fire that decoupler, though you may be able to help it by moving it about in the staging menu.
  3. Yes. kOS was changed a fair while ago and this behaviour became really noticeable (reporting 0 fuel, or fuel within SRBs that aren't firing, for a stage), but my understanding is that it matches the way KSP itself calculates it. Trying turning on the resources view in KSP and tick the "stage only" (from memory) box. See if that reports any fuel at the time kOS says it is zero. It's something to do with confusion as to what is in a stage. I tend to notice it when I have sepratrons that will fire on stage separation, that are attached to the stage that will be discarded.
  4. Well, the simple response is: where is missionT defined? However, the code you've printed is full of variables and function calls that aren't defined anywhere that we can see. missionT is just the first of many such problems and fixing them one-by-one would be quite painful. Is your code meant to be loading libraries that define those variables and functions? If so, those libraries need to be run at the top of your script, to load in all the bits you are dependent on.
  5. 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.
  6. 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)
  7. Woo! Pity I missed most of that and lost all sound on the stream I was watching.
  8. Ooops, sorry, that's my mistake. I was thinking about two things at once and thought you were after the boot file path!
  9. 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
  10. 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?
  11. 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.
  12. 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
  13. 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.
  14. 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.
  15. "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?