Frederf

You want your time to orbit to match the orbit of the target. For simple transfers like Hohmann this is well defined. For long-duration powered ascents the math is significantly more complex. For sanity's sake I suggest building fault tolerance into your mission profile. I'll give an example: Active vehicle altitude: 0 m orbital velocity: 175 m/s (surface) longitude: KSC Target altitude: 100km orbital velocity: 2256 m/s longitude: TBD A Hohmann transfer from 0 to 100km takes 14m36s. The target is sweeping 11 deg/min. Your ascent will probably take a lot shorter time than this, but I don't know how to calculate it. I'm just going to assume 2000 m/s at 20 m/s/s and get 100 seconds. OK, 100 seconds is two minutes. Leading your target by 22 degrees should mean a 267 km separation (trigonometry) at launch. Because you can't be exact, aim for a 90 km orbit but launch one minute after the 267 km marker. You'll be behind and faster and should catch up within about two orbits.

That's an astute observation. Dynamic cost based on part tweakables: resource contents, procedural dimension, etc. is going to be a necessary function.

Efficiency is mentioned in the thread title. For complete coverage you absolutely need to to pass over the poles or at least within one hex radius. Thus the most efficient polar orbit entry is needed. For further efficiency one would capture into an elliptical orbit from minimum safe to max sensor range over a full set of latitudes (your Ap could be outside sensor range as long as you got from +90 to -90 latitude on one side of the body at least). But honestly fuel efficiency is not that critical. Slap an ion engine and a tiny Xe can on something and it can leave LKO and scan Mun, Minimus, Duna and Dres and have enough to come back. Career mode may place some game-time restrictions. For example if life support ever gets modeled when not in focus it'll matter plenty. Some people just don't like time accelerating Kerbal years when it's only a probe. Good time efficiency could involve a polar orbit that is reduced to equatorial gradually as the pole hexes fill and are no longer needed overflight. I've also considered that your orbital period to Mun rotational period should avoid harmonization. Ideally your sensor craft would complete N polar scanning orbits as the Mun completed one rotation where N is the number of equatorial hexes. The idea is to have no duplicate scans and no gaps. I think this is physically impossible (negative orbit altitude) but 2, 3, 4, 5, etc. Mun rotation schemes are possible. The timing is frighteningly precise though.

Isp is "effect per fuel" ratio so four engines is four times the effect with four times the fuel rate so they cancel and the efficiency is unaltered, it just happens faster. As specialist says the downside is that more engines mean more mass. More mass means that the same effect (momentum change) from your thrust will be acting on a more massive vessel for a lesser speed change total. If you take a 10 ton space ship and make it 11 tons, you would expect 10/11th as much speed change with the same Isp and fuel.

What kind of efficiency? Fuel? Game time? Real time?

The return orbit is very sensitive to how you interact with the Mun's gravity. The most extreme case you exit the Mun with exactly zero orbital velocity relative to Kerbin and fall straight down on a degenerate (collapsed) orbit. What you're basically doing on free return is doing a no-assist gravity assist. You'll find that some Mun SOI interactions are gravity assist increasing the size of your orbit and others are gravity brakes decreasing them. A free return is finding a path through the Mun's SOI such that you are neither assisted nor braked and return to the orbital energy you had on interaction. In reality you want the slightest braking to take your original Pe down to something suitable for aerobraking. I disagree with using radial component on the maneuver node as with different timing there is an entirely prograde solution for the same impulse vector and will be more efficient. When I do it (usually to dispose of the TMI stage) I set up a Hohmann to intersect Mun CoM and then increase prograde until I arrive ahead of the Mun which sets up a gravity brake. I shuffle the node location and reduce prograde dV until I get the minimum deltaV that produces the desired resultant orbit. You'll find if you "cheapskate" on deltaV you will not be able to both clear the Munar surface and brake enough to lower your resultant Pe. In this case more dV is called for to lower your resultant dV somewhat unintuitively.

I believe the reentry effects depend on MM @REENTRY_EFFECTS[Default]:Final { @heatMultiplier = 25 @startThermal = 750 @fullThermal = 1150 @temperatureExponent = 1.03 @densityExponent = 0.85 }

No, with single parts all resource mass is concentrated at the CoM point of that part.

Clever. I wonder how non-part-mods might be included in the requirement method.

Have you asked the TV Aerospace creator? Usually mod authors have strong opinions on the balance of their own stuff.

This mod has singlehandedly saved the Journey Space Program. I have a Ke converter with a 1.0 unit buffer tank of each resource and this mod allows me not to have to do each transfer individually. ;_; *internet hug*

I'm messing around with Kethane mod -> LiquidH2/LiquidOxygen conversion. I had no success with 0.75 despite updating the MF1.3 overload configs to match the 0.75 format (they didn't). Ke 0.76 drastically altered the config format so here's hoping that it'll actually make MF resources now. Yay it works! Now I just need to find balanced values for the characteristics and I'll post them.

Finished a long 2400000 cm long Mun kethane tanker rover trip to arrive at the pre-placed mining rig and started to fill the tanker. A short time later the refinery rig arrived with two new hire kerbals and is ready to convert it into whatever. Soon there will be free fuel in Munar orbit for interplanetary missions! So not looking forward to repositioning the group to the next deposit. Maybe I'll develop a sky crane to haul the tanker.

Direct ascent is what you're describing. You absolutely want to do a gravity turn or similarly optimized ascent as if you were aiming for a parking orbit. The directness of the direct ascent profile comes from the zero time delay from reaching a stable orbit until burning for escape. If you take a typical ascent-park-escape mission profile and reduce the time spent in park you approach the direct profile. The nice thing about eliminating the parking orbit is you can choose a lower point at which to go hyperbolic since the time spent in the thin upper atmosphere is so small that the drag losses are overshadowed by the deltaV gains from being lower. The downside is the absurd levels of planning and precision required.

Sounds like the Spherical Fuel Tanks mod attachment points.

The surface of Kerbin spins to the east. Try changing from surface to orbit mode on the velocity display to see. Try setting up the maneuver with a maneuver node before attempting it so there is no surprise to the result.

Just looking at the pictures it looks like you managed to cage the Kraken and bring it back to Kerbin where it escaped. "Bugs, uh uhh, find a way."

I'm currently driving about 1/5th the circumference around the Mun... it'll be a while.

End burning is bad as the walls of the lower casing have to survive the punishment from upper fuel traveling past it. It's best for there to be a constant layer of fuel as a guard as long as possible.

Setting targets does absolutely nothing to the mechanics of docking. Tab A will fit into slot B just the same. The difference will be in the information displays that assist the player in accomplishing previous. I find that orbit-normal alignment is quite useful in docking depending on the orbital period. To follow an approach corridor in any other orientation causes the active vessel to fly a spiral path at significant difficulty and RCS expenditure.

1. Procedural tank parts would be AMAAAAAAAAAAAAZING! The fuel flow works on a constant fractional rate system. It takes the same time for per percent which means pushing fuel from a small tank to a big one takes a different amount of time than pulling. 2. Build-an-engine would be interesting. I think that would be a kind of open a dialog and do some editing and the part would come out. More actual parts with physics calculations is just going to slow down the game both gameplay and CPU performance-wise. 3. Indeed, actions-on-the-fly mod should be a stock feature.

It could work by assuming prograde/retrograde if your grabbed the AP/Pe markers and the normals if you grabbed the AN/DN markers. That would instantly reduce it to a 1-dimensional control based on context.

I've done tests with the Mk1 in a simple configuration: Mk16,Oct2,Mk1 and I can come in at Kerbin escape velocity anywhere in the 0-34km Pe range and only burn through about 40% of the shield. The Mk1-2 pod however I burn through the whole shield every time even for gentle 60x10 reentries (yes I know low angle is more heat). However the capsule temp peaks at ~1100 or so and I'm fine. It feels like many max temps are too low since I can reenter without a shield and just suffer the heat.

Whatever the old PID numbers are it's clear that the new SAS is just new PID numbers: static, unconsidered, one-size-fits-all numbers. One simply has to spin up a high moment craft with weak reaction wheels and hit T to see the results. You get a weak underdamped oscillation. To test the integration term one can put a slightly offcenter tiny engine and fire it with SAS engaged and see if the I term will eventually counter the torque entirely or will there be a steady state bias.

Because the trip is longer for mutli-scanning as one must conduct more orbits. He's comparing high-warp single sensor vs high-warp multi sensor.