steuben

You are moving too fast. The non-drogue chutes are usually safe to deploy at around 300 m/s. You can read the speed off the top of the navball. By default in the bottom center of the screen. If you're moving well beyond that speed you can usually scrub off a fair bit of it by tumbling. Or slap on some drogue chutes, they have a higher speed tolerance, in around 600 m/s iirc. As for it being the way that KSP should operate... yes it is. KSP isn't as simple as some space video games that most people come from player. But, it ain't like MS Flight sim or X-Plane either. It has a steep learning curve with few guardrails. But, once you learn it you appreciate the lack of guardrails.

In no particular order: CHON FE SI KA NA CA AL MG TI

Massive ships tank frame rates on liquid helium cooled rigs. Something about Math! and Physics! Have you tried interplanetary with smaller craft?

Odd that it is crashing on launch. Have you tried reinstalling, or the PS4 equivalent? Poked around the console support threads?

To expand on why it is very unlikely, never is a word used more frequently than wisely, to be added to stock KSP requires the invocation of that dreaded, for some, topic Math! The first and minor aspect is that a planetary system is one of the classic examples of a chaotic system. Over geologic, and even non-geologic, periods the bodies _will_ wander by a lot. This is why you may have heard of the phrase geologically stable orbit. Or at least something like it. For example the Moon, the Galilean moons, and the planets have geologically stable orbits. But step out side of that the orbits will wander. The Ancient Greeks called them πλανήτης, not for that reason but it was apt. If you try any simulation of something with n-bodies (excluding n=2) you will rapidly end up with radically diverging progressions even for very slight changes in initial conditions, and even with the same initial conditions. One of the main definitions of a chaotic system. The second and major aspect is that the number of calculations goes up with the square of the number of bodies, or near enough that it make no difference. Every body in the simulation interacts with every other body. And digital electronic computers, or their cores, have trouble doing more than one thing at one, though they can fake it really well. Your processing time per cycle will rise _very_ quickly for each additional body added. Start factoring in floating point error and things get very... interesting, very quickly. Sure you could add in a "calibration period", but the you have to figure out how to deal with "orbital snap"

KSP the OST! Merch!

Doing some quick calculations. Yes. It would appear working through the Laplace space, the transform of the double integral that takes acceleration to distance is F(s)/s2. It really doesn't do much for that product term however. In Laplace space that turns into Y(s)/s * Y(s)/s * Y(s)/s2. There might not be much for it. The mechanics of analog computers can handle it. But, I'm still rummaging for a method of mathing it away, or into a much more tractable solution. Part of the reason why I'm doing the work on this tarball is to add some solid background notes for my Greenfields series. Which runs from a tech level equivalent to 1950s to early 1970s. So electronic digital computers like we know, are rare, _expensive_, huge, and slower to solve a problem then a pencil, paper, and three books of look up tables. The other part is those who forget their technological history are forever doomed to recreate it.

When playing the game, I tend towards asparagus staging for the to-orbit lift, with a tendency towards IRL design philosophies. But, when I'm playing with the game it tends to be anything with a TWR greater than 1.5 and enough dV to get it there.

I had the same thought in the shower the other day. But, for different reasons. I've been reading some old electronic analog computer manuals. They say avoid derivatives like Da' Covid. I'll have to try the Laplace using y'' as the "solving" variable. This may solve the first sticking point of having to haul around and work with the first derivative of the Transform to find the solution. My naive check is that I would end up with F(s)/s2. But, I'll have to sit down with the raw definition of the Laplace transform to confirm. Unless somebody has a better table than the first thirty odd links in google.

You only need to scan if you want to get ore and/or fuel quickly. If you just want to plop down a base you can skip that step. But rough tutorial can be found here:

Given you're running through steam. I think you should be able to post the craft file as well.

My little kerbal computers are complaining about some of the calculations I'm asking them to do. Bunch of whiny little It is not without some justification. So I'm trying it to show them it can be done. The ideal rocket equation is good for spherical cows. But, they're not working with such creatures. Starting with: m(t)y''(t)=FE(t)-FD(t)-gm(t) m(t)=MD+MF-int(0->t)MR(t)dt =MD+MF-MRt assuming the throttle is constant FE=(((FV-FS)y(t))/yV+FS)T(t) =((FV-FS)y(t))/yV+FS assuming full throttle all the way FD=CDARS/(2yV)y'(t)2y(t) FE engine force FD drag force MD dry mass MF mass of fuel MR fuel burn rate yV altitude of vacuum FV vacuum force of engine FS sea level force of engine CD coefficient of drag RS atmospheric density at sea level Running everything in I get the monstrosity of (MD+MF-MRt)y''(t)= ((FV-FS)y(t))/yV+FS + CDARS/(2yV)y'(t)2y(t) Which looks to be a good reason why the Good Lord Math! asked the Good Lord Electronics! for the miracle of the electronic analog computer. But trying to find a solution that doesn't rely on numerical processes, I collide with a couple of sticky points in the math. Though it maybe because the math was long ago, and half forgotten. My reflex is to try and run it through the Laplace transform. The two sticky points I have are: 1. La(ty''(t)) -> d(s2Y(s))/ds = 2sY(s)+s2d(Y(s))/ds which looking down the road a bit might give me trouble. I think I may have to invoke some matrix math with this portion in the mix. 2. La(y'(t)2y(t)) -> sY(s)*sY(s)*Y(s) the convolution of the three functions... I think. Which is just as problematic and ugly. I vaguely recall that the transform of a product is a convolution and vice-verse, but I could be wrong. The math here one of the two reasons that rocket science is hard. Have I mucked up anywhere obvious? Any possible solutions to those Laplace transforms? Leaving aside the fact that if I run t too long I end up with negative mass.

Quick answer: You strap them to the top of a rocket and fly them there. And if they don't make it, add more boosters. The wiki has a tutorial: https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Building_a_Lunar_base Though I wouldn't recommend going with trying to keep things looking like real life equipment until you can do it.

Just to clarify, does it crash or does it hang? And your various drivers are up to date?

Define super heavy.

I've used OBS for the capture, and Adobe Premiere for the edit. Capture I think is a pretty limited pool. The editing though had a number of available options at a number of available price/difficulty to obtain options.

Get a kerbal to Eeloo and back using only level 5 tech.

1. Binky 2. DoB (_D_una _o_r _B_ust) 3. DLS (Duna Lifter Series) 4. Steve

Looks too much like something designed for equipment from the turn of the century. Can we have the option to change the theme so that those of us with real screen sizes and decent resolutions use them.

I'm going to generalize from youtube to video in general. 1. presentation. how are you presenting? dry prof? excited frat-bro? something in between? the presenter/narrator is as much of a character as anything else. 2. scripting. how tight and flowing is the script? a good presentation can save a bad script. but a good script makes everything easier. 3. story. yes this is part of scripting but does need to be mentioned separately. even if it is non-fiction you have to weave a story to keep people coming back. As for what would be interesting? dunno, what do you find cool and exciting?

for the moment yes.

Try rebuilding it with _pure_ stock parts and see. But, rebuilding the craft is probably the quickest and simplest way to fix it. The only other way is to go in and hand fix the craft file.

I used to get the problem in some of the earlier versions. Haven't seen it in a while though. Which version are you running?

They can have it in mind, and I'd put a dolla' on the pickle barrel that they do. But, there are two reasons why it is difficult, even for non-console folks. 1. MATH! 2. computer SCIENCE! But as the king of all sciences MATH! is the biggest reason why it is difficult.

Experimental Aircraft Design 108, Flight Designation: Pocket-108 Pocket-108 was an experimental design to prove the concept of a craft that could reach low Kerbin orbit with part of the launch path as a conventional aircraft. The one-oh-eight never proceeded further than the experimental design stage. However, many of the later spaceplane designs can find their roots in the one-oh-eight. Seen in Chapter 35: Unproven. Experimental. Prototype.