Empiro

I think the issue is that both Unreal and Unity make certain assumptions about the game: namely at its base it's a scene with some sort of geometry and entities that move and interact within the scene. This works great for 99% of all games but not KSP/KSA because of the scales involved. I think KSP's challenges with Unity wouldn't go away at all if you used Unreal. Somethings might work better, but the core incompatibility will still be there. At the same time, I think the nature of KSA is that you don't actually need an extremely complex engine. At its core, it's a physics simulation, and for the small stuff, its sounds like they're already using a dedicated physics library, while for the big stuff, it's all Newtonian mechanics. (That's not to say it's easy, but it's at least known, and it's not like any game engine supports Newtonian mechanics for celestial bodies out of the box anyway) For the default difficult, I don't think anyone would mind if the cats just came back after getting blown up. After all, they do have 9 lives.

The gravity there is low enough that I'm surprised you can get any sort of traction at all. Most likely, all your issues are due to the gravity there. Your wheels don't grip the surface properly and all sorts of weird things can happen at 4x physics warp.

Try to get your approach PE as close to Kerbin as possible. If you're at 4000 m/s at 100 km, this kind of speed is actually quite reasonable and expected when returning from Jool via a direct transfer. When you left for Jool, you probably were moving just as fast when you finished your burn. This is the reverse of that. If you can't survive directly driving into the atmosphere, you don't need to slow all the way down. Just slow down so that you're not on an escape trajectory, which means spending about 1000 m/s to be slower than escape velocity, about 3000 m/s. You can then take your time, at AP lower your PE into the atmosphere and slowly aero brake until you're able to land safely. In either case, it's most efficient to perform this maneuver as close to Kerbin as you can.

In my game, I have unlock all nodes set to false, and have to buy the parts and unlocks, so maybe that's why. In either case, I'm glad there's already an open issue about it, and hopefully it'll become optional (and not have the extra +funds text) going forward.

In my save game, I was able to locate the following lines: SCENARIO { name = PartUpgradeManager scene = 6, 5, 7 UPGRADES { Unlocks { HDD-Upgrade1 = True Unmanned-Upgrade1 = True Goo-Storage-Upgrade = True HDD-Upgrade2 = True SampleCapacity-Upgrade1 = True Upgrade-Slots = True Crew-Upgrade1 = True Upgrade-TV = False SampleCapacity-Upgrade2 = True HDD-Upgrade3 = True } Enableds { } } } I changed Upgrade-TV to false as you see above and everything seems to work fine.

I just wanted to bring back this issue / bug that is present. Basically, if you unlock / purchase the TV upgrade in the Advanced Exploration tech node, you'll increase the cost of habitats like the Hitchhiker Can by 33,500 funds. It also adds the annoyance that for some reason, every part in the game now reads something like √37,500.00 + √33,500.00 cost, even parts like parachutes and engines. I haven't gotten the Radiation module yet, but it sounds like that will make things even more expensive. I was able to fix my game by undo-ing the TV upgrade by editing the save game and removing the upgrade. I suspect that these upgrades are powerful and are designed to make it so that they increase the cost of the parts if you use them. However, there doesn't seem to be a toggle that allows you to NOT use them, and they should probably by default be not enabled on a part.

I have OPM installed, and that might have modified with the maximum DSN range. I'm not 100% sure, however. I can look through my mod folders. Do you know what's the setting to look for that modifies the DSN?

I was able to figure it out. Yes, I was using the default config. Under the Kerbalism Settings.cfg, I found: //DampingExponentOverride = 14 // Kerbalism will calculate a damping exponent to achieve good data communication rates (see KSP.log, search for DataRateDampingExponent). If the calculated value is not good for you, you can set your own. In my KSP.log, I saw that the value had been computed as: [LOG 09:34:34.502] [Kerbalism] Sim.get_DataRateDampingExponent Calculated DataRateDampingExponent: 365.9167 (max. DSN range: 2000000000000, strength at 2 AU: 0.999) I'm not sure if it's a mod conflict or something else that made the damping value so high. I uncommented out the override and everything now works as expected.

Is there some sort of bug with the data transmission rates in the current version? In my early game, I was getting a transmission rate of 0.1 B/s from the Mun even though I was using the antenna and the signal strength was 96%. It should be pretty close to the rated speed of 5kb for the HG-5 High Gain Antenna.

For the same reason that there's no HydroLox or MethoLox in KSP 1 (or even RP-1 since "Liquid Fuel" doesn't exactly have a real-life analogue). It's basically not a area where the developers want to increase complexity in. I'm sure there will be plenty of mods that add fuel types for enthusiasts who want the most realistic and customizable experience.

Looking forward to the improved UI!

There's different ways to do things, but the simplest (though not cheapest or fastest) way to do things is: Eject from Minmus just barely so that you're orbiting around Kerbin. Target the Mun and see where the AN or DN are. Create a maneuver node and burn normal to reduce the relative inclination to 0. Execute the manuver so you're at 0 relative inclination with the Mun. Create a maneuver node to bring down your PE so that it's barely touching the Mun's orbit. Move your maneuver node so that it comes later or sooner, and get an intercept. The encounter markers can help you here -- if the Mun is behind you at the closest approach point, then burn later. If the Mun is ahead of you at the closest approach point, burn earlier. You can reduce the total fuel cost by basically combining the inclination change and transfer burn, and doing it all from low Minmus orbit. However, this requires waiting for just the right window and very careful maneuver tweaking. However, the Minmus - Mun transfer is cheap enough that it's not worth bothering with unless you're purposefully trying to practice timing transfer windows. Going interplanetary is when it's really going to make a huge difference, especially to somewhere like Moho. It's the difference between a round trip needing a big ship, versus needing an absolutely massive one.

It's showing atmospheric versus vacuum TWR. In-flight, KER will always show the TWR in your current situation, while in the VAB, you need to toggle it by pressing the Atmospheric button.

It's possible, but I've found that the orbit lines and rendevous can be a bit finicky. I suspect it's due to floating point inaccuracies, but you'll find it hard to tweak your encounter my small amounts. The orbit lines will always jump around. Nonetheless, you don't need a very close encounter in solar orbit. Anything within a few thousand km will do. As you approach, use target mode on the navball and try to push your velocity retrograde into the target retrograde marker.

I haven't used the Trajectories mod, but I think it works pretty well. There is still a bit of risk that you land on a slope, which is also bad if you have a top-heavy rocket, but I don't think Laythe has too many of those. Using jet engines would work well on Laythe, but if you go that route, I'd recommend going for a space plane instead. Since you're bringing somethine separate just for Laythe, space planes are just way more fun, and will help you find a good landing spot. Anything that works well for Kerbin will work well on Laythe (and give you some extra room for error). Just make sure that you're able to land with a full tank! The Jool 5 is both harder and easier than it looks. It's very easy to overplan and overestimate the delta-V requirements. It leads to a complicated launch and assembly since your craft is so large, but once you're at Jool, you'll find everything really easy since you have so much leeway. The other way is to go with a smaller craft, but use complicated and efficient planning. It's quite cheap to transfer between Jool's moons if you're patient and wait for the right times. There exist delta-V maps for Jool moon transfers (https://i.imgur.com/skAIz90.png). Though that's a bit outdated for Laythe, the other numbers are still basically correct. Note how cheap it is to go from a moon's escape to the transfer orbit of another moon. You can also bring mining equipment, but I'm a bit of a purist, and like to do it without ISRU. Some general advice for the planning: Use Laythe or Tylo to reverse-gravity assist to capture and lower your orbit at Jool. Avoid circularizing in low orbit around stuff as much as possible. Instead, leave your main ship in an eccentric orbit with a very high AP and very low PE. This way, if your burn at PE, you'll escape the moon with minimal delta-V. You will need to wait for the moon to be in the right position so that your escape trajectory will be pointing prograde or retrograde along the moon's orbit, however, which is why patience is important. Note that your lander will need more delta-V to land from an eccentric orbit. This may be a problem for somewhere like Tylo. However, even in this case, you could do something like this: have an extra tank of fuel attached to the Tylo lander when you detach from the mothership. Circularize in low orbit around Tylo. Top off your lander while still leaving a bit left in the tank you brought with you. Then, detach from the tank and land on Tylo, do your science, and take off. Rendevous with the fuel tank in low orbit, which has just enough to allow your lander to reach the mothership's eccentric orbit. Essentially your goal is to move as little mass as possible at all times leaving fuel in places you will backtrack to. It's kind of like folks who go on long hikes and drop full water bottles as they are going one way, and pick them back up to drink on their way back. When coming back, it's best to drop your PE down around Jool if you're currently around the tiny outer moons. Note that you will be entering Kerbin FAST. I'm not sure aerobraking is an option even if you have the inflatable heat shield (never tried it lately).

The main considerations for the mission are Tylo and Laythe. The other moons are all quite easy to land on and take off from. The typical design would be (at least) a 2-stage lander for Tylo, and then reusing the upper stage for the other moons, all while refueling from your main craft. For Laythe, the most challenging aspect is landing properly. Laythe has so much ocean that you'll almost certainly be touching down in the water unless you use a space plane design. If you're using the same lander as for Tylo, you'll need to pack parachutes for Laythe, but want those to be detachable, as you don't want to waste mass carrying anything extra for Tylo.

If your closest approach is 11 million km, then you're not anywhere close to Kerbin. The distance of Kerbin to the sun is 13 million km. Without expending an enormous amount of delta-V, the only way to get an encounter will be to wait. You might be able to get an encounter a little bit earlier by putting a maneuver node at the intersection of your orbit and Kerbin's. You won't make the encounter the first time you get there, but if you put a maneuver node there, you may be able to get an encounter the next orbit or the orbit after that with a modest amount of delta-V in the prograde or retrograde direction.

In KSP, you can get all sorts of weird situations like SOIs overlapping and having two planets be on top of one another. As others have pointed out, KSP planets are "on rails" so there's nothing that can disturb their orbits. Realistically, if Eeloo encountered Jool, it'd likely be flung out of the system, or have its orbit drastically changed. In KSP1, there's the mod Principia that simulates n-body physics. It turns out that many of planet-moon systems aren't quite stable when you do that (for example, Minmus would be flung out of Kerbin, and many of Jool's moons would be unstable).

Believe it or not -- I wouldn't mind if after a few years of KSP2, KSP3 came out with even more parts, features, and improvements. More realistically, I don't mind part DLCs, but any new systems that gets added (e.g. ground science, inventory, mission builders, etc.) needs to be integrated with the base game for everyone. When I look at KSP1, I just feel it's really a shame that a cool system like the mission builder just kind of gets left by the wayside because it's not integrated with the main game modes. I completely agree that KSP 1 has its share of cobbled together systems. KSP2 is the chance to fix that, and ideally, avoid gameplay fragmentation via lots of small DLCs poorly integrated into the main game.

I don't mind spending money for more content, but I'm against DLC in a game like KSP. I want the gameplay experience to be all nicely integrated, and I feel like the DLCs for KSP1, while alright, have made the experience feel disjointed. Take Making History -- some nice new parts, but the real meat of the DLC, the mission system, is kind of just there. It doesn't integrate at all with the contract system or anything like that, even though it'd be super fun to have complicated contracts like what the mission builder can do. As a result, it just gets ignored and forgotten in most games. Breaking Ground was somewhat better -- the inventory system got added to the base game, so at least mods can make use of it. Still the deployable science and robotics and rotors just feel like they don't really fit in with the rest of the game.

Yes, you have the right idea. The thread for JNSQ has a delta-V map, so you should use that. I believe it takes 5000 m/s to reach Kerbin's orbit. The only caveat is that if any stage's TWR ever becomes too low (especially before you get into LKO), then your rocket may use up more delta-V or even fail to reach orbit.

How many m/s is your maneuver? If it's significantly more than 2000m/s, consider tweaking your maneuver or waiting for a better window. If you still have a 40-minute burn, try a higher orbit to start with. For Kerbin to Jool, the gate orbit is at 250km. This altitude minimizes the delta-V to get to Jool (not counting the delta-V required to get into that orbit). This will reduce the burn you have to do and give you more time to do it. You can also split the maneuver into pieces. Do half of the burn so that your AP is high but within Kerbin SOI still, and then complete the burn the next time you come around. You still need about 950-1000 above Kerbin escape so you're still looking at a 20 minute burn. One other thing you can try to do is to ignore the maneuver node once you're significantly past it. Once you're about 5 minutes past the maneuver point, just burn prograde. It will cause your ejection angle to be a bit off. One way to help plan around this is to split your maneuver in KSP -- place one maneuver that you can do within ~5 minutes at Kerbin's PE. Place another one about 5 minutes after that one that you can do in 5 minutes, and so on. It's a pain to do any corrections in timing (you'd need to move all your maneuver nodes around), but it will tell you with good accuracy where you'll end up.

The delta-V maps are just estimates and often are on the conservative side, just in case your TWR is very low or if you are slightly off and need to make corrections.

That should be more than enough. You should see what happens if you turn off SAS. Like others have pointed out, mach 2 at 2000m is quite fast. It may simply be very hard to keep a long rocket stable at those speeds.

This often happens with long rockets that have SAS enabled. Because of the aerodynamic stresses, your rocket is bending slightly. SAS tries to counter this, but your control point is at the top while your thrust vectoring and winglets are at the back of your rocket. This very easily causes an over-correction, which results in your rocket oscillating back and forth. Adding struts will decrease the amount of flex your rocket has Disabling SAS can prevent the oscillation from happening, but if your rocket is bending too much, then it may tumble out of control or break apart Reducing speed while low in the atmosphere will reduce the overall aerodynamic stress on your craft