Nicias

Members
  • Content Count

    160
  • Joined

  • Last visited

Community Reputation

59 Excellent

1 Follower

About Nicias

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

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

  1. You might also want to look at the GravityTurn Mod, it is simpler for this task then MJ.
  2. 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. Here is the link where I work this out:
  3. I was thinking if doing a Jool 5 with separate Landers going directly to each moon in a flotilla and and crew shuttle going moon to moon. I used to do insertion into a gateway orbit for this kind of mission but had a screwup with my relay sats carrier and so tried the direct insertion and saved a bunch of DV. This is at 10x rescale.
  4. Hi, I recently had the idea to try and capture directly into low Tylo orbit from a Kerbin-Jool transfer. The thought was to add Tylo's Oberth to cut down on required dV. What I did was make a node to set my perijool to be the same as Tylo's orbit while far away (thanks MechJeb) Then once I was in Jool's SOI, I made a node almost right away and put in some retrograde to get an intercept with Tylo. Fiddling with this node (adding normal and radial components) I was even able to get the correct peritylo. This cost about 50m/s. Then I coasted down into Tylo's SOI, and burned at peritylo to capture. It saved a TON of dV. I didn't get an accurate estimate because MechJeb's dv calculator had a bug in it for a couple of days. But I had a whole spare stage! So I decided to run the numbers, to see what the savings really was. Here are my calculations. I used vis-viva for everything. Jool orbital velocity: 4129 m/s. Transfer orbit 2372 m/s. Excess velocity at Jool: 1756s m/s. That velocity at the edge of Jool's SOI (2.46 E 9) with Jools mu (2.83 E 14) gives a SMA of -9.90 E 7 (hyperbolic) That SMA and Jools mu gives a velocity of 3332 m/s at Tylo's orbit (6.85 E 7). Tylo's orbital velocity is 2031m/s, so excess velocity relative to Tylo is 1301 m/s. 1301 m/s at the edge of Tylo's SOI (1.09 E 7) with Tylo's mu (2.83 E 12) gives a SMA of -2.41 E 06 (hyperbolic) That SMA and Tylo's mu gives a velocity of 3141 m/s at 50km (target orbit radius 650,000 ). Circular orbit at that radius is 2049 m/s so the actual burn needs to be 1056 m/s. The delta-v map gives 160+400+1100=1660. So the direct injection method saves 36% That seems like way to good to be true. Is my math off?
  5. I think something is wrong with the dV calculator. If you just put a poodle, X200-32, and RC-001S together, the dV calculator reports a dV of 11259 and a run time of 439.3 seconds. Both are almost exactly twice as large as they should be. If you just use a RC-001S, Nerv, and Mk1 LF fuesalge, MechJeb reports 3305 dv and a run time of 235.3 seconds. Both are about 90% of what they should be. This is with a bare 1.5.1 install with just MJ-dev (and MJ for all) installed.
  6. I find the length of the shroud on the 3.75m- 2.5m thrust plate to be too long. I was thinking of make a MM patch to clone the part and make a new "short" version, like there is for the 2.5m-1.25m thrust plate. Is there any reason this wouldn't work? Edit: I think I got it to work. This is the patch I used: //add a short version of the 3.5-2.5m thrust plate from SpaceY +PART[SYplate3m2mX1]:NEEDS[SpaceY-Lifters]:AFTER[SpaceY-Lifters] { @name = SYplate3m2mX1T @MODEL { @scale = 1.0, 0.5, 1.0 } @node_stack_bottom = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_bottom1 = 0.0, -2.5, 0.0, 0.0, -1.0, 0.0, 3 @node_stack_top = 0.0, 0.1, 0.0, 0.0, 1.0, 0.0, 3 @title = SpaceY A3-2 Interstage Adapter (Short) @description = (3.75m to 2.5m) Customize your engine clusters, in either an upper-stage (with fairing), or lower-stage configuration - Short. Suitable for Poodle, Mainsail, and Skipper. @mass = 0.25 }
  7. Would it be possible to add interstage nodes to the 5m fairing? (and the 7m fairing from Expanded?)
  8. I gave it a shot last night and it seemed to work fine actually. Thanks!
  9. I see that Sigma Dimensions has been discontinued. Is there another mod to play a 10x rescale of the stock system on 1.5?
  10. Sorta. You can combine two maneuvers if one of them can be made to happen "at a specific time". So circularization works for that. So, set up the plane inclination how you want. Then use the maneuver planner to create a new maneuver to circularize at a fixed time of t=0 seconds after the last node. Then you go to the maneuver editor, and it should have "merge with next node" button. Click that and it will combine the two nodes.
  11. Has anyone tried the latest version with 1.5.x?
  12. Yeah, right now I just kinda ignore it. If the contract says to add 15 seats, I add 15 seats. The only downside is that I don't get the nice contact completion on hab inflation. The cupola thing is more annoying.
  13. Yes, that is correct. Let's say that a station has a hitchhiker and a 8 person inflatable centrifuge (inflated). I might get a contract that requests that I expand the station to support 9 kerbals (and indicates that it currently only supports 4). If I just switch to the station, the check box for "supports 9 kerbals" is checked. I can double-check when I get home.
  14. I agree. I just wanted the stock contract system to count them as having the crew capacity for the purpose of calculating the current capacity of a station for station expansion contracts. I suppose this was because that system was seeing the "CrewCapacity" variable and not the "DeployedCrewCapacity" variable. So I suggested switching the paradigm. Presumably, the parts report their current capacity as CrewCapacity when retracted and DeployedCrewCapacity when deployed. The contract system only sees the CrewCapacity when making new contracts (It honors "Deployed CrewCapacity" when checking active contracts. It's actually neat watching the contract go green when you deploy the hab.) I was suggesting switching the behavior. So that the parts report their current capacity as "RetractedCrewCapacity = 0" when retracted and "CrewCapacity = 8" when deployed. Nertea said this was impossible for other reasons.