meyerweb

This line: local x is (shipMassWet / shipMassWet). …should always produce 1, should it not? You’re literally dividing a variable by that same variable.

It looks like you’re dividing the ship’s wet mass by the ship’s wet mass, so a result of 1 is to be expected.

Ahhh, it was the “set a boot script in the VAB before launch” that I was missing. The documentation there assumes you’ll study the picture very carefully to infer what’s needed and why, and I hadn’t—I was concentrating on parsing the text for instructions.

This did not work for me. Does there need to be a `WAIT 1`. before it or something?

You should be proud of yourself, Kartoffelkuchen-- that looks great!

Ooooo…

Hmmm. An interesting challenge, but one that does make some sense to think about and possibly deal with. I’m pondering the idea of having a place to pick an antenna—or input the antenna parameters, for non-stock antennae—and then show their transmission ranges as circles in the display. That would show whether satellites are in range of each other. But right now it’s no more than idle pondering, and that idea may not work given the antenna-power combination-range rules I seem to remember dealing with in the past. Out of curiosity, do you usually have one or two powerful relay satellite(s) that can “phone home”, and the rest of the constellation use antennae that need only reach each other?

If I’ve understood you correctly, you want to make sure the satellites in the constellation can talk to each other—make sure whatever antenna you’re putting on the satellites will have enough range to overlap each others’ positions. Yes?

Hey Gordon, what’s the use case for providing this information? (I ask as the author of the original web-based tool.)

I considered this as well--I'll be very interested to see what you come up with if you do!

Agreed! Anyone who wants to do that based on this code has my pity, and also my permission.

As a Mac user, I use BBEdit even though it has no KerboScript syntax coloring (I haven’t gotten around to defining it). Atom does have a KerboScript highlighting extension (https://atom.io/packages/language-kerboscript), so if you want those sweet sweet colors, it’s a good choice.

Ah, very interesting—that does make things more difficult. I’d be happy to have a slope method that only worked for loaded terrain, but I can see why that would be undesirable from a support point of view (“why does this function work here but not there?!?”). Thanks for the thorough explanation! This is one of the things I really love about the kOS community: the openness and interest in helping people understand. I’ve been on the web a long time, and communities like this are rare. I hope everyone here appreciates it, and especially the community leaders who set that tone.

Oooh, if we’re taking feature requests here, I’d really love a TERRAINSLOPE to go with TERRAINHEIGHT in the GeoPosition structure. I’m calculating slopes by sampling points and doing vector math, but a built-in would make the results more precise and landing scripts ever so much simpler.