HoneyFox

True, I've made an attempt to tweak these values but it seems like the propellants are still not susceptible enough For the drag during ascent, i don't think it's a big issue, we can always install ullage motors to counteract the drag and still provide slightly positive acceleration during stage separation (in fact, rockets like Saturn V do have such design for their 2nd stage), but it's true that this will be more tricky about how much thrust we need for ullage during our design phase (i.e. when in VAB) because we cannot easily know how much drag force there will be...

As stated in above posts, you can use ullage motors (either small SRBs, high-thrust RCS or pressure-fed engines that don't need ullage) to accelerate the rocket for a while to stabilize the fuel. As a last resort, you can pitch/yaw your vessel quickly. and due to centrifugal effect, some part of fuel will fall to the bottom of the tank. You then should throttle up *gently* and burn for a while to make the upper part of the fuel fall to the bottom as well, then later you can throttle up to full power. DO *NOT* throttle up too quickly or the fuel will get unstable again in this case.

I'm not sure if Realism Overhaul's engine config has EI config built-in. If not, you might need to extract the config-pack provided by EI itself. you'd better confirm this with RO's author.

Perhaps generator uses deltaTime while other modules use fixedDeltaTime, or vice versa? I donno if that will bring any trouble...

Great! I will do some further test and later release a build which fixes the launch pad issue. Oh and the requirement for the pad model will be slightly different then. And as always, a screenshot to show the current progress

I'm referring this, and is wondering what changes need to be done to fix these reference errors.

Alright, at least i should first test my modification and make it run on my own game, after that perhaps i can send pull-request to him.

Does that mean I can redistribute the modified version with his license + credit to my own portion or not? as you also disabled the launch button which is inside the main code part right? and TBH I don't care about my credit that much, i mostly hope that we can use that feature again. EDIT: and i found that your source-code link on mediafire is invalid...

I'm now working on a fix for the broken launch-site feature... It seems to be something related to the new launch site management of stock KSP. But i'm a bit confused about the license, is source-code-editing and redistribution disallowed because the OP stated "all right reserved"?

KJR will automatically destroy joints that are connecting two different vessels. so once the decoupler on the adapter is activated, the rocket actually turns into two different vessels and hence all the "auto-struts" should be destroyed at that moment. But I've met some situations that these joints are not destroyed as they should be, so I recommend disabling the auto-struts option. EDIT: As for the second design i mentioned, make sure you have installed fairings/fuselages to all these adapters, if any adapter has no fairing/fuselage installed, it will automatically decouple the floating node.

Yes this will work too, as long as you disable the Auto-Struts of the adapter. I still prefer the fuselage (though it's in a tech-node higher in the tech-tree) because fuselages won't add unnecessary staging icons into the staging list. You know that staging design will be quite tedious when you have lots of such stages in your rocket design.

Guess that it's the latter one, i.e. its own thermo-dynamics system. Just like what NearFuture deals with its nuclear reactors too.

Finally the RF will support MEFX soon! Yeeess!

The MultiModeEngine is introduced in KSP0.23, which is a simple switcher module that will pick one from two of the ModuleEnginesFX modules and will handle engine switching (aka activate/shutdown the selected/unselected mode).

I got several plugins twirling in my mind so forgot that. EDIT: Here goes the part. https://www.dropbox.com/s/ldshzk2w3pq1l3t/hollowAdapter.zip

Alright, a small update for V4 release. The floatCurve GUI editor is now finished.

Perhaps you need this. XD I forgot to pack this part, I will release the part soon. BTW you can disable the auto-struts to achieve this too. Here's a brief draft of two different designs I've been using.

Just in case any of you haven't discovered this plugin I made for ion thrusters to enable them to generate thrust during time-warp... http://forum.kerbalspaceprogram.com/threads/70881-0-23-Orbit-Manipulator-Series-%28WIP%29-%28Updated-March-12-2014%29 So yes, I suggest reducing the PB-ION thrust. Perhaps from 0.5kN to 0.005kN or so, it might be still OP than RL for 10 times, but anyway...

The toggle already exists. If you use the Toolbar plugin there will be several buttons for this plugin and one of them is the "NBody" on/off switch. Otherwise, use the hotkey mentioned in OP instead. For atmosphere decay height setting, shouldn't be too hard for values lower than actual atmosphere height since it's just an additional condition check. But for thermosphere/exosphere range that are higher than KSP's atmosphere height (>70km in stock KSP or >104km in RSS), I need to check if I can still get the correct air density value (because the drag force is affected by air density).

I'v tried disabling the TimeWarpLock but the throttle control still doesn't work. EDIT: Looks like the reason is something related to RemoteTech's flight control state hooks...

You mean the input lock of TIMEWARP & THROTTLE? I don't know if that will work...

use imgur or photobuckets... at least the latter one works for me.

The point is to destroy those debris that should have re-entried. In stock game those vessels/debris having Pe at about 30km will keep orbiting if you don't get close to them/control them directly. For a launcher that push the payload into a sub-orbit with Pe close to the upper boundary of atmosphere(like 50km for stock KSP or 80km for RSS), this feature will help to clean the launcher debris after several orbits. As for controlling the thrust via throttle, I guess it's not possible to catch the input because KSP doesn't need it in warp and actually it doesn't allow you to operate throttle as well... Of course I can catch the keyboard input directly ("X"/"Ctrl"/"Shift" keys) or perhaps joystick's throttle axis as well, but that takes quite some effort to implement. I would perhaps, provide an overall throttle slider-bar in the GUI for overall thrust control, what do you think?

I will consider adding "Kill Throttle" and "Full Throttle" buttons for convenience. The resetting-throttle-when-exiting-time-warp is an intended design but I will add an option to disable it (especially after the "Kill Throttle" button is introduced).

A "hot"-fix version just got released... yeah i know it's not hot at all... DL link is in OP, still unchanged. See change-log in OP for details.