Quick Questions and (Hopefully) Quick Answers

[Streetwind]

1 hour ago, TomArt said:

I have a MacBook Pro - how can I get around the right-click requirement?  I'm just using the touchpad.

Welcome to the forums!

Unfortunately can't get around it. KSP is built from the ground up to require the use of a cursor in many ways. Even when you're playing on a console with a controller, you still need to move a cursor to interact with your ship.

[fourfa]

3 hours ago, TomArt said:

I have a MacBook Pro - how can I get around the right-click requirement?  I'm just using the touchpad.

Go into your trackpad settings, and select a gesture for right click. Usually a two-finger click is the Mac default equivalent of right click. Then, go to Amazon and get a $5 usb mouse and make things a lot easier on yourself  You also want to have mousewheel click and scroll, which don't typically have Mac equivalent gestures

[IWanttobeEVA]

8 hours ago, TomArt said:

I have a MacBook Pro - how can I get around the right-click requirement?  I'm just using the touchpad.

In the touchpad settings you can set the right-click function to be one of the corners of the pad or as a special gesture, such as click with thumb while touching with two fingers or clicking with two fingers. 

[Diche Bach]

On 8/8/2016 at 4:16 PM, 5thHorseman said:

6. The center of the area in question is at the tip of the cone below the circle, but the entire area is usually several km (I think even as high as 25 or more in some cases) around it.

If you are interested in an elegant mod solution to contract waypoint markers, check out Waypoint Manager. Among several other things, it shows you waypoints on the in-flight screen so you can target them by eye without having to go to map mode.

That mod seems to be pretty awesome. I have yet to use it to great effect, but I think it can be (maybe) used to achieve landing on a fairly precise point.

The panel it opens up lists all of your waypoints along with their lat/long coordinates. Using this and Kerbal Engineer's "Lat at Impact" and "Long at Impact" and setting up a "reentry" maneuver node, well before you are close to any atmospheric disturbance, may well allow for a fairly accurate landing site to be specified.

The two problems I've encountered with it so far:

1. One has to pull the periapsis pretty far back into the negative before KER seems to recognize that there is an "impact" event (else it is a matter of closing then reopening a window or something) and when I first was examining it, I wasn't even sure that those "Lat at impact" values related to a vessel on reentry (thought they might have to do with "impact" experiments mod I have installed). Now that I see that they DO relate to the impact of a reentering ship I may be able to make better use of them.

2. Making adjustments to ones re-entry trajectory in upper atmosphere seems to be completely irrelevant and result in absolutely unpredictable results.

I'm guessing that one must set up a good reentry trajectory well in advance (and probably one within a certain fairly narrow margin of angles) and then simply hold bow on retrograde until one gets through the turbulence zone at which point some degree of navigability is restored . . . Probably deserves its one thread on "re-entry dynamics," or else revisiting an existing copy of such a thread . . .

[Diche Bach]

If I want to set up a communications satellite to always be on the far side of minmus (and slightly above/below and/or behind/in-front-of the moon relative to Kerbin . . . the goal here being to provide permanent RemoteTech linkage to anything on the far side of the moon at any given time:

I would assume it is as "simple" as: 1. matching Minmus inclination; 2. getting an apoapsis of Kerbin that is positioned in the rough position I want, then 3. burn prograde at that apoapsis in order to match Minmus orbital period and velocity (274.1 m/s) around Kerbin?

Which orbital period is it? The wiki provides values for about half-dozen different ones.

I'd assume it is the Sidereal orbital period, which is = 1 077 311s or (49 d 5 h 15 m 10.5 s)?

Or is this just a bad idea?

[Streetwind]

12 hours ago, Diche Bach said:

I would assume it is as "simple" as... *snip*

It's not as simple as you think it is, unfortunately.

For a satellite to always remain "behind" Minmus with respect to Kerbin, it would need to have the same orbital period as Minmus while inhabiting a higher orbit than Minmus. In a fully realistic N-body gravitational simulation, this is possible only at one specific point, called "Minmus-Kerbin L2" (the second libration point, or "Lagrange" point, around Minmus with respect to Kerbin). However, KSP does not do N-body simulation, using the patched conics approximation for 2-body systems instead. Therefore this kind of orbit is physically impossible to achieve, as there are no libration points in 2-body simulations, and any rise in orbit altitude always corresponds to an increase in orbital period.

So you cannot position this satellite in Kerbin's SOI; it must be within Minmus' SOI.

However, Minmus is not tidally locked. If it was, you'd just have to look up the synchronous orbit, which the wiki helpfully provides for every celestial body. A synchronous orbit around a tidally locked body automatically appears static from said body's central parent too, which is precisely what you want. Instead, you now have to figure out what the synchronous orbit would be IF Minmus was tidally locked. You do this by looking up Minmus' own orbital period. Because after all, your initial condition was that the satellite would have to have the same orbital period as Minmus itself. You've already found this number: it is the sidereal (= "with respect to the stars") orbital period, spanning 1,077,311 seconds.

The question of how high one has to orbit a body to have a certain orbital period around it can be derived from Kepler's third law, and is well solved: the semimajor axis required is equal to the cube root of the term GMT²/4π², where G is the gravitational constant (6.674x10^-11), M is the mass in kg of the body you're orbiting (2.6457897×10^19 for Minmus), and T is the desired orbital period in seconds. Solving this returns a value of ca. 3,730,393 meters for the semimajor axis. As this is by definition with respect to the center of gravity, you need to subtract Minmus' radius next, which is 60,000m. The result of 3,670,393 meters, or 3,670.4 kilometers, is the altitude above Minmus surface you need to put the satellite at.

The whole reason for doing all this math - instead of just going for trial and error by for instance using KER's orbital period display ingame to just figure out where you need to be - is to check if it's even physically possible in the first place. Minmus' SOI extends to 2,187,428.4 meters, or 2,187.4 kilometers, above its surface. Unfortunately, this value is smaller than the required altitude we just calculated. In other words: you cannot put a satellite into a Minmus orbit that is high enough to fulfill your desired conditions. Trying to do so will cause you to leave the SOI and enter Kerbin orbit - where, as laid out in the beginning, you can't fulfill the conditions either. (As an extension of that, if Minmus was tidally locked, the wiki would tell you that a synchronous orbit around Minmus is impossible. There are several bodies in the KSP solar system where this is in fact the case.)

Ergo, what you are trying to do is not possible in KSP. You will need to make do with a classic commsat constellation around Minmus instead. Three satellites for 100% equatorial coverage, although two will already achieve 99%.

Edited August 16, 2016 by Streetwind

[Spricigo]

17 hours ago, Diche Bach said:

If I want to set up a communications satellite to always be on the far side of minmus...

I have serious doubt it being possible at all even for different pairs of planet+moon. Also I'm so lazy to make the calculations myself so this is just a hunch.

Accordingly with kerbal wiki

 

Now compare it with height need as stated by  @Streetwind in his explanation if you want to calculate it for any given planet+moon combo 

 

 

Edited August 16, 2016 by Spricigo
Mistype

[Diche Bach]

@Streetwind & @SpricigoNeat! I hope you guys enjoy teaching what you know about the physics/maths of it. I just might wind up learning something 

I like to try things seat of the pants and then go back to the technicalities of it. It seems to "gel" better in understanding that way.

So how will this turn out to work!?

I'm guessing that:

1. There will be portions of the surface of Minmus (on both faces) that will NEVER be in contact (and wouldn't be even it is was completely flat): basically a region around the axis of the ascending/descending nodes?

2. This part is a bit more murky but . . . I'm guessing that: because the orbit is around the center of mass for Minmus, as Minmus rotates and revolves, the orientation of the orbit relative to Kerbin will also shift (probably in a predictable manner?) and the result will be eventual periods where portions of the orbit are "behind" Minmus relative to Kerbin.

3. I would think that, if I were to put a second one of these up there with a virtually identical orbit that was at a right angle relative to this one, that would accomplish more or less the goal?

4. Going back to point #1: there must also be an altitude at which the "blind" strip along the axis of the ascending/descending node is eliminated?

 

[Streetwind]

...Blind strip? o_O I'm not sure I follow you... the axis passing through AN and DN is definitely covered, since those are points on your orbit, meaning your satellite will pass through them and provide coverage. Perhaps you meant the axis perpendicular to the orbital plane? I'll get back on that one below.

 

You have a satellite in a polar orbit around a body with a non-zero rotation speed. Unless you have by pure chance picked an orbital period that's a low, even division of Minmus rotation speed*, this automatically results in the satellite passing over every part of the surface above the latitude defined by the inclination**.

*) In which case you would see the satellite repeatedly pass over the same few strips of surface.

**) Take the inclination of 114.7°, subtract 90°, and you now know that it is 24.7 degrees off of the north pole. Subtract this from 90° (the north pole), and you get a latitude of 65.3 degrees. So the satellite should pass over any and all surface area between 65.3° N and 65.3° S. If your orbit was not retrograde, you would have to do a lot less subtraction, because an inclination between 0° and 90° automatically corresponds to the latitude.

 

The reason why the satellite does this is related to your question #2. An orbit is fixed in space; its orbital plane does not change with respect to the starts. Therefore, if Minmus revolves around itself, that means the surface constantly passes through the fixed orbital plane. All of the surface (within the latitude bounds defined by inclination) does. So everytime the satellite comes by again, a different part of Minmus's surface will be below it. And yes, since the orbit is fixed in space, that means that the orbit will appear to change direction relative to Kerbin as Minmus travels along its orbit around Kerbin. If you set the orbit up so that its edge points directly at Kerbin, then a quarter Minmus year later, it will instead be flat side on towards Kerbin. And another quarter Minmus year later, it will be edge on again... but on the opposite side. It's a bit like the Earth's axial tilt remains static as it travels around the sun, thereby causing the seasons.

This property of polar orbits, that all of the body's surface (within the relevant latitudes) eventually passes through underneath it, is why we launch all our Earth observation satellites into such orbits IRL. The part about how inclination affects how far towards the poles that effect stretches, and how orbital period affects whether or not the passes of the satellite syncs up above certain strips of land or not, those may be quite difficult to visualize in your head. However, KSP being the game it is, there's a mod for that! If you really want it visualized graphically in front of you, install the SCANsat mod, and start trying to map celestial bodies. You will soon come to understand exactly what I mean, trust me!

 

As for commsat coverage... with stuff like SCANsat scanners that observe only a small part of the surface directly below it, choosing the right orbital parameters is extremely important. But your commsat's antennas are essentially omnidirectional - even the dishes are, if you set them to point towards "active vessel". And in a low orbiting constellation, you would pick either native omni antennas or a dish like the DTS-M1 with large cones, which are able to cover the entirety of the body from their altitude, and therefore become omnidirectional as seen from the surface by definition even if they are only pointing directly at the body and not the active vessel.

Because of this, your commsat covers the entire hemisphere visible to it at all times. And that, in turn, means that on a perfect sphere, even an equatorial orbiting commsat has no blind spots. It will not cover all of the surface at the same time, but at some point during its orbit it will be visible from absolutely everywhere. In fact, on a perfect sphere, a dish mounted on a small tower at one of the poles will even see an equatorial satellite at all times, able to track it 360 degrees around and around.

Of course, Minmus is far from a perfect sphere, so there are possible blind spots near the poles for an equatorial satellite. However, lifting the satellite's inclination just a little, some five to ten degrees, is often enough to overcome petty things like mountain ranges. A satellite in a relatively high inclination like yours (65 degrees retrograde) will reach anything except for the bottom of the deepest ravines at the poles... and Minmus does not have any deep ravines at its poles. Therefore your one single satellite easily achieves 100% ground coverage. Even if its orbit happens to accidentally sync up in such a way that there are large gaps between passes. The quasi-omnidirectional nature of the uplink ensures this.

But 100% ground coverage is not 100% connection uptime. One satellite cannot offer this. If you had a second one though, in the exact same orbit but directly on the opposite side, you would get pretty near it. The communications link covers a hemisphere, and two hemispheres make a full sphere... almost, due to terrain. You'd have 99% average link uptime. If you were on a hill, maybe 100%... but if you were in a valley, maybe less than 99%. You can add a third satellite, and stagger them 120 degrees apart - in this scenario, even valleys get 100% uptime, unless that are absurldy steep ravines. (Which don't exist on Minmus.) That's why three staggered satellites is considered the smallest "constellation" you can build.

Now, even such  a constellation has two theoretical spots in which comm links can temporarily fail. Those are the points on the suface that host the axis perpendicular to the satellites' orbital plane. However, keep in mind that the terrain constantly rotates through the orbital plane. Meaning it also rotates through those two points. The chance for a surface installation to actually lose comms to this phenomenon is exceedingly small, since a 3-satellite constellation means that any surface installation always sees two satellites above the horizon of a perfect sphere. You'd have to have landed in a deep valley situated precisely on one of the exact two latitude values through which this axis passes (which, not by coincidence, is the polar offset of your inclination: 24.7° north or south for you) in order to actually suffer an issue. And even then it will be over in a couple moments, as Minmus continues to rotate and put you back into view. If you want to eliminate these tiny problem zones as well, you need a more complex constellation, like a second set of three satellites in an orbit with a plane at a right angle to your first set of three (much like you suggest in your third question). And of course, you can make this arbitrarily complex

 

To summarize answers to your questions:
1.) A commsat with an inclination like yours will see every point of Minmus' surface at some point; it's a feature of polar orbits
2.) The way the orbit looks from the point of view of Kerbin does indeed shift as Minmus travels, in a predictable manner
3.) Doing this does indeed improve coverage, but you still need more than one satellite in each orbital plane if you want high link uptime
4.) There is no blind strip along the axis of the ascending and descending nodes, only two latitudes where a single-plane commsat constellation may in rare circumstances lose a link for a few moments, then resume it

Edited August 16, 2016 by Streetwind

[Diche Bach]

1. Is there a limit to how tall a ship can be built in the VAB?

 

2. Dealing with evolving ship designs / sub-assemblies as one's career play progresses (and if like me, one is learning/relearning the game as one goes): Any suggestions on "best practices?"

I have some good designs, and have _sort of_ made use of the sub-assembly mechanic, but honestly I feel like every time I open up another tech node, I need to scrap most of my old designs and just start from the top down again.

This combined with using Kerbal Construction Time--which adds incentive to reusing the same design over and over by virtue of making it "cheaper" to build stuff your workers have built before--has me in a real paradox.

 

3. Am I the only one who: I use the RCS "place anywhere" pod thing almost in preference to anything else and make use of "displayer" booms: Space craft goes from ~4m diameter at bottom to say, 1.25 at top. Seems to me, having ALL the RCS thrusters lined up in the same planes is better?

Not only that but those "5 way" and "4 way" etc. just do not seem as "good" as me making their equivalent with girders and the place anywhere pods.

I probably need to post pics but . . .

Edited August 21, 2016 by Diche Bach
append more questions

[Streetwind]

15 hours ago, Diche Bach said:

1. Is there a limit to how tall a ship can be built in the VAB?

Not strictly speaking, no.

But you can't launch an arbitrarily tall craft unless your launch pad is level 3. Levels  2 and 1 have craft size restrictions as well as mass restrictions. Also, as your rocket gets ever larger, it will become ever more difficult to edit it - you need to keep adjusting its position if it is taller than the VAB itself. You may also need to turn it sideways and point it out the door.

 

15 hours ago, Diche Bach said:

This combined with using Kerbal Construction Time--which adds incentive to reusing the same design over and over by virtue of making it "cheaper" to build stuff your workers have built before--has me in a real paradox.

Note that KCT calculates its build time reduction based on the individual parts you are requesting, not the way the parts are assembled. If you choose different amounts of the same parts and arrange them in a completely different way, you still get the full build time reduction. (If you have the parts in storage, it's even better.)

I'm perhaps the wrong person to ask this though, as I don't even use subassemblies. I just load up a saved craft and tweak it for a new mission if said mission is similar enough to the old one.

 

15 hours ago, Diche Bach said:

Space craft goes from ~4m diameter at bottom to say, 1.25 at top. Seems to me, having ALL the RCS thrusters lined up in the same planes is better?

Yes, you get more rotation torque if your RCS is placed on booms pointing outwards from your craft - or more specifically, from your craft's center of mass and/or axes of rotation. RL satellite builders do this too. The linear RCS port also has twice the thrust output.

Do keep in mind though that it's less mass efficient. A four-way RCS port weighs 50 kg, but four linear ports weigh 120 kg... plus whatever the boom weighs. More mass means more monopropellant is needed to move the spacecraft. For rotation, the extra lever arm makes up for this and improves fuel efficiency, but when translating, you're stuck with spending more. The main engine also has more to push.

[Snark]

23 hours ago, Diche Bach said:

I have some good designs, and have _sort of_ made use of the sub-assembly mechanic, but honestly I feel like every time I open up another tech node, I need to scrap most of my old designs and just start from the top down again.

Yeah, me too.  I hardly ever use subassemblies at all-- they're just not useful to me.  The hassle of dealing with them, and their obsolescence, just isn't enough value to me to make up for the benefit they provide.  About the only thing I ever used them for was booster stages-- e.g. "here's my standard heavy-lift booster for 100-150 ton ships", that sort of thing-- except that as I got more experienced with KSP, I quickly reached the point where I can slap that together so fast that honestly using a subassembly doesn't gain me anything.

Of course, I don't run with KCT, so that particular aspect doesn't enter into it with me.

23 hours ago, Diche Bach said:

Am I the only one who: I use the RCS "place anywhere" pod thing almost in preference to anything else and make use of "displayer" booms: Space craft goes from ~4m diameter at bottom to say, 1.25 at top. Seems to me, having ALL the RCS thrusters lined up in the same planes is better?

Really having trouble picturing what you mean, here.  Pics would really help.

I've found that pretty much all my RCS-enabled ships fall into one of two design categories:  "small and roughly equal in all three dimensions" (e.g. landers that need to dock to a mothership), or else "big, and long/skinny" (tankers, motherships, etc.)

In the former category (i.e. small landers):  a single ring of four of the 4-way ports, placed so that their plane is as close as possible to the ship's CoM.  If the ship has a design that makes four-way symmetry placement impractical (e.g. that would put an RCS thruster on top of the hatch, or something), then I do essentially the same thing, but instead of a 4-symmetry group of the 4-way thrusters, I use a 2-symmetry group of the 4 way right next to a 2-symmetry group of the 1-way, mounted on left and right sides of the ship.

In the latter category (i.e. big motherships and tankers):  I use two 4-symmetry rings of thrusters, one at each end of the ship.  Those two rings will generally be one ring of the 4-way thrusters and one ring of the 1-way thrusters.  Reason for that choice:  prefer to use the 1-way thrusters because they're more mass-efficient (only weigh 30 kg apiece instead of 50 kg), but have to have at least one ring of the 4-way (so that there's some thrust authority on the ship's longitudinal axis).

In that latter case, the fact that the ship is a smaller radius at the top than the bottom really doesn't matter; the length of the ship is much bigger than the lateral radius (even counting the fatter bottom end of the ship), so the fact that the ports are out at the ends of the ship is all that matters.  (And I never use RCS for rotation anyway; I use reaction wheels for that, and always have my RCS ports set to translation-only.)

7 hours ago, Streetwind said:

Do keep in mind though that it's less mass efficient. A four-way RCS port weighs 50 kg, but four linear ports weigh 120 kg

Depends how you have them arranged.  I'd contend that the one-way port is more mass efficient than the 4-way, at least in the two-ring solution, because a ring-of-four 1-way thrusters is less mass than a ring-of-four 4-way thrusters.  If you're using a one-ring solution, then yes, it's better to use the four-way thruster.

I've never seen any reason to use booms with RCS thrusters, myself.  Either I have a small, compact craft-- in which case the moment of inertia is so low that booms aren't needed-- or else I have a very big, massive craft, in which case they're always very long, so the 2-ring solution works great without the added complications of booms.  (And the extra 120kg of having a second ring of thrusters is trivial compared with the overall mass of such a large craft.)

[Diche Bach]

Heh! @Snark You'ved saved my current career play from the archive bin!

Been having performance issues and have resolved to archive that permutation of GameData directories, start with a minimal mod build (only the 20 or so that I regard as absolutely essential) and see how that performs, and then add more in ONE at a time, thus allowing the capacity to eliminate the one(s) that are contributing to RAM hogging.

But in the interest of grabbing some screen caps of some of these RCS "boomsticks" I'll keep playing it a bit more. Will post some pics in here this evening stay posted!

I've got a several ridiculously complicated space station designs that I had been stalling on screen capping, and putting on Kerbal X, but I'll do that.

[Diche Bach]

Okay, some examples of the "Offset RCS" and especially of the "RCS Skeleton" I've found to be very effective for launching excessively top-heavy craft which would otherwise be untenable: Launch two largish modules = two dockings? No. Launch one ridulously large module = struggle for the first 40,000m just to keep it pointing up and not laying down on the ground in pain? Yes

Need to put them in the correct order and add some explanations, so if this doesn't seem to be "comprehensible yet" hold on as I addit it

These first two show a fairly simple example of the girder + 5 linear RCS ports, which I just added to a revised version of a ship I've used quite a bit "Vinci" from the pre-space station era, upgraded with docking port and better RCS.

This example isn't so good for showing the real beauty of this method: the four modules at the base of the service module fuel tank and above the heat shield are not in line (vertically, as well as laterally), but for a small ship, it shouldn't matter. The girders provide a nice place to stow a bit more hydrazine and to put some cheapo solar panels.
 

These next one (which I think are more or less in the order one would properly view them, are of a recent ship I finished, which I've tested in simulation mode, but probably will not build until I open another tech node. The design is to fulfill a "Build a Sun Space Station" that yields 5 million funds! and while I can probably figure out how to get its orbital period worked out so it doesn't ever get out of range of Kerbin SOI (and thus those 90Mm-range KTR dishes should suffice), given the total distance that could separate it from Kerbin could be more like 26 Gm (whatever twice the semi-major axis of Kerbin is I think?) it probably makes sense to hold off on launching it and put the longer range dishes on it.

#1 is a view of the whole ship.

#2 is a closeup of the joint between the payload and booster sections Those things that look like paper bags/cardboard boxes are "inflatable Lf/O fuel tanks!

#3 is a shot from the "front" of the vehicle (there is no "cockpit" the two command modules attached on the sides are utility/escape/contingency modules . . . I figure, if I've got a space station outside of Kerbin SOI, I might as well start using it as a "depot" for taking steps toward manned missions further away and these two ships are intended to make it easy to send up lander modules, fuel modules, etc.)

. . .

Edited August 22, 2016 by Diche Bach
explain pics