MirageNL

I also ran some simulations using the variable Isp and including models for air density and resistance. Though the drag coefficient has a large influence on the maximum altitude, it seems to have little effect on the optimal starting mass. Starting with too much fuel also turns out to be much worse than having a suboptimal amount. You could start off with tons of less fuel, only costing you a few km of altitude. Also interesting: from the KSP 1 wiki I found an Eve SL pressure of 5 atm and temperature of 420 K. However, to get the pressure at 15 km to around 1 atm from that, I had to give the air at Eve a low molar mass of just 20 g/mol. For comparison: a CO2-rich atmosphere like that of Venus would be 44 g/mol, while Earth air is 29 g/mol. Lowering the temperature lapse rate could increase the molar mass, but only up to 22 g/mol. The temperature would have to increase with altitude to get higher, but it would have to be 1400 K at 15 km to get a value of 44 g/mol. If KSP 2 still has the same SL values for Eve, then Ammonia (17 g/mol), Methane (16 g/mol) or even water (18 g/mol) would have to be pretty large components of Eve's atmosphere.

This week I tested some of the engines for additional altitudes. The Dart has pretty constant performance as expected, though it weirdly decreasse a bit between 2 and 8 km. The nuclear engines have constant Isp up to 9 km, then start to climb, stall a bit at 15 km and then increase again; also pretty odd behaviour. It might have something to do with the fact that 15 km corresponds to Kerbin sea level Isp values. Other engines also have a slight nod at 15 km, but otherwise behave as expected. The Rapier turns out to have better Isp than the Mammoth up till 16 km and between 5 and 11 km it's even higher than that of the Vector. Its lack of thrust still makes it a poor choice for a vertical launch, but an SSTO from Kerbin to Eve and back might be feasible. Above 25 km Isp's start to approach their maximum and at 50 km all Isp's are at vacuum levels.

Without drag effects, it would be better to keep the engines: That's a huge difference, but drag definitely is a factor. I tested these setups yesterday: the 2-stage Terrier+7xDart setup easily achieved an Ap of over 150 km. However, by the time it was high enough to start the gravity turn, its speed was already so high that my stabilizers started to overheat. Turning too fast would flip the craft over, but within seconds the Ap was already above 90 km and I didn't have enough fuel left to do the full circularization. The Terrier+7xDart asparagus setup was much more manageable , though the core Dart stage struggled a bit with the gravity turn due to the low TWR. Still, after circularizing I had over 100 dV left. A core stage of 3 Darts with the other 4 Darts in asparagus setup might yield better results. That would mean climbing gradually to 20-30 km until starting the gravity turn, after which the speed could pick up. Actually at Eve SL the Dart TWR is 8.5, while the Vector TWR is just 6.2. I do agree though hat the thrust-to-size ratio (TSR?) of the Vector is unparalleled, so I understand the preference when dealing with heavier payloads. The Swerv however is 10 tonnes alone, requiring plenty of additional fuel and payload to justify. It's also LG sized, adding to drag. The amount of fuel for the Vectors would be massive, so what kind of payload could you possibly need to lift from Eve?

I thought of another way to compare the performances. I realized getting out of Eve's atmosphere is not actually the real problem; the challenge is landing a rocket capable of doing so. Given the difficulties involving aerobraking and landing, having a low starting mass means everything. So, I changed the equation for impulse to a function of the total mass: J = (g/R) * ((8/9)*(F/g - mpayload - mengine)*(mtot - mpayload - mengine) - (40/81)*(mtot - mpayload - mengine)2) Solving for dJ/dmtot = 0 gives us the mass for maximum impulse: mtot = 0.1*(9*F/g + mpayload + mengine) So, for each tonne of payload, optimal starting mass increases by 100 kg. I plotted the impulse graphs for 0, 3 and 10 tonne payloads: The question to ask here is how much impulse you need. My guess is somewhere around 20-30 kNs would be a good aim, which no single engine can achieve and so multiple engines will be necessary. Below is a comparison between the previous number of engines with similar optimal starting masses: For actually equal optimal starting masses we would need to use fractions of engines: Since the payload mass affects all optimal starting masses equally, the engine number ratios stay the same for increasing payloads. All the curves just get lower and narrower. Increasing the number of engines increases the impulse, but also the optimal starting mass.

Given the extreme environment of Eve, I’ve always wondered what effect this has on engine performances. The Vector, Dart and Mammoth are often recommended for Eve, but I never really saw any quantitative numbers backing them up. Fortunately, the staging interface in the VAB lets us set the environment to Eve at sea level and it’s only a matter of using math to derive Isp values from the deltaV values. As expected, I found that the Vector, Dart and Mammoth do pretty well while most other engines suck. Interestingly, the Thud also performs pretty okay. The highest Isp values for Eve are: Dart: 267; Vector: 152; Thud: 101; Mammoth-II: 97; Mainsail: 96; Spider: 74. All others are below 50 (except possibly the Rapier; I forgot to test that one). The Isp values translate to the highest thrust values: Mammoth: 1332; Mainsail: 501; Vector: 411; Bottle-Rocket: 230; Clydesdale: 228; Dart: 142; Kickback: 115; Thud: 92. Using Eve’s gravity of 16.68 m/s2 (1.7x Kerbin), the highest TWR values are: Dart: 8.5; Vector: 6.2; Hammer: 5.6; Mammoth-II: 5.3; Mainsail: 5.0; Thud: 3.5; Kickback: 3.3. Optimal launch configuration While the Dart has the highest efficiency and TWR, it lacks absolute thrust and an efficient engine is useless if it can’t get its payload off the ground. Since the delta-V calculation doesn’t account for gravity pulling the rocket down, I find that instead the most useful quantity for a launch is the total change in momentum (or impulse) that an engine can deliver, which is equal to the net upward force integrated over time: J = integral (F - g*(mpayload + mengine+ mfuselage + mfuel - R*t)) dt Here F is the engine thrust, g is the local specific gravity and R is the fuel burn rate in kg/s. We can assume that for most cases mfuselage = 0.125 * mfuel . The total burn time can be calculated from t = mfuel /R. The equation then results in: J = (g/R) * ((F/g - mpayload - mengine)*mfuel - 0.625*mfuel2) By solving for dJ/dmfuel = 0, we can find the amount of fuel for which the maximum impulse is achieved: mfuel = 0.8*(F/g - mpayload - mengine) Interestingly, this means that for every ton of payload, you need to substract 800kg of fuel to keep the impulse maximized. From this, we also get the optimal launch TWR: TWR = 1 + (F/g - mpayload - mengine) / (9*F/g + mpayload + mengine) This means optimal launch TWR is always <1.111, getting lower with increasing payloads and gravity, depending on the engine. By adding the optimal fuel mass to the impulse equation, we find the maximum impulse: Jmax = 0.4*(g/R)*(F/g - mpayload - mengine)2 Since g=16.68 m/s2 for Eve, and F, R and mengine are constant for each engine, the only remaining free variable is mpayload. Engine comparison As you can see, the Mammoth-II can potentially deliver the most impulse by far for any payload. In second place is the Vector for payloads below 12t, but above 12t the Mainsail would be a better second choice. Without any payload, the Dart has almost as much maximum impulse as the Mainsail, but that quickly drops off. However, to get the most out of the Mammoth, you’d need an enormous amount of fuel. Without local production, this would all need to be brought in from Kerbin and you would need to manage to land it on Eve without burning up in the dense atmosphere or smashing too hard into the surface due to the high gravity. So, maybe the best value to look at would instead be the maximum impulse per kg of starting mass. The math becomes a bit more complicated at this point, but the Dart would now become the best choice for payloads below 2.5t. Between 2.5t and 5.3t the best choice would be the Vector and for payloads above that the Mammoth-II brings the most impulse per kg: Now, do keep in mind that these are the values per engine. Given the LG size of the Mammoth-II, you could argue it should actually be compared to 7 SM or 3 MD engines for similar footprints. In that case, the Mammoth becomes completely inferior to 7 Vectors and would only be better than 7 Darts for impractically heavy payloads of over 40t. It would perform about the same as 3 Mainsails or 36 Thuds: 7 Vectors would however require much more fuel for maximum impulse than a single Mammoth. So yet another way is to compare the amounts of engines that need a similar starting mass to achieve their optimal impulses. For very large payloads, that would be the case for either 7 Darts, 3 Vectors or 1 Mammoth-II. For smaller payloads, the 7 Darts would deliver far more momentum, followed by the 3 Vectors: Staging configurations For a final comparison, I considered a payload of about 3t (a command pod, a Terrier, sufficient fuel for a circularization burn and some appendices) and an asparagus staging configuration. Using 7 Dart engines would require 3.6t of fuel for the center engine and 13t of fuel for each of the 3 outer stages (so 6.5t per engine), giving a total of 24,000 kNs of impulse and a starting mass of 58t. Using 3 Vectors would require 14t of fuel for the center engine and 34t of fuel for the outer stage (so 17t per engine), giving a total of 22,500 kNs of impulse and a starting mass of 70t. A single Mammoth-II would require 50t of fuel for a total impulse of 18,300 kNs, with a starting mass of 74t. Again the Dart comes out on top, but I do have to note that I used sea-level values for all stages. Performances of the Vector and the Mammoth would especially improve a lot while gaining altitude, while the Dart would only improve a bit. You could consider using a Vector at the center stage with 6 Darts on the outer stage, but the additional fuel for the Vector would then count as a higher payload for the prior stages. This makes the Darts much less effective and it would only result in a total of 19,300 kNs of impulse, while having a starting mass of 74t. In fact, since the Dart suffers so much from higher payloads, asparagus staging is probably not even the most efficient way to use it. Just using 7 Darts without staging would give us a much larger impulse of 43,200 KNs, for a starting mass of just 55t. Using drop tanks while keeping all the engines would be even better. Of course, this doesn’t account for the effects of drag as a result of the wider rocket and the increased acceleration, so the best results might actually be achieved by an in-between solution. Conclusion Given all these results, I would at least have to conclude that the Mammoth-II and the Mainsail are never good picks, at least not when they have to be brought in from Kerbin. The optimal choice would be to use Darts. For larger payloads the Vector is a viable choice to lower the amount of engines, or when stabilizers aren't enough and you really need thrust vectoring (which the Dart doesn’t have). The only advantage that the Thud brings is that it’s radially attachable, but you would need a lot of them to make them work. This was pretty interesting to work out as preparation towards the Under Pressure mission, but it's all just theoretical. I don't have a lot of actual experience with Eve, so I'm wondering how this all corresponds with your experiences.

I do think it can be done, but it would require a much more elaborate interface than the current trip planner. Maybe it could look something like below? It could start off with a launch location, followed by the stages that were added in the VAB. (Or when already in flight: the current location, followed by remaining stages.) Additional destinations could be added in manually, with the the required steps added automatically. Options like aerocaptures could be added where relevant. Stages and location nodes could be dragged around to set up the desired flight plan, also allowing for vessels to be separated and recombined. The planner then calculates the remaining mass and deltaV at each step. (Don't quote me on specific values; it's a concept.) Adding in existing vessels would also be very useful. Gravity assists/captures, plane changes or custom orbits could be additional options.

Deleting some steps could also help a lot. You don't need the 950 dV for returning to Kerbin's SOI, nor the 3400 dV to land when you can simply aerobrake. Adding different destinations would only help if the vessel stays in one piece. Usually though, a vessel would split up in that case. Even when only having one destination, a vessel could split up into an orbiter and a lander, making the whole calculation more complicated than what the trip planner can account for. For complex missions, you would need an entirely revisioned mission planner, where the maneuvers can be linked to different vessel parts and combinations. You would then also have to select which engines to use for each maneuver.

Well, burns are more efficient the closer they are near periapsis (Oberth effect), so it's not entirely untrue. The fixed node direction just makes it worse. However, I'm not sure at what point TWR would outweigh Isp in that regard.

You're not necessarily playing the game wrong. If you want to put a Mammoth engine on everything because you want its superior thrust, then that's your call. You're just wrong to expect DSE's to provide sufficient thrust for tight orbital maneuvers. That's not what they're meant for: they're DEEP space engines, for long (fuel) efficient burns. I think the problem is that DSE's are unlocked too late in the tech tree. They come way after the Nerv and only just before the Swerv. They then try to fill a niche between orbital and nuclear engines that isn't really there. Whenever resources, heat and maybe radiation become issues, that might change though.

Actually, for large inclination changes (>43o for LKO) it would be better to raise your Ap, do the inclination burn there and then lower the Ap again. But besides that, I suspect you're right. Keeping the direction normal to the trajectory would keep the Ap/Pe nicely constant, but it's probably less efficient in terms of deltaV than a fixed burn. Anyone wants to do a comparison? I do think the retrograde adjustment is a bit of a hassle. Maybe we could have the (anti-)normal node take this into account, automatically adding a retrograde component to keep the shape of the trajectory intact? Though I'm not sure if that could entirely work with a fixed direction. It might also screw up (anti-)normal correction or intercept burns.

I noticed this problem as well. Setting up a long enough prograde burn can even cause the periapsis to drop below the surface. Keeping the direction relative to the trajectory instead of fixed would definitely be a big improvement. For a plane change, wouldn't it also be better to maintain an (anti-)normal direction instead of a fixed one? A fixed direction also changes the Ap/Pe and has to be corrected by the pro-/retrograde direction. The other two maneuvers are usually small burns involving a lot of fiddling, so I don't think it would matter a lot whether they're relative to the trajectory or to a fixed frame. As for the fuel limitation, wouldn't it be possible to just use the remaining dry mass for calculating the continued trajectory? It would need to be clearly marked red of course. In any case, I don't think there need to be any additional maneuver node modes, that would just make it more complicated.

I unintentionally completed this mission by planting a flag on the Moho croissant.

To be clear: I don't want to get rid of science points. In fact, I agree they work great as a tech currency, making you think about what to invest in next. What I'm suggesting is to make the available options depend on what the player has achieved so far,. This adds a sense of natural progression and prevents skipping steps. So yes, the requirements should be minimal, so they can be achieved by playing the game normally.

I wasn't saying that KSP needs that, in fact that would be terrible. I was just pointing out the difference and why it causes a lacking experience in KSP. The problem isn't the finite amount of science, it's that you can spend it arbitrarily. Early tech becomes cheap after a while, so at some point I tend to just complete entire tiers without ever needing the parts. Then suddenly I can build spaceplane parts, even if I've never even used wings before. I totally agree, but unlocking jet engines should be earned by actually flying. Unlocking orbital engines should be done by actually going to space. You've accomplished something, now there's demand for the next step. All available tech is relevant to what you've achieved so far and to what you want to do to take it further. Progression should come naturally and so should the achievements. That shouldn't be a chore, it should happen automatically when playing the game. With every step you work with what you have and improve on the previous design. You learn how to go fast with the Panther, then you learn to go higher with the Whiplash, then how to transistion to orbit with the Rapier. No cutting corners: earn it. Never did those either, but mostly because getting the required parameters was tedious work.

Of the games you named I only played Civilization and ONI, but in those games you need to choose a tech beforehand and then invest resources in them over time. It requires you to make a strategic choice, which then pays off later. In KSP you collect a pool of science points, which can then be used to instantly buy the technology you want. KSP just lacks that feeling of actual accomplishment when unlocking new tech. Besides that, gathering science also feels a bit like doing a side-quest instead of being a core part of the gameplay. I made a suggestion in another science topic to improve the science system: Sure, but actually doing stuff in space is what creates the demand. The achievement prerequisites should accomplish exactly this: perform an action that creates the incentive to research the next step. By the way, I'm not a big fan of the current tech tree structure, so I made a concept of what I think it should look more like. (I also added a few wish-list features.) This way the player can unlock technology in an order that actually serves his playstyle. The achievement prerequisites make sure you actually do stuff in a cetegory before unlocking the next tech level.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 Pro | CPU: AMD Ryzen 5 3600 | GPU: MSI Geforce RTX 2070 Super Gaming X | RAM: G.Skill Ripjaws V F4-3600C18D-64GVK Yesterday I did my first Tylo capture. After I entered Tylo's SOI I noticed that Jool was fully visible, but I couldn't see any of the other moons. I looked at the map view and it turned out Tylo was right in front of both Vall and Laythe, so first I thought that explained it. Then after I moved to the other side of Tylo, I still couldn't see them. Considering the angle between Jool and Kerbol, they should've been fully visible to the right of Jool, outside of Jool's shadow. After I exited Tylo's SOI and returned to Jool's SOI, Vall and Laythe were clearly visible again. Included Attachments: .ipsImage { width: 900px !important; }

I agree that science should be more immersive, but I also agree with @AlexCmers not to make it tedious. In my view there could be a couple of improvements to the current system. First, science experiments should provide actual information to the player: Surface scanners (ground and orbital) should add maps with elevation, biomes, discoverables and resources. Useful for picking landing spots, science gathering and mining. Atmospheric scanners should add graphs for pressure/temperature vs. elevation. Useful for planning aerobreaks, flight paths and determining engine performances. Space scanners should add graphs for gravity/radiation vs. elevation. Not sure how useful, but maybe at least interesting. Secondly, have the player unlock certain technology through relevant achievements, instead of just spending generic points. For example: in order to unlock the Rapier engine, it would make sense to have to gather atmospheric data first, as well as having reached a certain altitude and velocity with the Whiplash. Nothing too hard, but it would feel logical and earned that way. Actually researching the tech could then be done with the science points as a form of tech currency. These prerequisites could also be shaped in the form of secondary missions.

Lots of good ideas. A different kind of problem is that the Training Center is pretty much an isolated part of the game. Early tutorials will be either too easy for experienced players, causing them to quit the TC before learning something new, never to return; or players will tend to play through all the tutorials in one go, providing too much information at once and causing them to forget stuff before having a chance to use it in the actual game. Therefore, I think tutorials would work better as an integrated part of the mission structure, providing all the relevant information bit-by-bit. Play a clip when accepting a new primary mission, then unlock the tutorials at the TC and add an optional shortcut to go there to practice the new mechanic. Possible mission structure could look like this: Launch a rocket: how do rockets work? Get to space: learn about moving in a vacuum and re-entry heating Achieve orbit: missing the ground Specific orbit: orbits are weird Mun flyby: orbital transfers Mun landing: learn about landing and launching in a vacuum Mun Arch: learn to do a precise landing These missions should cover all the basics. After that, the game should open up more. Like many others, I believe there is too much focus on the monuments after the Mun Arch. It makes further progression feel forced, while it should be up to the player what to do next. This could be done by offering multiple primary mission sequences, each focusing on a different aspect of spaceflight and each accompanied by appropriate tutorials: Exploration missions: learn about transfer windows, ejection angles, gravity assists/captures and aerobreaking. Example missions: land on Duna, enter Jool SOI, dive to location X on Laythe, return surface sample from Eve. LKO missions: learn about rendezvous, RCS and docking. Example missions: rescue a stranded Kerbal, remove debris from orbit, build a space station. Probe missions: learn about power demand, ComNet and Kerbnet (when implemented). Example missions: launch a probe to Keostationary orbit, establish a relay network around Kerbin, launch a polar survey probe. Plane missions: learn about lift, stability, effects of wing shape and air intakes. Example missions: fly a plane for X seconds, fly to location X, achieve a velocity of X m/s, fly to an altitude of X km, achieve orbit using a spaceplane (all while only using jet engines). Maybe a bit off-topic, but I also think science progression should be linked more to the playstyle of the player. Now it's just collecting points by clicking an icon, but it doesn't make sense to unlock a Rapier engine while never having built a single plane, or learning anything about flight. Unlocking parts could be tied into the mission structure, where completing specific missions unlocks specific technologies. Another approach would be to link unlockables to certain achievements. Just launched an X ton rocket into orbit? Now you can unlock the Labradoodle for even bigger payloads. Just reached a height of X km with a plane? Now you can unlock the Rapier for even higher altitudes. Actually researching the technology could still cost science points, but it would now make more sense to have the option available. The prerequisites also provide the player with more challenges and it would actually feel earned to unlock a part.

I figured flying a plane would take me way too long, so I built a rocket for a ballistic approach. It took a few reloads to get the trajectory and landing near Kapy Rock, but because my DeltaV was a little limited, a precise landing proved challenging. In the end I settled for a few km of walking at 4x speed, which was still certainly faster than flying all the way. I took on Stargazer Point with the same approach, but after walking the last bit, I found out I actually had to land on top. So I went back to the VAB to build a more maneuverable lander. After countless reloads to fine-tune my re-entry, I finally managed to land on top! Then I realised I used a command pod instead of a lander can, so it didn't count. Again back to the VAB and do it all over again. I almost had the right re-entry again, but fine-tuning the landing proved more difficult than before. My thruster exhausts were apparently hitting the heat shield, causing the lander to flip in all directions and preventing burns longer than 1s. I stubbornly refused to go back to the VAB again, so I kept trying anyway. I finally succeeded and learned some valuable lessons, but flying a plane might have been faster in retrospect.

I know there are still many bugs and incomplete features to work on first, but those are obvious. It isn't really a priority list, just some problems and suggestions I would personally like to see addressed at some point. I don't mean procedural tanks, just incremental length. Otherwise, listing from short to long would be more logical than the current alphabetical order where 16 comes before 8. (Change it to 08 for all I care.) I want to know where on the surface of the body the collision will be. The end of trajectory icon doesn't account for body rotation.

Here's a list of features I would like to see addressed: VAB Parts should be listed numerically, not alphabetically. The X200-8 fuel tank should come before X200-16. Make part length incremental, specifically fuel tanks. There are a lot of parts, but there is no real difference between 2 FL-T400's and 1 FL-T800, so why not just make the length adustable? Make ladder lengths adjustable. Make building fairings more intuitive. The KSP1 method worked fine. Add a warning for blocked hatches. Address engine imbalance (also see fixing the methalox engines) Address command probe reduncancy. Charge and torque vary, but these can also be addressed with batteries and reaction wheels, so why all the variations? If it's just about looks, then just give them the same properties. Address communication part reduncancy. Why would I use a large dish when a small, radially attachable, deployable antenna has the same range? Add performance graphs for engines, air intakes and aerodynamic parts. Give each part a unique optimal working range. Add appropriate resource balances to staging info. (Air intake for methane engines, electricity for xenon engines, etc., adjusted for body, altitude and velocity.) Closing the body/altitude menu should not reset the staging info to minimal. Add more coloring options: eyedropper tool, favorites, hex/RGB codes. Map view / Tracking station Show AP/PE values while editing maneuver nodes. Add ability to add maneuver nodes in other SOI's. Add ability to add and adjust maneuver nodes while paused. Add next/previous orbit for maneuver nodes. Add suicide burn countdown, or at least show time until impact. Show altitude when clicking on a trajectory position. Add icon for collission location on surface (adjusted for planet/moon rotation). Add alarm clock list, showing planned maneuvers, SOI changes and upcoming transfer windows. UI Point-and-click nav ball as suggested by @BechMeister Dotted text font is difficult to read. Numbers 0, 6, 8 and 9 are especially hard to differentiate. Additional parts Electric propellors, mainly to use on Duna and Eve. Methane powered propellors for Kerbin and Laythe. High-pressure optimized engines for Eve and Jool. Deployable wings. Deployable ramps. Inflatable balloons for oceanic and atmospheric buoyancy. Inflatable cushions for soft landings.

At .1c the lorentzfactor is barely 1.005. You would need to go over .4c to achieve a noticable factor of 1.1, but I don't think that will be remotely achievable without mods. Since KSP already simplifies classical physics, adding any form of relativity to the base game would therefore be pointless. However, given that there will be mods with relativistic engines, time dilation would be a good addition to limit ship velocity and give players a hint of special relativity. I wouldn't underestimate the KSP community. You'd only need a mod to simulate .0000001x time, or build a ridiculously long ship and barn. Would be fun to watch though.

I agree with this and would like to add: Switch between hex and RGB codes Pipette: copy colors from part Save colors as favourite, beside agency colors

I could understand an infinite resource pool at Kerbin. I imagine Kerbalkind to be fiercly dedicated to its space program, so money restrictions always felt a bit out of place in KSP1. It didn't really work either, as after upgrading KSC it wasn't much of an issue anymore. KSP1 also had technical limitations like maximum size and mass, which did feel a bit more natural. Instead of upgrading KSC with money, bigger rockets could be made possible by unlocking new science tiers. However, that doesn't intrinsically reward efficiency, it just places restrictions on how you should play the game, which isn't very Kerbal. For me personally , an efficient rocket is a beautiful rocket, which is already its own reward.

Most methalox engines do. Only the Ant, Dart and Reliant don't have it as far as I know.