ElWanderer

Members

245

83 Excellent

1 Follower

• Rank
Spacecraft Software Engineer
1. How do I map Antenna Class Types shown in KSPedia to actual antennas?

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!
2. How do I map Antenna Class Types shown in KSPedia to actual antennas?

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.
3. Calculating launch windows and rendezvous maths

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.
4. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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.

The Turtle moves, though I'm not sure in which direction!

I prefer "turnwards" (plus other directions noted by "widdershins", "hubwards" and "rimwards").
7. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

You're only comparing the desired filename to the first file in the list, then immediately returning true or false depending on whether that file is the one you were after or not (so it's probably always returning false). Move the bit that sets the volume to 1 and returns false outside of the for loop, so it is only executed if you've looped through every file and didn't find what you want. Alternatively, the EXISTS(file_path) function exists so that you don't have to loop through the files yourself.
8. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

The concept of not checking further parts of an expression once we definitely know the overall result is called short-circuiting. kOS does this: http://ksp-kos.github.io/KOS_DOC/language/features.html#short-circuiting-booleans This means it is useful to order checks within expressions, so that simple checks are done first that can prevent something complicated being checked unnecessarily. It can also be used as a safety measure, to avoid doing something potentially crashy (though this is less obvious to someone reading the code, so it's not necessarily best practice). The two comparisons in your example are both on the simple end. I'd just go for whatever seems more readable to being with, though I'd later viciously reduce it in size to the minimum possible as I am always running out of hard disk space until the KAL-9000 is available.
9. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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.
10. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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).
11. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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).
12. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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
13. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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
14. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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.
15. [1.2.2] kOS Scriptable Autopilot System v1.0.3 2016/12/07

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.