meyerweb

Members
  • Content Count

    197
  • Joined

  • Last visited

Community Reputation

60 Excellent

2 Followers

About meyerweb

  • Rank
    Rocketry Enthusiast

Contact Methods

  • Website URL Array
  • Twitter Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. This did not work for me. Does there need to be a `WAIT 1`. before it or something?
  3. You should be proud of yourself, Kartoffelkuchen-- that looks great!
  4. 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?
  5. 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?
  6. Hey Gordon, what’s the use case for providing this information? (I ask as the author of the original web-based tool.)
  7. I considered this as well--I'll be very interested to see what you come up with if you do!
  8. Agreed! Anyone who wants to do that based on this code has my pity, and also my permission.
  9. 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.
  10. 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.
  11. 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.
  12. And now: Version 1.4, which includes the ability to specify occlusion modifiers. The default values are the stock defaults, which are—and I am trying to be charitable here—bananas. The default atmospheric occlusion modifier, 0.75, means you can have satellites connect to each other at half the altitude needed without the modifiers. (E.g., instead of a minimum line-of-sight of 600,000m above Kerbin, you can get away with 300,000m.) This craziness is why I left the use of modifiers off by default. If y’all think they ought to be enabled by default, though, let me know why. About the only thing I think I have left to do is add a service worker, in order to remember your parameters between uses, and also to make it all work offline without a hitch. That’ll be version 1.5, or maybe 2.0. It’ll probably be a while before that happens, honestly. But I’ll still be hanging around to answer questions, consider feature requests, fix bugs, and suchlike.
  13. Version 1.3 is done! Now with the ability to pick from the stock system (the default), Real Solar System, and Galileo’s Planet Pack. Also, made a few more under-the-hood improvements. I got the data for body names, equatorial radii, masses, atmosphere heights, and SOI from the game itself—I wrote a little kOS script to dump them all out to a log file, and took it from there. So if there are bodies in RSS or GPP that the game wasn’t telling me about, like minor moons or large asteroids or something that need to be discovered first, they aren’t listed in the Body menu. But! I put the “configuration file” on GitHub for inspection, correction, and extension. You can find the repository at https://github.com/meyerweb/ksp-resonant-orbit-data. The file in question is systems.js, which contains the data for all three systems. If you have a favorite system-remaking mod, please submit the necessary data as a pull request and, assuming there are no problems, I’ll be happy to add it. Now back to my list of other things to deal with, like occlusion modifiers…