Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

64 Excellent

About Nicias

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Are you asking about the numbers or the image? I can definitely help with formulas for the numbers.
  2. Does anyone know of a way (MM patch I assume) to add interstage nodes to the fairings from this mod?
  3. Does anyone have a patch to add interstage nodes to the SpaceY fairings?
  4. Same result. Also happening around Plock. I think it happens with all OPM bodies. Put the logs up here: https://filebin.net/oedgokihhbx529np
  5. I'm having trouble with my OPM/Rescale install. Something is wrong with Thatmo. The surface blinks on and off, and when I reach the surface my lander always explodes. I tried removing Rescale/Sigma and now I can land, but landing gear go through the ground. My lander rests on its engine, but the gear go through the ground. retracting or extending them makes the lander jump. I tried replacing the Thatmo height, color, and normal dds's with those from Karen, and that worked without Rescale/Sigma, but then same problem showed back up with Rescale/Sigma installed. Any suggestions on
  6. Ok, I use this post all the time, and did some more math on it and found a few things out: First, as @GoSlash27 points out in the other thread, this works out to r= -2a (where a is the SMA of your departing orbit), It doesn't quite work out as nicely as @Red Iron Crown suggests since we have finite SOI's. What you get instead is: r = 2 / (v^2/ u - 2/ SOI). Second, when you use these gate orbits, the maneuver dV is equal to orbital velocity. Surprising but not unusual in these kind of optimization problems. Third, if you are using a rescale, as long as distances and radii all s
  7. Well, 10 was just a Well, actually it was more. I wanted to move a maneuver from 500 days from now to the current (~3 hour) orbit. 10 was just a place holder.
  8. Is there a way of adjusting the timing of a node by more than one orbit at a time? I would like to be able to move a node say, 10 orbits sooner in the Maneuver Node Editor.
  9. You might want to look at this mod: and this thread: I tend to go with a start TWR of 2 for a SRB +drop-tank first stage, then 1.5 for a second stage and 1 for the third stage. I'm working at 10x rescale using SMURFF, so I need quite a bit more DV to get to orbit (~8000) I also found via simultation, that (ignoring atmosphere) an optimal gravity turn uses almost the same dv as porpoising to maintain time-to-ap. (what GravityTurn will do) So, once i get out of the lower atmosphere, I don't mind if I end up porpoising.
  10. If it's any help I recently found that constant vertical velocity launches tend to use almost the same as optimal gravity turn launches. The benefit is that dv of CVV launches can be calculated analytically. Assuming constant TWR and zero vertical velocity, and neglecting any sideral rotation, gives that if you are taking off from a body with a given mu and r with a certain twr, and going for a zero altitude circular orbit, it takes: (1/2)*Sqrt( mu/r ) * twr * ln( (1+twr)/(twr -1 )) If that helps.
  11. Part of the problem is that the inverse-square law for solar intensity is incorrectly modeled in KSP. It should be inverse square of the distance from the center of the sun, but it is inverse square from the surface. This doesn't make much of a difference away from the sun, but when you get close the intensity goes up way faster than it should, with the surface effectively having infinite temperature.
  12. I just wanted to share some off-label use I've been getting out of GT. I've been using it to implement constant vertical velocity takeoffs. (Only recommended for vacuum launches, also I've been using 10x rescale and SMURFF so I have DV costs that are about sqrt(10) times larger, but I have much better mass fractions.) The idea is to use just enough vertical thrust to keep from crashing into the terrain. In terms of GT settings, I set the starting velocity to 10m/s (or something small, but enough to give the vehicle time to get truly vertical) time to AP I set to 20s for both start and en
  13. You might also want to look at the GravityTurn Mod, it is simpler for this task then MJ.
  14. You will probably want food for the way back too. So you should pack 601 foods for the journey. You also need food for the dwell time at Duna. You can over-estimate and use the synodic period 1/(1/(Kerbin Year) -1/(Duna Year)) which gives 2.15 years (916 days). This is the time between transfer windows. So you should pack about 1500 days of food. You could improve that guess by looking at when the next duna-kerbin departure window is after each kerbin-duna arrival window. I did that a while back and found that they are separated by 529 days. So you really only need 1129 days of food. H
  • Create New...