ElWanderer

Members
  • Content count

    254
  • Joined

  • Last visited

Community Reputation

84 Excellent

2 Followers

About ElWanderer

  • Rank
    Spacecraft Software Engineer
  1. On the one hand, I don't know exactly which "readings" you are referring to. On the other hand, that is a tiny difference that could have lots of explanations, not least of which would be the natural inaccuracy of floating point representation and arithmetic, and that Kerbin is always rotating and revolving, so the game engine is having to adjust all the time (though this may be a case where Kerbin remains fixed and the engine rotates the universe around it).
  2. What exactly do you mean by this? Do you have an example?
  3. 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).
  4. 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!
  5. 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).
  6. 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.
  7. 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).
  8. 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.
  9. 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).
  10. 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!
  11. 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.
  12. 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.
  13. 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.
  14. The Turtle moves, though I'm not sure in which direction!
  15. I prefer "turnwards" (plus other directions noted by "widdershins", "hubwards" and "rimwards").