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.

I respect that people value their money differently. Even if the price has increased gradually since early access, the game has evolved and its value has actually increased. You would not see the sort of changes that have been made up to version 1.1 in any other game. And remember that $40 is the current full price of this game, but it is frequently on sale for less. Back when I bought the game, I thought the price was pretty stiff too, especially for an early access game from an unknown developer. The screenshots were pretty underwhelming (and the game still looks somewhat ugly). The demo is what convinced me that it was worth the money. It had a different kind of fun to it than you usually see in games.

I think there are a couple instances of this bug on the tracker already. http://bugs.kerbalspaceprogram.com/issues/8974

If there is a sequel to KSP, I hope it has NOTHING to do with launching rockets and orbital mechanics. KSP already does a good job with those. I don't think a 2nd KSP-like game would be able to significantly improve on the gameplay experience. A sequel should be something related, but completely different from the original. Examples: MMO about colonizing Duna with exploration, base building, resource management and trade Kerbal adventure game or RPG featuring the characters from KSP 1. Kerbal submarine program on Laythe On the other hand, as a pure business decision, a KSP 1 remake would probably guarantee enough sales to be a risk-free profitable endevour.

I'm not sure if real world comparisons apply in the Kerbal world. I tested a tier 1 plane that used canards for pitch controll with 1 juno engine and 200 units of fuel just now. It could be landed quite brutally at 50 m/s. I was looking at the wheel stress meter and it didn't reach further than 20. 60 m/s landings were also fine, but at speeds higher than that I had trouble getting it to land on its rear wheels. I think the key is to keep the mass low by not adding too many engines nor too much fuel.

I've experienced some problems with the tier 1 wheels also, thinking that early plane tech could be a shortcut to easy science and money before going to the mun. For my plane it was fixable by taking some of the fuel out to shed mass and using the ailerons as flaps to give more lift during takeoffs and landings. I still needed to be very careful by pitching up very gently and landings had to happen at 30m/s with nearly no vertical speed. Maybe also putting the wheels on parts that will flex (like the wings) instead of the main body could have helped. Another way of dealing with it might be to use canards (wings in the front) to lift the nose up instead of an elevator in the back to pivot the plane on the rear landing gear. In retrospect, it would have been better to either get the better plane parts first or to make the planes launch vertically. I still think the wheels are fine even if they are very fragile. Just realize that 1.05 planes using those wheels will likely have to be reengineered.

Problem scenario: Your vessel is in low Kerbin orbit. Your goal is to reach Jool using as little delta-V as possible. You know if you immediately make a burn, the transfer orbit won't hit Jool at the right time and place. So you have to wait for a better window. You want to make the manouver node NOW that is or a time way ahead in the future. The only way to do it now is to increment the time of the node forward by 1 orbit around Kerbin. 1 orbit in low kerbin orbit is maybe an hour, but your window might be 100 kerbin days away. That means you would need to click the increment button 600 times. My idea is that you can use the parent body's orbit to create a pseudo-manouver-node for the parent body. This pseudo-node can be handled as a regular manouver node that can be moved with anchors that can be pulled to create a hypothetical trajectory. Encounters with a target body will also be shown. Once you find a good trajectory, you can transfer the time of the pseudo-node to a newly created node on your current planetary orbit. The hypothetical burn does not transfer over. Then you can adjust the node on the planetary orbit to get a similar trajectory as the the hypothetical one. This would allow you to create nodes far off in the future and would also make it easier to find a good window for transfer burns. Drawbacks as far as I can tell: It simplifies finding good transfer windows and maybe ruins the game for players who want to figure things out more mathematically. The pseudo nodes might create clutter and confusion for the player. It might not be obvious for the player how the new manouver nodes were created and what they mean. You can't timewarp comfortably 100 days ahead in a low Kerbin orbit anyway. Maybe the player should just get used to timewarping from the tracking station first and worry about manouver nodes close to when the burn needs to happen. If your current orbit gets you an encounter with a moon before the time of the manouver node, your orbit will be different. It is not obvious how this should be handled by the game.

A massive reaction wheel system, judging by the torque you can get out of it.

Was the satelite built after the contract was accepted?

If so, hopefully camera wobble won't be implemented.

I would say science mode is the main game if you have just started playing the game. That way you can't lose because of repeated disasters. In early career, you are always just a couple crashes away from bankrupt. Science also has the added benefit of gradually getting you into the game instead of dumping the entire part library from the very beginning. I might change my mind if career mode becomes more forgiving. Technically the main game is sandbox with a boatload of mods though, but that comes after learning most of the basics.