stenole

I think two things need to be in place to enjoy the stock game after getting used to having deltaV and TWR values handed to you: - You need to have enough experience to eyeball what kind of TWR you will get with different. You know how many of tank X can get lifted by engine Y off of Kerbin. And you just convert the mass of payload into number of tank X. It's not accurate but it gets the job done. You also know what amount of engines you need to make trajectory changes in one burn. - You need to accept the loss of precision compared to before. You need to have greater margins for more complex missions which visits several worlds. Alternatively, you make refueling stops along the way to keep the uncertainty constrained between the individual legs of your mission. There is also the possibility that you have squeezed as much fun as you can out of this game. You've already achieved what you wanted to achieve and you've learned everything you wanted to learn.

The manouver node system was an eye opener. I was for the longest time oblivious to its existence. What really expanded my horizon was when I started designing rocket stages for what they were actually meant to do in a deltaV-budget-like way. Early on, I was just trying to always have at least a TWR of 2 and I would just pile on tanks and stages as needed. It made for some gigantic rockets which very often ran out of fuel before completing their missions.

There is a 5% royalty on UE4 if you are using it under the standard EULA. So it is definitely not free.

I think Kerbal characters fit perfectly for a game where you just plop fuel blocks on top of engine nozzle blocks and launch to space. The game is really only as complicated as you make it yourself. You don't have to calculate everything to achieve basic success in this game. Optimization is an optional activity.

You can have parking orbits in KSP as it is now. And you can do it at any point of the orbit of the planet outside the planet's SOI. You just have to match the planets orbit perfectly. This synchronicity will eventually fail with timewarp. The same is also true for Lagrange points in the real world. A ship will get perturbed by other bodies in the solar system and the ship will start floating away. The Lagrange point is not really stable so the drift will eventually increase over time. In order to get a ship to be properly parked at a Lagrange point, it needs to adjust its position using thrusters regularly. This active park mode could be implemented in KSP right now with more elegance than it would be to create fake N-body physics using special SOIs with different gravity rules.

The Lagrange points aren't gravity wells. They are more like gravity saddles. The ships' movements nearby a fake Lagrange point wouldn't make sense. When approaching, the ship shouldn't accellerate towards it.

For anything below 0.3 TWR and larger than small, I would recommend LV-Ns (unless cost is a factor). Aerospikes and poodles work well if you need higher TWR in the 100t range. Rhinos are great for even more massive high thrust ships. Add as many engines as you need to get the appropriate TWR. Source: http://meithan.net/KSP/engines/ (best KSP web tool in the universe)

The only purpose I can think of for a Sun space station is to get the science lab bonus from solar orbit in career mode. It may work as a refueling station if it is capable to mining nearby asteroids which are in similar orbits, but if it can move around to mine asteroids it's not really a station anymore.

I was constructing a space monstrosity in LKO, adding modules one by one. I had one module rendezvous a little too aggressively... I frowned, then I smiled, then I frowned again. I fought with myself to not revert to launch.

http://meithan.net/KSP/engines/ This webtool makes graphs that show which engine is better depending on payload, TWR and deltaV requirement. It can give you a good idea of when to use the one and when to use the other. Something else to take into account is also that LV909 is much shorter which is useful for landers and has gimbaling which is also especially useful for landers. In general the LV909 works better for small things and the nuke is better for bigger things.

Although your problem is likely related to your landing gear, spinning may also be a symptom of yaw instability. If this is the case, if you rotate your aircraft to sit sideways, the CoL will not be sufficiently behind the CoM. This is most simply fixed with a tail fin. But if your problems are on the runway, chances are that it is a landing gear problem. Checklist: All landing gear points towards the direction the plane is supposed to go. All landing gear is standing straight up and down. The landing gear is not attached to a part that flexes too much when the plane is resting on the ground. This will cause the landing gear not to sit straight. Assuming a tricycle placement of the landing gear, the back landing gear should be relatively close to the CoM, and the front should be towards the very front. This will put more of the weight on the back landing gear. As a result your aircraft won't as easily tilt sideways and start to want to turn. Assuming tricycle placement again, turn off steering on back landing gear. Assuming tricycle placement, turn friction control off for the front landing gear and set it manually to a low number 0.3 or less. If you follow the checklist, your landing gear can be eliminated as the cause of your problems. A picture of your plane would be very helpful. A one line description of your problem is not really good enough to yield advice that isn't already available on the forum by searching.

A combination of whiplashes and rapiers. Enough rapiers to get sufficient TWR in closed cycle mode for the last part of the ascent. Whiplashes are there to supplement the rapiers to blast through the sound barrier and gain altitude relatively fast.

Your reasoning is correct, but I would try to keep things as vectors to make sure you're not adding errors into your calculations. Vectors will make your code cleaner because a lot of the variables that you extract in kOS will already be vectors and you have access to simple vector functions. "set v_Earth_Ap to (v_Ft-v_Earth_Fg)/ship:mass. " This line of code assumes that your thrust is always pointing opposite of gravity which means it will be incorrect if your rocket is not going straight up. If you had thrust and gravity as vectors instead of scalar numbers this would make it easier to apply newton's 2nd law of motion. If you intend to use scalars and keep gravity going in the -1 direction, be aware that the angular speed (horizontal speed) will affect the gravity value because you are in a rotating reference frame; Think Centripetal force

Vall is the only "planet" I have not set foot on. The main reason is probably that it is Tylo's little brother. It is very similar, but less challenging.

If it doesn't wobble, it wasn't designed by me.