Grizzlol

I would like to raise an important note most people do not realize or even understand. The input to output translations differ in joysticks. Some joysticks have a 1:1 (linear) ratio between input and output, others do not (non-linear). This linearity of input/output is important because it greatly affects the responsiveness, accuracy and general feel of the joystick. One would think it is as simple as "pull the stick this way, and the software will output the same corresponding maneuver", but while this is mostly true, it is not the whole truth. A non-linear output model will reduce sensitivity close to the center of the stick's freedom of movement to allow higher accuracy, while gradually increasing the sensitivity further out the edges. This is to allow higher precision with small movements. However, it also introduces problems as your hand-to-eye co-ordination will be much more challenged, having to not only estimate the hand movement, but also take into account that different lengths of the hand movement corresponds to different lengths of movement in the output. Most people do not even notice this or care, but an enthusiast will very much be frustrated with having the wrong form of output. By the way, manufacturers do not tell you any of this. You will have to do the research yourself. In KSP, specifically, it would not matter too much in most cases, but in other games where you more actively use the stick, it may have a much greater impact on your abilities to use the stick. It is, of course, possible to get used to it either way. I just think people need to be informed. For the record, real life sticks in real airplanes often have some non-linearity, but is negligible, not nearly as severe as some of the PC entertainment joysticks.

I do not believe they said anything specific about this in the stream, but that is the only way it would make sense. Otherwise any off-center engines would only provide centered thrust (combined) at 100% thrust (if they are set up that way), and they did say that off-center thrust would be much easier to manage this way.

Pretty sure this is not true. They clearly said in the stream that multiplayer will be worked on after career mode is complete, which currently is top priority. They also showcased an improvement in career mode in 0.23.

I have seen multiple claims about the resources feature being 70-75% done. I am curious whether or not this is an official number. Citation needed. My first guess would be that people are making assumptions based on the screenshots that were released. These images show us that progress has been made. No further conclusions can be drawn in terms of progression based on this. It is an understatement to say that it takes a lot of work to implement a feature of this magnitude. I suppose the (somewhat arbitrary) number is not really important, but it makes even less sense to bin the whole idea the closer it is to 100%, even if it does not turn out to be the greatest thing.

If you play around with the parameters provided by the Launch Window Planner tool by alexmoon, you will find that the resulting dV requirements can differ greatly depending on when and how you execute the entire process, so it is not surprising to find that dV maps can be wildly inaccurate as they provide limited information. Once life support is added to the game, this particular tool (Launch Window Planner) will be even more useful still, as you can choose to prioritize travel time versus fuel consumption and vice versa.

The poll results are skewed because people do not understand the question. You should specify more clearly in the title and answer options.

You just need to copy the quick save file. Then you can rename the copy for reference. When you want to load a specific save, you just rename it back to quicksave.sfs. It is very simple, stop complicating things. There is also the persistent.sfs file which is the auto-saved state.

One reason for a change in sound of clustered engines is due to their synchronization. If you have a multiple of the exact same sound playing at the same time then the slightest change in their sync makes an audible difference. Think of dropping two golf balls on a rock floor at the same time. Even though they are only two balls, they produce an acoustic frequency (pitch) when they hit the floor, which may sound very different with the slightest mistiming.

You could also simply quicksave, create a node with the approximate dV you wish to burn, burn anywhere just to see the estimated burn time, quickload and then do a proper node and burn.

I have had major loading issues lately, both on steam and a backup copy, one of which is a clean install with no mods. Not only does the loading time inexplicably increase exponentially, especially with mods, but when it is finally finished, some part models and UI elements become corrupt even though the game itself runs fine. It may be due to tabbing out during loading or previously quitting the game by pressing alt+f4. Once this happens, the only fix seems to be to reboot the PC, restarting the game alone does not help. It has been happening a lot on 0.21 and 0.21.1, but if I recall correctly, it may have happened in 0.19 also.

That makes sense, so what is missing here is a tool to figure out the approximate launch time and exact inclination which is a problem aside.

I think that is just the inclination you end up with after the burn is complete. Executing the burn from an equatorial orbit works perfectly well, so I assume that it would not be the case had the same burn been executed from an inclined orbit (given that the ejection dV has a normal or anti-normal component to it).

I assume that all transfers (including ballistic trajectories) are, as is explained, assumed to be departed from circular, equatorial orbits. Considering how accurate this tool is, how come you did not add the option to depart from an already appropriately inclined orbit, which would then result in less dV overall? I guess it does not apply if say you were to visit a station at an equatorial orbit first, but otherwise the vehicle could be launched from the ground inclined.

Sorry, I forgot to add the plane change dV, it makes much more sense now.

I am not convinced that leaving the final orbit blank works properly (for fly-by or aerobraking). Plotting a Kerbin to Jool transfer with it blank gives me ejection dV results of around 2000 m/s. If I input a final orbit of 100 km, however, it gives me a best result of 1944 m/s (ejection). Surely the former should be giving lower dV results as the insertion dV is irrelevant and only the injection dV matters. Otherwise excellent tool with superb results.

I never said inertia is a force. I was referring to the term, which most assuredly does exist, "centrifugal force" as is, whether or not it is a force, nor did I intend to imply that inertia is responsible for an object moving in a curved path (which would indeed be the centripetal force), but the contrary (resisting change in movement). Moreover, I never implied that you were wrong about anything, I just did not like your original statement "centrifugal force does not exist", without any clarification whatsoever, but now we do have a very detailed clarification, thanks. I will say, though, that centripetal force is much less commonly known, and in this case it is indeed the centripetal force (simply the gravity) responsible for the resulting orbit, not centrifugal force.

I do know basic physics. You are pointing out that the gravity is acting as a centripetal force and is the only thing that is an actual force, I was pointing out that centrifugal force (inertia) is what counters the gravity as the object curves around the surface (as it wants to continue forward) and as such causes the perception that gravity is no longer there due to being in a constant free-fall.

I would not be the only one reacting to "it does not exist". It may be that it is just a concept, an apparent effect caused by inertia and in that sense it is not actually a force, and it would be negligible in a regular plane, but I do not see a reason to disregard it as the title of the thread is "...near-orbital speeds". The actual gravitational force does not change with horizontal speed, but the perception of it does due to the centrifugal force (inertia). How is this wrong?

The Gravoli instrument is not affected by forces other than gravity, as opposed to the G-force indicator, which is the main difference between the two. The change in gravitational force at higher altitudes is not massive but it is not at all insignificant. There is a measurable difference within just a few thousand meters of altitude. In orbit, the G-force indicator will read zero because gravity is pulling on all atoms equally, while the Gravoli instrument will read less than what it does on the surface because the gravitational pull depends on the distance to the body. In addition, your TWR is directly related to the value given by the Gravoli instrument.

It seems to often be unresponsive for just a little while every time they update it.

Even if the stress levels are high for a game, which by the way is normal for an alpha release, your temperatures should always be within the limits at full load. If you are concerned then consider upgrading your cooling. It can be as simple as moving the fans and cables around for better airflow or buying better fans. Some people even under-clock their GPU to maintain healthy temperatures, but this is not really an issue in KSP as the CPU does most of the work unless you tend to use many light sources and have not set a low limit for them in which case the GPU usage goes up to 100% for me. Regarding RAM and HDD, these do not generally tend to overheat, and if they do it is usually because of bad airflow inside your case.

It does not perform the maneuver for you, it just shows you what it will look like and when and where you should burn. The blue reticule shows you which direction to burn in.

The advanced button will add the position of the moon. The alignment of the departure and destination bodies (not the moon) is the most important factor, the rest do not need to, and will not, be perfect. You can always adjust the transfer orbit in several ways, the bodies' position you can not. The position of Minmus can be off by quite a bit and still be effective. There are too many factors to rely entirely on the add-on, you will need nodes to make up for that. By burning before or after the Kerbin periapsis, you can adjust for Minmus being at the wrong position, which it most likely will be.

The Protractor add-on has functionality specifically for this, in "advanced" mode. Not sure if Mechjeb does this. If you do not like add-ons then you just need to play with the nodes a little. It is really not that difficult, you just have to make sure that the ejection angle ends up about the same as it would have been doing a normal transfer from LKO. It does not need to be perfect. You get many opportunities to make corrections, and even if it is not perfect, you will still reduce the overall delta-V requirements compared to a standard LKO transfer. If you do attempt this, you will find that the numbers do not line up perfectly because Minmus will (almost) never be in the perfect spot. It does not need to be. I would highly recommend using nodes to see where you will end up regardless of using an add-on or not, though.

It has been proven in practice in a challenge and in theory using maths and plots that the most efficient way to transfer to Duna (and therefore any other planet, from Kerbin) is by dropping from a Minmus orbit to an elliptical Kerbin orbit at about 100 km periapsis, and timing it so that the transfer burn to the destination is executed at the Kerbin periapsis. This does not, however, take into account any possible gravity assists that may or may not further reduce the delta-V requirements, nor does it assume that you take into account the efforts of placing a station around Minmus to begin with. The question is if you really want to take the effort of doing all of this. To Duna, specifically, the gain is not much, but to any distant targets it could be quite significant. Unfortunately, all of the posts I know about regarding this was lost in the attack a while ago.