Nicias

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 }

Would it be possible to add interstage nodes to the 5m fairing? (and the 7m fairing from Expanded?)

I gave it a shot last night and it seemed to work fine actually. Thanks!

I see that Sigma Dimensions has been discontinued. Is there another mod to play a 10x rescale of the stock system on 1.5?

I'm using stock contracts.

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.

Has anyone tried the latest version with 1.5.x?

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.

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.

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.

Well, crap. That's too bad. I really like the centrifuges, but I also like station building contracts. What would happen if I added my own MM config to changes the CrewCapacity to be the same as the Deployed value?

I don't understand how the inflatible/extendable parts are coded, but I see that they have in the cfg's, for example: CrewCapacity = 0 ... DeployedCrewCapacity = 8 Might it be possible to set them up to have: CrewCapacity = 8 ... RetractedCrewCapacity = 0 Of course, that would require recoding. It also might break other things and I have no idea how difficult it would be.

Hi, Great Mod! I'm having trouble where the contact system doesn't seem to count the inflated and/or rotation hab sections when doing "expand station" contacts. So it's value of "current supports" number is too low. Likewise it doesn't recognize the large cupola as a cupola.

I do basically this, but I also have a small module attached to the front of the docking port with a probe core, rcs tank, and rcs thrusters. A couple of meters out I uncouple this module and quickly thrust it out of the way.

If you turn off crossed on the decouplers and use fuel ducts going up then you might get the behavior your want.

Drop tanks on top of SRB's, times so that the tanks empty when the SRB's burn out. Free staging.

I don't know how helpful this is, but I realized that for many trips, most of the time is coasting. So if life support supplies (and their containers) are heavy, you want to stage them. Ideally you are never burning with any empty containers. So I have three LS container stages. The first one gets dumped before I burn for capture. The second gets dumped before I burn to go home, the last gets dumped before capture at home. I typically also have a couple of weeks on LS in on the Kerbin capture stage, in case I need to do a two-pass capture. This is using Snacks!, which mostly just adds a mass penalty for LS.

No, he's @JP_Magoo is correct. Surface gravity is proportional to M/R^2. Mass is proportional is d*R^3. So, surface gravity is proportional to d*R. If you divide R by 10, you have to multiply d by 10 to keep the same surface gravity. My favorite armchair astronomy fact is related to this. Tidal forces are proportional to M/D^3 (D is distance to body.) M is proportional to d*R^3, so tidal forces are proportional to d * (R/D)^3. Now R/D is (to good approximation) the angle the object makes in the sky. So since the moon and the sun have the same size in the sky, (to good approximation) , the ratio of the tidal forces from each is the same as the ratio of their densities. You can measure the tides to determine that the sun's impact is about half the moon's. So the sun is half as dense as the moon.

Ok, so I mathed the heck out of this. I used Mathematica for all of my calculations. I did everything as if you are going from Eeloo to Kerbin. I could re-run it to go the other way if I just change the AoP of Eeloo to negative its current value. I first ignored inclination. I determined both the dV for transfer with minimum eccentricity at a given departure angle. I also determined the minimum dV for a departure at the given departure angle with periapsis at Kerbin's orbit. The results range from 3141 m/s to 3740 m/s for both methods, departing at apoapsis for worst case and periapsis for best. Note that periapsis is at 0 or 360 degrees and apoapsis is at 180 degrees. https://imgur.com/rzZXYtZ https://imgur.com/usf927a As other have mentioned, the dV is dominated by the Eeloo burn. Now adding in inclination I first did it by correcting the inclination at the AN or DN that is on the way down to Kerbin. Again I used minimum eccentricity and optimized for dV transfers. For the least eccentric I got a range of 3782 to 5013 m/s. Departing at 226 degrees and 291 degrees. The range in inclination change is the largest of the factors. Breaking down the dv budget as Eeloo departure, inclination change, Kerbin capture gives: 3782 = 1221 + 410 + 2151 and 5013 = 1732 + 1289 + 1993. As you see the inclination burn is the biggest factor. (410 versus 1289) https://imgur.com/4LYot79 The same calculations minimizing dv gives: 3584 @ 100 degrees to 4882 @ 309 degrees. With breakdowns: https://imgur.com/SXO9sB4 3584 = 1289 + 203 + 2092 and 4882 = 1664 + 1255 + 1964 The minimum transfer one saves dv on the inclination by going a little farther out. than the mimimum eccentricity one. If you look at the graphs for these two you'll notice a sawtooth pattern to the inclination changes and hence the total. As the departure location of the transfer orbit approaches the line of nodes, the transfer gets cheaper as you are departing closer and closer to the node. As the departure location passes the node (100 and 280 degrees) then you have to correct at the lower node. So that 1255 in the above example is correcting right outside Kerbins SOI. This explains the jumps in the graphs. In practice you could roll that correction into the Kerbin capture and then have Pythagorean and Oberth savings. Finally I allowed for correcting the inclination at either node. That gave: 3619 @ 146 and 4512 @ 10 for least eccentric with breakdowns: 3619 = 1101 + 345 + 2172 and 4158 = 1834 + 417 + 1906 https://imgur.com/iT3COSl dv optimized were: 3531 @ 125 and 4495 @ 8 degrees, with breakdowns of: https://imgur.com/FjXfSgk 3531= 1122 + 265 + 2144 and 4495 = 1835 + 755 + 1906.

Slashy, Thanks for giving it a look :). That change is correct, the difficulty is in finding theta. Theta is the angle between the vectors. It is only the angle between the orbits if the velocity is purely tangential (so at apoapsis or periapsis). Take the limit of two orbits that 90degrees inclined to each other, but highly elliptical. If they have 1000 m/s radial and 1m/s tangential, then the angle between the two velocities is only about 0.08 degrees, rather than the 90 degrees. So you need to find that angle, it isn't just the relative inclination. Or you have to find the tangential velocity, which is easier, because it is just given by h/r (where h is the angular momentum of the orbit) but then you need to find the radius when you do the burn. Which means you need to find out where on the transfer ellipse the AN/DN is, which means you need to find the AoP of the transfer ellipse, which leads to my question about AoP. Basically, I am asking how you calculated velocity at the inclination change? -N

I am trying to run the numbers on this, and I think I almost have it. I just need to add in the inclination change. I have a couple of questions. 1) I'm trying to use the formula for an inclination change given at: https://en.wikipedia.org/wiki/Orbital_inclination_change My question is in that expression, if the inclination change is happening at one of the nodes, then f is 180 - w or -w right? w measures the angle between the semi major axis and the line of nodes, and f measures the angle between the current position and the sma. So if we are at one of the nodes, then f is the measure to the next node from the sma, so since the nodes are 180 degrees apart, its either -w (if we are changing at the ascending node,) or 180 - w (if we are changing at the desending node), That would make w+f 180 or 0 right? 2) I am parametrizing the transfer orbits by true anomaly (f) and eccentricity of the transfer orbit. To use the formula for inclination change I need the argument of periapsis for the transfer orbit. I know my radius from the sun at departure (r), I can work out the new aop (w) using: r = a * (1-e^2)/(1-e Cos[f-w]) Solving this for w gives: w= f +/- ArcCos[ (a (1-e^2)-r)/ e r ] With +/- depending on if I my current radial velocity is outward or inward at this time. Does that seem correct? With that done, added in, I think I could definitely work out the problem for any planet to/form kerbin. If one end is not circular, I don't think I could get it to work.

You could also turn off the RCS monoprop *tanks*.

The way to deal with inclination changes is to roll the into one of your burns. Then you get an Oberth boost, but more importantly a Pythagorean savings. For instance, doing a 700 m/s inclination change on top of a 2000 m/s ejection burn only costs: Sqrt(2000^2+700^2)=2119 m/s. @GoSlash27 I was looking at doing the math for a Hohmann transfer ellipse to ellipse, and found it to be rough. Even just doing ellipse to circle was rough. I couldn't figure out how to find the optimal burn to go from a given point on a given elliptical orbit to an new elliptical orbit with a given periapsis. Is there an easy way? Is it a safe assumption that the burn should be entirely retrograde?

I think @Tig is suggesting that the "every year" is "every synodic period." (Which is about a year for targets with very long orbits) Ignoring inclination, the question is then: Given two orbits, with given SMA and eccentricities (and AoP). If you departed your original planet at any random transfer window, what would be the maximum DV you would have to spend on the transfer (just counting hyperbolic excess, which is what I think he means by "from the edge of the SOI"). Equivalently. If you left the original planet's orbit (around the sun) at any point in the orbit using a Hohmann transfer to the target planet's orbit (but not necessarily hitting the target planet) what is the most DV you would need? In other words, there are good transfer windows and bad transfer windows, how bad are the bad ones?

This is just incredible! Great work!