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.

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.

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…

’ello, all! I just updated the Stock KSP Resonant Orbit Calculator to v1.2. Most of the changes are under the hood, but this version also corrects an embarrassing error on my part in previous versions, where at least some synchronous orbit values were off by a small but significant amount. (One of the under-the-hood changes is to stop defining that as a static value for each body, and instead calculating it from the body’s various physical characteristics.) It also fixes a duh-me bug that broke the line-of-sight diagram when the constellation was too low, which I introduced in the previous version. I made a distinction above that it’s the Stock KSP calculator because I’m beta-testing resonant calculators for both Real Solar System and Galileo’s Planet Pack. My eventual plan is to let users pick the system they want from a list of known mods, and possibly put the system configuration data on GitHub to allow mod authors and users to submit updates. Another thing on the planning board: figuring out what to do in cases like Enceladus in RSS, whose minimum LoS altitude for a three-satellite constellation is precisely the SoI boundary. Relatedly: figuring out how to include, account for, and hopefully diagram the effects of KSP’s occlusion modifiers. Only sort of relatedly: deciding if I want to deal with antenna strength and satellite separation distances…

It was Distant Object Enhancement that was dimming the skybox. It has a dynamic-dimming setting that was enabled for some reason. Turning it off made the skyboxes suuuuper pretty.

Oh hey! That worked! Thank you! I guess I thought that if Sigma went in its own separate directory, we were supposed to manage the files there. Lesson learned. Sadly, now that I get the skybox to load properly, it’s being shown incredibly dark in the game itself, though it seems like it might be correct in the main menu. This is a screenshot of the galactic center from Poodmund’s Milky Way Skybox with a full-white circle drawn around it, just so I could be sure where it is. Said white circle is the dim gray hoop in the upper part of the screenshot. (The one in the lower half of the game is the halo around Gael.) But that doesn’t seem to be the fault of this mod, unless it’s trying to do some kind of color- or brightness-correction of DDS files.

And put them in which folder (with the full path from KSP root)? Which of the several settings.cfg files should or should not be changed, and in what ways? Where should settings.cfg be placed, and should the others be deleted or altered? If not, how does one ensure that only one of them is actually used? If you look at my previous detailed post, I actually did rename the files in the pattern you suggested. If there is something I did wrong in the steps I laid out, it would be helpful to know which. I’m happy to write out a working guide for newbies, but I can’t do that until I actually get it working myself.

This claim turns out to have been just about 100% false. There’s a Milky-Way-like skybox in my game, but it’s not the one I chronicled in the previous post. I believe I know this because I scribbled on all six of the .dds files and one of the PNG files in EnvMap to make sure, and nope, no sky-scribbles in the game. (Which I quit and relaunched after altering the texture files.) But my career game is also not showing, so far as I can tell, the GPP-default skybox, so I have no idea WHAT the frell is going on. If someone else manages to work all this out and can explain it in a way that makes sense to outsiders, I’d very much appreciate it.

Okay, I got mine working, it seems, so I’ll be the one to post this. This is with Poodmund’s Milky Way skybox, which I downloaded from SpaceDock. (I say it seems I got it working because the skybox looks a lot darker in game than it does in the SpaceDock screensots. This may be due to gamma differences between Windows and Macs, but I’m not sure if that’s the case or not.) First, I created a SkyBox folder in /Sigma/Replacements. Then I unzipped the file I downloaded from SpaceDock and dropped the contents into SkyBox. One of the things there is a folder called Default. It contained the following files: GalaxyTex_NegativeX.dds GalaxyTex_NegativeY.dds GalaxyTex_NegativeZ.dds GalaxyTex_PositiveX.dds GalaxyTex_PositiveY.dds GalaxyTex_PositiveZ.dds These were renamed to: GalaxyTexXN.dds GalaxyTexYN.dds GalaxyTexZN.dds GalaxyTexXP.dds GalaxyTexYP.dds GalaxyTexZP.dds Then I went up to /Sigma/Replacements/Settings.cfg and made the contents look like so: @SigmaReplacements { SkyBox { CubeMap { rotate = false // set to true if you want the Milky Way at some angle to the ecliptic SkyBox = Sigma/SkyBox/Default/GalaxyTex } } } Now, in the /GPP folder, there’s a GPP_SkyBox folder (which I installed via CKAN) that contains its own settings.cfg. It was completely unclear whether that would be overridden or would fight with the other skybox configuration or what, so I edited it to: SigmaReplacements // this line used to have an @ symbol at the beginning, but I removed it { SkyBox { CubeMap { mirror = true rotate = true SkyBox = GPP/GPP_Skybox/Galileo } } } Besides removing the @ symbol, I left the file’s contents otherwise alone. As I say, I have no idea if that was necessary or not. Maybe one of the devs can chime in to clear up this part. Once I did all that, the Milky Way did show up in my game, albeit seeming rather dim, even when in orbit on the night side of Gael. But it’s there and the skybox looks complete. As far as I can tell, the EnvMap folder (and its files) that came in the SpaceDock download are not used by Sigma, but again, hopefully a dev can clear that up. If there’s a better way to have done all this, and especially if anyone knows why the skybox might look dim on my Mac and how to brighten it up, I’d love to know!

It didn’t work for me, I don’t think—I got a blotch of Milky Way in one small part of the sky, not too far from the sun (using Galileo’s Planet Pack). And there were very few apparent stars in other parts of the sky. If someone can post clear file structure and config contents to get the intended effect, that would be much appreciated.

Wow, yeah. Clearly I was on crack. I’d try asking in one of the more general forum threads, like https://forum.kerbalspaceprogram.com/index.php?/forum/16-gameplay-questions-and-tutorials/ . Someone there probably knows enough to work out the right answer.