HoneyFox

nah... KT will store the asset path in the cfg file so it will fail if you change the folder name... and after that, all kinds of strange bugs might easily happen ...

No I'm not planning to take over. I'm just fixing some "bugs" for it.

That's what i did in my local version of ProcFairing: i added an option "Cut Joints" so that, when the option is enabled, these joints created by "auto-struts" will be destroyed too when the adapter decouples. But, uh... since e-dog hasn't put his codes onto something like GitHub, i cannot send my changes to him easily.

You need to know the difference between a "strut" and a "joint". A strut (which is a part that is provided by stock KSP and some other mods like NP/KW) contains a joint, but a joint can exists without a strut. Additionally, attach nodes (including surf-attach node) are actually holding joints inside as well. Now, ProcFairing will add *additional* joints (yeah it was named "auto-struts" but they are actually invisible joints) between the fairings and the object attached to the floating attach-node when the "auto-struts" option is on. These joints are not belonging to any strut, and thus will not be destroyed like these struts' joints when the adapter decouples. that's why the top object cannot separate though it's already another vessel. KJR, as I know, will, at some specified moments, try to destroy any joint whose two endpoints are not on one same vessel. That can explain why you can decouple the payload without jettison the fairings, even if you have "auto-struts" option on.

You are using fuselages instead of fairings, so they won't be jettisoned from the adapter and the joints between them and the upper stage won't be destroyed as well. That's why you got this issue. You can: 1) Switch off the auto-struts of the adapter (by mouse-over and click "T"), you might need to manually struts the two stages if it starts to become wobble. 2) Use fairings instead, but that will create more debris when staging.

Isn't that orange color intentionally given by adding some "additives" into the fuel? Pure hydroLOX flame should be quite transparent and white, might be only a little blue-ish I guess?

On my planning list and that "station keeping" sounds interesting as well, but I might start these features a bit later because i want to enjoy the new ARM as well.

Like this idea...if it can be dragged by mouse that will be even better.

you are right.

but if i don't actually have that many kerbalnauts... this will actually turn into a cheat that can provide cash infinitely, well anyway...

RendezMe-Modified, TP, ETC, EI, Tweakable Gimbal, KerbTown's launch site feature & Orbit-Manipulator-Series all seem working nominally.

happy to tell everyone that this works well in ARM. I've just finished an asteroid capture mission with combined propulsion system including ion thrusters and conventional engines. It works good and I can save a lot of liquid fuel for later use. (e.g. fast retro-burn at Pe)

Ok Tested. So far everything works well. EDIT: here is a modified config.xml which makes ullage much easier via small acceleration. Replace the file in "GameData\EngineIgnitor\Plugins\PluginData\EngineIgnitor\" folder with it. https://www.dropbox.com/s/12g16cz9yf2hvpy/config.xml

I think that won't work, just like the stock KSC's launch pad and runway, you don't need to provide any resources to build a rocket...

Actually modders will hate that more than you I think... Once an update is released, busy hours of testing and debugging plugins done before start and some of these plugins might not have a solution to be compatible to the new release... that's the worst part...

I don't get it... what do you mean "get the launch pads to work with extraplanetary launchpads"?

Until i get back home and finish the download of 0.23.5 of course.

If Squad hasn't made big changes to engines (I think they haven't, they basically are focusing on new vessel type & claw related things IMO), it should be still compatible I think. You can always make a try.

Try the hollow interstage adapter I uploaded in the ProcFairings thread... it has dedicated collider that will not block the engine's thrust.

Can you add support for ModuleEnginesFX? currently it seems like only ModuleEngines modules are recognized...

If the first stage burn-out when the orbit velocity is already near 7000m/s, the gravity pull is actually only 1-(7000/7900)^2 of 1 Gee (suppose the velocity required to reach orbit is 7900m/s, but if your orbit is higher, this value will be lower), which is only 0.21G vertical acceleration you need the upper stage to compensate. Thus even with only 65kN thrust for a total stack of around 20t, the TWR is still around 0.32 which is higher than 0.21... so that you roughly need to pitch up for 40 degrees at that moment. Note that the above calculation is based on the condition that you have already reached the Ap point when the first stage burn-out, otherwise, you have some more "free" time to accelerate without the need to pitch up that much.

No it has nothing to do with the name of your PartModule class name... it's the folder name of your plugin that matters. So if you change your folder name to ZActionGroupExt, the plugin (and the ModuleManager cfg file inside that folder too) will be loaded after the RT2, hence there won't be such problem. EDIT: Adding :Final is also a working solution, since it forces the MM cfg to be processed after all non-Final MM cfgs (including RT2's).

Might be possible I think.

AFAIK it's hard-coded in KSP... there's not even a chance to modify some variable (even if it's a private one) to change that...

Hmm, for upper stage engine nozzles, though they are designed with much larger nozzle ratio, the under-expansion still exists since it's impossible to have a nozzle with infinite nozzle ratio... and yes I like that style, which has been seen in many demonstration videos made by NASA.