Rayder

Not sure if it's been reported yet, but... I've noticed a bug with the Octo-Girders when switching the configuration. When I'm switching between tanks, the pop-out shows tanks being added on, but not removed. That is, when I switch to a LF tank, it puts that resource in. Then when I switch to the oxidiser tank, the LF tank remains and now it has both. THEN when I switch to the LFO tank it adds in two new LF and O tanks. The part will just keep accumulating tanks every time I switch the part. The curious thing is, it seems to only be cosmetic. When I unclick the part and re-click it, the part shows the correct tanks. The mass display on the bottom-right seems to display correctly, for the selected tank. So I guess it's a relatively minor bug, but it's there nonetheless. KSP v1.7.1-2539 NFT Construction v1.1.1 (with B9PartSwitch and MM v4.0.2) No other mods installed.

Does it occur only with Kopernicus installed?

I don't know what to tell you. I checked in Kerbal Engineer and my test craft gives 4,239 dV and an Isp of 482. My math was wrong, and I checked the forum post I linked. You're right, the Isp is not simply (a+b)/2. But the math is complex, and I guess it's up to you whether it's worth the effort. Me personally, I just use Kerbal Engineer. Saves me the headache haha.

Centre of lift, different name for the same thing. You want to keep your CoL behind the CoM at all times. If you don't, without enough control authority your nose will flip around.

Agreed. Hitting the right windows is already difficult as it is. I can also recommend Precise Manoeuvre. Adjusting nodes really early is almost impossible to do by hand. The adjustments are just way too big. Dropping down from Tylo would be a good idea - no atmosphere means you can get nice and close. You could even try to line it up with Laythe direct then aerocapture - means insertion into Laythe could be almost free.

Agreed, however he claims he's only had this speed issue since slightly modifying the craft. To me, it seems there's a part he added that's adding excessive drag when it shouldn't be. I know this occasionally happens with some modded parts - Mk IV spaceplanes had serious drag problems with the crew cabin. I've also seen anecdotally that some cargo bays have this problem as well, even if they're occluded. Whether this is the problem OP is facing though, I have no idea. OP also stated he removed the parachutes but didn't say if that resolved the problem.

It's been a long time since I've used Rapier engines but is this because there's limited thrust to overcome the drag? Since only increasing the drag slightly the craft loses too much speed? OP, do you still have the original version of the craft that made it to space? If so, try reverting back and do another test run. Then start adding parts one at a time until you start having the speed limiting issue again.

As far as your original question goes, then no. There's no measurable efficiency loss by having a longer burn time. Even players who use Ion thrusters to go interplanetary, break up the burn into multiple stages do so for convenience, or to ensure the accuracy of the trajectory. Best engine for interplanetary burns?

Yes my scenario was still very simplistic, and ignored all the extra tanks, converters etc that you'd need to achieve it. But that's not needed to explain the concept. Reality is, if you add all the extra weight and ore, yes your actual m/s will change - but the difference in efficiency will not. The Nerv would still be worse than the LV-909, and using them both would be better still. Even if you added an extra 100t to my example craft, you still get the same order: Nerv: 854 LV-909: 881 Nerv + LV-909: 1,192 Nerv + Ore: 1,870 Remember that a core part of delta V calculating is the difference in the wet and dry weight. The only way to influence these numbers is to change the fuel capacities or the engines, which in my simple craft scenario we are not. By introducing fuel synthesis we are effectively modifying the available fuel which is why converting Ore the Nerv wins out.

When it comes to ore and converting to fuel, it's actually rather easy. Remember, when converting from ore to fuels the mass remains the same (with the exception of monopropellant). Consider my simple craft scenario. If you change nothing else, it's more efficient to convert to just LiquidFuel and use the Nerv engine. Why? because LiquidFuel is 45% of the tank. Also, LiquidFuel and Oxidiser have the same mass, but are just used in different proportions. How do we do it? Simple. Since the mass conversion from Ore to LF or Oxidiser is the same, you get the same out. Converting to LFO you'll get 14.4t of LF and 17.6t of O. But converting just to LF you'll get the whole 32t of LF. You get 2.2x the amount of LF as you'd get by doing an LFO conversion. As a rough guess, you'd get ~7,700 m/s using the Nerv from the same amount of Ore, as it would take to fill the tank of LFO, where you'd get ~5,600 m/s using the LV-909. I know my example craft isn't realistic, but consider that doing this for a useable craft in the game is much more complex, and it's dependent on the engines used, number of engines, tank sizes etc. There's simply too much to consider to give a generic answer.

Your rear landing gear are a pivot point. If the wheels are too far back you'll find you need a high speed before the craft will pitch up. If you bring the gear further forward closer to the CoM, the craft will pitch easier and you'll lift off easier. Ideally you want it as close to the CoM as possible, but not in front. Being a touch behind is best, so that the craft doesn't tip backwards. You also need to consider ground clearance. Having your landing gear further forward means the rearmost portion of your craft has the potential to contact the ground. You can either limit how much you pitch up, or you could add a small wheel there to prevent impacting the engine on the runway. I'm not sure on OP's mods, but I know in RCS build aid the red CoM indicator is an average CoM (between full and empty tanks). It's handy for placing RCS thrusters so that 'on average' you won't have an excessive torque when translating.

A craft using different ISP engines (for the same fuel type) effectively has the average ISP of all those engines. Multiple engine specific impulse math This thread discusses the deltaV of a craft with different ISP engines. You can effectively invert the equations to see what your remaining fuel mass will be if you use different types of engines. But overall your average ISP will be lower. Granted, given your specific case things become more complicated since you're involving different engine types and also fuel synthesis. This is further complicated by how much fuel mass you have, how much extra LF you have for the nuclear engines, the mass of the craft etc. KSP makes things slightly easier since fuel and oxidiser have the same weight and density. So for a given fuel tank, you can work it out. Let's use the nuclear engine and the LV-909 Nuclear: Mass - 3t ISP - 800 LV-909: Mass - 0.5t ISP - 345 Since you're carrying both engines we will add them to the weight of our fuel tank. Let's use a Jumbo-64 tank. Full Mass: 36t Empty Mass: 4t This gives us 32t of total liquid mass in the tank, 14.4t LF and 17.6t O. Now we can start working out our weights. Since the Nerv doesn't use the oxidiser, this means we have different 'wet' and 'dry' masses: LV-909 Wet: 39.5t Dry: 7.5t Nerv Wet: 39.5t Dry: 25.1t So if we sub all of this data into our deltaV calculations, for our simple craft of 1 tank and two engines, each engine separately would give us the following results: Nerv: 3,555 dV LV-909: 5,617 dV In this case, you can see that the LV-909 gets more delta V even though it's less efficient as it's burning away a lot more mass. BUT this is not what your situation is. You want to see if using more engines at once gets you more efficiency. For that, we now have to take in fuel usage rate into account. You also need to consider that as you're burning, some LF will be used by the Nerv so you'll have some excess oxidiser left over as dead weight. So let's re-sub all of this in one step, and calculate for both engines. Averaged ISP: (800 + 345) / 2 = 572.5 Wet Mass: 39.5t Dry Mass: 12.8t (5.3t of oxidiser remaining) Now I REALLY hope I got all my math correct, because running both engines together results in a total deltaV for this craft at 6,322 m/s. So yes, @Vanamonde is correct that using both could potentially net you better efficiency.

It really depends on the use case. Since you cannot land on Jool you don't need to get close to it unless you want to build a low orbit station or something - or doing science (Jool's 'low/high space' boundary is 4,000 km). Why it depends is because up to about 40,000 km (which lies just outside Vall's orbit, from memory), you can get huge fuel savings just by circularising up higher. The difference between a 40,000 km and 250 km circularisation is about 1,500 m/s deltaV. Going higher than 35--40 Mm doesn't save all that much fuel. What's more interesting is that if you go much higher than 200,000 km it actually starts to take more fuel to circularise, so it's the sweet spot to do your insertion. Caveat: this window is HUGE! Going down to 100,000 costs <50dV more, and going up to 300,000 only costs <10dV more. Going all the way up to 2,000,000 km only costs ~200dV more. This is the premise behind gate orbits. You're balancing the difference between your vessel's velocity and the velocity of your desired orbit. What's more, if you plan on returning to Kerbin then ~200,000 km is the most efficient orbit to leave from, so it could be a handy spot to setup your centre of operations. You'll be fighting Pol for the real estate though, so to avoid any accidents setup a little higher, maybe around 250,000 km. The difference is literally around ~2 dV for your insertion burn. Ultimately I suppose you could calculate it, but I suspect your instinct is correct - there just isn't enough in it. Your best option I'd say is if you really wanted to maximise your savings using Oberth, consider using manoeuvre node splitter. You can split your insertion burn into two parts: 1st part just enough to capture into Jool's SoI and then 2nd to do the circularisation. I suspect you won't save all that much fuel, however.

Indeed, it is mostly for curiosity / fun. I've been messing about with gate orbits and they're dependent on the excess velocity, which changes depending on the apoapsis of your transfer orbit (ie. the distance the planet will be when you arrive). Since the planet will be at a different distance at each transfer window, it was just finding a formula to plug in some numbers and get C3 out. After some investigations yes @Snark is correct: Duna doesn't change much. The difference is less than ~50dV for the whole ejection and insertion. The bigger differences come into play with Jool and Eeloo, which can be on the order of hundreds of deltaV depending on where they are in the orbit. Duna more or less was just used as an example.

Hello all, I've been doing some research on how planets move through their orbit and I've hit a snag. I'd like to calculate for example, what Duna's distance to the sun will be at a specific time and date in the future. Such as, what distance will Duna be from the sun at 'Time = 2y 120d'. Since we have all the orbital parameters available to us, I figured we'd be able to calculate it. Alas, its turning out to be more difficult. I've probably stumbled upon the equation somewhere but not realised what I'm reading.

So I've been able to narrow down where this issue is coming from: The sun shines through Jool from around Tylo's orbit. Closer than that, the sun disappears. This happens in map view and also in-game. The issue is coming from Kopernicus.dll, specifically the latest version (v1.5.1-1). I downgraded only this file to the one from v1.5.0-1 and the problem is gone. So this issue is coming from this file, specifically something added or changed for the latest version. EDIT: Disregard, the only reason it didn't work was because Kopernicus wasn't actually loading, despite not throwing any errors. I'll keep digging, but it seems to be an issue as far back as v1.4.5 EDIT 2: Okay I've realised this is not an issue with Jool, specifically. It's only most noticeable with Jool. It seems at a certain distance from a body, the sun ignores occlusion from that body and the sun shines - regardless of that body's size. You will see the sun from directly behind Moho at the same distance as Kerbin, or Eeloo and even Jool. It's like beyond a certain distance, occlusion isn't even considered anymore. This isn't a issue with most planets as they are small compared to Jool. But yes, for Jool the sun shines through the planet quite obviously.

Is it possible to have the part produce some ambient light around where the light is placed? It looks a bit odd for the light to come on but not have the part(s) around the light illuminate. This is how my lights appear: As opposed to lights from another mod:

I've just setup a fresh install of KSP. With only Kopernicus installed, I've noticed that the sun shines through the surface of Jool from about the distance of Tylo. This seems to appear both in the map view as well as from a ship landed on Tylo's surface. Anyone know of a way to correct this?

The data for a geostationary orbit around Kerbin is as follows: Orbital Period: 5h 59m 9.4251830898s Semi-Major Axis: 3,463,334.059488768 Using KER will get you extremely close but for perfect results either edit the save file, use Alt+F12 or HyperEdit.

Not sure if it's been mentioned, but is there a way to change the point where scatterer decides the flare has been occluded? I'm getting images like the one here. This one was taken from Moho: It seems that the flare is centered on a singular point in the center of the sun. If it were say, the same size as the sun the flare would cut out properly once the sun was fully occluded. Also, is it possible to have a fade out animation for the flare? The same way the stock sun fades out behind planets, instead of turning off abruptly.

As far as I know there is no auto-throttle feature built in. Your best bet is to fiddle with the power settings to give you just enough power, so that as you're just about to run out the sun will rise and you will recharge.

On the subject of new parts, one idea I had was adding a switchable tank to the octo-girders. It could be like a large heat sink, with elements that glow on the inside as it gets hotter. You could then attach radiators to this unit to dissipate the heat. Although the benefit of something like this could only be realised with heat pipes, so you could pump the heat into it.

Exactly. It seems either KSP or the system was limiting how much RAM to assign. As I mentioned adding in extra allowed KSP to use up as much as it properly needed without hitting the cap.

You might also find adding extra RAM is useful even if you're not hitting your limit or crashing. My KSP install was running on about 6GB in my system with 8GB and it seemed to run fine for a long time. Although I did have the occasional crash. I found that the game actually was running out of RAM and it was just hit and miss whether it was going to crash. I threw in some more RAM and I'm now running with 24GB. KSP seems to appreciate the extra breathing room and is now routinely using up to 9GB.

Agree with you here. As I stated in my first post in this thread, getting an SMA approximately right (such as you and I have) will keep your satellite stationary for far, far longer than anybody is willing to invest into a single savegame. Haha another wrench in the works. I checked Kerbin's sidereal rotation period in Hyperedit and the value it threw at me was 21549.4251830898. Not entirely sure how Hyperedit works in some circumstances but I assume that it's pulling the values directly from the game?