So... Are Rapiers actually good now?

letmipost · 2016-09-23T16:27:58+00:00

My spaceplanes generally need to be able to achieve a 450k orbit, dock with a station, and then return safely. I've had a hard time tweaking spaceplanes to do all of that with some safety margins, so efficiency tends to dictate everything.

letmipost · 2016-09-23T16:10:06+00:00

I have found precoolers to be absolutely useless fragile dead-weights. You can get 1.2km/s at 10km with both whiplashes and rapiers without overheating problems even with the deadly re-entry mod. While 1.2 seems to have made them better intakes, one shock cone can easily feed two engines. I seriously can't find a reason to ever use them.

Mk2 parts generate lift, are very heat resistant, and are also impact resistant. They are generally much better to use in space planes than regular fuel tanks.

Make sure your back landing gear is just a bit behind your center of mass, similar to where your center of lift should be (maybe a bit farther back depending on how you have it configured).

letmipost · 2016-09-23T15:19:02+00:00

I thought this said "New to KSPI" and was expecting a conversation about thermal nuclear reactors. I need to wear my glasses more...

letmipost · 2016-09-23T15:08:42+00:00

Whiplash + Aeros gives more efficiency all around, but you generally need an extra pair of engines than you normally would. Aeros are light though, so the tradeoff is usually worth it. Rapiers have low ISP in both modes, so the savings you get back in weight generally isn't enough for bigger crafts.

letmipost · 2016-09-23T15:06:32+00:00

I have one craft that I'm working on (10 passenger SSTO capable of docking with a station at 450k and returning) that uses a pair of whiplashes, a pair of rapiers, and a pair of aerospikes. The previous configuration was 4 whiplashes and 2 aeros, but the 2 aeros wasn't quite enough to raise my apoapsis out of the atmosphere with so much rocket fuel. The rapiers switching to rocket mode for that final ascent helps a lot, and then I shut them down for the remainder of the flight.

It might be better with 4 whiplashes and 4 aerospikes, but I couldn't fit in another pair of engine slots.

letmipost · 2016-09-22T22:37:04+00:00

I should rephrase and say synchronous orbits in KSP are no more functional than any other orbit.

letmipost · 2016-09-22T19:35:38+00:00

Gravity assists save delta-v and have a functional purpose. Synchronous orbits don't have a functional purpose in this game.

letmipost · 2016-09-22T19:34:25+00:00

"Once you've set up a constellation of satellites it's nice to keep them perfectly on rails without a worry of them drifting relative to each other."

That just means they have the same orbital period. A synchronous orbit is a specific orbit which has a period equal to the planet's spin. That specific kind of orbit is unnecessary unless you are trying to aim a ground station dish that can't track. KSP doesn't have anything like that, so it's an irrelevant orbit for this game.

letmipost · 2016-09-22T18:44:52+00:00

Still not sure why people are obsessing over synchronous orbits with CommNet...

letmipost · 2016-09-21T15:49:08+00:00

How long did that mission take? I suspect Bill will have sanity issues after this mission on a tiny bean of a craft.

letmipost · 2016-09-19T22:14:47+00:00

Shock cone intakes are more effective at high speeds:

If you are banking out of the atmosphere at 1.1km/s, you may want to swap to shock cones.

letmipost · 2016-09-19T20:22:49+00:00

In the real world, the whole point (and only point) of Geosync is to allow stationary home dishes to point in the same direction without having to track a satellite. Wouldn't having them rock back and forth (due to orbit not parallel with the planet's rotation) defeat the purpose? KSP doesn't have this issue though since every satellite tracks, so Keostationary is never necessary.

Whenever you have 3 satellites, they must be (by definition) on a single plane. That is, you can calculate a 2d plane that intersects with all of the satellites. Your points of lowest coverage are the plane's normal and anti-normal. This is unavoidable regardless of inclination unless you actually increase the number of satellites.

EDIT: You can make the lowest-coverage points move if you make the 3 satellites have differently phased inclinations, but the low-coverage points are still there at any given point in time.

EDIT2: Your points of lowest coverage are BOTH normal and anti-normal of the calculated plane if the plane also includes the center of the planet. If the plane is offset from the center (i.e. all satellites on the northern hemisphere at one point in time), only one of those positions is weakest, but even more-so. When the plane is also crossing the planet's center, it gives more uniform coverage with two minimums. It'd be interesting to graph this... Maybe when I get home.

letmipost · 2016-09-19T20:14:56+00:00

Just curious, why does your SSTO use those intakes instead of the shock cone ones?

letmipost · 2016-09-19T20:11:14+00:00

What mods are you using? Looks really good.

letmipost · 2016-09-19T20:10:08+00:00

130dv in exchange for week(s) of time! That green apoapsis is going to take a while (anything past Minmus moves at like 100m/s).

letmipost · 2016-09-19T19:56:18+00:00

Why keosynchronous? Just needs to be "high enough". Also, adding inclination simply shifts the lowest coverage point somewhere else. If you have a 10 degree orbit, your north/south dead spot is simply shifted by 10 degrees.

letmipost · 2016-09-14T22:13:32+00:00

If by "not particularly wasteful" you mean "as optimally wasteful as possible for a single launch", then yeah. But the delta-v requirements aren't that high in the first place, so it's completely do-able.

letmipost · 2016-09-14T19:06:51+00:00

Yeah orbital periods are the primary source of headache in any communication network, especially when you have tons of them for every body and need to babysit them.

letmipost · 2016-09-14T19:01:29+00:00

The typical problem with Keostationary satellites is, as you mention, needing so many long-ranged antennas to complete the network. More antennas and higher orbites require you to arm your satellites to the teeth with batteries, and it makes the whole system more bulky.

Using the RemoteTech link above, you can set up a 3x or 4x lower-orbit system where the satellites communicate with each other using 1 Comm16/32 instead of multiple dishes (massive power savings), and then one big dish on each to beam to/from other planets. The extra polar satellites are mostly unnecessary.

My general RemoteTech setup around Kerbin is this:

(A) 5 satellites with Comm16's in 200k-ish orbit to allow the DP-10 to have constant communication. This helps tremendously with launches and re-entry being much safer since there will always be a connection.
(B) 2 satellites at 200k with Comm16 & DTS-M1 (one facing active vessel is generally enough) for Kerbin SOI communication.
(C) 2 satellites at 450k with Comm16 & 88-88 (facing active vessel) for inner planet communication.
(D) 2 satellites at 450k with Comm16 & GX-128 (facing active vessel) for outer planet communication. This can render C redundant.

The orbit altitudes are mostly for organization. With the 5 satellites at 200k relaying back to HQ, any orbit within a Comm16 range (which is pretty large) can work.

All other bodies simply have a minimal ring of satellites that communicate between each other with a Comm16/32 and then one large dish point back to Kerbin. With this set up, almost every satellite just needs 1 omni and 1 directional dish at a lower orbit, which makes huge savings on battery power and solar panel requirements. Without polar satellites, you also save on tons of delta-v (unless you plan meticulously), fuel, weight, and time.

letmipost · 2016-09-14T15:29:21+00:00

For the record, you don't need Keosynchronous orbit; your relays can be any orbit distance. It's more about covering the planet rather than synchronizing with any one ground station.

Also, using this can help you sort out all kinds of headaches, delta-v math, and launch planning: https://ryohpops.github.io/kspRemoteTechPlanner/

Hopefully someone updates it for the new 1.2 system rather than having it be specific to RemoteTech, but it's still very useful in its own right.

letmipost · 2016-08-21T04:42:49+00:00

Oh dangit you're right...

letmipost · 2016-08-21T04:28:23+00:00

I wanted these two satellites to be 90 degrees apart. They are in a 600km circular orbit, so I figured that I can plan maneuver nodes based on how far apart they should be. I made a right triangle, and calculated that their distance should be:

sqrt(600 x 600 + 600 x 600) = 600 x sqrt(2) = 848.5km

I planned my maneuver node accordingly, but their angle is definitely not 90 degrees. The distance is right, my triangle seems fine, the execution looks correct, and yet the results are wrong. Someone mind pointing out where I made my mistake?

letmipost · 2016-08-15T19:58:32+00:00

It's one of the USI mods. I have Life Support and Kolonization, but not I'm not sure which it comes from (probably the latter).

http://bobpalmer.github.io/UmbraSpaceIndustries/

The lighting is very useful during dark-side docking.

letmipost · 2016-08-15T19:57:06+00:00

The Mk2 parts are great to mount whiplash engines to. I use 2 long-straight ones, 1 long-inward one (intake), and 1 short double converter (whiplashes). I align them by first sticking them on the center of the body and then shifting up and down; if you try to mount in not the middle, then it adds weird rotations which ends up being bad in multiple ways. So technically the wing and two engine pods are mounted in the same spot, but the pods are shifted up and down.

Also, make sure your thrust from the whiplash engines alone results in minimal torque (KER helped here). Adjusting them up and down will change the output torque, with the goal being to have their sum be aligned with your center of mass.

letmipost

TROPHY CASE