Rabada

Thanks to advice in this thread, I successfully sent Jeb from an 80 km Low Kerbin Orbit to briefly exiting Kerbin's SOI and entering the Sun's SOI for a couple hours, and then I was able to return Jeb to Kerbin. All together it took a little over a thousand m/s of dV. The ejection burn from Low Kerbin Orbit to a Kerbin escape trajectory cost about 950 m/s of d/v, then once Jeb escaped Kerbin's SOI, I needed a 90 m/s burn to plot a return trajectory back to Kerbin with a 25 km periapsis for an aerocapture. When I first tried to accomplish this, I originally attempted to plot escape trajectories similiar to the ones you describnes, the escape trajectories at first had Jeb exit Kerbin's SOI moving in Kerbin's prograde direction, and then I tried again having Jeb exit in Kerbin's retrograde direction. However to return to Kerbin in a short amount of time from either direction cost a lot of dV. After I posted this thread, I read Snark's reply where he suggested that I exit Kerbin's SOI moving radially out from Kerbin. By exiting radially out, Jeb ended up in an orbit with a slightly higher apoapsis and a lower periapsis than Kerbin's orbit, but a very similiar orbital period. After Jeb exited Kerbin's SOI, it only took a small retrograde burn to return Jeb to Kerbin from the Sun's SOI.

I personally never found Munar gravity assists that useful. The amount of dV you save never really seemed worth it to me. However I do find reverse gravity assists to be incredibly useful. I sent out 4 probes to Jool earlier today for contracts and science around the moons. I was able to set up a Laythe Reverse gravity assist to capture each probe by only spending about 10 M/s of dV. I should write up a guide on how to do that.

Ah! That makes sense! I was mostly messing around with ejecting prograde and retrograde, I never thought to try ejecting anti-radially. I had an ejection angle mostly anti-radial and a bit prograde relative to Kerbins orbit. This put Jeb on an orbit slightly larger than Kerbin's and a bit offset once he escaped Kerbin's SOI. To return, I only had to burn 80 m/s retrograde with a little bit radial burn and I got a Kerbin intercept with a 25km periapsis 9 hours after making the escape. This makes perfect sense to me now. By ejecting radially with a bit of prograde, I eject Jeb ahead of Kerbin's orbit, but I sent him into an orbit that is higher and thus slower than Kerbin's, so that allows Kerbin to catch up. And the little burn seemed to speed up this process. Thanks! Edit: Also, the reason I am doing this in my game is mostly to get a bunch of Kerbals some experience to level them up, thanks again!

I've been playing KSP for a very long time, and there is one orbital maneuver I cannot seem to figure out. In most of my career mode games I usually do a mission where I will have Jeb escape Kerbin's SOI to gather some good science. Usually it seems to take about 950 ish dV to get on a Kerbin escape trajectory, and another 950 dV for me to plot a kerbin return. I can't figure out a way to plot a return trajectory after escaping Kerbin's SOI that doesn't use a lot of dV, and I feel like it should be possible. I usually play with lifesupport mods, so I don't want Jeb to be on too long of a mission. What is the most efficient way to briefly escape Kerbin's SOI and safely return?

Its hard to say... We need more info... There's a ton of different ways this could happen. My best guess is that either an important requisite mod didn't get installed or a conflicting mod did get installed. Could you post a pic of all the folders in your gamedata folder? Also if you could host the output_log.txt found in your KSP_Data folder somewhere in its entirety that would be very informative on whats going on.

Reaction wheels work fine for me. Which command module did you try this with? If I recall correctly Realism Overhaul removes the reaction wheels from the stock command modules and you have to add a seperate reaction wheel part.

I'm curious why the Sphere of Influence of most of the moons is so small? Is the size of a SOI defined somewhere in RSS configs? For Example, The Sphere of Influence for Io, which is larger than Earth's moon, only extends to an altitude of about 5500 km above Io. I think they should be larger for a couple reasons. First of all, they can be very difficult to plot an intercept towards, and encounters with these moons can be very brief. Also, it seems to me that attempting gravity assists using these moons is almost useless because these is very little time for the moon to affect a trajectory.

I agree. I would also really like to have the option of researching the longer range Remote Tech dishes without having to unlock many of the moon techs. I would really enjoy playing a game where i got most of the science to develop by space program from interplanetary probes instead of land on the moon. Also, while Autochton is right, I believe that only OMNI antennas get a bonus from multiple antennas, while the directional dishes don't. The KR-14 with a 1000Gm dish reange is the first dish you can use to communicate with craft in orbit of Jupiter. I think it costs 300 science to unlock the node with the KR-14.

Yeah Smoke FX causes stuttering for me and I'm running an overclocked 5960X. Smoke Screen has button for the toolbar mod. (you can see it in the top left of my pic. That will bring up a menu where you can change the max number of particles that smoke screen will use. I think its set to 4000 stock. KSP ran a lot smoother after I set that to 500.

Since I barely ever use IVAs, I like to delete the IVA interiors to free up about 118 MB of RAM. The interiors are stored in the GameData/Squad/Spaces folder. I delete everything inside that folder except for the Placeholder folder. Now those parts will still need an IVA, so I edit the .cfgs of all Squad's parts with an IVA to use the placeholder IVA. To do this I looked for the INTERNAL module in the .cfg and replaced it with this. INTERNAL { name = Placeholder } Edit: This could probably be done with a module manager .cfg instead of editing Squads files directly, but I don't know how to write it.

I agree. It kinda seems to me that perhasp whoever set that price messed up the unit conversions. I'm pretty sure that 1 fund in RO is supposed to be equal to 1,000 US dollars (in 1950's dollars balanced for inflation I believe)

I have a quick bug report I came across in RP .37. The code that adds avionics for the mk1-2 command pod has a typo in the avionics.cfg. Line 34 reads this: @PART[FASAApollo_CM|Mark1-2]:FOR[RP-0] When it should read this: @PART[FASAApollo_CM|Mark1-2Pod]:FOR[RP-0]

This is probably what's causing your problem. do a clean install without these two mods. Kopernicus is included in the RSS download, so when you installed Kopernicus into your game, it probably overwrote the RSS configs with configs meant for the stock solar system. I don't know if the expantion mod is compatible with RSS, but I highly doubt it. Edit: Also the outer planets mod is incompatible with this mod.

I would like to make a suggestion. I love the idea of adding avionics packages, but I do find them a bit difficult to integrate into my rockets easily. I suggest that RP-0 use KW Rocketry's radial SAS parts as avionics packages. Here is a quick Module Manager config I wrote that adds avionics to those parts. @PART[KWSASmodule2mHalf]:FOR[RealismOverhaul] { MODULE { name = ModuleAvionics massLimit = 90.0 } } @PART[KWSASmodule3mHalf]:FOR[RealismOverhaul] { MODULE { name = ModuleAvionics massLimit = 240.0 } } @PART[KWSASmodule5mHalf]:FOR[RealismOverhaul] { MODULE { name = ModuleAvionics massLimit = 640.0 } } I really like to use those parts because they look good with a rocket, they are aerodynamic, and most of all they are very convenient to use. Also tweakscale seems to already be set up to adjust their size, so these parts would not be limited to 2.5m, 3.5m, and 5 m. Here's a quick example I mad using 2 of the 3.5m SAS halfs. The numbers I put up were just an example. I would also suggest removing the reaction wheels from those parts, and adding some electric charge or whatever. I'm not sure where it would fit in the current tech tree but I could see using these parts to represent using lightweight and power efficient computers for avionics near the end of the tech tree.

I have a couple questions about using ullage motors. I've had RCS fail to settle the fuel tanks on some of my larger craft. Im guessing that there is minimum acceleration needed for ullage? What is the minimum? Also, what is the best way to set up the staging for ullage SRBs on the second or third stages of rockets? For example here is a rocket to put the first Kerbal into orbit of the Earth in my latest career mode game. When my main stage runs out of fuel, I hit the spacebar (S6) to eject my main stage. Then I usually wait about 4 or 5 seconds then I'll hit spacebar (S5) to activate the 6 ullage sepratrons. Then I'll wait about 2 seconds and hit the spacebar (S5) right before the ullage sepratrons run out of fuel. This is my standard way to set up my staging for most rockets, but often times my engines fail to ignite. (I'm using RF v10.6 so I don't think its the "says stable but fails to ignite" issue) And finally, Is it a bad idea to limit the thrust on SRB ullage rockets? I used the small sepratrons from Ven's revamp as the ullage rockets for my second stage. Their default burntime is about a second. Initially I had 4 of them with a burntime of 4 seconds but I had issues where only one of the 2 Agena 80xx Engines would ignite. After I added 2 more sepratrons and reduced their burntime to 3 seconds this problem went away. Now I'm wondering if the ullage SRBs would work better at full thrust. At first I thought increasing the SRB burn time would give the fuel in the liquid fuel tanks more time to settle. Now I don't think that's how it works though.

What version of MechJeb are you using? Try deactivating your engines and see if MechJeb is better at turning with RCS with the engine deactivated. Another possible solution would be to try updating MechJeb to the latest stable dev build. There was a bug with how MechJeb reads the torque available to a craft where it thinks it still has torque available from engine gimballing when the engine is not burning. I submitted a report in the official MechJeb thread a week or two ago. A subsequent dev build was released of MechJeb that had a fix for this issue, but I have not had the free time to test it. Also if I recall correctly deactivating the engine (and maybe disabling the engines gimbal) also avoided this bug.

So I've fallen in love with this mod lately! Great job guys! I have no idea how to program, so this has been a huge challenge for me! Ive been writing programs lately to launch rockets using the Realism Overhaul mod. I think that I've come very close to getting a launch script fo work well. THere is one part that I am stuck on, getting my second stage into a circular orbit. I Can't figure out how to get my second stages to go smoothly into orbit. Specifically I can't figue out how to actually to pitch my craft upwards enough to cancel out Gravity losses. ELSE IF runmode = 6 { IF VERTICALSPEED > 0 {Lock STEERING TO PROGRADE. } ELSE IF VERTICALSPEED <-90 {SET PitchUp TO -45. } ELSE SET PitchUp TO ((-1)().25)VERTICALSPEED). LOCK STEERING TO ANGLEAXIS(PitchUp,PROGRADE:STARVECTOR)*PROGRADE. } EDIT: Here is my latest version, I think that it works well. ELSE IF runmode = 6 { IF SHIP:PERIAPSIS > 200000 { SET THROTTLE TO 0.0. RCS OFF. SET runmode TO 0. } ELSE IF VERTICALSPEED > 0 { LOCK STEERING TO PROGRADE. } ELSE IF VERTICALSPEED < 0 { LOCK STEERING TO ANGLEAXIS(PitchUp,PROGRADE:STARVECTOR)*PROGRADE. IF VERTICALSPEED < -140 { SET PitchUp TO ( -45 ). } ELSE IF VERTICALSPEED < -10 { SET PitchUp TO ( -10 + ( .25 * VERTICALSPEED ) ). } ELSE IF VERTICALSPEED < 0 { SET PitchUp TO ( VERTICALSPEED ). } } } WAIT .001. (This is all inside an UNTIL Loop.)

I have had a similiar issue with different SRBs, I think it was with the Ariene V's SRBs. Eventually I figured out that the problem I was having was that I was waiting until the SRBs burned out before I staged them. However in real life SRBs are still burning when they are staged. the thrust curves in this mod for SRB s has them still burning but barely producing any thrust for quite a while after they should have been dumped. since I waited for them to completely run dry before I staged them, I basically had my rockets carry a bunch of dead weight that provided barely any thrust. This drastically reduced the amount of dV I got from my rockets. Now whenever I add SRBs to my rockets using the realism overhaul mod, I look them up online first to find their burn time on Wiki. I always keep the thrust limiter on them set to 100%. When I launch my rockets I discard my solid boosters a second or two after the burn time I find on Wikipedia. For example, if I'm using a GEM 60, I'll ditch my SRBs at T+ 93 seconds because according to this the burn for 91 seconds. Lately I have been using the Smart Parts mod to automate this and it works very well.

I think I figured out what was going on with the Science Lab. I think that there was a conflict with Ven's overhaul mod. RO re-sizes the science lab with this code: @PART[Large_Crewed_Lab]:FOR[RealismOverhaul] { %RSSROConfig = True !MODULE[TweakScale] { } %rescaleFactor = 1.6 @node_stack_top = 0.0, 1.830905, 0.0, 0.0, 1.0, 0.0, 4 @node_stack_bottom = 0.0, -1.830905, 0.0, 0.0, 1.0, 0.0, 4 Ven's Stock Revamp mod uses module manager to delete the Mesh for the Science lab and replace it with Ven's model. I think that the "%rescaleFactor = 1.6" part of the code is buggy with re-skinned parts. When the part is loaded in the VAB, or when the part is launched from the VAB to the launch pad, that portion of the code seems to work. However, when a craft is loaded from the Space Center or the Tracking Center, the rescaleFactor will fail and the part will revert to its stock size. I was able to figure out a solution. Using "%MODEL {scale = 1.6, 1.6, 1.6}" instead of a rescaleFactor seems to avoid this bug with re-skinned parts. It took me a little while, but I was able to write a Module manager script that fixes this problem and works both with and without Ven's Revamp installed. I'll post my edited version of RO_Squad_Science.cfg below: @PART[avionicsNoseCone]:FOR[RealismOverhaul] { %RSSROConfig = True @mass = 0.50 @MODULE[TweakScale] { @type = RealismOverhaulStackSolid } } @PART[GooExperiment]:FOR[RealismOverhaul] { %RSSROConfig = True @mass = 0.075 !MODULE[TweakScale] { } } @PART[Large_Crewed_Lab]:FOR[RealismOverhaul]:NEEDS[VenStockRevamp] { %MODEL { scale = 1.6, 1.6, 1.6 } @node_stack_top = 0.0, 2.929448, 0.0, 0.0, 1.0, 0.0, 4 @node_stack_bottom = 0.0, -2.929448, 0.0, 0.0, 1.0, 0.0, 4 } @PART[Large_Crewed_Lab]:FOR[RealismOverhaul]:NEEDS[!VenStockRevamp] { %rescaleFactor = 1.6 @node_stack_top = 0.0, 1.830905, 0.0, 0.0, 1.0, 0.0, 4 @node_stack_bottom = 0.0, -1.830905, 0.0, 0.0, 1.0, 0.0, 4 } @PART[Large_Crewed_Lab]:FOR[RealismOverhaul] { %RSSROConfig = True !MODULE[TweakScale] { } @description = The mobile processing lab was developed to help increase the amount of science we're able to do in the field. Instead of needing to haul samples all the way back to Kerbin, the mobile lab will allow you to process these samples on site! Also has the equipment necessary to clean out and restore functionality to inoperable experiments. Contains O2 supply for it's scientists, however there is no food or water allowed in the science facility. Ships with 1 day supply, able to store 30 days. @mass = 12.5 @MODULE[ModuleScienceLab] { @RESOURCE_PROCESS[ElectricCharge] { @amount = 800 } } MODULE { name = ModuleFuelTanks volume = 750 basemass = -1 type = ServiceModule TANK { name = ElectricCharge amount = 43200 maxAmount = 43200 } TANK { name = Oxygen amount = 2520 maxAmount = 75600 } TANK { name = CarbonDioxide amount = 0 maxAmount = 1200 } TANK { name = LithiumHydroxide amount = 3 maxAmount = 90 } } MODULE { name = TacGenericConverter converterName = CO2 Scrubber conversionRate = 4.0 // # of people - Figures based on per/person inputResources = CarbonDioxide, 0.0062500000, ElectricCharge, 0.010, LithiumHydroxide, 0.0000085683 outputResources = Water, 0.0032924498, true, Waste, 0.0000191062, false } } @PART[science_module]:FOR[RealismOverhaul] { %RSSROConfig = True !MODULE[TweakScale] { } } @PART[sensorAccelerometer|sensorBarometer|sensorGravimeter|sensorThermometer]:FOR[RealismOverhaul] { %rescaleFactor = 0.5 %mass = 0.001 } Here is a download of the script. I'm really proud of that fix, but its also the first coding of any type I've done, so I'd like to know what you guys think, Thanks!

I was able to get this bug to appear with the following steps: I started by unzipping a clean install of 32bit win ksp .90. Then I downloaded the newest Ckan.exe, placed it in the new KSP_Win folder. I selected only Realism overhaul and RPO for ckan to install. I let ckan install all the recommended mods that were pre-selected, and nothing else, then I launched KSP from ckan, and started a sandbox game. I turned off Kerbal Construction time, then I built a the stock science lab with a Science junior on top in the VAB, then I launched it. I extited to the space center from the launch pad, then I loaded up the craft from the space center and when I went back to the science lab, it was too small. Here's a pic, and here is the output log. Edit: This also seems to happen in my own personal install that I manually installed and made sure all the mods are up to date.

I have had the same issue with the science lab re-sizing. I don't think that it has anything to do with Engineer. I've seen similiar bugs with re-sizing parts and I'm guessing that the problem is either in the RO .cfgs that edit the part (unlikely, the code looks fine to me), or the problem is in module manager itself (unlikely), or that the problem is a stock KSP, which seems the most likely to me. The Lab is already pretty buggy in stock KSP. In place of the stock science lab, I used the science lab part from the Taurus Crew Capsule Mod. It's not quite the right size, but it looks a lot better than the stock science lab in my station. Here are two pics, its inbetween the hitchiker modules. Edit: The issue for me could also be Ven's Stock Revamp.

I have had some crafts appear onto the launch pad with empty or partially filled cryogenic fuel tanks. I always attach FASA Umbilical Towers to my craft in the VAB. I then turn on their fuel pumps on the launch pad to fill them up. Also I have TAC fuel balancer installed in my current game, and that mod allows you to fill empty fuel tanks as long as your craft is still on the launch pad. I have not had any issues with non-cryogenic fuels

That sounds really awesome! Unfortunately it also sounds like it would hit the 32 bit limit pretty quickly. I'm curios, what resolution do you play KSP in? I recently got a 4k monitor, and while I love how much screen space I have with KSP in 4k, I also had quite a bit of trouble reading some of the small text UI elements. I would abolsolutely love to see this gigantic texture on Earth in 4k.

Really he should only try to take these pictures at night... Everyone knows that is the best time to land on the sun. OP, perhaps you could try the ambient light adjustment mod? Normally it is used to make the game brighter when your craft are in Kerbin's shadow, but I just checked it and it also can make the game slightly darker.

I like this new avionics feature! It makes building small probes more interesting and it makes solar panels a lot more important in a cool way. It add some new interesting restrictions to the rockets I build. I'm about half way though the tech tree and I have been mostly using the Agena Aviotics package for most of my probes, and attaching additional avionics units as needed. Protip!: The procedural interstage adapter part has a third attachment node that you can use to hide additional avionic units as needed. I would like to make a couple small suggestions: First of all, I'm only halfway through the tech tree, I would really like for there to be a probe core/avionics package similiar to stock size that could support 3t. Also I would suggest using KW's radial SAS parts as avionics packages. They would make adding avionics to boosters quite a bit easier. And finally, I think that a Remote Tech dish big enough for interplanetary probes should be available earlier in the tech tree. Right now it feels like I am unlocking those RT dishes around the same time I have an Apollo Program nearing completion. I really like where this is going though! You guys are doing an amazing job! Keep up the good work!