NathanKell

Just to repeat: in KSP, all engines need to have at least one propellant with density>0 or put another way all engines need to shoot mass out the back for any thrust to occur. If you make an engine that only uses massless (density = 0) resources, you won't get any thrust.

Did you follow the instructions when downloading RftS Engines to also download the gimbal plugin?

Snjo: Ah, I didn't see any error in the log (caught exception maybe? or not even that?) so I thought I should just try everything. Will fix. Also, thanks so much for the nosecones--I didn't even realize you'd added them! They let me make this pretty little thing (instead of, y'know, doing my work):

Niiice! Snjo, when you get a sec, could you check out pWings's procedural control surface? I'm trying to apply the texture switcher to it and failing. No log messages... It works fine for the regular and the all-moving wings BTW. Here's what I have now: @PART[pCtrlSrf1] { MODULE { name = FStextureSwitch moduleID = 0 showListButton = true textures { name = ProceduralDynamics/Parts/Aero/procedural_ControlSurface_1/model000 name = RftS/FS/SurfGreen name = RftS/FS/SurfBlack } objects { name = obj_ctrlSrf name = model name = Armature name = Root name = Tip } } } I'm just tossing all the transforms I could at it...

Since your collision mesh will hopefully be a different, custom made mesh, not your actual part's mesh, the facecount of the visual mesh shouldn't matter for physics.

Multiple antenna multiplier will work as follows: The maximum omni range of a node = largest_range_antenna's_range + sum(all_other_antennae's_ranges) * multiplier Root works as follows: For two nodes A and B, where max range of A < max range of B: max distance between two nodes = rangeA + sqrt(rangeA * rangeB)

Nonono, the reason for using 1/rescaleFactor is if you use a non-1.0 rescaleFactor. Let me example: Instead of this: MODEL { model = foo scale = 0.5, 0.5, 0.5 } scale = 1.0 rescaleFactor = 2.0 node_bottom = 0.0, -1.0, 0.0, blah.... do MODEL { model = foo scale = 2.0, 2.0, 2.0 } scale = 1.0 rescaleFactor = 1.0 node_bottom = 0.0, -2.0, 0.0, blah....

The _R means I modify a copy, not the original, so as not to interfere with FASA realism patches. The new engines are created in my local cfgs, which I haven't released with RftS because of FASA's licensing. I doubt Frizzank or I want RftS configurations of engines in FASA, but I was planning to ask whether he'd mind if I include the copy cfgs in RftS.

Man, you just keep pumping this stuff out! Impressive! A pretty-please request, though: could you make the engines without baseplates? (As you did for the earlier ones.) That way they can be used on any size tank (or clustered easily).

I really like your probe ideas. Before RT2 came out I had a module based on RT1 for "science cores" that allowed right-clicking but not flight control, for uncontrollable (but still science-returning) satellites. So I guess what I'd suggest is adding that kind of "probe" as well.

Tex_NL: you might want to consider the fact that not everyone uses the stock soupodynamics. Some of us use FAR, and in that case MJ doesn't work. Under FAR, your best bet is to enable wing leveler and the dampers, and trim out as close to 0 vertical velocity as you can, then adjust pitch trim every few minutes.

It's a known issue; I heard about it from Greys, and taniwha and I verified it with Talisar's spherical tanks mod. As Starwaster says, you have to use rescaleFactor = 1.0 when you're using MODEL nodes.

I thought I had made RftS not change any real engines from FASA (I assume the mini LR-91, etc, are all fair game since they're not actually real) but it looks like I still have a config for the Gemini lunar lander engine hanging around. Will fix.

OP states: This converts the Kerbol system into our real solar system. So yes.

For normal KSP: divide diameter by 1.25, round normally (except: precisely 0.625m = size 0) For RO: divide diameter by 1, round normally (except: precisely 0.5m = size 0)

Given that it's referring to KSP Achievements, I'd suggest removing that and seeing if things get fixed.

jamis: hope the job changing went/is going well! A note on MJ: you should always be grabbing the latest dev version; the only difference between a dev version and a version in the OP is that r4m0n edited the OP to point to the latest dev version. FYI I'll be updating all my stuff very soon (I too have been semi-away, moving).

I don't suppose you could do the same for the altimeter? Feet and nautical miles would be great.

We do. We just don't need to.

It's by the original author of MM, who has now returned (sarbian was maintaining MM in ialdabaoth's absence). So yeah. Heard one person it didn't work for in the thread though; I've been AFK moving for the past forever so I have little testing experience with it as yet (seems fine).

1. Convert the texture you want to png using the . 2. Rename original model00x.mbm to .bak 3. Edit the PNG in GIMP to taste. 4. Profit!!!

Because that's totally unrealis...oh..

Ah, sorry. What I mean is that in .23.5, the stock KSP method that writes to the Navball executes after Ferram's, so his value is clobbered (and thus never shows). As a fix, if you write to the navball textbox via the LateUpdate() method, it won't be clobbered. Thread is here: http://forum.kerbalspaceprogram.com/threads/75308-0-23-5-Speed-Unit-Changer-Simple-plugin-to-visualize-speed-in-different-units Dev thread (discussing the fix) is here: http://forum.kerbalspaceprogram.com/threads/74918-Not-possible-to-write-on-GUI-Elements-%280-23-5%29?p=1068081#post1068081 Uh...to be clear, this has to be a fix implemented in source and recompiled, so you might want to wait for Ferram to do it if you don't want to (edit and) compile from source yourself.

Uninstall the mod. (Literally: just delete the BoulderCo folder)

And by unofficial you mean official. (just because r4m0n hasn't edited the OP yet, doesn't mean that the latest version of MJ isn't official)