ElWanderer

Members
  • Content count

    237
  • Joined

  • Last visited

Community Reputation

75 Excellent

About ElWanderer

  • Rank
    Spacecraft Software Engineer
  1. 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.
  2. 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).
  3. 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).
  4. 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
  5. 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
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. >Is there any way to time a launch such that we can insert directly into a minmus plane (applying our inclination burn during launch)? Yes. You can time the launch visually by waiting in map mode until the plane of Minmus's orbit passes over your craft (at the KSC). I realise you want to fly the mission in IVA view, but perhaps you would allow map mode prior to launch? It's quite awkward to do so, but you can try to fly at an azimuth of 83.5°/96.5° by hand. That's the initial compass heading you need to take at launch to end up with an inclination of 6° in LKO. Alternatively you can use maths and mods (for the maths to be doable you probably need an information mod at least). Myself, I use kOS to calculate the launch time and control the launch. Yes, being able to convert between geographic longitude and universal longitude via the universal reference vector is important, but you need to know where that reference is. It's not exposed in stock. It would be useful to work out what longitudes Telemachus is giving you. To answer your earlier questions: You can do the plane change to match Minmus's orbit in one go, rather than zeroing your inclination first, but that's harder to calculate. OhioBob's website is pretty handy for this kind of thing: http://www.braeunig.us/space/orbmech.htm
  12. Wikipedia has a Stability of the Solar System page: https://en.wikipedia.org/wiki/Stability_of_the_Solar_System Confusingly, it also has a page on "Orbital Stability" that has nothing to with orbits, but is related to mathematical functions.
  13. I did find this: One suggestion from that is to turn off fine control if you're using it. It's not the thread I was remembering, though.
  14. This rings a bell. I think there is a KSP bug whereby it calculates the torque each RCS thruster will generate invorrectly, causing those well away from the centre of mass to fire barely, if at all, which is the opposite of what you want to happen. I'm not sure what search terms to suggest, though.
  15. My code calculates the available delta-v for the current stage prior to each manoeuvre, so as to determine if it needs to stage, which affects the burn time estimate. When I recently started testing against KSP v1.2.2/kOS v1.0.3, I noticed I was getting 0m/s printed out a lot indicating STAGE:LIQUIDFUEL/OXIDIZER were both zero. Toggling stage view in the KSP resources tab showed the same data: no fuel. Yet the engine was active and had fuel (and the engine part gauge in the staging list in the bottom left showed access to liquid fuel). I had a bit of a play, and got the impression that staging and stage (re-)ordering seemed to matter. KSP didn't seem to like me firing the next stage at the same time as triggering the decoupler. Separating those into two steps seemed to help. I say "seem" because my testing was definitely not rigourous. One example that stuck in my mind was when my upper stage was reported as having no resources except for 16 units of solid fuel; that fuel was in two sepratrons mounted on the stage to deorbit it, but naturally they weren't activated at the time (they were set-up to activate along with the decoupler above). This is fairly common in my designs, and may be the reason why I'm suddenly seeing this with almost everything I launch (compared to launching the same craft in KSP v1.1.3/kOS v1.0.1). Another example was a ship that docked to another craft, then undocked. On undocking, KSP reported it no longer had any fuel in the stage. I added an empty stage below the current one and triggered it. Then the stage fuel numbers appeared. In this example, I think I was using my docking tester, which has a single stage once in orbit, but it's possible that I was using my crew shuttle that has extra stages (decoupler, chutes, heat shield jettison if I'd forgotten to remove it) to confuse matters. I'm sorry I don't have any concrete examples; I don't get much time to play the game itself. Edit: I should point out that none of my current designs use fuel pipes so that's not a factor in these examples. I know the kOS v1.0.2 release notes explicitly mentioned asparagus staging as an area where you'd expect to see changes in behaviour.