[Eve terminal velocity charts]

On 1/31/2024 at 9:26 PM, rogerawong said:

The Kerbin wiki has a terminal velocity chart that gives you a rough yet practical and useful sense of the relationship between air resistance and altitude. 

Rough is correct, for reasons mentioned above.  Terminal velocity is dependent not only on the characteristics of the atmosphere, but on the characteristics of the craft, and can change dramatically over the course of the flight (as a case-in-point, this is how parachutes work, though I admit that I do not know whether this is how their simulation works in the game).

On 1/31/2024 at 9:26 PM, rogerawong said:

So I went looking for the terminal velocity chart for Eve, but didn't find it in the wiki, despite many old articles referencing it. Old articles got me thinking "I bet it existed at one time". And so it did. About 9-10 years ago, the Eve wiki page had a terminal velocity chart. And then someone unceremoniously and without explanation, deleted it.

I can give you an explanation.  That chart was an attempt to provide information that would be useful to players who had to work with few mods, few stock indicators, and a weird atmospheric model.  None of those things is still true.  It comes from this challenge:

If you're not familiar with the Goddard problem, the short version is that it is an efficiency problem.  The slightly longer version is that it is the question of how best to control a rocket to get the most altitude out of its propellant while taking into account the drag and atmospheric characteristics.  It's of practical use because more efficient control means getting more out of a given load of propellant, but because of the reasons mentioned above, it's very specific to a particular rocket in a particular atmosphere.  It's also only useful for a particular trajectory:  straight up.  Reaching maximum altitude is rather useless when the goal is to achieve orbit:  the principles are different and the optimum solutions have almost nothing to do with one another.

That being said, KSP is great for simulating these kinds of problems because it offers true reproducibility.  It's also terrible for getting practical results from simulating these kinds of problems because it's not simulating other real concerns such as unavoidable variations in manufacturing the rocket, changing atmospheric conditions, or a fully-accurate aerodynamic model, among other things.

However, at the time that it was made, that chart did provide some useful information.  I'll provide details in the spoiler, mainly because it discusses completely outdated game mechanics and I don't want to create confusion.

Spoiler

At the time, KSP calculated drag with a modified version of the drag equation:

F_d = 1/2 * C_d * m * ρ * v²

Where:

F_d = drag force
C_d = drag coefficient (though described in-game as a parameter maximum_drag, which may have mattered)
m = object mass
ρ = atmospheric density
v = velocity

For illustration, the real version is this:

F_d = 1/2 * C_d * A * ρ * v²

Where A is the cross-sectional area of the object facing towards the direction of travel.  The other parameters are the same.

I really don't have time to describe in detail how wacky the KSP version was, but for example, it meant that a part with twice the weight experienced twice the drag if all else was equal, and if you're not familiar with aerodynamics at all, then please understand that there is no reason why this should be true.  This led to interesting behaviours such as full propellant tanks falling at the same rate as empty ones when in an atmosphere, because terminal velocity is simply that velocity where weight equals drag.  If both depend on mass, then the mass cancels out and the terminal velocity becomes a function of only the local gravity and atmospheric density.  Because area was not part of the calculation, it also meant that rocket profile meant nothing:  there are old pictures of pan-shaped rockets flying just as well as needle-shaped ones.

There were other wacky things in the simulation, too, such as the fact that engines operating in an atmosphere would consume more propellant rather than lose thrust, and the less said about the semisolid slurry that passed for an atmosphere, the better.

Anyway, the important part is that this silly mass term made a number of calculations absurdly simplistic.  The optimum ascent profile in terms of drag is one where the drag force equals the force of gravity (mathematical proof here, but the general idea is that for the least amount of propellant expended to gain altitude, you want your engines to fight drag and gravity equally, and the velocity where that happens is equal to the terminal velocity--but in the opposite direction, of course), but when drag is calculated from the mass and ignores cross-sectional area, the masses cancel out and it all simplifies to TWR = 2 in all cases.

In such a circumstance, a terminal velocity table makes sense, especially when you're using a navball that doesn't show TWR, and velocity is the only useful indicator that you have.  Remember, this is when people were playing KSP with spreadsheets, not Kerbal Engineer.  The table isn't really meant to convey terminal velocities as the useful part, but rather to convey those velocities (and altitudes) that indicate a TWR of 2.  If you follow the table and hit those velocities at those altitudes, then you are staying close to the magic TWR = 2 and thus have an efficient ascent.

Now, drag accounts for cross-sectional area, at least somewhat, and doesn't include mass.  There are still problems with the aerodynamic model, but it is worlds better than it used to be.

However, the table is still no good.  Terminal velocity gives an efficient ascent profile for going straight up.  Once you deviate to the horizontal, it's no longer the optimal solution, but you must deviate to the horizontal to achieve orbit efficiently--as I mentioned above, the Goddard problem and orbit are two different things.  Terminal velocity also no longer correlates directly to thrust, because the area of the rocket matters now.  So do the drag coefficients of the front-facing parts:  once upon a time, people didn't use nosecones because the extra mass made the rocket less efficient both in delta-V and drag.  Now, nosecones are almost required for atmospheric flight, albeit there are exceptions.

The point is that because the drag model takes into account specific properties of the individual rocket, the terminal velocity changes with the rocket and cannot be generalised very easily.  There are some general rules that can apply (similar problems in getting to orbit from Eve breed similar solutions), but there are also new mechanics that override those rules.  For example, it is often necessary to limit thrust and speed on Eve because overheating is a problem on ascent (it's a problem for descent, too, which is why you'll see powered Eve landers), and if the overheat speed is lower than terminal speed, then you're not going to reach terminal speed.  It doesn't matter that it's efficient if it's not available to you.

That being said, I think that this is actually a very interesting piece of KSP history, because this is from 2012 and people were still trying to figure out the mechanics of the game (and for a lot of them, spaceflight in general).  Have a look at these cutting-edge graphics:

Note the lack of lights, gear, and abort action groups.  Also note that SAS was in the staging and had a finite capacity.  Note the lack of info panels and KSPedia.

Suffice it to say that there once was a time when people got to orbit by launching straight up and out of the atmosphere, then turning over and burning horizontally to make orbit ... hopefully before falling back into the atmosphere.

At the time of this challenge, the atmospheric model was something like ten times more dense than what it ought to have been.  Eventually, people settled on a hybrid approach to ascend in something (very) roughly approximating a gravity turn.  What you see here is some of the experimentation that the players performed on their own to try to figure out those optimal ascent and control profiles.

The terminal velocity table came from that.  It worked at the time, so it made it into the wiki.  After version 1.0 and the new model, someone noticed that a table of terminal velocities and altitudes no longer made sense for general use.  It's not a matter of updating the table with new values for Eve:  general values simply don't exist.

On 1/31/2024 at 9:26 PM, rogerawong said:

So, what would the equivalent of this be in modern times?  I'd like to add this back to the wiki. I found it useful for Kerbin. It would likely be helpful for Eve.

An atmospheric density table would be nice, but density varies with temperature, which varies a lot with latitude and time of day, as well as altitude, so a table probably doesn't make much sense compared to an equation, or at least an algorithm.

More pragmatically useful would be a list of good landing locations that combine high-altitude plateaus for launch with proximity to multiple biomes for research.  Eve's rotation period is nearly four (Kerbin) days, so there isn't much to be gained from landing at the equator (55 ^m/_s of eastwards rotational velocity instead of Kerbin's 175 ^m/_s), but landing four kilometres above sea level is useful to avoid both the density and the heat of Eve's lower atmosphere.

There is the idea that, given Eve's greater and more constraining challenges, the kinds of rockets needed to ascend from Eve's surface will be much more generally similar than the many and varied vehicles that come from Kerbin.  In such a situation, you can make simplifying assumptions about the nature of these rockets to get a generally applicable range of solutions to the optimal ascent problem.  However, those solutions are still dependent on the type of rocket, not on the planet itself, and so still wouldn't really fit on the wiki.

But if you wanted to make a tutorial thread, however, then that would be a fantastic idea.

[KSP fun fact thread]

On 10/9/2023 at 4:31 AM, Duke MelTdoWn said:

Did you know there are 32 mini biomes around Kerbal Space Center, not only the Runway and Launch Pad?  [. . .] Some biomes only become available after you upgrade the building.

I'll toss one on:

One of these mini-biomes becomes unavailable after you upgrade the building.  The tier-2 VAB has a group of buildings called the VAB South Complex:

Spoiler

The South Complex is composed of the three arch-roofed hangar-like buildings between the main VAB building and the Tracking Center.  You can see two of them clearly on the right side of this picture, with the third building partially visible.

The fun fact is that upgrading to tier-3 adds some new miniature biomes to the VAB, but removes the South Complex, which makes this the only natively permanently missable science content in the game.  Everything else either remains available (as in the other biomes and World's Firsts rewards) or else is repeatable (as in contracts and asteroid science).  Granted, available must be taken with a grain of salt, because I believe that would technically include such absurd situations as Landed on the Sun, but I believe that there was a quality pass a few years ago that finally removed that one from the list.

Anyway, it doesn't amount to much, but it does serve to filter the unrepentant completionist players from the rest because they won't upgrade the VAB until they've unlocked. Every. Single. Science. Experiment. In the game and retrieved all of that delectable, collectible science from the South Complex before it goes away forever.

Yes, this means grinding away without custom action groups until unlocking that elusive Tier-8 tech tree node for the silly gravioli detector.  Good luck if you're using mods that add science experiments and science parts elsewhere in the tech tree.

[First (ultra basic) station - tips/feedback?]

18 hours ago, Anaxagoras said:

For instance, is this OK for docking port placement, reaction wheels, and RCS?

You may be better off sticking to standard ports for traffic, Sr. ports for station expansion, and Jr. ports for nothing if you can avoid it.  That's purely up to you, of course, but it reflects my usual procedure (it prevents confusion--I won't say that I've never used them and never will, but I do try to avoid it).

You don't need that many of them, either.  Let's say that you go with the full kit and eventually you have a dedicated transfer vehicle to go to the Mun, another to go to Minmus, an emergency re-entry vehicle to evacuate the crew to Kerbin, a passenger- and cargo-rated vehicle for surface-to-orbit-to-surface traffic, and an RCS docking tug for handling station expansion modules:  that adds up to an extremely fancy and well-equipped station that needs only five docking ports, of which you're regularly using only two (Kerbin surface-launched traffic and a moon transfer vehicle), and at least two of which are for redundancies (emergency return and a second moon transfer vehicle).

It might not be a bad idea to eliminate one ring of ports and move the solar panels to where the ports used to be just to better avoid trouble with collisions and the shadows of any docked vehicles.  You've already said that you're not fond of docking, so I imagine that breaking solar panels while trying to dock would be extra frustrating.

You may want to exchange the retractable (SP-L) solar panels for the non-retractable (OX-4L) ones; that will save a bit of mass and cost.

You don't really need RCS on this; other things dock with it, but it doesn't dock with anything.  Keep the monopropellant tank, but only for a depot.  Maybe only fill it one-quarter of the way, too:  you won't run out any time soon.

You may want more battery, especially with the big 2.5m reaction wheel.

Hitchhikers don't provide control, but I see that you have a probe core on it.

A probe core will be fine, and you don't need one with normal hold:  you can orient the station yourself and use stability assist instead.  You'd need to do that or something similar anyway, because you'll need to set the port you want to use to 'Control from Here' to get the navball markers in the right places.

All told, this is a good first station--albeit a little ambitious with its docking capacity--but ambition is a good thing in this game.

 

Good luck!

[S-wing drag]

21 hours ago, miklkit said:

Is there a source that lists the proper drag values?

Look at the delta.cfg link in the infobox to the right of the wiki page and it'll tell you more.  The maximum and minimum drag values in the file are .02, but there's an angular drag value of 2, and a value for drag that varies with the angle of attack between 0 and .6 in ModuleLiftingSurface.

Whether those figures mean anything to you is another matter.  If that's not what you want, then you might be best off looking at modder resources:  modders who make wing parts need to make their wings perform predictably in concert with KSP stock wings, so seeing what they're using to do that (and how they're comparing their parts to stock parts) might be of help.  The mods themselves might also be instructive:  B9 Procedural Wings comes to mind as one that not only properly has to account for drag, but must do so on the fly, to coin a pun.

Good luck!

[tips on docking?]

10 hours ago, Dunas Only Moon said:

i need help on docking for the first time in console ksp... any tips?

I'm going to assume that you're good enough with rendezvous to reliably get good close encounters and only need help with docking, itself.  I'll not parrot the standard advice that you can find most anywhere, but will instead share a couple of tricks that I've learned over time:

• Docking ports generally only engage when your closing velocity is less than .3 m/s--that's 30 centimetres per second.  You need to drift--with purpose--but still drift to dock.
• If you put your docking port on the front or side of your vessel and approach from zero relative inclination, then depending on how slowly you perform the manoeuvre, you may find that the circular path of the target vessel's orbit has rotated the target port away from a good angle by the time you reach it.  You can do one of two things to help with this:  you can learn to drift quickly, or you can use reaction wheels on the target to orient the target port to normal/anti-normal and approach from above/below.  Orbital rotation will then merely spin the target port round, not turn it away from your port.
• For learning, it's okay to be generous with monopropellant and attitude thrusters.  Efficiency can only reliably come with skill, so learn the skill first.
• I play on PC and thus have access to the alternative translational controls for the attitude thrusters, but I think that on console, you are stuck with docking mode instead.  I don't know the way to get to docking mode on console, but I will say that translational control is much more important than rotational control for docking.  This is another reason to rotate the target so that the docking port is aligned with the normal axis:  you can rotate your vessel to face normal while still somewhat far away from the target port, and then switch to docking mode and use the translational controls to bring your vessel in to dock.
• Precision control mode (accessed on PC with CapsLock--I hope that helps you find the appropriate control for console) is, if not absolutely necessary, then certainly helpful.  When it's active, the roll, pitch, and yaw indicators on the lower left of the screen are blue instead of orange.  You don't need power to dock; you need precision.  The best unsung feature of precision control mode is that it balances the thrust output of your attitude thrusters to keep your vessel aligned.  This alleviates any balance issues that come from not having the jets positioned equidistantly from the vessel's centre of mass.
• Lastly, if you need to practise docking, then you should consider sending up a set of docking trainers.  These are little tugs with a probe core, monopropellant tank, attitude thrusters, docking port, and only the minimum necessary hardware to power and control them.  They're cheap, highly manoeuvrable, and a lot more forgiving than your 3-million-Funds orbital station.  If you send them up as a set of two, then you won't need to worry about rendezvous, either; simply undock, re-dock, and continue doing so in various situations until you're comfortable with the process.  If you break one, then de-orbit and try again.

I hope that helps.

Good luck!

[Not getting full science points]

2 hours ago, alfrank said:

Where do I find R$D?

On the main KSC screen, it's the complex that touches the VAB and the Astronaut Complex.  Here's the relevant wiki article:

https://wiki.kerbalspaceprogram.com/wiki/Research_and_Development

It's the same place where you research upgrades and new parts, but the archives are there, too, and you can select them with the button at the top left once you're in the tech tree.

On 7/24/2023 at 7:21 PM, alfrank said:

So when I run science jr while in orbit it says I have 25 points for that experiment. But when I recover the vessel I only receive 8 points

On 7/24/2023 at 7:38 PM, alfrank said:

just tried again and this time I earned zero science

22 hours ago, alfrank said:

Perhaps it was a spot where I ran the experiment before?

Almost certainly it was.  What you describe is the diminishing return of a science experiment run twice (three times, actually) in the same location.  When you're orbiting in Kerbin 's Low Space, the Science Jr. has a total of 32 base Science points available (with normal difficulty settings), but only allows you to recover 25 of those on the first run of the experiment.

The game then uses that fraction, 25 / 32, for each subsequent run of the experiment.  In this case, it's approximately 78%, so what that means is that every run of the Science Jr. in a location where you ran the experiment before will recover only 78% of the remaining Science.  The first time, you get 78% of 32, or 25 Science points.  That leaves 7.  The next time you run it, you get 78% of the remaining 7 Science points.  It goes to zero fairly quickly; as you discovered, there's not much point to running the Science Jr. a third time (at least, not in Kerbin's orbit; some places with very high science multipliers do make a third run worth a try).

Every experiment is different:  some give you all of their Science the first time.  Some give you less than 78%.  Some give more.

If it told you that you had 25 Science points coming to you, but then only awarded 8, then my guess for what caused that is that you had another Science Jr. that ran the same experiment in the same location, and you recovered it before the module that only gave you 8 Science.  That happens especially when you have both experiments flying at the same time:  KSP tells you that both are worth 25 points, even though only the first one is, because you haven't yet recovered either one and so it's not set in stone yet.

8 is a weird number to receive; 78% of 7 points is closer to 5.5 than 8.  The extra points could have come from craft recovery.

Anyway, it's easy enough of a problem to address:  run different experiments, or else run this experiment elsewhere.  If you take your rocket up to 250,000 m, then you'll reach High Space, which is a different location and for which the Science Jr. has a base number of 48 Science points (of which you should get 37.5 the first time).  There are many, many different combinations of altitude, celestial body, and other factors that affect the available Science.  Part of the point of the game is exploration, and this is one way that it encourages you to do that.

Have fun!

[KEKKJ/KEEKJ gravity assist launch window list?]

On 7/15/2023 at 8:31 PM, Eddy119 said:

I can't get the gravity assist calculators (like KSPTOT or https://kerbal-transfer-illustrator.netlify.app/Flyby) to work (or please tell me ways to calculate this).

I can at least help you with this part.  Here's a link to a relevant comment in the FlybyFinder thread by its author, @PLAD:

On 5/23/2014 at 1:09 PM, PLAD said:

Here is the latest version of my Lambert spreadsheet, I use it to test my algorithms, and to doublecheck that FF is giving good results. It can do double flybys. It is not made for casual use and is not user friendly, but you can see the entire process that FF uses, step by step. It now does 6 bodies and includes the OPM planets. If there is interest I can make a version for Galileo's Planet Pack.

https://www.dropbox.com/s/5i2foga1f2j9kq5/LambertHOPMrel.zip?dl=0

-PLAD

The link still works, so there's that.

The thing to note is that most Lambert solvers (which would be the algorithmic wizardry that makes porkchop plots and calculates flybys, among other things), cannot handle transfers that start and end at the same point.  However, this spreadsheet manages to do that by adding a way to track double-flybys through the use of orbit ratios.

It involves a lot of trial-and-error and is not very user-friendly, but in fairness, this very high-level stuff, even for KSP.

[How do I find the duration of a year?]

8 hours ago, king of nowhere said:

what does it say about me that I prefer to run that calculation rather than installing another mod?

Good things!

8 hours ago, king of nowhere said:

wait a minute, though: the formula works with distance from the center. ksp gives distance from the surface, so I will have to add the radius of the sun to r. not that it makes a huge difference

You're right!  It's been a while since I've tripped over that particular KSP quirk.  It makes enough of a difference:  the error becomes truly negligible at about four parts in ten thousand.  I've edited the earlier post to include that bit of data.

[How do I find the duration of a year?]

On 7/13/2023 at 6:51 PM, king of nowhere said:

I'm facing a very unusual problem: I can't find how to determine the duration of a year on a planet.

[...]

here i'm using another mod, i would like to know how long is a year on certain planets for the purpose of planning orbits, and I can't find this information.

[...]

I was hoping there would be a better way.

Not to cause an argument, but if @jimmymcgoochie's suggestion holds, then I didn't see a local year readout anywhere in Kerbal Engineer.  It might be in later versions, though.

To your problem, @king of nowhere:

It's Kepler to the rescue!

Actually, that's not quite true; KSP does give you some information that Kepler didn't have.  However, it's largely the same problem, so we'll solve it the same way:  with (simulated) telescopes and a lot of (not simulated) maths.

If you don't mind a bit of calculation, then here's how to derive the answer from the information at hand:

First, you won't need the parameters window for the planet.  You will need it for the sun.  If your mod changes the sun, then you'll want to find the number labelled GM.  For the stock sun, it has a value of 1.172 x 10¹⁸ m³/s².  You can find more precise values in the game files, but this works with what you can get from the Tracking Station.  (Also, if you want to figure orbits for a moon, then you'd want to get its planet's GM, instead.)

Second, you'll need the altitude and velocity values for your planet.  You can get these simply by putting the camera focus on the planet and zooming out until you can see its orbit about the sun.  For an example's sake, let's use Dres at time Y1, D01, 00:02:52:

velocity = 4,629.8 m/s
altitude = 46,499,448,126 m

Note that you will also need to add the radius of the sun, since KSP gives the altitude over the surface and we're using a formula that depends on distance from the centre.  The radius is the first value in the parameter window, so it's just as easy to find as GM.  For the stock sun, the radius is 261,600 km, which is easy enough to convert to 261,600,000 m.  Putting it together:

focal distance = altitude + radius of sun
focal distance = 46,499,448,126 m + 261,600,000 m
focal distance = 46,761,048,126 m

If your planet has a particularly eccentric orbit, then these values can change quickly.  You may be better off using Map View, where you can more easily pause the game, to obtain these values.

Next, we need to use the vis-viva equation.  Here it is:

v² = GM ([2 / r] - [1 / a])

where:

v = the velocity, which we found
GM = the gravitational parameter, which we found
r = the altitude, which we found
a = the semi-major axis of the orbit, which we need

As it is, this equation doesn't help us much.  We need to solve for a:

v² = (2GM / r) - (GM / a)
GM / a = (2GM / r) - v²
a / GM = 1 / ([2GM / r) - v²)
a = GM / ([2GM / r) - v²)

With the numbers:

a = (1.172 x 10¹⁸) / ([2 * (1.172 x 10¹⁸) / (46,761,048,126)] - [(4,629.8)²])
a = 1.172 x 10¹⁸ / ([2.344 x 10¹⁸ / 46,761,048,126] - [21,435,048])
a = 1.172 x 10¹⁸ / (50,127,191 - 21,435,048)
a= 1.172 x 10¹⁸ / 28,692,143
a = 40,847,419,449 m, though given the precision of GM, we can only commit to 4.085 x 10¹⁰ m.

If that's too tedious, especially if you have multiple planets, then I'd recommend a decent calculator, such as the ones at Wolfram Alpha or Desmos.  

Once you have a, it's a fairly straightforward matter to get the orbital period:

T = 2π √(a³ / GM), where the only new and unknown value is T, which is the orbital period--or local year, in this case.  Substituting our value for a yields:

T = 2π √([40,847,419,449]³ / [1.172 x 10¹⁸])
T = 6.283185 * √([6.815439627 x 10³¹] / [1.172 x 10¹⁸])
T = 6.283185 * √(5.8152215 x 10¹³)
T = 6.283185 * 7,625760
T = 47,914,063 s, which in Kerbin days is 2218.2 days.  This is off by just a little less than 1 day (which, at .04% error, is better than good for a single observation) and is mostly due to the rounding error, which results from the mere four-place accuracy that we get from the sun's GM.

If your mod uses the stock sun, then I can give you a better GM and radius:  the most accurate value for GM is 1.1723328 x 10¹⁸ m³/s², and the best value for radius is 261,600,000 m.  That won't help much, though:  the velocity only has five-place accuracy.

Otherwise, you'll have to use the in-game value or else look into the mod files for the system parameters.  That should be easier, though:  if your mod is configured with Kopernicus, then the planet configuration files should have a section called Orbit that lists the semi-major axis by name.  You'll still need to calculate the orbital period yourself, but that's trivial compared to deriving the semi-major axis from (pseudo-)celestial observations.

I hope that helps.

Good luck!

[What does every space station need?]

On 7/8/2023 at 5:01 AM, Space Shuttle destroyer said:

I want to make a space station, not massive just a single launch, can anyone tell me what I need?

On 7/8/2023 at 5:07 AM, James Kerman said:

Perhaps reading about the construction of the ISS may give you some inspiration.

May I suggest Skylab, instead?  I'd argue that that's much more in line with the idea of a single-launch station.

The bare minimum for a station is going to be the same as any other orbital mission, minus the provision for re-entry.  That means that you'll likely want power, either a probe core or a permanent pilot, and reaction wheels.  These are not necessary (you can rendezvous and dock whether it's powered or unpowered, but unpowered is more difficult to dock), but they are so helpful that they might as well be necessary.

That said, if you want to do anything with it, then you have a number of options:

• If you want to have a propellant depot, then you'll need appropriate tankage and a docking port (I suppose you could rely on the claw, but that's a bit later in the tech tree).  Nothing says that the appropriate tankage can't come from the rocket that put it in orbit in the first place.  You don't even need to remove the engine--though I'd suggest manual deactivation it if you keep it.
• If you want to transfer crew, then you'll need a crew module with an accessible hatch (no docking port needed; you can EVA them over).
• If you want to do orbital science, then you'll need appropriate experiments.
• If you want to process science in a mobile lab, then you'll need one of those and scientists to put in it (and a source of science, but that need not be on the same vessel as the lab).  You'll also need an antenna, battery, and power source to return the processed data to Kerbin.
• If you want to expand the station later via orbital assembly, then you may want a docking port.
• There are other things that you can do with a station, but a lot of that depends on your own goals (and a great deal on your mods if you have any--space telescopes, passenger terminals, training centres, life support modules, communications relay stations, refineries--all are possibilities).  Here's an example:  I run a station for tourists that allows me to get them into orbit using my standard passenger tour rocket, then transfer them to an interplanetary vessel that stays in space all the time, and finally a second station around the Mun or Minmus that has the landers for those who want to touch down.  That's not necessary, but it lets me run a couple of different kinds of tourist missions at once without needing to take all of them to land on the Mun.  Since I also use life support mods, keeping them in a station with overbuilt support machinery means not worrying about them using up all the air on the Mun lander, too.

Good luck!

[can't make a rendevous]

On 6/16/2023 at 10:18 PM, alfrank said:

Suggestions, tips. ideas anyone?

Others have covered the basics of rendezvous, but one thing that I wanted to bring up is that sometimes, the shield icons will go wild when you're very closely matched with your target.  If you're in nearly the same orbit, then your distance from the target is nearly constant, and something as simple as rotating in place can affect what the game thinks is your closest approach.  The shield icons can only give you a general idea and are no good for final approach and rendezvous.

There comes a point in any rendezvous when you need to get out of Map View, for the same reason that you don't use Map View when landing a plane:  you need to see details that Map View can't show you.

Another issue, which I suspect is closer to what you're experiencing, is that the shield icons represent the next two closest approaches only.  It is possible to have two close approaches on one orbit and then have a third closest approach (which is not shown at first) on the opposite side of the planet.  Once you pass the first point, the game doesn't have the subtlety or nuance to understand that you're still fairly close--it jumps to the next prediction and if that prediction is for a closest approach on the other side of the planet, then so be it.  The solution for this is, again, to ignore Map View once you're close and use other tools for final approach and rendezvous.

[Simple way to isolate a fuel tank?]

On 6/25/2023 at 6:25 PM, jnbspace said:

Is there a simple way to isolate one fuel tank so that the intact tanks don't empty themselves?

@Vanamonde has the answer:

On 6/25/2023 at 8:11 PM, Vanamonde said:

You should be able to r-click on the tank and click the tiny button to block its use. 

The original writer of the mod has a wiki that explains this, located at this link:  https://github.com/Ippo343/DangIt/wiki/Failure-modes

There's a section on tanks that tells you to click the little green icon in the tank's context menu, which is what you open when you right-click on the part (its official name is the Part Action Window).

You may have tried this before and saw that the tank kept leaking; I understand that that's how the mod works.  The damaged tank itself will continue to leak until you repair it, but by locking it, you at least keep the rest of the vessel from trying to pump more of the resource into it from intact tanks.

[Beginner and cannot progress in science/research]

On 2/26/2023 at 10:06 AM, FABIODONATO said:

I have just started KSP (shame, I know), enjoyed a lot of the trainings (until mun 1 which I find difficult). But... 

Don't worry about coming to KSP late.  Orbits are periodic, after all.  Also, welcome, new person!

On 2/26/2023 at 10:06 AM, FABIODONATO said:

I have the 3 first badges, I seem to have launched straight rockets and science things as high as I can and returned safely,

Those badges would be from the World's Firsts milestone achievements.  You do get a nominal amount of science from that, but you're right, it's not enough.  You'll need to do scientific experiments to go farther.  I will explain something that I have not yet seen other people here say, which is to tell you that, with a very few exceptions, the science experiments do not work automatically.

On 2/26/2023 at 10:06 AM, FABIODONATO said:

but cannot find how to get more research points and tech progress.

I see no guideline or challenge indication, the tech I have access to is minimal and I have no clue what to do to improve. Any help would be greatly appreciated. 

When you start a new game, the experiments available to you are EVA Report, Crew Report, Surface Sample, Mystery Goo Observation, and Temperature Scan.  Mystery Goo Observation and Temperature Scan require special science parts to be attached to your rocket; these are available under the Science tab in the VAB.  You can unlock new science parts (and thus new experiments) in the Research and Development Complex, but it requires science points to do so, so we'll not focus on that just yet.

To perform an experiment, you need to right-click on the appropriate part and find the experiment in the Part Action Window.  Note that for crew reports, the appropriate part is the crew pod or command module, and for EVA Reports and Surface Samples, the appropriate 'part' is a Kerbal on EVA.  Usually, the experiment is obvious in context (to take a surface sample, the button is the one labelled Take Surface Sample).

It may seem difficult to run science experiments while you're also flying an untested rocket.  It probably won't make you feel any better, but real astronauts flying real rockets thought so, too.  There are some tricks that you can use to make things work a bit better:

• For one, you can run science experiments right on the launchpad:  don't ever say that KSP didn't give you anything for free.  That will get you some easy science and let you see how the experiments work without needing to split attention between that and flying the rocket.
• You can open the Part Action Window on a part before you launch.  If you click the pin button in the corner, you can keep the window from disappearing when you click on something else.  This way, you can have the window open and shoved off to the side while you get the rocket in the air, and can then run the experiment without needing to find and right-click on the part while in flight.
• Experiments work in certain combinations of biomes (roughly, locations on the planet) and situations (roughly, how high off the ground you are).  Some experiments give one global result in certain situations, and some won't work at all in certain situations (there's a seismometer that won't work unless it's on the ground, and a deep space telescope that needs to be in deep space, for example).  The early experiments all give unique results (and more science points) when landed in different biomes, and most of them give unique results when flying over different biomes.  Don't be afraid to turn a rocket to the west or north to catch some of those biomes, even if only in flight.  Rovers and precision landings can wait for better rocket parts later in the game.
• Situations are considered on an immediate basis:  what that means is that an experiment that gives new results in low space will give those results if you run it as soon as you leave the atmosphere.  You don't need to be in a stable orbit.
• When you run an experiment, the result is stored in the part until it is transferred to a science container.  There's a dedicated part for that, but command pods also count as science containers.  Transferring a result to a container generally requires a Kerbal to go on EVA, so it's not advised to do this while flying through the atmosphere.  Transferring the result lets you reset the experiment so that it can be run again.  There are exceptions and caveats to this.
  • The Mystery Goo does not reset unless you have a Scientist do it, and for early rockets, you'll often have only a Pilot.
  • Crew Reports necessarily get stored in the command pod where they are generated, but the experiment storage is not the same as a science container, even though both are on the same part.  This means that you'll need to exit the pod with an EVA Kerbal, take the data from the pod, and put it back in the pod, whereupon it will go into the science container and let you take another crew report.
• Transferring data to a command pod is useful because with large, multistage rockets, the pod is often the only part that comes back:  the science parts are abandoned to burn up in re-entry or on the Mun or wherever.  However, if you're recovering the entire rocket, then you can leave the experiments in the science parts and recover the whole thing when you land or splash down on Kerbin; recovery will extract the science data from the experiments without you needing to do anything more.
• This means that if you want more science on fewer flights, it may be worth your time to attach multiple thermometers and multiple Mystery Goo containers to your rocket and run each one in sequence as you reach new situations.
• Also note that you can repeat an experiment in location/situations that you have visited before, but there are sharply diminishing returns.  Mystery Goo stops generating useful results after the third time, for example.  EVA Reports and Crew Reports give you all of the science they can the first time.
• Don't bother with transmitting results in the early game.  There is a time and place for it, but transmitting reduces the Science you can get from the experiment:  you always get the most Science per mission from recovery of the data, either from the experiment part or from the science container.

Should you have any other questions, or anything was unclear or unhelpful, please feel free to ask.

Have fun!

[Request Help Cleaning up Discarded Stage]

20 hours ago, Lemit said:

Can I attach a docking ring to the expended stage using EVA construction, dock with it, and push it back into a degrading orbit?  (assuming I can pull off the rendezvous)

Yes!  While the game tools do offer some easier options for this (such as the claw, as @Vanamonde mentioned, or even just deleting it from within the Tracking Station), this is a great way to practise rendezvous.  I will caution you to make certain that any docking clamp that you attach has its axis point through the centre of mass of the booster, if possible, or else you will get a surprise when you light the de-orbit engines.

20 hours ago, Lemit said:

For future efforts,  can I put a second command or Mechjeb on with reserve fuel,  and  fly it back to Kerbin?   I want to try to think and fly with some sense of environment conservation.  Any helpful ideas / discussions are appreciated. 

That can work, though you should be aware of which way the MechJeb module points.  Orientation is important for a probe core, and if what you think is prograde is a direction that it thinks is anti-normal, then you're going to have bad results.

If you want to pursue this seriously, then you might want to look at Stage Recovery to recover Funds.

Another option is to fly the booster into the Mun (the mod is a bit out of date, but I always thought that Impact! was a lot of fun, and Strategia, which is also somewhat out of date, has an impactor probe strategy).

If you want to try your hand at a flyback booster, then kOS is the mod for you.  There are quite a few scripts and script tutorials out there for building flyback boosters; the main problem is flying them while you have another vessel coasting to apoapsis.

Next, if you're interested in reusing the materials for some other project (and why not, since you went to the expense of getting the thing into space in the first place--David Brin's short story 'Tank Farm Dynamo' explores a similar concept, though with much harder science fiction), then you should look at Modular Kolonization System, or MKS for the ability to break down rocket parts into material kits that can be used to make other things in space.

Lastly, if you just want to blow things to smithereens without too much hassle, you have two mod options:  first is TAC Self-Destruct, which is exactly what it says on the tin, and the other is Kerbal Inventory System, or KIS, which has an explosive part that your engineer can attach to something that you would like to make go away.

Have fun!

[Free KSP2 Giveaway!]

I'm excited for bug reports, if you can believe it.  During KSP1's development, I always appreciated the interactions between the developers and the forum community, and seeing things brought up by the community be worked into the game was always thrilling--it made a person really feel like a participant in making the game better.  I found that was true even when I wasn't the one who wrote the report.

[Docking on mun surface]

8 hours ago, whiteturtle0923 said:

Is it possible to dock these 2 crafts together?

Not with that configuration, no.  The closest you can get is to land the rocket's bottom port on the rover's top port, but don't try it:  the exhaust from the engines will destroy the rover.

Usually, your best options for surface docking are, in no particular order:

1. Have ports aligned for horizontal docking (such as two rovers, or a rocket with a very low-slung port), though getting them to align is tricky
2. Use an extremely lightweight craft that can fly around on monopropellant, because such a craft will not destroy things with its exhaust
3. Use a claw (be aware that the claw, unlike regular docking ports, requires some velocity to dock, but also be aware that the resultant momentum can damage or destroy parts)
4. Use a mod
5. Don't surface dock (you can refuel in orbit)
6. I don't know what your engineer's capabilities are, but you may be able to move your docking ports to a more accessible orientation.  This one may tie into 4, above
7. If you have Breaking Ground, you can try a robotic arm, assuming that the crossfeed rules let you do this.

[Where is the Duna SSTV signal thing?]

On 12/27/2022 at 12:59 PM, cebu516 said:

kerbal maps is down

There is a 'temporary' Kerbal Maps (that has proved to be more or less permanent) that I normally would be happy to link for you, but although the original made was presented as an add-on and only accessed information that was available in the public API, I couldn't find a licence for either it or the temporary version.  I do not know whether it is authorised officially, and I don't want to fall on the wrong side of infringement.

If there is an official opinion on that, any mod watching is welcome to share.

On the other hand, there is a thread on this forum that links to it, and it was commented on with approval by a moderator (who is no longer a moderator, but was one when this was posted), so I'll link that, instead.  Here it is:

 

[I think this mission is not possible to complete]

11 hours ago, Superfluous J said:

I'm not 100% sure you are given the tools to do that.

Does the game tell you over where on Duna you have to put the Stationary satellite, BEFORE you accept the contract? I don't know for sure but I don't think so.

The Tracking Station shows the locations and orbits and such for proposed contracts.  I believe that that extends to placing a marker on the point on the ground that is supposed to remain in view of the satellite.  I don't know the extent to which this is affected by the Tracking Station upgrade level, but a fully-upgraded Station should tell everything that you need to know.

11 hours ago, Superfluous J said:

Sure, you could just never take a Stationary contract at Duna, in case the location was under Ike.

That said, this is probably the best option in terms of a long-term solution:  you either know that Ike is in that orbit, or you'll certainly find out.

8 hours ago, Leganeski said:

You could even just move Ike to a different longitude (something like "@meanAnomalyAtEpoch += 1"), which would make the contract possible but maintain the usual complications of Ike being in an unhelpful orbit.

True.  Or you could just move the contract target area to the other side of Duna.  My point was more about the fact that there's no way to salvage this contract without some kind of save-editing, and less about the practical complications of how to do so.

8 hours ago, Leganeski said:

On the flipside, you'll often get contracts that are easier to complete because of a technicality in the fine print. For example, the "extract ore from Eve and deliver it somewhere else" contracts don't require the ore you complete the contract with to be the same ore that you mined on Eve. You can mine the ore on Eve, immediately jettison it, do the already difficult ascent without extra payload, and then just get more ore on Gilly or anywhere else.

Also true, and hilarity can often ensue.  We've had a few people in here who asked how they were supposed to lift hundreds of tonnes of Ore to Eve orbit, and I quite enjoyed the facepalm moments when they were told, 'Don't bother.  Use different Ore.'  Technicalities are important:  'Test Launch Clamps on the Launchpad' is a lot easier than 'Test Launch Clamps in High Orbit', but for a while, anyway, both were potential contract offerings.

[I think this mission is not possible to complete]

13 hours ago, kiel814 said:

As far as I can tell, there is no way to be on that orbit, above that point and not be in Ike's SOI... So is there a way to complete this mission?

There is a way, but it is absolutely cheating.

Spoiler

1. Install Kopernicus.
2. Delete Ike.
3. Occupy the volume formerly held by Ike and complete the contract.
4. Move out of that volume (don't forget this part!).
5. Restore Ike.
6. Marvel at your godlike power.

That last step is optional, of course, but you might as well get some enjoyment out of it.

On a much more serious note, I suppose that this is a good time to point out that one of the unwritten caveats and general gotcha! moments of this game is that, unlike many (most, I think) games that offer repeatable, random missions and quests and the like, no provision is made in KSP to ensure that completing these missions is actually possible:  the random number generator will create elements that are possible (so you won't get something that asks for an orbit of 13 Gm over Kerbin), but it doesn't check to see whether the combination is possible.  It's up to you to decide, based on the information offered, whether to take the contract.  I think that the idea behind it is twofold:  first, as the administrator of the space agency, it's your job, not that of the contract writer, to decide whether doing these missions is within your capabilities.  The contract writers can be a lot like children who write NASA begging to be taken along on a trip to the moon without really understanding why that cannot be done.  Second, the impossible ones can be rather funny.  You've got a perfect opportunity to say, 'That's no space station; that's a moon!' right in front of you.

You could also say, 'That's not a satellite!  Oh, wait, yes it is.'

[drag inside cargo bay]

9 hours ago, miklkit said:

It sure looks to me that the rover is dragging but I don't know how this is so.  Even the wheels have red on them.  Am I seeing this wrong?

You're not; the game thinks that your rover is exposed to the outside airflow.

Pardon my complete lack of technical expertise on this, but I understand it that there's a bug with occlusion such that objects docked inside closed cargo bays can be considered separate vessels by the game, which means that they are subject to drag.  Of course, they're still physically connected to the rest of the vessel, so that drag pulls on the whole works.

What I don't know is whether this appears always, or only when there are certain conditions at work (such as certain kinds of clipping).

What I do know is that if you want to eliminate it completely, then the only solution that I know will work is to install FAR, since FAR uses a completely different approach to figure occlusion.

[Developer Insights #16 - Kerbal Community Program]

@Ghostii_Space:

It does seem that Oxygen Not Included, Astroneer, Satisfactory, and KSP all share a certain type.   Of course, now that you've admitted it, you're pretty much stuck here.  Committed, even, as the nice men in the white scrubs might say while they help you put on a special jacket.

One of us!  One of us!  One of us!

*Ahem*  I have two questions for you:

1. You are the most recent in a long line of community managers, leads, moderators, developers, and pretty much anyone else who has had a stake in this forum to say that this is among the very best of on-line communities.  I was wondering, since you're the first one I know of who has credentials in anthropology, whether you had any special insights into just why that is, or whether there's any kind of objective criterion that informs that assessment.  Not to put you on the spot, of course, and not to suggest that I disagree (I keep coming back, after all), but is there something repeatable in that, or is this a group that managed to turn lead into gold by accident and never wrote down the formula?
2. Who made that fantastic Kerbalised portrait, and is it the same person who does the forum avatars?  Either way, there should be an offering of fruit baskets and possibly small, fuzzy animals.

[revert flight is greyed out]

8 hours ago, Weather said:

and cannot revert flight for some reason

If you switch away from the vessel just launched, whether to view another vessel or go back to the KSC, then you will lose the ability to revert.  Quicksaves help when reverting is not possible.

[Gap in research development / career mode]

On 11/25/2022 at 3:02 AM, Psykikk said:

getting enough deltavV stuffed into a mun lander that really is able to get loads of science back to KSC is ...hard , especially when you hit parts and tonnage requirements. 

especially when you try to minimize trips to maximize science (aka biome-hopping)

I enjoy the challenge, but I do not remember it being THIS hard. or am I just rusty ? 

In addition to what everyone else has said, I'll add that you may also be trying to take a bigger bite than your program can support at the moment.  You're not wrong that there's a hump in the middle of it, but maybe the approach you need at the moment is a Mun orbiter than can manage low and high space in a polar orbit, rather than a multi-hop lander.  There are a few early-game spaceplane SSTOs, but there are also much more mission-capable spaceplane TSTOs that exist because the designers didn't feel the need to force conformity to the single-stage constraint.  Also, you get quite a lot of manoeuvring reserve when you don't need to use the propellant for landing (and take-off).

Don't forget solar orbit, either.  The high space science multiplier isn't the best, but it's something.

Don't feel the need to get comprehensive.  There's nothing wrong with sending out a couple of Goos on a bare-minimum core-transmitter-power stack with not much else.  The OKTO is a fine core for probes that don't need to do much (and even a lot of probes that do).

On the other hand, maybe the thing to do is to focus more on making money than on retrieving science, since money is what you need to upgrade facilities to get past the parts and tonnage requirements.

Either way, good luck and welcome back, and remember:  you don't get rusty in space; you vacuum-cement instead.

[Jool delta V question]

19 hours ago, miklkit said:

It's a pretty clean screen.

Wow.  I don't normally see screens that pristine even in stock.  Also, nice plane.

Anyway, were you executing this burn by hand, I see a potential problem in that you're set to prograde hold in your second screenshot.  A sphere-of-influence change would cause a problem there, since prograde is relative to the body you're orbiting.  But MechJeb uses a form of manoeuvre hold to execute its burns (actually, it just knows which way to point the rocket, and points it in that direction--which is a throwback to how everyone had to do it back before SAS manoeuvre hold was a thing), so the sphere change wouldn't affect that.

I'm starting to think that you've got a bug of some sort; this stopped making sense three posts ago.

[Jool delta V question]

6 hours ago, miklkit said:

I really don't know.  The buttons themselves change.  The prograde button flips the ship retrograde.

Normally, I'd call that a 'control from here' problem as @king of nowhere mentioned.  However:

6 hours ago, miklkit said:

Checking the map out showed MJ had changed the target to Jool and was swinging the ship around to start burning there!

... I'm honestly not sure of how to parse this one.  Even if you had previously set up a manoeuvre for your Dres-Kerbin return using MechJeb, that would just be a standard manoeuvre node in the game--you could shut down or even disable MechJeb and the node (and planned burn) would remain.  MechJeb works with KSP, not independently from it, which means that a lot of what it does is done merely using automatic control of features that are already accessible to the player.  What I mean is that MechJeb shouldn't be randomly changing your target, but even were that to happen, it definitely shouldn't be cancelling existing manoeuvre nodes and setting up new ones.

The only time I've ever seen similar behaviour from MechJeb is when someone deliberately created a new manoeuvre in MechJeb's planner and asked it to execute that plan immediately.

Obviously, you're not doing that--at least not deliberately.  The only way I can think that you might be doing it accidentally is if you keep MechJeb windows open under other menus while you do other things.  One thing that a lot of mods in KSP do not have is click-through opacity (assuming that that is even the correct term), meaning that if you have menus open and overlaid on one another, then clicking on one also registers as clicking on any menu underneath that one, because the mods only register the cursor's screen position, not the menu 'depth' under the 'surface' of the screen, to coin an analogy.  Is it possible that your MechJeb manoeuvre planner is under, say, the resource panel or a part action window that you're using on your rocket?  If so, then you may be accidentally telling MechJeb to plan a manoeuvre and burn for Jool.