Leganeski

Solid rocket boosters can be activated just by pressing the spacebar, but liquid fuel engines are more complicated. Is your throttle set to maximum? (Pressing the Z key does that.) Do your rocket engines have both liquid fuel and oxidizer? Do your jet engines have liquid fuel and air intakes? I don't think so, especially not if your solid rocket boosters work properly. Pictures are usually shared here using Imgur.

Each process produces heat separately, so running multiple converter processes definitely increases the heat output. Conversely, a converter process running at less than full capacity due to a shortage of ore produces less heat. The ore concentration does not affect electricity consumption or heat production, except in the case where a faster ore mining rate allows the converter to process more ore. Due to conservation of energy, one would expect heat production to be roughly proportional to electricity consumption. In KSP, however, I'm not sure that is entirely true. I don't pay that much attention to heat output, so I'm not sure exactly how it works, but testing the radiator heat dissipation readouts in a variety of conditions should reveal the answers fairly quickly.

This is because you landed so far away from the equator. Thankfully, when coming back from Mun, there's a relatively simple solution to the problem of inclination. After reaching low Mun orbit, create a 290 m/s prograde maneuver, and move it around until the planned trajectory exits Mun's sphere of influence horizontally. (The maneuver should be positioned about 45 degrees after your orbit crosses the equator.) This gets rid of the inclination by using Mun's gravity to rotate your velocity towards the direction you want. Click the "next orbit" button repeatedly until the planned trajectory reaches Kerbin. (This could take up to 60 orbits, depending on where Mun is.) Execute the maneuver.

MechJeb does not attempt to get its information from delta-v maps; it automatically calculates everything from the in-game orbits of the bodies. Or at least it would if it was working correctly. There's nothing too special about Armstrong that would logically cause MechJeb to break, and other maneuver-planning mods like Astrogator work just fine, so this seems more likely to be a problem caused by MechJeb.

It's on CKAN if you search for "BetterTimeWarpContinued." Alternatively, there are downloads available on SpaceDock and GitHub, as well as more information on its forum post. Most mods can be found with a similar approach: almost every single mod is on at least one of SpaceDock, CKAN, or its own forum page, and a large number of them are on all three.

Δv = 2v sin(θ/2) is the correct formula. However, the angle change of the direction of velocity, θ, can be less than the angle change of the orbital plane. Consider the extreme case where you're in a very elliptic orbit, moving almost directly inwards. No matter how much plane changing you do, your new velocity vector is still pointed "almost directly inwards", so the angle between the old and new vectors remains small. In the example you provided, the eccentricity is not as extreme, but the same idea still applies, and the turn angle θ is substantially less than 45.4°. The values v = 724.6 m/s and Δv = 372.9 m/s let us calculate θ, which turns out to be 29.82°. If you look at the maneuver from the direction perpendicular to the old and new velocities (rather than looking towards Kerbin), you'll see that the actual angle between the velocity vectors really is about 30 degrees.

What doesn't make sense, though, is that the intended multiplier is 2.5! If Sigma Dimensions were working properly, it would look up Hale's sphereOfInfluence parameter, find 41000, and multiply it by 2.5 to get 102500. However, the picture shows that Hale's SOI is actually 16 km, meaning that sphereOfInfluence ended up not at 102500 but either as the default SOI radius or missing entirely. Here it gets even more confusing. Hale's sphereOfInfluence parameter is defined at :FOR[OPM], which is before the relevant Sigma Dimensions patch at :FOR[SigDim2]. This means that sphereOfInfluence should already be 41000 by the time Sigma Dimensions gets to it. The patch in my last comment runs at :FINAL, after Sigma Dimensions has finished entirely, and manually sets sphereOfInfluence to 102500. That didn't work either, so the only possibility left that I can think of is that some other mod, also running at :FINAL, is deleting the parameter for some reason. But that's a really weird thing to do, and I don't know of any mods that would do that. That's for sure. If there were any other rescale mods out there, I would suggest using one of them instead, but Sigma Dimensions seems to be the only one available for OPM. I'm not sure what to do other than reinstalling all of the relevant mods.

This is probably the most important part. Because Laythe orbits so quickly, it's really important to meet it in exactly the same direction as it is moving around Jool, effectively allowing you to subtract off Laythe's full orbital velocity (3223 m/s) from your velocity around Jool. As it is, you're meeting Laythe about 60 degrees too early, which is always going to waste at least 1500 - 2000 m/s. Thankfully, the Laythe encounter problem isn't too hard to fix: you can make a correction maneuver halfway along the route to Jool which moves the entire Jool flyby about an additional two hours into the future. Keep adjusting it until the planned trajectory encounters Laythe just as it is about to reach its closest approach to Jool. This will save a lot of fuel when you reach Laythe, and 2800 m/s should probably be enough to complete the capture. As others have stated, another relevant thing to get right is the transfer to Jool. Although your transfer isn't terrible, and is likely good enough considering how much extra fuel you packed, encountering Jool in the same direction that it is moving will save even more fuel. If you line up both encounters well, it costs less than 500 m/s to capture at Laythe.

Wait, Serenity also uses the Jool template. Is the problem avoided there because of the ocean, or do you get a "bottomless ocean" by forever remaining in a "splashed down" state?

A 20-30% error margin is totally reasonable, if a bit on the high side. For consistency, I would recommend choosing some standardized way to calculate error margins (25%? 100 m/s? 30% capped at 200 m/s?), but that is entirely your decision. I got almost exactly the same numbers for Fracture and Echo, but still significantly less for the other planets. However, my numbers are entirely theoretical, while yours came from real maneuvers. An experiment is worth more than any prediction, and maneuvers from TWP are much more similar to what players using the map will actually be doing, so you should probably stick with what you found.

The SOIs shown in the picture are the automatically calculated values based on the relative masses of Hale/Ovok and Sarnus. As you've noticed, these are too small, so OPM includes patches that manually override the SOI sizes to be bigger. Your 2.5x rescale mod has somehow disabled these patches or otherwise forgotten to take them into consideration, so they no longer fix the problem. Try using this Module Manager patch: @Kopernicus:FINAL { @Body[Hale] { @Properties { %sphereOfInfluence = 102500 } } @Body[Ovok] { @Properties { %sphereOfInfluence = 235000 } } }

This is actually what I was assuming. Because I usually play with Better Time Warp in science or sandbox mode, I'm used to thinking of transfers like that despite the increased travel time. But you're right that it's not a direct Hohmann transfer, so I made a note explaining the unusual situation. All the other direct resonances are between systems I modeled as having circular orbits, but now I'm somewhat worried about the indirect 5:2 Cerberus-Esker resonance. Assuming I did the math right, Cerberus is within 25 degrees of the optimal location for each of the four transfers (both directions, and both of Esker's orbital apsides), but Dessic is off by more than 50 degrees for all of them. I'm not sure exactly how bad that is, but it's probably enough to make the optimal transfers be somewhat unusual.

Or RTG-powered Breaking Ground propellers! I've had surprisingly good results getting them to work on similarly challenging bodies. Of course, they don't use up delta-v in the same way that rockets do, so they don't produce a meaningful ascent value either. That feature used to exist, but it was removed in 1.6.

The unique planetary system layouts present some very interesting orbital possibilities! For example, starting at you can spend less than 160 m/s to reach The GitHub repository seems to have quite a few unreleased fixes and new features that would be really nice, especially Kronometer configs and the option to de-barycentrize binary systems. Is there any schedule for when these features might be packaged for a release?

I made a delta-v table for the system. Currently, it is up to date as of 0.22.1. There is already an excellent delta-v map in the OP, but it does not have numbers for transfers between two bodies other than Haven. In a table, all possible direct Hohmann transfers can be included. If for whatever reason you want to know how much Δv it takes to eject from Acheron to Tempest, now you can find it in the table! (It's 678 m/s.) My numbers were derived independently from the ones on the official map. They generally agree, but in most cases, mine are about 3-5% lower, likely due to me using lower low orbit altitudes as well as making generally more optimistic assumptions about how transfers work (for instance, prioritizing lining up apsides over taking the next available transfer window). Nevertheless, the values are still theoretically achievable. There are a few sources of variation I have not included due to complexity, most notably inclination, atmospheric drag, and gravity losses during ascent. I'd love to hear about ways to incorporate these, but they seem too dependent on the exact flight profile to fit nicely into a table. (Update: I have now added somewhat more accurate ascent estimates based on WarriorSabe's calculator, using my own model for typical TWR as a function of surface gravity. These values will serve as placeholders while I create a system for estimating ascent costs.) As Edge of Eternity is still in active development, I will try to keep the table updated with new releases.

Most of the numbers look good, and the graphics are quite informative! The colored ocean symbols are a really nice touch. I'm getting significantly lower numbers for the interplanetary transfers, though. Fracture: ejection 1200, capture 5000 Echo: ejection 290, capture 600 Windswept: ejection 85, capture 140 Scourge: ejection 15, capture 30 Rage: ejection 45, capture 13 Serenity: ejection 150, capture 45 I know it's the standard to do a subway style map like this, but I personally dislike it because it doesn't have any numbers for transfers between two bodies other than the homeworld. However, I agree that the format makes an excellent starting point. Serenity's atmosphere is so thick that I'm not sure what an ascent delta-v number even means when rocket engines simply fail under the absurd pressure. You could replace the practically unachievable number with a note saying something like "good luck getting out of this atmosphere" (like JNSQ does), a figure from a starting point at high altitude (like Edge of Eternity does), or something else entirely.

When you're doing a contract, can't you select the contract orbit as target to make it show the relative ascending node between your orbit and the target orbit? If so, that would be the best place to burn. In general, it is more efficient to reach the correct orbital plane (inclination, LAN) first, then worry about the rest of the orbit.

Did you set the navball to orbit mode? If you don't, it will calculate prograde as surface prograde, which doesn't deviate from vertical until after you start turning.

I'm just as confused as you are. Despite many attempts, I have never gotten a bilateral counter-rotating propeller plane to actually work either, so I suspect there is a large amount of unintuitive variation dependent on the precise positions and angles of everything. This means that your propeller blades are somehow set up incorrectly. However, the second picture makes it look like you did everything right. At this point, the only thing I can think of would be to check the action groups to make sure that they all do the right thing. In particular, if the main throttle was bound to the deploy angle on the propellers, replacing the propellers could have removed or changed that binding.

Without any gravity assists, the cheapest route is a direct transfer from Kerbin to Vall and back. After reaching LKO, the ejection to Jool costs 1920 m/s, and the injection at Vall costs 980 m/s, for a total of 2900 m/s. After landing and rejoining the mothership, the ejection back to Kerbin costs another 980 m/s. If you have a more capable lander, you could theoretically save 260 m/s in each direction by parking the mothership in an elliptical Vall orbit, which would reduce the total Δv requirement of the mothership from 3880 m/s to 3360 m/s.

No, the deepest that the ocean gets is 1393 m. You've somehow managed to clip through the surface. The water goes all the way to the center of the planet, but it's normally impossible to reach the part below the ground.

Jool is larger than Eve, so the ascent should always take more Δv. However, with fusion power, Δv is likely not a concern. Instead, there are other factors that make Jool easier: Jool has a denser atmosphere at the datum level, making it easier to start flying. Jool has less surface gravity than Eve, making it easier to ascend. Jool is less dense than Eve, making the ascent slower overall and giving you more time to react to anything that comes up. Jool rotates more quickly than Eve, giving you an extra boost and making the decrease in apparent surface gravity start sooner. The speed of sound is higher on Jool, so Mach-limited engines can go faster.

The clouds look great! Unfortunately, Hale has the same name as a moon from Outer Planets Mod. Given how frequently other mods refer to planets and moons by name, this could be an issue when using Zive and OPM at the same time.

Getting off the ground would indeed be easier. However, there are many other problems involved. Most importantly, Venus doesn't have oxygen in its atmosphere. This means you would need propellers for the initial ascent rather than a jet engine, so the rocket stage would need start from an airspeed of at most 250 m/s rather than 1500 m/s. Also, keeping the propellers attached throughout the ascent means that they would cause extra drag in the upper atmosphere. Slogging through the dense lower atmosphere would require a lot of energy. Keeping a propeller powered is easier than a jet, but storing hours worth of electricity in one plane would be quite challenging. (Solar panels might be possible, but good luck operating that many solar panels without causing a ton of drag.) While the 85 m/s wind would help, it's not much compared to Earth's 465 m/s rotational velocity that Venus doesn't have. In summary: while low orbit on Venus is 600 m/s slower than on Earth due to its smaller size, you would be need to start the rocket engines at an orbital velocity of more than 1600 m/s slower, so the actual fuel requirements would be significantly higher. Add that to all the other problems, and Venus is in fact a much worse place to fly an SSTO.

Yeah, that surprised me too, especially given how much easier it is to climb to orbit. However, Laythe is only worse than Kerbin close to sea level. Laythe's main heat source is tidal heating from Jool, so the temperature falls very quickly as altitude increases. This raises the density, meaning that once you get a few kilometers off the ground, Laythe really is better. Also, Laythe's higher scale height means that the pressure doesn't fall as quickly, so higher altitudes are even better on Laythe compared to Kerbin all the way up to 38 km. Altitude (m) FEI (Kerbin) FEI (Laythe) 0 1.000 0.789 2500 0.740 0.709 5000 0.538 0.621 7500 0.382 0.460 10000 0.251 0.332 15000 0.097 0.171 20000 0.0364 0.0837 25000 0.0140 0.0473 30000 0.0054 0.0298 35000 0.0022 0.0156 40000 0.00098 0.00745 45000 0.00048 0.00193