Jacke

Out of likes again. Can't drive anywhere without an explosion or two, eh? The new buggy is definitely fasta. What do you think made the difference?

So, I'm finally finding the time to get a Caveman career started. And I'm looking into the details of it. And suddenly I understand a few of the specific things you've all be talking about. With a level 1 Astronaut Complex, you can't EVA except on the surface of Kerbin. So that's why you have Kerbals "ride ladders" so they're already out of the pod. So, how well can you transport these ladder riders?

Oh, yeah. Approximately 3500 m/s to LKO, 900 to 950 m/s for TMI, 300 to 350 m/s for MOI if going into MOI. For return missions, another 300 to 350 m/s for TKI. If you're aiming for a polar Mun orbit, you need another 150 m/s delta-V for the half-way course correction to aim for a Mun polar pass.

I know they are called "fictitious" forces but they are quite real in the rotating frame of reference. It's the rotational analogy of Einstein's Principle of Equivalence. And maybe even more real than that. Try reading the Wikipedia article on Mach's Principle. Thanks.

SDHI SMS v4.0.1 is already on CKAN. It just has a version typo, being marked for KSP 1.5 rather than KSP 1.6 (which I'll raise as a CKAN issue to resolve). Just add KSP 1.5 as a compatible KSP version in the CKAN client and refresh and you'll be able to install it. KSP since 1.5 has had few breaking issue and most mods for KSP 1.5.x (and 1.4.x) will work on KSP 1.6.1.

CentriFugal forces and accelerations Fling away from the centre. CentriPetal forces and accelerations Pull towards the centre. Centripetal forces in astrodynamics are gravitational forces, so they're in the non-rotating frame of reference, that of the planet if it wasn't rotating (or the distant stars). Centrifugal forces don't appear to have any source (let's no bring in Mach's Principle, things are complicated enough already), so they're in the rotating frame of reference, that of the rocket itself. I'm going to have to think on this one. Will have to go back to the basic problem and physics first principles. What parameters of the coasting ellipse are available from KOS ?

Looks like you've got a good approach. It's important to remember that centripetal acceleration is in the unrotated frame of reference, as in a frame of reference rigidly attached to the planet. There, the centripetal acceleration is due to gravity and the rate of angular rotation of the rockets velocity vector due to that is reduced by moving faster. This is case where I think with these methods, things are better understood in the rotating frame of reference, one attached to the spacecraft. There you have the centrifugal acceleration caused by the horizontal velocity of the spacecraft as well as the acceleration of gravity down opposing it. There's also the Coriolis force that provides sideways acceleration and the Euler force due to the change in angular velocity and in the opposite direction, but hopefully both of those will be small. Moving the viewpoint between the 2 frames during any investigation has to be done carefully, but this approach can help get simpler formulae to manipulate. Unfortunately, the Wikipedia articles are rather thick with vector math and thin on diagrams.

Not when there's bugs to find (found another...).... And over to @X Sonic Pro X....

'Fraid not. @Triop, once more, with feeling!

In my settings.cfg, I've got this, which I think is default for KSP 1.6.1. PHYSICS_FRAME_DT_LIMIT = 0.04

Before even Gagarin flew into space. 1960. As was I. My parents had me in their mid to late 30's, so it was age that took them. Still hurts and I still feel their absence from time to time. Oh, very much so.

R.I.P., Bill. You drove Bugger all well. Damn, already 2 KIAs. I've heard that we still need some sort of loading stabilizer, like @whale_2's WorldStabilizer. "And here's the Astronaut Complex. Normally buzzing with the sights and sounds of Kerbals veteran and recruit planning and training for new missions. But today, for unknown reasons, eerily quiet and empty."

@linuxgurugamer, if it's a MM script, could you post your workaround patch? I'm wondering how this interacts with @taniwha's Custom Bulkhead Profiles. Especially @4x4cheesecake's workaround above.

Wow, @Triop, you're a lot older than I thought you were. I do kind of understand your dilemma. But I'm in the opposite place. My parents are both gone and I have no close family. And I didn't have any children and it's very unlikely I will. This is an ache all its own. Fortunately, I don't think of it that often.... There are many that are worse from around the same time. I dislike them so I won't make us all more miserable than we already are. But, hey, I tracked down issues on 3 mods today and reported them, even posted a fix for one, and dealt with an irritating config issue as well. So slowly we make the world a better place.

Need more details to help here. See the red labelled link in my signature. However, there were issues with Module Manager 4.0.0 and 4.0.1. Try either downgrading to 3.1.3 or upgrading to 4.0.2 and see if that fixes things.

Hiss!!! Hmmm.... @Hotel26 ?

Out of likes again! Whoa! I watched the flip sequence a few times. Just over a gentle crest, the back end bounces up twice. On the second one, while the rear wheels were off the ground, the left-front wheel comes up a bit. Then the rover pivots to the right as only the right-front wheel was in contact. When the left wheels touch down, the rover is going sideways and the contact drag has it flip and tumble. Fortunately ending upright. Looks like @GDJ and @Hotel26 were both right. Perhaps you need to soften the suspension and put some fins on, especially fins and a spoiler to keep that rear axle down. And paint it red. Because red ones go fasta!

I had to correct my approximate formula for A0 above. Forgot to square one term and square-root another. All of this is very approximate. To solve this exactly, it's a power track--an accelerated trajectory--and to solve that to a high degree is best done with a Lagrangian method. Which I was introduced to reading Von Braun's The Mars Project. (And even he only did it for the long burn in the Trans Mars Injection, to get the angle around the Earth of the burn to set the lead to get the right ejection angle.) That was a long time ago and I'm quite rusty with the math. I think more approximate methods will work here. Since we're working in the frame of the rocket, it's a rotating frame, so it means it's centrifugal acceleration. And you're right, it will be a factor. Think of the vertical acceleration component. We want that to change the vertical velocity to zero over the burn. In the rotating frame, there's the local acceleration of gravity down, g. And the centrifugal acceleration, ac, is up, h^2/(r0 + A), where h is the instantaneous horizontal velocity, r0 is the radius of the planet, and A is the instantaneous altitude. g over the period of the burn will be roughly constant. (r0 + A) will change little. The centrifugal acceleration will increase as h^2 increases. The thrust of the craft will change, but hopefully not much. That means the total acceleration doesn't change much. And because the burn is at mostly shallow angles, that means the horizontal acceleration doesn't change much. What will change is the vertical acceleration, as the centrifugal acceleration will increase. The plan for the burn is for that vertical acceleration to be about constant, which means as the centrifugal acceleration goes up the rocket will have to pitch down. I think the autopilot mods set this up and then use a PID to drive the numbers at a steady rate towards the goal values at the right time. For your case I think you can calculate the angle at burn start and the angle at burn end and just pitch the spacecraft through that angle. angle start = arctan ( (av - g + (h0^2 / (r0 + A0))) / ah) angle end = arctan ( (av - g + (hc^2 / (r0 + Ad))) / ah) where av is the roughly constant desired vertical acceleration, g is the local acceleration due to gravity, h0 is the initial horizontal velocity, hc is the desired circular velocity, r0 is the radius of the planet, A0 is the initial altitude, Ad is the altitude of the desired orbit, and ah is the roughly constant desired horizontal velocity. And here's how to calculate the local g, where g0 is the g at the surface of the planet. g = g0 ( r0 / (r0 + A) )^2 And I hope this is a little less murky than muddy water.

Have you even taken the more direct from KSC to the west coast, about WNW? Or is the ground just too rough at too many places?

If you want help, you have to give us more than that. Following the red labelled link in my signature for troubleshooting instructions. A description of what you do when starting and running the game, what the game does, and sharing the logs on a file sharing site are almost certainly required for help here. That link will tell you how to find the logs.

Assuming you're trying to circularize at 100km, that's 700km semi-major axis (SMA), ie. the altitude of the desired orbit. So your +800m high and 1500m low are about 0.1% to 0.2% error. I think to get closer, use the best estimates to get the start of burn, but then split the problem into components: the vertical SMA and velocity and the horizontal velocity. You want to zero the vertical velocity component at the desired SMA and change the horizontal velocity to the circular velocity at that SMA. That's why the spacecraft angles down, to decrease the vertical velocity to zero at the SMA altitude and increase the horizontal velocity to the circular velocity. Figure out the component accelerations to do that. '0' indicating start of burn, '1' indicating end of burn, and 'd' indicating desired, given vertical velocity v0, altitude A0 and Ad, horizontal velocities h0 and hc, and burn time dt, find vertical acceleration av and horizontal acceleration ah av = v0^2 / (2 ( Ad - A0)) - g ah = (hc - h0 ) / dt And av^2 + ah^2 = ( (2 Thrust ) / ( m0 + m1) )^2 The last is a linear approximation, but I think it'll get low error as long as the burn's not too long and the change in mass too much. Take all those and solve for A0, the altitude at which to start the burn. A0 = Ad - ( (v0^2) / 2 ) / sqrt ( (2 T / (m0 + m1) )^2 - ( (hc - h0) / dt)^2 ) Calculate av and ah and then get the angle from angle = arctan ( av / ah ) You perhaps should put in an override to cut throttle when vertical velocity is zero. The orbit is circular at that point.

dT = (Mass * ISP * 9.81/Thrust) * (1-e^(- dv / (ISP*9.81))) That minus sign in the exponent is vital. Else the formula will return too low a value. That's the scalar burn time. You have to do the vector math of the velocity subtraction to get the vector dv and thus the angle down for the burn.

Dude, you have got to document this in a Mission Report topic of its own, like @Triop does. https://forum.kerbalspaceprogram.com/index.php?/forum/51-mission-reports/

That back end gets a lot of damage. Perhaps the rear wheels should have been a touch farther back?

That's interesting. I decided to switch to using TextureReplacer to replace the navball texture. At some KSP update this mod will stop working and TextureReplacer is maintained. The current TextureReplacer is also on CKAN. There's instructions lower down in the first post of the TextureReplacer topic telling how to place the replacement textures. What's really good with this topic is the second post is a library of navball textures. I think most of the links still work. I suggest downloading the ones you like and switching to TextureReplacer.