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.