SFJackBauer

This information comes from a respected website (IEEE), so: Original article here: http://spectrum.ieee.org/aerospace/space-flight/apollo-13-we-have-a-solution-part-3 Part 1: http://spectrum.ieee.org/aerospace/space-flight/apollo-13-we-have-a-solution Part 2: http://spectrum.ieee.org/aerospace/space-flight/apollo-13-we-have-a-solution-part-2 Also http://www.universetoday.com/62339/13-things-that-saved-apollo-13/

Ok so assuming that foo is an existing part, and I would like to duplicate it and then just give it a new name, is this the way? $PART[foo] { @PART { @name = newfoo } }

Also, it could also be done this way: - Burn at perigee (295km) to raise apogee to 80,000km - Burn radially at apogee to reduce inclination - Burn at perigee to reduce apogee to 35,786km - Burn at apogee to raise perigee to 35,786km Which approach is cheaper?

Assuming the parking orbit was at 295km, and since its final apogee was 80,000km, the burn to reach this apogee would be 2804 m/s. After that, once the satellite reaches apogee, it will burn simultaneously radially and prograde to both reduce its inclination, and raise the perigee from 295km to 35,786km (I don't know if it will do a single burn or several burns over several orbits). Then, once its perigee has been raised to 35,786km, it will burn retrograde at perigee to reduce its apogee from 80,000km to 35,786km, which will consume 490 m/s of deltaV. Basically this pic:

Ok, where is the table-flipping icon when we need one... oh here it is. (ãƒŽà ² ç›Šà ² )ノ彡ââ€Â»Ã¢â€Âââ€Â» And I was typing ONE BY ONE... sorry I feel so ashamed I will bury my head in the toilet now. Well... not so fast. Its not perfect, it doesn't have mass or exact dimensions, or serial numbers... And most of the same-engine iterations will be taken care of by tech levels, this also reduces the number quite a bit.

Of course, I know this is a possibility. In the case you mention of the RS-68 is perfectly understandable - even though the RS-68 was never used outside the Delta, it is/was considered for Constellation in a cluster of six. So having one "clusterable" version is necessary. The quads... I borderline agree with picking a similar engine, multiplying by four and calling it "RS-68 Quad", for example. But if my first stage needs 5? Or 3? Having the stand-alone engines is much more flexible. One less engine to maintain. And then we will run out of real engines before filling all the mods engines... so what we do with the three NP Orbital Bertha models? When committing to only MMing-out the engines is obligatory to support ALL of them, like MFS does, understandably. Otherwise the user will have to comb through the parts to see which got resized and which didn't. If we do separate part.cfgs, we can pick only the engines that make sense. And it makes possible to filter through PartCatalog (I assume everyone who have more than 3 mods use PartCatalog). But I am assuming there are no other show-stoppers that prevent us from doing part.cfgs. Also I don't want to sound picky or whatever, I'm just used to plan things before doing it, at max doing an exploratory work to test the possibilites in a small scale, before fully committing. I've only had good results by following this philosophy.

Uh, thought I did. It is now.

Nathan I was thinking something more in this line: https://docs.google.com/spreadsheet/ccc?key=0Aotgw0qR1h0UdDhRazYxaDNPT0psVnhNNHFIVnZLM3c#gid=0 And then once the data was decided, porting to the excel and generate the cfgs. But one question first - is there any problem if, for the realistic engines, we make new part.cfg files, (reusing the original engine models with MODEL{} calls), which is what I was doing privately? Because its easier than being obliged to find a purpose for EVERY engine in the modpacks. Of course we would have to still generate the cfgs for MFS. This would allow more flexibility.

Just to give a glimpse of what could be done with the already existing models: Left to right: J-2, RL-10B, SSME. In the three models the attach node was moved to hide the "engine adapter" inside the tank. The last two engines (AIES C6 and NP Bearcat S2) were given a stretch in the Y-axis. Again, would be much better to have a modeller doing the actual models instead of this contortionism, but I think this looks decent. Another thing is I think the engines should have correct throttleability and restartability stats. I have to install the engine ignitor mod, haven't had time to check it out yet. There is the entire SpaceX pack here -> http://forum.kerbalspaceprogram.com/threads/29388-LazTek-SpaceX-Launch-Pack-2-0-1-w-Dragon-2-21-(8-2-13). EDIT - zzz Merlin is really good but oh... that huge top adapter

You mean calculating thrust and Isp given the bell geometry? Nope, I'm definitely not doing that I was just doing what I proposed barely a month ago in this post, although at a slow pace since my job is taking almost my full time for the last couple weeks. But my methodology has been the same, so yeah, there is a duplicate effort here. But I'm not in a hurry or in a race, I like to do things slow and surely. So if you arrive at something that can be released, talk to Nathan and go ahead.

Thanks for the ideas. I'll post pics later today of what I have so far, after also considering this and the recently-released RLA engines. I'm aiming to match the nozzle bell curve, mouth diameter and general visual characteristics as best as it can.

For sure, S-IC is there, I just removed it to get a better shot. BTW excellent job Nathan on putting those size tooltips on ST, very helpful! Chronic, mostly is as Razorcane mentioned, Editor Extensions, but in this case I attached to cubic struts since the engine model origin is at its center, not on top. I wonder if the COMOffset parameter can be used to change it... It could be tweaked to hide those weird engine top adapters inside the tanks when attaching.

I am hoping for a good J-2 model too, as we have the F-1 already (and its beautiful... I hope Hakari makes a J-2... and a SSME... and a RS-68 ). But in the meantime, after staring for a long time at photos and KSP engines, I found the AIES C-6 resized to 2.5 a good fit - the nozzle diameter ends up in 2m (the stretchy tanks in meter-steps are good for measuring). I'm going to tinker with the adapters to see if a good rounded bottom for the stage can be done. BTW I am building some personal-use cfgs where I am relocating the engines into real life names, counterparts etc, mostly american and european since we have Bobcat awesome pack for the russian ones. If anybody wants (or perhaps is doing) something similar, shoot me a PM so we can discuss ideas, share opinions etc.

Is there a spreadsheet with the engines list and stats, similar to MFS? It could be handy while I don't re-memorize all the thrusts / isps again.

Have you noticed the third stage cuts off with still 1230m/s in the tank? First three stages have 10226 m/s vacuum dv. Thus expended 8996 m/s of vacuum dv. Hmm I should have rounded to 9.0 then No way, if anything is MechJeb gravity losses dv expended counter that stops counting sometimes (occurs sometimes with me too). Drag losses should be at 300m/s max, and that is if you screw up. Regular real life rockets lose 150m/s. MAKC care to share the .craft file? It seems strange to me that it shows only two stages in MJ deltaV stats, when it is three right? (boosters, core and upper)? And you seem to have used MJ ascent AP is that right?

US-6 - Establish an Earth and space weather monitoring program. Mission Briefing Primary goal - Launch the MeteoSAT system into orbit, thus completing the satellite constellation needed for LEO exploration. Secondary goals - Test the concept of multiple payload deployment per launch. Payload MeteoSAT-1 e 2. Dedicated platforms to mapping of radiation belts around Earth, to monitor the Earth weather from space, and to monitor incoming Sun radiation. Lifter RL-3C, 170 tons, 4.5t to LEO Mission Results Success! Yesterday the KSC saw the trusted RL-3 rocket engines roar one more time to deliver another payload to space. The MeteoSAT twins will perform monitoring of Earth's complex weather system, crucial to mission planning in regard of launch and recovery windows. Also the twins will help scientists to build a profile of the radiation present in Earth's near space.

8.9 km/s to 200km orbit - and dual satellite deployment to GTO

The BSA is flexing their muscles huh? I guess its time for a space race with SEA? Looking good man. Its weekend, time to update mods, stretchy-tank some lifters and launch more stuff!

Ops haven't noticed ferram answer Sorry ferram, it seems you forgot to split the major axis in 2 to get the semi-major axis

You will arrive at approx. 100º of longitude (not latitude) forward. I did the calculations here. Basically: - The flight time to apoapsis for a GTO orbit is 5h 20m (19,165 seconds). - Also, considering that a Hohmann transfer puts your apoapsis 180º away from the initial burn. - Earth moves at 464m/s, a degree of longitude is 111km wide, so in 5h 20m it will rotate 8,892km, or 80º of longitude. - You move 180º, Earth moves 80º, then the difference is 100º.

US-5 - Launch an Earth-mapping satellite in a highly-inclined polar orbit. Mission Results Success! Today the EarthSAT-1 was positioned in a polar orbit (437x435km, 85º) beginning its long-duration mission of mapping the Earth surface. It also marked the first use of the CSAT tracking network, which provided engineers with vital information during the spacecraft flight to Earth orbit. There were, however, two small incidents - the first, when the payload fairing didn't separated cleanly as expected, and the second, when the third stage engined failed to throttle down to limit the max-G load factor. The spacecraft seems to be in regular conditions, and technicians are working on fixing this for the next flights.

Ouch, so the Romfarer plugin was killing my fps - I had the robotic arms installed. But your latest version (p2) is an order of magnitude better for me. Romfarer plugin will be sitting in the mod quarantine for a while... I'll attach the logs anyway, it may be of help. http://www./download/ga7dqod3tsnqxux/eclss_logs.zip i5 3570K @ 4GHz

US-5 - Launch an Earth-mapping satellite in a highly-inclined polar orbit. Mission Briefing Primary goals - Position EarthSAT-1 into a polar orbit. Secondary goals - Certify launch capability of the RL-1B lifter. - Verify operation of Earth mapping equipment supplied by SCANsat Inc. - Verify operation of the telemetry package. Payload EarthSAT-1 satellite, 430kg Launcher RL-1B, 36t Summary Under pressure for more scientific missions, SEA pressed forward its Earth-mapping project, using a modified RL-1 lifter for its requirement of a polar orbit. It will be the maiden flight of the RL-1B lifter.

Have you been able to open the lifter I attached before? It contains the satellite, so if you can open that, you're good. I think I used two different RCS tanks from AIES. Anyway here is the save: http://www./download/sqvzy6oqf6t22or/persistent.sfs BTW I am adding another mod to the mod stable: the Flight Recorder mod. I hope to be able to create nifty graphs from this.

Keep in mind that the center of mass of the external tank was off the center. The upper 35% of the ET houses the liquid oxigen tank, which comprises 82% of the total mass (620 tons). The remaining 65% of the tank is liquid hydrogen which comprises the remaining 18% of the mass (106 tons). Therefore to get a closer approximation of the shuttle center of mass during ascent, the center of mass of the external tank should be about a third down from the top. Also, may I ask you from where is that picture? I don't remember seeing it from my researches of the STS program.