NathanKell

RO includes appropriate ground stations on Earth (the DSN). The RP-0 FAQ covers this pretty well. The final orbit is about 2Mm x 3Mm, for a Venus orbiter contract.

@goldenpeach Yes, certainly we can come up with something. If nothing else you can help the Flight Director or Trajectory by watching various telemetry readouts and warning them when numbers go bad (or good). There's also all the rest of the stuff that's prior to (and after) flying the actual mission.

Sylph 2 Part 2 We finally near the Venus encounter with the Sylph 2 lander + bus spacecraft.

Also, I wonder if @e of pi and @Workable Goblin might be interested / willing to share some of their considerable experience for this endeavor.

Yeah, here's my current thoughts, adding on what Duo and others mentioned. Once we have a general idea of interest, we will move forwards. In the mean time, I suggest that all those interested in participating familiarize yourselves with the early part of the RP-0 career. It is very, very different from stock KSP. Sadly this is not the sort of things that lends itself to just applying existing KSP know-how--indeed, that can be counterproductive. A minimal-resolution RSS/RO/RP-0 install with only the required mods is very doable in 32bit even on Mac, let alone on Windows with -force-direct3d11 or -force-opengl arguments. It would also be a good idea to do a bit of reading on the rocketry and aviation experiments of 1945-1955 or so. The start of the RP-0 career models that era, before moving on to orbital flight; a history of early probes (the Sputniks and Lunas, Explorer and Pioneer, CORONA, etc) should also prove helpful. As for roles: here are the roles as I see them. I will consider three mission cases: an x-plane mission, an uncrewed rocketry mission, and a crewed rocketry mission. 1. X-planes. Flight Director: facilitates interaction and when necessary calls the shots. Emphasis on the former. Pilot: flies the aircraft, makes the split-second decisions as necessary. Trajectory: tracks the aircraft, computes trajectory and guidance information for use by the others. Designer: designs the equipment for use in the mission. Public Affairs Officer: collates the information from tracking and other sources and narrates for public consumption (including lowering the volume of mission control chatter when needed--unless people just want the direct feed, but the PAO role is fun too). 2. Uncrewed rocketry: Flight Director: as above. Probably also handles range safety. Trajectory: a harder and larger role now, since it also involves planning the maneuvers and the orbital mechanics necessary to achieve our goals. Guidance: flies the booster and/or payload. Designer: as above, though there is a distinction between booster and payload. PAO: as above. 3. Human spaceflight: As uncrewed rocketry, except also: Crew (one each, or combined) CAPCOM: handles crew <-> mission control communications so neither side is overloaded by crosstalk Life support The mission cycle would proceed as follows: We decide on a mission, dependent on funding, technology level, and contract availability (mostly milestone contracts, I presume, so they will pretty much always be available). We sketch out a mission plan, and determine our requirements in terms of hardware and delta V capability. (If needed) we research any required technology, and ground-test any new equipment. (If needed) we design any new boosters and/or payloads. We flight-prove any hardware from 4 if not already extensively flight-proven. Failure during an actual mission would be bad to catastrophic. (Concurrently) we make a detailed mission plan, involving: Launch window(s). Flight plan(s). Risk assessment and (if high-risk) what backups should be produced. Relatedly, failure modes and what to do in case of a mode occurring. Exactly how the roles shake out. Scheduling the day of flight. We integrate the hardware. We fly the mission. We conduct an extensive debriefing. We repeat, starting with 1, recalling that we now hopefully have more funding and more science. Am I missing anything notable here? @DuoDex: 1 is problematic due to the pilot changing. 2 I heartily support and I believe the above demonstrates that. 3. I definitely am open to roles changing between missions, and for there to be room during the non-flying portions of the mission cycle for lots of input. 4. Ah, a very nice idea! @Blue_Eagle7 @Choctofliatrio2.0 I hope that makes things clearer.

Very cool! For solar and body radiation you can probably harness the existing occlusion system that flightintegrator uses, it sets up occlusion based on from-the-sun and from-the-celestial-biody directions.

@adsii1970 thanks! But I don't want to steal you from RSP (or indeed anyone else--part of the impetus for this is that RSP was getting rather big and a second somewhat-similar project would allow for roles to be free again).

We are certainly not competing with RSP. The flavor of what we are doing is somewhat different, both because of the integration of RP-0 (and all that entails) and because our roles will not be hard and fast, but rather mission dependent. For example, for an X-Plane mission someone good at designing aircraft can design the plane, while someone good at flying them flies it, and the others do the other mission control tasks. By contrast for an orbital launch the roles might be rather different. Besides, even if we were taking the same approach as RSP, it wouldn't be competition, just more people doing a fun thing. ZNG I think you accidentally a word.

The current Real Space Program thread/project is proving very popular (and fun), so much so that it's time to start another. The idea is simple: together, we plan, design, build, and fly RSS/RO/RP-0 missions. We'll have to design for reliability and redundancy, because there are no reverts when you're doing it live, and you never know when TestFlight (or a fallible human being) might cause something to fail. The advantage of doing this within the RP-0 framework is that it gives us manageable challenges at each step, it has a natural space-racey progression, and the mod suite is known to work well together. It also gives rather more scope for planning and consideration than just taking each mission and payload alone. Finally it lets us seamlessly weave together rocket and aircraft missions while still sharing a common goal. @Red Iron Crown, @DuoDex, @goldenpeach, and @tetryds have already expressed interest, so I am hereby pinging them. For the current thread, see here!

Awesome!

atmosphereCurve uses pressure (in atmospheres). atmCurve uses density, normalized to 1 = sea level density for standard (288K) temperature.

For nostalgia's sake, here's my big sounding rocket from early on, the Grunt missile with a Terrier (dog names were later re purposed for capsules) sustainer playing the role of upper stage.

Since there's actually an uptick in interest in this, rather than overloading the existing crew I think it makes sense to start a sister organization. (So I'll be posting a thread shortly)

@komodo I did update the file to handle drag cubes seamlessly so the only issue is the rescaleFactor thing.

Are you running with terrain on high detail?

And finally there's RO Mini, which is like SMURFF but also applies a flat 1.6x rescaling to all parts (to fix wonky ballistic coefficients, high part count LVs, etc). https://github.com/KSP-RO/RealismOverhaul/blob/master/ROMini.cfg @Bumlebi I believe that is caused by resizing the KSP window once you've started the game, it's a stock/Unity issue.

That won't change slowing down, just how fast you heat up. The problem here is that KSP payloads generally have realistic mass for their use (~t for 1-person capsule, ~5-6t fully specced out 3 person capsule) but only 40% of the surface area, i..e 40% of the drag. That means you will have a lot of trouble slowing down. To fix you can use Realism Overhaul, or you can just use https://github.com/KSP-RO/RealismOverhaul/blob/master/ROMini.cfg (a simple MM patch that gives a flat 1.6x scaling, and real TWRs/structural fractions/etc). It's like SMURFF only it rescales too.

Wing L/D isn't the whole story, vessel L/D is. While all wings/control surfaces have the same AoA->lift and AoA->drag curves, that varies with mach anyway, and total vessel L/D at a given AoA is highly vessel-dependent.

Ah, what exactly does it entail then?

I'd say go with Duo; my strength is much more in building things than flying.

The other launch of that Mars window is Faerie 2. It's a repeat of Faerie 1, only this time targeted at Phobos (and the bus will remain in Phobos orbit while the lander/hopper hops). Soon after Faerie 2 (and Sylph 3) launch, Sprite 7 finally nears Jupiter and performs a flyby. The first picture is from the earlier course correction (a refresher if you will) and the following pictures document the flyby.

A general suggestion--and this may have already been discussed, apologies if so. But I would suggest that going forward the PAO (whoever s/he may then be) act more as a real-life PAO: the PAO should be the one describing the activities that can be seen in simple, summary terms; by contrast the audio from the mission control team should be quieted while the PAO is speaking. Similarly, for crewed missions, there should be three audio streams; the PAO (who lowers the volume of the others while speaking), CAPCOM<->crwe, and mission control.

@pingopete aha! That must be what it was. I'll try sans Scatterer. Thanks!

@Stephen Stiles what mods are failing? Remember, you don't have to select any of the suggested mods, you can just install the required only.

@K3achas update your KSP. 1.0.5 has been patched since the version you downloaded.