wrexecute

Best way to eyeball it is wait until the orbiter is directly overhead or perhaps a minute before, launch into orbit as normal but keep your Ap lower than the target's by a little. Circularize at Ap, and now you have an orbit a bit smaller than the target, but you are steadily catching up now. Coast until you've gained enough ground but don't allow yourself to pass the target. Gradually extend your orbit to match the target and you will notice you don't catch up as fast anymore. This is how I do it the first few times, until I get that Tracking Center upgraded. BTW: You don't NEED to wait until the target is over the launch site, this just drastically cuts down the catch-up time you spend coasting at a lower orbit. If the orbital periods of 2 craft differ at all, enough time-warping will eventually lead them together, no matter how far on opposite sides they are at the moment. This just isn't always ideal like when you're using life support and need to work quickly.

This thing is awesome with Alarm Clock! The details it adds to alarms when using the plotter is just amazing. Even better, pair it all up with KCT and then you really gotta grind and design on a deadline especially with Duna coming up around the 225 day mark in a fresh career. OP: While non-optimal ejections are totally possible and explained very well in some posts already, waiting for the right window has been made less uncertain and less boring with the help of Transfer Window Planner, Kerbal Alarm Clock, and Kerbal Construction Time.

Heh, tell that to the walls crumbling around me! I just need KCT, KJR, FAR, KIDS, and RemoteTech then this captain is ready to set sail again. All seriousness, I can't wait to see what changes as a result of the new KSC mechanics. And with the inclusion of FinePrint into stock now, I only hope the dev team starts looking closer at this concept of time.

@UAL002 - Yeah, that's the one I messed with. I'm getting a switch between these formats when I use it: (WrongDay), (h),(m),(s) or (WrongDay), (hh):(mm):(ss) The further I get along the timeline, the worse it's getting. I first saw it at Day 6, the logs saying Day 2. Now I'm 30 days into the game and the logs are on Day 7-ish. It's 180 hours either way you look at it, just weird that they're not adjusted for Kerbin 6h days.

This is an excellent mod. Way better than trying to track everything on my phone calendar. One question: Does the time currently work? I have KCT and so my first launch wasn't until day 6, but the ribbons credit me for day 2. I see the Kerbin Time toggle in settings, but it's already on? EDIT: I get it now! It's working to change the display time format, I thought it meant something else. New Question: Is there an option I'm not seeing, to make the logs display the Kerbin day instead of a 24h human day? I can just math it out if not, but I thought I'd ask.

Hmm, this is embarrassing.. It appears to have been working the whole time, and I only thought it wasn't working because something was different about the tooltip in VAB. I also play a 10x Kerbol game with RftS engines, and they show a minimum throttle on the tooltips. In RO, this shows up as a minimum thrust (not throttle) I believe. I was getting these 2 confused. I derped, you see? LOL anyway thanks for another update!

I seem to have lost the throttling limits on engines. They will throttle all the way down now, like the stock engines used to. Let me describe the situation: I had a clean RO but slowly started adding pieces from other mods. At this point, I still have throttle limits. Next the game started frequently crashing on the end of flights. Engines still have throttle limits at this point, but I can't take the crashing anymore so I totally scrap the folder to the Recycle Bin. My Steam installation of KSP is completely fresh, validated, and untouched. I use it as a mother-folder to produce offspring installs in another location via copy/paste. So I create a fresh KSP off that, and start filling its GameData with the required RO mods. Lastly I check the mod list against my folder, make sure it's all there and finally install RO 6a11. This is when I noticed the engines had stock throttling. I have ONE unsupported mod: GoodspeedPump This is installed on every proceduralTank* part like so: @PART[proceduralTank*]:HAS[!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } I installed this after noticing the problem, because my last install had both Goodspeed and limited throttles working fine. In fact I thought this would fix my problem, since at this point my GamaData was identical to the last install minus the extra mods that started crashing me. OUTPUT LOG HERE

EatVacuum: You were dead-on about the TWR. It was way too powerful, and I built a lifelike R7 to compare. The R7 slowly inches up the launch clamps, beautiful star-shaped separation with no heat or flipping issues, and gets into a nice parking orbit. My other one by contrast, took off like a bottle-rocket, sometimes losing structural integrity on the way up. And yes, it was a big ol' nasty single-stage KeroLox lifter, pushing up a Hypergolic service module/MK1-2 pod. This may have worked in KSP but I obviously didn't follow Realism Overhaul's instructions of "forget KSP". regex: I'm taking your advice and getting another flavor of the game installed with the stock 6.4 scaleup and all my old favs. I am just getting so much mileage out of this little piece of software, between my bare-stock Steam install for career play and now a folder dedicated to RSS/RO and another for 6.4x and crazy mods. I personally can't say I've ever gotten 3 games out of 1 unfinished game anywhere else.

I will try out both the 6.4 and the full sized RSS. Speeds will definitely make more sense to me either way. It's crazy how small Kerbin feels when the machinery works like its supposed to.

First I'd like to say that since I've been using FAR, I haven't had much motivation to enter space since it's just so fun to tool around Kerbin with realistic aircraft. Now after getting back into the game to check out all the great things that have changed, I finally WANT to go to space. But I have a few issues in that area I'm trying to figure out. I absolutely NEED to have FAR, but I didn't realize how serious the "horror stories" were when they said how easy it is to get to orbit. So I thought I'd embrace RealFuel, RftS Engines, and KIDS(FAR to Real Adj setting). This is more like it... but I'm having a monster of a time trying to control the speeds of my contraptions. I either end up with a rediculous Apoapsis near the Mun, or I break apart trying to pitch down a bit. This is made extremely more difficult because of the engines pack having limits on throttling down. The early engines especially have little to no throttling down. Should I just give up and go big with RSS? Or is there some combo of realism that works and makes sense with stock Kerbin?

For me, rendezvous was the trickiest part. Your orbits are different and you're travelling at breakneck relative speeds, very likely to over or undershoot without experience. Once you get down to the 5km or less range and get that relative speed down, following MiniMatt's instructions step-by-step, you will find that the actual docking difficulty is much less severe than a rendezvous. Slowly drifting near your target, you will have all the time in the world to maneuver and eyeball things to your heart's content. If you don't mind addons Navyfish Docking HUD greatly outperforms the navball, no parts and no autopilot. Just a UI that only pops up when targeting a dock port. Another thing: Unless your craft is exceptionally heavy, you will have too much translational power to dock effectively. CapsLock by default toggles all directional and translational movements to precision mode, and you will know this when you see the Pitch/Yaw/Roll arrows on the bottom left screen turn blue.

See, I was just firing them straight up like the first way. That explanation helps a lot. Kinda combines both ways, skipping LKO circularization. It even trimmed down my rocket a little, as it was slightly overpowered for the sake of just getting to 2868km very quickly before any major longitudinal changes relative to KSC. With a normal-ish launch profile, some patience and a 4hr period at 2868km, I only need to wait a few orbits before I'm back over KSC at the right altitude for an initial release.

Which of these would take less effort? 1. Launching something straight up to geostatic altitude and circularize? 2. Launching to a stable LKO then raise Pe to geostatic altitude and circularize?

Sure thing. They go: Waste, WasteWater, and also I left out CarbonDioxide. They're defined names are CamelCased like that. These resources don't mean life or death since TAC autodumps any excess, but I can definitely see a use for waste pumping. Greenhouse comes to mind.

Try this out, I use it and love it. It would pump anything from TAC. I've also thought of ECLSS even though I'm currently not using it. It even grabs tanks with no default resource definitions like Spherical and Toroidal utility tanks after using MFT to fill them in VAB. It would take care of RocketParts, Ore and Metal as well.: //------------------------------------- // TWEAK FOR MFT @PART[*]:HAS[@MODULE[ModuleFuelTanks],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } //------------------------------------- // TWEAK FOR EPL @PART[*]:HAS[@RESOURCE[RocketParts],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } @PART[*]:HAS[@RESOURCE[Ore],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } @PART[*]:HAS[@RESOURCE[Metal],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } //------------------------------------- // TWEAK FOR TAC @PART[*]:HAS[@RESOURCE[Food],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } @PART[*]:HAS[@RESOURCE[Water],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } // This should grab ECLSS as well @PART[*]:HAS[@RESOURCE[Oxygen],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } } // If not then this will @PART[*]:HAS[@RESOURCE[CO2],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]] { MODULE { name = GoodspeedPump } }