Tallinu

September 19, 2019

I'm sorry if it sounded that way. There's only one "complaint" and it's the very first paragraph, and it's in regards to what I assume is a normal behavior for the plugin, where it disables gimbals and re-enables them depending on throttle state.

The issue has to do with that feature's implementation: Because the plugin controls the gimbal locks via the same toggle the player would use, you lose the ability to manually control gimbal locks (at least via the usual toggle).

Since this appears to be "working as designed" behavior and there don't appear to be any errors to report, I did not consider it a bug or expect the log to be of any use. And the rest of what I wrote was simply an attempt to provide as much information as I could about the nature of the behavior I was "complaining" about and to describe my attempts to work around it. I don't remember whether the "show actuation toggles" option I used to do that is available in a stock game, which is why I mentioned TE. Oh, and the comment about a gimbal limit slider is just irrelevant wishful thinking, as in "wouldn't it be nice if the game had..." (Sorry for getting sidetracked and confusing the issue.)

As for the Bobcat, that's a stock part from the Making History expansion, not a mod, so I just assumed you'd be familiar with the name (sorry again). It's apparently implemented with two separate gimbal modules -- I guess they couldn't give it roll control authority (as a single central engine) with just one module. I mentioned what I'd learned about it in my experiments because I thought the fact that the plugin only locks/unlocks one of those gimbals might be something you'd consider a bug. I don't know if any other engines actually have multiple gimbal modules, so maybe it's just an edge case that hasn't come up before. Either way, since one of them does get automatically locked/unlocked, the plugin clearly is "working," it just doesn't take into account the possibility that a part might have more than one gimbal module.

The issue should be reproducible by launching any craft using an engine with a gimbal and attempting to manually lock any of its gimbals while the engine is running. The gimbal setting in the menu immediately changes back to unlocked and the engine continues moving in response to yaw/pitch control input. In the case of the Bobcat, providing yaw/pitch/roll control input while the throttle is off and looking at the engine and the part right-click menu, you should see that one nozzle still moves and the second gimbal hasn't been auto-locked (and can be manually toggled, whereas the first gimbal option will instantly switch back if clicked on, as previously stated).

I ended up removing the plugin because I really needed to be able to lock some gimbals on a mission I had in flight (and couldn't use the workaround of disabling the actuation toggles due to being in flight already). But if you can't reproduce this, let me know and I'll reinstall it and create a log (would you want one where I'd launched a craft and moved the engine around? Just at the main menu? Or what? I haven't seen any error messages regardless of what I tried).

September 17, 2019

It seems like this plugin makes it impossible to lock the gimbals of certain engines the normal easy way, whether during flight or in the VAB. If you try to lock a gimbal while your engines are active, it instantly resets back to "free," and of course if you try to toggle it while engines are shut down they just go right back to "locked."

Surprisingly, tweaking the gimbal range down to zero in the VAB (with Tweakable Everything) doesn't seem to have any effect either. (That seems to just be broken in general, but it most likely doesn't have anything to do with this plugin.)

The only thing that does work is to use "show actuation toggles" and turn them all off. This may also be a Tweakable Everything feature though, I'm not sure.

Sadly there is no "gimbal limit" slider available in flight that could be used to easily adjust them on the fly in the same way that engine thrust can be scaled for more precise burns...

While investigating this I also discovered that this plugin only affects one of the Bobcat's nozzles, and the other still moves. This seems to be because there are two separate gimbal lock options on its menu (and a different, "0-100" gimbal limit adjustment -- which only affects one nozzle?!) and in the action group editor there's an entire extra set of gimbal-related options, one for each nozzle. Using these I was able to get both its nozzles to stop moving by toggling all six actuation toggles in flight, but that can't be done for both nozzles in the VAB.

August 30, 2019

Ah, thanks! I think the wording of "non-resettable" must be what confused me -- as in, "But why can't I reset it? How is that a good thing?"

I guess it really meant "non-resetting" as in "it doesn't get reset when you switch away from them." And the hotkey in #3 is just a way of setting more than one of them to do that en-masse.

August 30, 2019

On 8/27/2019 at 2:28 PM, Dizor said:

1. Implemented non resettable independent kerbal intentions.

Sorry if I'm being dense, but what does this mean?

August 30, 2019

On 8/29/2019 at 2:34 AM, Sandriell said:

What mode are you playing in? In my experience at least, the mod only works in Career Mode.

I am indeed playing Career, although I would expect the recovery of science and/or Kerbals (where applicable) to function in the other modes.

August 28, 2019

I'm on KSP 1.7.3 with SR 1.9.1.3 and RecoveryController 0.0.3.8 and I have a couple of questions.

1: I don't know if this is actually a feature that Stage Recovery is supposed to have or if I'm remembering wrong. I thought that in the past I had been able to drop an upper stage or payload from orbit back onto a suborbital trajectory and have the mod recover it for me while I do other things (assuming it met the parachute, heat shield, and/or propulsive landing criteria of course), but recent attempts haven't even resulted in a "stage destroyed" message, as if the mod just isn't handling the event. It works fine for stages jettisoned as I launch a new vehicle, but it seems like once something has achieved orbit it stops paying attention (or at least doesn't generate the expected messages).

2: It was also tricky to figure out just how many parachute modules I needed to attach via docking ports to successfully bring down an older "space bus" craft for recovery (which was replaced by a larger model with better crew capacity and more delta-V). When attaching the parachute-laden probes to the old design in the editor, SR treated each of them as separate stages (even though no staging was enabled on the docking ports), and stubbornly kept telling me that the main craft was 0% recoverable. I had to replace the docking ports with structural connections and/or move the parachutes onto the main craft in order to figure out how many were actually needed.

At first I thought that the parachutes all being on these docked probes might be responsible for SR not recovering the craft after I dropped it out of orbit, but then I realized that it still should have generated a "stage destroyed" message if that was the case, so it's probably just a separate usability issue. It's easy to find out if something like a docked escape pod ("MOOSE" etc) has enough parachutes to land safely by simply detaching it from everything else, after all, and I just keep coming back to that after trying to think up any use case that would require the current treatment of docking ports. I understand that it might not be easy to do anything about, but it would be a "very nice to have" feature/tweak/whatever if there was a way to make it treat unstaged docking ports in the editor as being one stage instead of separate stages and base its diagnostic report on the combined unit.

Thanks for keeping this mod going, and all the others you maintain -- I use quite a few of them!

February 18, 2019

Alright, sounds like either there's a bug in MM or it's an intentional change and the documentation hasn't been updated to reflect it...

February 18, 2019

18 minutes ago, Tonka Crash said:

The problem is that if you try to use :BEFORE or :AFTER on a mod that doesn't use :FOR those patches get removed in step 2 when module manager can't find the :FOR that the are referencing. You have to explicitly use :FOR for :BEFORE and :AFTER to function at all.

Ideally every mod would use :FOR on patches included in its installation to enable use of :BEFORE and :AFTER by other patch writers. In the case of the Mining Extension and Mk3 Expansion, these should be using :AFTER if the intent is to override the default patches in TweakScale, but that won't work without TweakScale using :FOR.

Also I want to be clear I'm not blaming @Lisias on these issues at all. He didn't create these issues, he just inherited what was there when he chose to take over maintenance. It's pretty apparent that not every mod author fully understands ModuleManager syntax (and I don't claim to be an expert at all)

... But... if a mod is installed... then why would its "modname" not exist in step 2? Regardless of whether or not the mod uses FOR[MyModName] in all of its patches. Assuming it's installed properly, of course. From the very link you posted:

Quote

Valid [modname] values

Module Manager generate list of case-insensitive modname values that will work in NEEDS, BEFORE, AFTER by doing the following:

Scans all the loaded DLLs and adds modname.dll to the list of loaded mods (just the modnameportion)

Scans all the configs for properly configured FOR[modname] and add modname to the list of loaded mods

Scans the GameData directory and adds modname to the list of loaded mods, with white space characters removed from the name of the folder (space, tab, and several others defined by Unicode/.NET).

The first and third bullet points. It has examples right after that.

Although the DLL is called "Scale.dll" instead, "TweakScale" is the name of the folder out of GameData, so that should absolutely exist. Granted, the advice he gives about making sure of that by using FOR at least once is sensible, and making all of them use FOR for consistency (and to allow BEFORE to work) would also make a lot of sense. But AFTER, at least, should still be working right now, at least for TweakScale, even if its patches don't currently include a single FOR.

February 18, 2019

5 hours ago, Lisias said:

Craft files too. Any "tainted" (i.e., a craft saved by a tainted KSP) will have (potentially) that zero mass problem, including the ones you download from Steam Workshop and Kerbal-X.

Until the moment, I don't have evidences that the mere presence of the tainted part is enough to cause "zero mass induced troubles". You have to scale that part on the editor to kick the update routines that would lead to zero mass. Parts already scaled will be reset to default on sane KSP installments, however, what will induce the user to try to scale it back - and then that nasty chain of events is complete.

Assuming I know how to read code (hehehe), as long as you don't scale anything, you should not have problems. But once you export your crafts to Kerbal-X, anyone downloading your craft (unless it have a tainted KSP as yours) will be prone to the problem. This thing spreads. While you don't rescale things already spawn on the savegame, it's theoretically possible to do that - but you main concerning on savegames is that once the misbehaviour is fixed (what can happens at anytime the MM cache is rebuilt), all your crafts on the savegame that have scaled parts will have them reset to normal size, ruining your game. But, at least, this is perceivable.

Ahh, I had suspected saved craft files might be susceptible too, that's why I checked the ones I'd made recently!

I can see what you mean about the problem spreading between users. However, it sounds to me like there's an easy preventative measure. Any time you download a craft (from KerbalX or anywhere else), open it in the editor, and then simply save it, without touching anything. (After having the TweakScale update installed, of course!) That should trigger TweakScale's module duplication fix, and ensure that the craft file you have on disk is now a "safe" copy, whether or not it was "tainted," right?

5 hours ago, Lisias said:

There's a problem lingering however - the latest TweakScale prevents you to save new files prone to the problem - mas don't do anything when loading tainted crafts into a sane KSP. I prevented the infection to keep spreading, but I did nothing to prevent being infected.

[...]

So, in a nutshell: merely installing the newest TweakScale is not enough. It will only be able to act once you start saving your things. It can't do anything if your MM cache is rebuilt and the misbehaviour vanishes before you load/save your crafts and savegames.

Which is why you said people needed to switch to all their ships (via tracking station, etc) to get them to be loaded up and then resaved in the persistence file.

However, this is only necessary for craft which contain parts suffering from duplicated modules, right? Because those are the only craft which could be affected by TweakScale resaving them in a way that prevents future corruption when the module cache ends up fixed (has its "sanity" restored).

So, it's not that every craft must be activated and resaved (in flight or in editor), it's simply that all craft which contained duplicate modules on some part must be. So in my case, my saved craft and persistence file contents shouldn't need to be resaved. (I'll still run through the important ships and stations in flight just to be sure, and I'm resaving all of my recent craft files even though they're mostly stock parts that were unaffected! Can't hurt to be safe, especially for the craft I was posting in case others liked them.)

1 hour ago, Tonka Crash said:
I took a look in my ModuleManager.ConfigCache and found problems like @Tallinu posted. Since I'm tweaking patches almost daily, just editing the ConfigCache is not practical as it just gets replaced frequently, so I tracked down some of the problems.
I've got @SuicidalInsanity's Mining Extension and Mk3 Expansion. Both of these have their own tweakscale patches installed with the mod in addition to the patches included with TweakScale. They are slightly different, so I opted to use the mod author's version instead of the ones installed with TweakScale. I changed the TweakScale versions to .txt to avoid applying them on top of the ones provided by the mod. This is part of Tallinu's problem. This was the only source of my duplicated MODULE[TweakScale] nodes.
In addition to using % for the MODULE[Tweakscale] line in the patch you need to use it for each line in the patch to replace entries if they already exist if you aren't sure that you are the only one applying a patch, i.e.
@PART[probeCoreSphere] // Stayputnik Mk. 1
{
    #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        %type = stack
        %defaultScale = 0.625
    }
}
Doing this across the board for all TweakScale patches locally took care of some places where I had multiple defaultScale & type enties in the TweakScale nodes.
[...]

ScaleExponents.cfg has errors in the patches for TWEAKSCALEBEHAVIOR for Decoupler and Science at the end of the file. They apply mass and DryCost values as separate nodes. I believe they should all be in the same node as shown below. This dealt with part of Tallinu's issues.

Ahh, now I understand what's causing those type and default scale entries to get doubled up.

Thanks for pointing these out, @Tonka Crash! And for the explanation of the ordering:

1 hour ago, Tonka Crash said:

TweakScale would have to use :FOR[TweakScale] on every one of it's patches to allow the :BEFORE or :AFTER directives to function as intended. As it stands other mods only have :FIRST or :FINAL to control when to patch around TweakScale

[...]

So for the Mk3 Expansion and Mining Extension mods, their TweakScale patches run before TweakScale patches run. As long as there aren't conficting patches there isn't a problem.

Wouldn't this be true only if the mod was trying to use :BEFORE[TweakScale]? If TweakScale's included patches run at step 4, and :AFTER patches in the last part of step 5 for each mod, doesn't that mean :AFTER[TweakScale] still runs after TweakScale's patches?

Either way, it sounds like adding the % signs at least, and possibly using :FOR, would be good preventative measures to take. It might avoid some cases of a mod's included patches (being overly simple and/or not understanding exactly how to use the proper directives) conflicting with TweakScale's, since if they don't have any ordering directive they'd be applied first, and TweakScale's patch (being written with this possibility in mind) wouldn't introduce any problems (which wouldn't have been introduced in any case by patches from the mod itself). Does that seem reasonable?

February 18, 2019

Okay, I believe what you're telling me is that if any of my active craft (the ones saved in the persistence file and any quick saves) contained parts which suffer from this module duplication issue, "fixing" the duplication before installing the newest release of TweakScale would have caused the affected parts to experience issues like zero mass and other nastiness, regardless of whether or not their scale had been changed (simply the presence of the broken duplicate module is enough). Is that an accurate summary?

Assuming that is true: Since I have not used any of these parts (the parts in which I found module duplication in the cache file) in any of the craft I've launched so far, none of my existing craft should experience any problems, regardless of what I do (because none of the parts they contain have duplicate modules saved).

But now that I have installed the new version of TweakScale, it will prevent the duplicated module in those parts from eventually corrupting any craft I might launch that use those parts, because it renames the extra module to something else which won't overwrite the correct settings in the first instance of the module. Therefore, with the new version installed, I should be able to safely use any parts which are affected by that duplication, without having to try to manually fix hundreds of lines in the cache file every time I install or remove or update an mod (which happens frequently enough that it isn't really feasible). Correct?

February 17, 2019

How do you know for sure if you are affected by the problem? That doesn't seem very clear to me.

None of the craft files I have saved recently seem to have any duplicated TweakScale modules, but when I hunted through my ModuleManager.ConfigCache file I found some parts where this was the case, matching what you showed on the GitHub issue even down to the duplicated type and defaultScale settings in the first module.

Spoiler

This example was taken from near the end of the part M3X_CLEAVER from Mk3Expansion, looking through the file further it seems like many of that mod's parts have the issue:


		MODULE
		{
			name = AYA_Engine
		}
		MODULE
		{
			name = TweakScale
			type = stack
			defaultScale = 3.75
			type = stack
			defaultScale = 3.75
			TWEAKSCALEEXPONENTS
			{
				mass = 2.5
			}
		}
		MODULE
		{
			name = ControllingRecoveryModule
		}
		MODULE
		{
			name = SensiblePumps
		}
		MODULE
		{
			name = TweakScale
			TWEAKSCALEEXPONENTS
			{
				mass = 2.5
			}
		}
		MODULE
		{
			name = ModuleB9PropagateCopyEvents
		}

I also found this slightly different-looking but also not quite right version in RLA_Reborn's small_decoupler_stack:


		MODULE
		{
			name = TweakScale
			type = free
			TWEAKSCALEEXPONENTS
			{
				mass = 2
			}
			TWEAKSCALEEXPONENTS
			{
				name = TweakScale
				DryCost = 0.5
			}
		}

The affected parts don't seem to include any that I have actually used in my craft so far. And as I said, I didn't find any evidence of this issue in my saved .craft files. Does that mean I don't have to worry, and once I install this TweakScale update, there won't be any problems if these corrupted extra modules do get added to things in the future?

I actually don't use TweakScale very often, funnily enough. I'm usually able to do everything I want without changing part scales. The only thing I can really remember doing most recently is increasing the size of the micro landing legs one time when I needed longer legs for a lander but only had those legs unlocked, and that craft was recovered a long time ago.

February 15, 2019

The Klaw is the (official!) nickname for the Advanced Grabbing Unit, in the Actuators (160) research node. It's capable of latching onto other vessels/parts without needing a docking port on the target (and can latch onto asteroids in order to stay attached while mining or moving them).

(Ninja'd!)

February 15, 2019

On 2/10/2019 at 6:56 PM, bewing said:

As mentioned already, the kerbal's helmet always points north. So you can't adjust that dimension with the camera.

You can actually change which direction they point their helmets by switching camera modes using the V key (pretty sure that's the default).

In "Orbit" mode, "up" is north as bewing said. But in "Free" mode, "up" is away from the planet, and pressing space will orient EVA Kerbals that way instead.

If your target is significantly above or below you in one camera mode, or you're having trouble getting a grip on a ladder because of the target craft's orientation, switching camera mode may make it significantly easier to maneuver to or around your target.

February 15, 2019

46 minutes ago, Zhetaan said:

My intent in saying that was only to recall that for this specific problem, there is a special reason why the ascending node must occur at ±90° true anomaly: the Draim constellation constrains not only the inclination and eccentricity, but the argument of periapsis as well.

Right. I just didn't understand that when you said "this is a special case" you were referring back to this constellation setup again, rather than orbit segment time scaling in more general terms, which is where my mind was leaning (as in that last paragraph) as I'm learning how these things work. I always understood intuitively why the TA of 90 was needed in this case, even when I was originally describing it wrong, lol! It needed to be symmetric, with the AN/DN equidistant from both Pe and Ap. Anywhere else would not put the nodes in the right place, the orbital plane would be tilted around the wrong axis, and sufficient error would prevent 100% coverage.

February 14, 2019

1 hour ago, Zhetaan said:

Oh, I don't doubt that one launch would work better for anything interplanetary, at least in transfer costs. That being said, you may still want to consider the flotilla alternative, or possibly a hybrid where you have one carrier to take the satellites into interplanetary space but then separate the satellites and set them to their own intercepts before the target encounter. That may not be necessary but it's probably worth investigating; thirty-three degrees inclination is expensive no matter how you look at it.

Actually, the biggest issue I'm addressing by having all four satellites be deployed by a single carrier vehicle (second to interplanetary encounter/capture) is to get the correct relative timing between the four satellites. Each must reach apoapsis at a different time, staggered by 1/4 of their period and in proper sequence. Deploying them from a lower circular orbit that makes 1/4 less than a whole number of full orbits in that amount of time allows each satellite to arrive at the target apoapsis from its deployment burn with the correct timing, raise its periapsis and tweak its period to be as accurate as possible, and from then on remain synchronized with the others, even as they all later perform their inclination changes -- the orbits are fairly high even at that point, so the delta-V cost of doing inclination last was acceptable.

A small lightweight relay satellite can easily have 2000 to 3000 delta-V with just a few oscar tanks and a spark engine, though relays meant to reach Kerbin from the outer planets would by nature require larger, heavier antennas (or arrays of them) and therefore more fuel and thrust -- although a better way to go about it, especially around Jool, would likely be to have a pair of large, powerful relays as the main link back toward Kerbin, while small satellites with RA-2 antennas like the ones I've been experimenting with provide local coverage of each moon, bouncing signals around to reach the larger relays as needed.

1 hour ago, Zhetaan said:

That will work well enough for most situations. It will give issues when you need to deal with either massive bodies orbiting your targets closely (because their sphere of influence will interfere with your desired orbit) or targets with low mass orbiting closely to their primaries (because the target's sphere of influence is too small to give you the correct orbit within the constraints). I know that there is no solution for Laythe that fits the parameters (Laythe is fairly large for a moon but not compared to Jool at that orbital distance), but Duna should be possible provided that you orbit outside of Ike's influence. The target value from the other thread is a semi-major axis of at least 7.25 times the planetary radius, (which is the value of 1 / tan 7.853°) so that's yet another verification method. I saw nothing constraining the maximum value of the semi-major axis except insofar as the constellation needs to remain in orbit.

[...]

As I mentioned above, Laythe's sphere of influence is too small and Laythe itself too large for the tetrahedron to work with 33° inclination and .28 eccentricity. Its sphere of influence is 7.45 times its radius, which fits one parameter, but that requires orbits to have eccentricity of no more than .027, which is too circular to be of help (the minimum for a Draim tetrahedron appears to be more than .1). I have seen references to some other solutions that work with five satellites, but I am not familiar enough with the details to tell you whether they would work in Laythe's sphere.

Really? Let's see, the SMA given in his thread is 3,625,000m and according to the wiki, Laythe's SOI is 3,723,645.8m and its radius 500,000m. So that's 5/6 of Kerbin's radius. Scaling 4,350,000 by that factor does indeed give 3,625,000. Despite the fact that Laythe's SOI is vastly smaller than Kerbin's, that result is still lower, but the orbit isn't circular, so...

Okay, I think I finally found what I need to do to figure out the Ap and Pe (to center of mass) from eccentricity and semi-major axis. Google was all like "Here's how you calculate the things you already know!" Eventually found https://jtauber.github.io/orbits/017.html and managed to piece it together from various pages there...

Focal distance c = a * e
3625000*0.28=1015000
It looks like Pe = a - c/2
3625000 - 1015000 / 2 = 3625000 - 507500 = 3117500
And then I think Ap = 2a-Pe
2 * 3625000 - 3117500 = 7250000 - 3117500 = 4132500

Dang, it's less than 10% outside the SOI! And for the most interesting and science-rich of Jool's moons, too... Well, that one will just have to make do with three equatorial satellites. Anything landing on the poles will probably be able to see the strong primary relays north or south of Jool. A set of three of those, equidistant in a polar orbit, should ensure that one or more are always visible.

1 hour ago, Zhetaan said:

Duna has a radius of 320,000 metres, so that would require a constellation semi-major axis of 2,320,093.7 metres. Eccentricity of .28 gives an apoapsis for that orbit of 2,969,719.9 metres. Ike's periapsis is 3,104,000 metres, and with its sphere of influence of 1,049,599 metres, that gives a potential closest approach of Ike's influence at 2,054,041 metres. More likely, that conflict would occur farther out (33° inclination gives a lot of extra room in 3-space), but it would still occur. You're right about the coverage gaps: the table-given SMA of 2,080,000 metres reflects the three-dimensional geometry (it's too large for anything coplanar), but even so, 2,080,000 / 320,000 = 6.5, or alternatively a sight angle of 8.746°, which is too close to Duna.

On the other hand, if you go higher, then Ike's apoapsis is 3,296,000 metres, so it gives a maximal influence conflict at 4,345,599 metres. Let that be the periapsis and that gives the satellites a semi-major axis of 6,035,554.2 metres. You can get closer (again because of three dimensions) but that value guarantees no conflicts with Ike. It's nearly nineteen times the ratio of the radius to the SMA, or a sight angle of only 3.035°, but I see no reason why that wouldn't work. Satellites on that orbit would have an apoapsis of 7,725,509.4 metres, which is well within Duna's sphere of influence (nearly 48 million metres). But there are still coverage gaps: Ike gets in the way. That's probably why the author chose the lower orbit.

On the gripping hand, the solution to that is simple: put a constellation around Ike.

Indeed, I was just thinking that as I read the previous paragraph. (Also: I get that reference! High-five! :cool: )

1 hour ago, Zhetaan said:

Yes; assuming that you hold eccentricity constant and travel from a specific true anomaly θ_a to a specific true anomaly θ_b on both orbits, the change in mean anomaly will be the same and the travel time will scale linearly with the period: t = MT / 2π. It's not enough that the craft travel through the same angle; the caveat is that the trip must begin and end at the same true anomaly on both orbits.

Good, I had a feeling it was something like that.

1 hour ago, Zhetaan said:

However, understand that this is a special case since both endpoints are identifiable as other orbital parameters (Pe and AN/DN).

And now I'm confused. I'm not sure what the difference is, compared to what you said earlier in that paragraph. How does "being Pe" or "being AN/DN" change anything, compared to going from, for instance, 30 degrees to 45 degrees TA on two orbits with the same eccentricity but different periods?

February 14, 2019

Wow, you've really gone above and beyond here!

19 hours ago, Zhetaan said:

Without access to that particular paper, I am limited in what I can figure out. The radius and the gravity tend to increase and decrease together, but there is no requirement that they do so--planetary density can vary quite a lot. Saturn, for example, is less dense than water, because its volume belies the fact that there simply isn't that much mass to it. In other words, Saturn is our fluffiest planet. However, satellite coverage has more to do with the visible surface, which is of course related to radius, but it appears that the parameters for this tetrahedron are very flexible. Nevertheless, I note that the table of parameters in the original challenge post seems to preserve the angular relationship from Draim's work, which is why the satellites in KSP have the semi-major axis that they do.

For a satellite orbiting Kerbin with a semi-major axis of 4,350,000 metres, the (true) apoapsis and periapsis are as follows:

Ap = 5,568,000 metres
Pe = 3,132,000 metres

These were derived from the relation Ap = (1 + ε) * SMA and Pe = (1 - ε) * SMA.

With the planetary radius of 600,000 metres, the angle between the satellite and a point on the circumference of the greatest-size cross section that faces the satellite (in other words, the farthest possible visible point) is given by:

Sight angle Ap: arctan 600,000 / 5,568,000 = 6.15°
Sight angle Pe: arctan 600,000 / 3,132,000 = 10.84°

Using a similar derivation for satellites orbiting Earth:

Earth's standard gravitational parameter is about 3.986004419×10¹⁴ m³/s².
Earth's average planetary radius is 6,371,000 metres.
The required minimum orbital period for Earth of 27 hours is equal to 97,200 seconds.

A 27-hour period gives a semi-major axis of = 45,691,651.57 metres, so:

Ap = 58,485,314.01 metres
Pe = 32,897,989.13 metres

Sight angle Ap: arctan 6,371,000 / 58,485,314.01 = 6.22°
Sight angle Pe: arctan 6,371,000 / 32,897,989.13 = 10.96°

I think we have our relationship. So long as your sight angle is less than 6.22 degrees at periapsis and 10.96 degrees at apoapsis (smaller angles mean greater distance, which means better coverage), it can work.

Did you get your Ap and Pe references swapped in the above line? Or is there some reason to use the Ap sight angle for Pe and vice versa?

19 hours ago, Zhetaan said:

Since we're using the same eccentricity for everything, we can also find the semi-major axis directly:

Hypothetical sight angle: arctan 6,371,000 / 45,691,651.57 = 7.938°

To figure the minimum semi-major axis for a given body of known radius:

SMA = r_body / tan 7.938°

To check for Kerbin:

600,000 / tan 7.938° = 600,000 / .1394375 = 4,303,002 metres. This is lower than the given value for Kerbin because, I think, the original poster decided to be safe, but again, without having access to the paper, it is possible that there is a practical reason for the given figure. If you prefer to have that margin, then the hypothetical angle to use is actually 7.853°.

And considering that I actually used a SMA greater than 4,350,000m around Kerbin anyway (5,506,299m), in order to get easy to work with periods (12h), and plan to do the same around other bodies, there should be an even larger safety margin.

19 hours ago, Zhetaan said:

This is in line with your supposition that you can scale the semi-major axis by the radius times a constant; I simply took it a step farther to determine both that 1 / tan 7.853° is the value of that constant, and why it appears.

To check these figures, we can use the Mun (radius = 200,000 metres):

200,000 / tan 7.938° = 1,434,334.13 metres

Alternatively, with the safer angle:

200,000 / tan 7.853° = 1,450,058.58 metres

See whether you can get a good network there using that parameter, and if so, you'll have your solution.

What I had in mind was,

TargetBodySMA = KerbinSMA * TargetBodyRadius / KerbinRadius

which I'm pretty sure gives the result I'm looking for, linearly larger or smaller in proportion to the change in radius. If that does the job the way I believe it should, then I don't have to mess around with math that I can't do in my head.

It's great to have alternate verification though!

19 hours ago, Zhetaan said:

Edit:

Alternatively, you can use this set of precalculated figures that I just found, of course, only after doing all of that:

https://forum.kerbalspaceprogram.com/index.php?/topic/155188-orbital-parameters-for-a-tetrahedral-satellite-constellation/

Edit edit:

Draim's original paper is behind a paywall, but he also got a patent for it, and because of the wonderful scope of U.S. patent law, the patent itself is available: Tetrahedral Multi-Satellite Continuous-Coverage Constellation

Edit edit edit:

And here's an interesting animation of satellite coverage using this model:

Dangit! Google never dug up Zyx's post for me. ;.; And you had even posted there, too, at the time. "Indeed, you're looking at the prospect of four launches, at least for Kerbin." Well, I'm getting all the satellites there with one launch, but making that plan work is what I needed help with in the first place. XD Mainly I'm doing it that way because I wanted something that would work for moons and other planets, and getting a single vessel carrying multiple satellites to intercept a planet will be far easier than trying to manage multiple vessels, and means that the satellites themselves only need to carry enough delta-V for moving into the correct orbits once they detach from the carrier.

And it looks like he already did the work of figuring out the SMA for all the planets and moons! I'll probably check a few with that ratio method to see if they match, and if they do, I can just use his values as minimums and try to find nice periods above them. It seems the only one that he had an issue with was Duna because of Ike, and for some reason he went lower instead of higher. I'll have to have a look at Duna's SOI and see if the constellation could be set up in higher orbits instead, to avoid creating gaps in its surface coverage.

And that video and patent document are also interesting. I suspected there was probably a range of values that would work for things like eccentricity and inclination, and one of those illustrations confirms that, though it seems like 0.28 and 33 are pretty close to optimal there.

Again, thank you for all your help, you've done far more than I asked!

Edit:

I just had a thought that might save me a lot of trickier calculations if it's correct.

Assume that the eccentricity of the orbit remains the same, and only the period is altered (causing the SMA and both the periapsis and apoapsis heights to increase). For example, going from a 12 hour period to an 18 hour period. Am I correct in thinking that the time taken for a satellite to travel from periapsis to latus rectum (TA=+-90) scales linearly with the period? As in, 18/12=1.5 so t=7000*1.5?

In my notes from working out the right equation to do what you showed me, I have:

t=(2tan^-1(3/4)-(0.28*sin(2tan^-1(3/4))))*43200/(2pi)

It looks to me like the location of that 43200 value for period makes it a simple linear scaling factor for the result.

February 13, 2019

https://steamcommunity.com/sharedfiles/filedetails/?id=1654472000

I just got done setting up for the first of these maneuvers, and it looks great! Not exactly crossing the other satellite's orbit line but I doubt that's possible without performing the inclination change for the first two satellites before the other two (the ones opposite them) are even launched...

https://steamcommunity.com/sharedfiles/filedetails/?id=1654490026

Aaaand done! Periods correct down to a thousandth of a second thanks to thrust limiting down to 0.5% and slow-mo physics warp. Pretty much perfect.

1 hour ago, Zhetaan said:

so any deviation from circularity was anomalous--hence the term anomaly.

Yeah, reading about it did fill in a bit more historical detail for me, which was interesting. The whole epicycles thing, heh... And to think that today we have people "all around the globe" (lol) who supposedly believe the Earth is flat again. :rolleyes: ;.;

1 hour ago, Zhetaan said:

Correct. Though if you are starting from apoapsis, then it may be simpler to subtract 7000.63 seconds from six hours to get time after apoapsis rather than time before periapsis.

Right. I figured that one out.

1 hour ago, Zhetaan said:

This will work around any body, and yes, the orbital period encodes the gravitational relationship between the primary and the orbit in its calculation; that's why an orbit of a given semi-major axis around a given body has the orbital period it does. Furthermore, it's why we need further calculation to locate things on that orbit: any orbit with that SMA about that body will have that orbital period, regardless of its shape, and the need to find the differences that relate to eccentricity is the reason that the concept of orbital anomaly was invented in the first place. However, you won't need the orbital period until you are ready to include the mean orbital motion to get time from the mean anomaly; all ellipses of the same eccentricity are similar, so the angles will be the same in any case. Bear in mind that you must know the eccentricity to get that far, but orbital eccentricity is trivial to calculate, especially if you have Kerbal Engineer to do it for you. However, if not (or if you'd like to do it yourself):

e = (r_a - r_p) / (r_a + r_p),

where r_a and r_p are the radii of the apoapsis and periapsis to the centre of mass (meaning the planet's centre if you're orbiting a planet), respectively.

Bear in mind that this requires the actual apsides, but KSP displays the altitudes above the surface. You'll need to add the planetary radius to get the correct value, but that radius is available both on the wiki and in the KSP Knowledge Base. For Kerbin, it's 600,000 metres.

Yeah, I had to figure out adding in and removing the planet's radius already. It's nice that they gave Kerbin such neat round numbers, heh.

The reason I was trying to figure these calculations out to begin with was that I couldn't find a way to do it (accurately) using Engineer or MechJeb, but hey, maybe I've actually learned something! I doubt I'll remember the details of the equations a week from now, and there's no way I could write any of them out from memory, but the relationships between the anomalies and what everything does and means is all pretty clear.

You've been a tremendous help with this! I don't suppose you have any thoughts on the additional issue I noted near the end of the OP, about figuring out what semi-major axis would be required around other planets?

My best guess on that right now is to compare the radii of the planets and just scale up/down proportionally from the 4,350,000 that was used in the original details for Kerbin (in the thread I referenced), on the assumption that the geometry will end up the same. I'll still need to figure out what the period would be in the rescaled orbit and figure out if it can be done within the SOI of some of the smaller moons, or if the reduction in mass (and hence gravitation) causes even that (presumably) closest possible orbit to be outside the SOI of, say, Minmus the same way a synchronous orbit would. Although I have the advantage of not worrying about the planet or moon's rotation speed, only its radius, which is going to be smaller along with the gravity, so maybe it'll work out nicely...

February 13, 2019

12 hours ago, Zhetaan said:

I can help you with some of the prediction. If you want to know when you'll be at 90 degrees true anomaly, then you need Kepler's laws; that's non-negotiable.

I'll assume that you're starting from a true anomaly of zero; it's one element that is easy enough to see both in KSP's interface and in Kerbal Engineer.

I figured that would be the case. Just to make sure I'm not missing anything important, my understanding is that TA = 0 at periapsis, is that right?

12 hours ago, Zhetaan said:

True anomaly, θ, is given by the equation:

(1 - ε) tan² (θ / 2) = (1 + ε) tan² (E / 2)

Where E is the eccentric anomaly and ε = .28, the eccentricity. In this case, we know that we want a ninety-degree (or π/2) true anomaly, so this equation is a matter of solving for E.

(1 - .28) tan² (π / 4) = (1 + .28) tan² (E / 2) --- This is easy enough; tan of π/4 is 1
.72 = 1.28 tan² (E / 2)
.5625 = tan² (E / 2)
.75 = tan (E / 2)
.643501 = (E / 2)
1.287 rad = E

This is about 73.7 degrees.

Once you have E, you need to solve Kepler's Equation for mean anomaly, M:

M = E - ε sin E --- This is the easy way to do it; if you were solving for position instead of time, you'd have to solve the transcendental

I need to figure out how to get characters like ε typed in without copying and pasting from something else. And how to remember what to call them (other than "curly E" or "curly W" LOL).

I've seen these equations everywhere, but always in the context of solving for position, and just couldn't sort out what I needed to do to get the answer I wanted. Looks like I was overthinking things, and except for the first one they were already in the required form with no "numerical analysis methods" (whatever that means) needed!

12 hours ago, Zhetaan said:

M = 1.287 - .28 sin 1.287
M = 1.287 - .28 (.96)
M = 1.287 - .2688
M = 1.0182 rad

This is about 58.3 degrees.

Mean anomaly is the mean motion times time, and 2π radians divided by the period is the mean motion, n; you mentioned earlier that the period is twelve hours, so I'll use that. Twelve hours is 43,200 seconds, so:

2π / 43,200 = 1.45444 x 10^-4 radians per second.

1.0182 rad = 1.45444 x 10^-4 s^-1 * t
7000.63 seconds = t

Your time after periapsis passage at true anomaly of 90 degrees is 7000.63 seconds, or 1 hour, 56 minutes, and 40.63 seconds.

Awesome! Thank you so much for the walkthrough of this process. And the answer -- when I try it myself I can use that to check my work.

This should be able to get me the time before periapsis as well, right? Symmetry and all. If my satellite is at apoapsis (just after getting the 12h period matched), just subtracting 7000.63 from the UT at which periapsis will be reached should give me the position on the closer side, without having to wait and go past PE.

And I should be able to use this around other bodies as well, right? It doesn't appear to directly require any constants regarding gravity and such, just the parameters of the orbit and the period. Taken together, those effectively incorporate that kind of information already, I believe?

So what I need to do now is go back to make sure all of these are solved in the form I need, more or less the way you did but keeping the input of True Anomaly as a variable, then chain it all together with another variable for period, and I should have an equation where I plug in those two values and it spits out a time-since-periapsis as a result. I could then convert that into a bit of code to do the job quickly. Maybe even figure out how to write a KSP mod to do it. (If I decide to get really ambitious I could probably work up a pull request for MechJeb to let it automatically place maneuver nodes at specific points in the orbit...)

12 hours ago, Zhetaan said:

The next question is whether you are certain that you want the true anomaly to be ninety degrees. θ of ninety degrees actually gives the location of the latus rectum, which is certainly useful for some purposes, but if you really want the location of the semi-minor axis, then you want E to be ninety degrees, not θ. Of course, that's even easier to solve; you can dispense with the true anomaly completely and can begin with Kepler's Equation.

As it turns out, I was very much mistaken when I claimed that the position I wanted was along the semi-minor axis. In hindsight, that should have been pretty obvious, since the minor axis goes through the center of the ellipse, NOT either of its foci. I'm glad I mentioned the true anomaly, since that's the actual position I need in order to change the inclination correctly. The apoapsis and periapsis need to be the points most distant from the equatorial plane, with the orbit not tilted one way or the other around the major axis, to match the example configuration as closely as possible.

February 12, 2019

2 hours ago, Xd the great said:

Lazy way: 3 satellites at high eccentricity (high Ap, low pe), 1 polar low-altitude satellite.

Pretty much 4 satellites at any "widely separated" configuration will do.

If not, CUBESATS.

Or if you want, launch to a low orbit. Then use the manouvers to do 2 burns, 1 to reach desired ap at desired place, 1 to circularize at AP

2 hours ago, Curveball Anders said:

Erh, Resonant Orbits?

https://meyerweb.com/eric/ksp/resonant-orbits/

Credit for trying to help, but yes, I am familiar with orbital maneuvers and standard relay satellite deployment patterns. And I am, in fact, making use of a particular variation of a resonant orbit (or maybe it's something more properly known by some other name), a kind of result which that calculator isn't designed to provide, to get all four satellites launched on their different trajectories at precise times.

I'm afraid I put "advanced" in the subject line for a reason. I'm working on this because I want to do something way cooler and more effective with fewer satellites. The kind of help I need is not "how do I shot relay satellite?" It's "how do I math Kepler to solve for X given Y" or "how do I avoid having to math Kepler and get this accomplished to the desired precision by some other means." I don't want to be just eyeballing the position of my maneuver node based on where the lines appear to cross, I want to do it right, or find a way to make the game or the mods do it right for me (that doesn't take launching extra equipment).

I've been trying to figure out how to get from point A to point B mathematically speaking, where A is the assortment of orbital parameters I have and B is the one piece of information I think I need to solve for. But, at least so far, I'm just too unfamiliar with the relevant equations to know which I need and in what order and form, compounded by my programming-trained brain always finding it harder to work with variables that don't have names which are intelligible words that remind me what the variable is and does just by reading it. About the only one I even know how to say is theta, because it was used so often back in trig class, lol!

February 12, 2019

14 minutes ago, Plusck said:

So, the gravity turn has to be:

at full power at all times (otherwise you could use less engines, saving weight),

[...]

On lift-off, time-to-Ap is necessarily zero and rising. It therefore doesnt help much as you try to start your gravity turn right.
However, it becomes a very good indicator of efficiency when you're at around 8-12km altitude, 45° inclined to the horizon. At that stage, time-to-Ap should be around 30s or 40s or so, climbing slowly before stabilising, then remaining that way until you're nearly in orbit.

[...]

And conversely, if you have a low TWR and time-to-Ap starts falling below about 40s or 35s, you know that you've messed up and are losing vertical speed too fast. It's only recoverable (if at all) by aiming a lot more radially out, meaning a big loss of efficiency.

This is also a great perspective, overall, but I think it needs a couple of minor caveats.

Time to Apoapsis (I'll abbreviate as TTA) isn't necessarily going to stabilize and stop increasing "until nearly in orbit" if you run your engines at full power at all times the way you suggest. In my experience it never stops going up, slowly at first but more rapidly later in the ascent, unless I'm actually taking too sharp a turn and not going to space today after all. If you're taking a high enough turn to make sure you don't burn up or lose excessive amounts of speed to drag, once you start to get into the upper atmosphere TTA can rise quite rapidly, thanks to the increase in TWR as your stages expend fuel. This can happen even if you start with low TWR (around 1.2), as in your engines are just barely strong enough to take off.

Taking a sharper turn isn't necessarily a surefire answer to that, especially if your TWR drops quite dramatically when you stage. It depends on your rocket design and what fraction of your trip to orbit is performed by each stage. In fact, the closer you come to getting all the way into orbit on your first stage (doing so creates a SSTO rocket with any remaining stages as payload), the more you have to throttle back as you get closer to aiming at the horizon in order to avoid pushing your apoapsis up to your target too soon.

Another issue: Being a little too high compared to the most efficient possible gravity turn for your craft is basically safe. Being a little too low can be deadly. Keeping TTA stable toward the higher end of the range gives you more time to correct if it starts dropping (for example, after staging), by aiming slightly above your prograde vector. Doing that is not necessarily the most terrible thing ever in terms of efficiency, as long as you don't have to veer too far off prograde. For example, I've read that real-life rockets often circularize post-apoapsis, which would require just such an orientation.

February 12, 2019

The most efficient kind of ascent path is typically what's known as a gravity turn. This involves gaining a certain amount of straight-upward velocity, and then tilting the rocket a certain number of degrees in the desired direction (usually east, and often north or south for polar orbits), waiting for the prograde marker to descend to match the rocket's new "forward" direction, and from that point on following the prograde marker in a smooth curve that minimizes drag. If you have a level 1+ pilot or a good enough probe core, you can turn on SAS and simply set it to the "follow prograde" mode.

And as mentioned by many others everywhere, there is no single, optimal ascent for every rocket. Finding the best gravity turn path for your unique rocket takes trial and error, even when a plugin is doing it (the Gravity Turn launch autopilot is an excellent assistant and/or learning aid if you want to watch how it tries different paths and see what the results are, just be sure that you have the option to 'revert to launch' before using it).

With experience, you'll get more of a feel for what's likely to work well for a given rocket. It depends mainly on two factors: TWR (Thrust to Weight Ratio) and staging. Drag can also be an issue if it's very high (large fairings or a great deal of parts sticking out without a fairing, for instance).

TWR determines how fast your rocket accelerates. If it's not above 1.0, you can't even get off the ground. I prefer to keep the starting TWR in the 1.2 to 1.5 range, and though going higher is an option it could also mean that you have built too much rocket for your payload and might be able to save some money by using a weaker engine. TWR will increase over time as each stage expends fuel, reducing its mass and thus its weight while the amount of thrust (typically) remains constant, resulting in a greater acceleration being felt, peaking right before the fuel runs out.

Staging affects your ascent by typically causing your TWR to change suddenly, usually decreasing quite a bit as your spent first stage's powerful engines and rising TWR are traded for a more efficient but weaker upper stage engine. If your second stage (or third, etc) doesn't have enough TWR you could potentially find yourself falling right back into the atmosphere if your prograde is too low to the horizon and you haven't gained enough horizontal speed yet, especially if the engine is simply too underpowered for the amount of payload it's trying to push. I'd recommend keeping this above 1.0, but keep in mind that sometimes you need to make sure it's showing you the vacuum stats (rather than atmospheric / sea-level) in order to see the right TWR and delta-V figures, as some vacuum-optimized engines (like the Poodle and Terrier) have abysmal sea-level thrust and efficiency (ISP).

How does all this affect your ascent path? If your starting TWR is high, especially if your second stage's is as well, you typically want to make more of a turn away from vertical, and start sooner. If your TWR is low, you want to start later and turn less. Expressing when to start the turn is also often done in terms of your rocket's current speed, such as "start turn at 100m/s" rather than by giving a time or altitude. They're all interrelated along with TWR anyway, and since a high-thrust rocket will gain speed faster than one with lower thrust, using starting speed figures can make it easier to make comparisons and take what you've learned with one rocket and apply it to another.

Finally, it's typically best to throttle back when your time to apoapsis reaches about 50 seconds (in the stock game you have to go to the map view and point at the apoapsis marker to see this, you can right click it to make it stay visible without having to track it with your mouse). Try to maintain that time at 50 seconds so that more of your rocket's thrust is applied later in the ascent when the rocket is aiming closer to the horizon.

The benefits of this are twofold: You waste less thrust on going up, and you delay causing your apoapsis to reach your intended orbital altitude. The sooner that happens, the larger a circularization burn you'll need to finish gaining horizontal velocity. For "getting into orbit" purposes, a larger circularization burn is bad. That's because having to apply more of your horizontal thrust at apoapsis, compared to at a lower altitude, reduces the efficiency of that thrust, costing you more fuel, according to the Oberth Effect. (Basically, you spend more delta-V for the same effect when you do it at a higher altitude.)

It's a bit counter-intuitive, so to put it another way: Applying less thrust during the middle stages of the ascent (when you're aiming more upward) allows you to apply more total horizontal thrust prior to reaching your desired apoapsis height, which saves you from having to apply significantly more thrust at the end of your ascent where that thrust is less effective. The net effect is that you spend less fuel to reach orbit if you throttle back as needed to avoid pushing your time to apoapsis over about 50 seconds until as late as possible in your ascent (often into the 25-50% range, although TWR affects it too).

February 12, 2019

Hello! I'm not sure if this is really the right place for this advanced topic, and if anyone has a better idea for where to put this I'll happily post there or get it moved if possible.

I'm working on a mission plan to place four relay satellites in a tetrahedral configuration which will provide 100% uninterrupted coverage of a planet's surface, using Kerbin as my starting point for now (since I still need to figure out how to calculate the minimum semi-major axis required to provide such coverage around other planets and moons). This requires four eccentric (0.28), inclined (33 deg) orbits with the same orbital period and, for Kerbin, a SMA of 4,350,000 km or greater. I'm using 5,506,299 km because that results in an easy to deal with period of 12 hours. I'll include the exact orbital parameters needed farther down, which I have shamelessly lifted from a very old (2013) thread which I will also link.

Here are a few screenshots to give you a quick idea of what it looks like.

Four-satellite tetrahedral configuration for 100% comms coverage on Imgur, or open the following:

Spoiler

View from one angle near the equatorial plane, showing where the orbits with apoapsis in the southern hemisphere cross each other.

View from another angle, rotated around the planet's axis by about 90 degrees, giving a clear view of where the orbits with apoapsis in the northern hemisphere cross. Tetrahedral shape of connections between satellites can be seen more clearly here.

View from above north pole, with orbit inclinations flattened to zero (equatorial). These are the initial orbits the satellites will be deployed into prior to the plane change maneuvers which finalize their orbits, allowing them to provide uninterrupted polar coverage as well as equatorial.

I've figured out how to accomplish *almost* every step of the process! Plotting the inclination changes to be performed at the correct time/location is the only thing eluding me. It's not a simple matter of doing something at the current ascending/descending node since they all have to start out in equatorial orbits, and I couldn't just target another vessel and use the relative AN/DNs unless I launch two additional satellites and carefully position them in 90 degree polar orbits which are perpendicular to each other and have their Longitude of Ascending Node carefully tweaked to be positioned exactly along the semi-minor axis of the pair of satellites which need to change inclinations relative to that plane. But launching six satellites instead of four defeats the entire purpose of this plan, and if I knew how to figure out where the AN/DN of these polar satellites needed to be, I think I would already have what I needed to figure out when the inclination changes should be performed without requiring some external reference.

All I really need is a way to find out the number of seconds since periapsis (or AP, whatever) which will put the satellite in line with ~~its orbit's semi-minor axis (not major, the one at a right angle to it),~~ the latus rectum, which is to say, when the satellite is at +/-90 degrees True Anomaly. (For an elliptical orbit like this, 90 degrees is not simply 1/4 of the orbital period, like it is for a circular orbit.) Kerbal Engineer can show me what my vessel's current True Anomaly is, but it doesn't provide a way of finding out what the UT will be at that point in the orbit or how much time remains before it, so that doesn't help me plot a maneuver node in advance so that it occurs exactly at 90 degrees, which is necessary to allow the burn to be started at the right time.

For reference, here's where I'm at in terms of the mission plan.

The four satellites each need to reach their target apoapsis in sequence, 1/4 of their final orbital period apart. The period I'm using is 12 hours, so each satellite need to decouple and burn to raise its apoapsis at 3 hour intervals. Additionally, since the Argument of Periapsis for each satellite is rotated 90 degrees (drawing lines from their APs to Kerbin will form an X or + when viewed from far above a pole), the launch vehicle needs to complete 1/4 of an orbit more or less every 3 hours (180 minutes). A circular orbit with a period of 48 minutes will result in making 3 complete orbits in 144 minutes and another 3/4 of an orbit in the remaining 36 minutes.

So, first the launch vehicle gets into an equatorial orbit at an altitude of 305,314 meters, which gives an orbital period around Kerbin of 48 minutes. Just before every 3 hour mark the launch vehicle decouples a satellite, I take control of it and create a very precise maneuver node, first using MechJeb's maneuver planner to "raise apoapsis" after an arbitrary fixed time of several minutes and then tweaking the values using PreciseNode until the accuracy is down to the 10 meter range (just because I can), and then I set the UT of the node to a specific time. For the first satellite I just pick some convenient round number far enough in the future to allow time to get ready. I record this value, and then for the other satellites I simply add on the correct number of additional seconds (3 * 60 * 60 = 10800) to ensure that each node is executed with the correct timing.

The time taken for these satellites to reach apoapsis from the deployment orbit is around 3 hours 40 minutes, so the first will need to perform a burn shortly after the second is deployed, and so on. The AP burn brings the PE up to approximately 3364.5 km, and I adjust as needed to ensure that the orbital period is as close to the intended 12 hours as possible given the limits of precision in the values displayed by Engineer and MechJeb. Getting MechJeb's Synodic Period (with another of these deployed satellites as a target) to display a value of over 1000 years, for example, is not difficult and offers more than sufficient precision.

After all four satellites have performed these burns, the final step will be to change their inclinations so that they provide constant polar coverage as well as equatorial. And that's what I'm not sure how to do accurately, as described.

Here is a save file for a 1.6.1 sandbox game that shows the desired final configuration (it's really nifty to watch in the tracking station as the comm network lines maintain this rolling, stretching irregular tetrahedron, always completely surrounding the planet as the satellites sweep through their elliptical orbits). The state I need to get there from is simply the same thing but with all satellites having an inclination of zero. You'll find two quicksaves in there, one showing each configuration.

https://drive.google.com/open?id=1Y71svhDTCd6uBXDtN0mRpcN0l1dGn3z2

Additionally, I'd be grateful if anyone could provide suggestions regarding how to determine what the minimum SMA is for establishing 100% coverage with such a constellation around other planets or moons. Even having a simplified calculation that overestimates somewhat would be perfectly useful.

Finally, here are the exact orbital parameters and the thread I referenced for them (the real source, Draim's article, is sadly behind a paywall):

Spoiler

I originally went looking for information about the minimum number of satellites that could be used to provide 100% coverage of the surface at all times. I suspected it might be as low as four and that it would use inclined orbits. It apparently also requires eccentric orbits. As it turns out, I found a post on these very forums where someone had set up an example of this as a challenge. With the comm network, this satellite configuration has become useful even in stock KSP.

Here are the details of the orbital parameters required for this kind of constellation, in the terms used in KSP's save files. (LPE technically would be short for Longitude of Periapsis, which is the sum of LAN (Longitude of Ascending Node) and Argument of Periapsis. But I believe KSP actually stores Argument of Periapsis there despite the misleading field name.)

All satellites have the same eccentricity and inclination values:

ECC = 0.28
INC = 33.0

EPH (Epoch) and SMA (Semi-Major Axis) must also be the same (or nearly so) for all satellites in order to be properly positioned and maintain that positioning over time. That makes it tricky to cheat four satellites into proper orbital positions to see an example of how it should look, since you can't do them all at the same instant. So I did it by placing them in orbit, then editing a quicksave file and loading it.

Just using EPH = 0.0 for all four is fine. And for Kerbin, the minimum SMA for 100% surface coverage appears to be pretty close to the 4350000 km used in the thread.

The other three important parameters are different for each satellite (and MNA is Mean Anomaly, an angle expressed here in radians):

Satellite 1

LPE = 270.0
LAN = 0.0
MNA = 0.0

Satellite 2

LPE = 90.0
LAN = 90.0
MNA = -1.57078

Satellite 3

LPE = 270.0
LAN = 180.0
MNA = 3.14159

Satellite 4

LPE = 90.0
LAN = 270.0
MNA = 1.57078

February 8, 2019

On 2/6/2019 at 12:50 PM, boolybooly said:

@Tallinu yes, you are right, as long as the mods dont alter craft physics from stock then its fine. The purpose being to enable comparison between missions and permit meaningful competition for some of the kudos titles.

I havent tried Atmosphere Autopilot, but if it simply stabilizes and guides the craft as it appears to then its fine, MechJeb is OK too.

You have a striking craft design which from the sound of it has already completed the K-Prize. I will wait for the promised video in the hope you will supply a name.

I am afraid Kerbal transfer doesnt count unless you leave their cabin at the station... The problem is a pilot swap would be a zero mass Kerbal transfer achievement and it would require complex rules to make sense of passengers which I am not going to get into. So payload delivery is what counts for utilitarial kudos. Hope that makes sense

Even the basic fly-by-wire system in AA is amazing, it's like SAS on steroids. The craft goes exactly where I tell it to and stays rock-steady in other respects.

I finally got the kinks worked out of the OBS I installed (mainly an irritating hiss in my microphone input line) and got the mission recorded last night, along with a bit of description and commentary. I didn't expect the resulting video to be basically an hour long, although part of that is that KSP ran noticeably slower while recording, but it's done and the latest minor revision of the craft landed intact once again, despite a mishap at the end which nearly led to a crash for the utterly silly (silly, I say!) reason that my velocity readout never switched back to Surface mode automatically, so I thought I was going far faster than I actually was and kept trying to slow down unnecessarily!

Here's a link to the video:

Which apparently the forum automatically embeds! Alrighty then.

It's unfortunate that you can't simply count passenger cabins, particularly those which are required to allow the vessel to contain the number of Kerbals occupying it during the ascent or descent phase, as payload mass -- it uses more delta-V to keep such dead-weight attached for the return trip than it would to drop it off in orbit, after all! And detaching components that make up more than a third of the main body of the vehicle isn't exactly something you can do with a spaceplane, and have it remain stable... or even intact.

But I believe this qualifies for utilitarian credit despite that ruling, thanks to the relay satellite "payload" (which weighs less than 10% of what those passenger cabins weigh, LOL ). And it turns out that little thing could actually prove quite useful, since despite its size the satellite actually has enough delta-V to transfer itself to either moon and take up a decent high orbit, and the RA-2 antenna can provide 100% signal strength even from Minmus to a level 1 tracking station.

There are links in the description of the video to KerbalX pages with both craft files, for the basic version and the one with the relay payload. I actually rebalanced the RCS thruster positions on the latter in order to compensate for the slightly heavier fairing base left behind after dropping off the satellite. It probably wouldn't make a significant difference, but it's there if anyone cares about the difference.

February 8, 2019

@Shadriss I didn't see such a question or answer when I glanced through the last few pages or the first page, and there's only so much time you can spend looking for things that may not exist.

Also, since it doesn't look like anyone responded to that part: "KSP.log" is the one you'd want, found right in the main folder where the executable is.

@wile1411 Thanks for linking those! That spreadsheet makes it so much easier to figure out how far you can reach with various setups -- I had no idea that you could get more signal strength than the level 3 DSN with four stock RA-100 relays! A set of relay satellites spread out in a solar orbit could extend your reach quite a bit...

February 5, 2019

I have a question about a couple of the rules.

Rule 3 suggests you don't have to use a completely stock KSP install. More specifically, would I be correct to assume that if you're flying a stock craft in a save with mods installed (I have a station I want to dock with that has mod parts, for example), but none of the installed mods change stock parts or affect how it flies (like FAR does for example), then the mission can qualify?

I could switch to my clean install and spend the time to sandbox up a demo station to run the mission there, but I'd rather just use my existing career game.

And am I right to assume that even Atmosphere Autopilot's fly-by-wire mode, which is basically what SAS wishes it could be when it grows up, is not allowed for the stock challenge? Or is that actually okay to use?

Also, just to clarify, while rule 1.B says "Crew transfers are permitted," does bringing passengers or tourists to a space station counts as payload delivery for the "Utilitarial Commendation?" The mass of those comfy cabins is basically payload after all! (I could probably squeeze in a fairing with a tiny relay satellite on the tail though...)

Here's what I'm planning to use, by the way (Edit: updated the screenshot to show current version, click for a few more. Also, craft file).

Spoiler

For years now I've been occasionally trying to build working passenger transport SSTOs, without needing to unlock the whole dang tech tree first. It never worked out well. But now, I've FINALLY come up with one that I can actually fly and land intact on the runway! It has a "payload" capacity of 11 13 Kerbals (counting the pilot) and makes it into orbit with an average of about 800 delta-V to spare for rendezvous, rescues, docking, crew transfers, returning science experiments to Kerbin, etc. On top of that it doesn't use any tech over 160, and only two aviation-specific tech nodes! So I didn't have to sink a lot of science into aircraft tech just to easily shuffle crew and bring science home.

Updated: I just rearranged a bunch of parts, removed 400 units of fuel, and added another cabin, bringing the passenger count up to an even dozen... and still made orbit with 740m/s despite a decidedly non-excellent job of manual flying (to make sure it was still stable enough, etc). Made it home just fine too -- quicksaved and deorbited twice, hit the runway (gently) each time. I want to do a proper job of video recording on an actual mission though, not just test flights, to demo what it's really good for.

I think the ship looks even cooler now, and I updated the screenshot and added a few more to the imgur album if you click on it. ~~Also, here's the craft file.~~ (Update: Scroll down to my next post, open the video on youtube, and look in the description for up-to-date craft file posts on KerbalX!)

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Tallinu

Valid [modname] values