I realize that this might require having adding a bunch of transforms to the model, but would it be possible to split up the custom upper stage's RCS so that the ones facing backwards can be disabled for rotation? They seem to be powerful enough to mess up my maneuvers a lot of the time.

This could be accomplished by duplicating the thrust transforms and renaming them so that when it's used as a standalone part there is only one group but when used on the custom upper stage there are two groups.

Would really rather not do this; already such a PITA dealing with one model, set of transforms, and module. Adding a second one to deal with will... well.... yuck. (And as you point out, I would have to re-export/recompile the model with the second set of transforms named differently, and this model would not be usable for the normal part).

Will leave this open for now while I give it some thought; If I can come up with a way to do it that doesn't require too many code-side changes, then sure.

Really though, the stock RCS functionality just needs to be fixed, finally and for good; there is no legitimate reason for it to function so poorly with regards to rotation and translation commands/intermixing thruster output; most often the unwanted thrusts could be perfectly countered by the system given the thrusters available, but it does (almost) the most nieve

Well it could still be one model, but yes you would have to re-export it. You could have two sets of identically placed but differently named thrust transforms in the same model, since ModuleRCS identifies the transforms by name.

I could probably import the model into Blender and re-export pretty easily. Would you be willing to accept a PR for this?

It requires other code in the MUS module as well to handle the interaction with the second RCS module; I would say don't worry about it for now. I will get to it when I have time to rework the module code (re-exporting the model is a minor concern compared to the module side changes, and I need to get those models/etc re setup in my U5 project soon'ish anyhow).

Thanks for the offer; but having the new model would not do me any good at this point :)

Ah, forgot that the module actually interacts with RCS. Still, should be a pretty simple change

        private void updateRCSThrust()
        {
            float scale = currentTankDiameter / defaultTankDiameter;
            rcsThrust = defaultRcsThrust * scale * scale;
            foreach (var rcsMod in part.Modules.OfType<ModuleRCS>())
            {
                rcsMod.thrusterPower = rcsThrust;                
            }
        }

OfType<T> won't return any nulls so the check becomes unnecessary.

Yeah, the nice thing about RCS is that thrust is per-transform rather than total, so you don't have to worry about recalculating the fuel flow.

Indeed; will pretty much be a drop-in replacement after I update the model. Much simpler than messing with engine/gimbal/etc setups.

Have updated the part configs; all that is needed now is for me to get home and have time to re-export the model (and setup the unity scene, prefabs, link textures... all the fun Unity bits; I do not have access to my Unity project on my work comp).

Ooh.. and apparently they've just posted an updated pre-release build... so should likely be seeing this stuff over the weekend.

Ugghh... so i go and update the libs for my plugin with the latest from the 1209 branch.... only to find out they've changed both the IPartMassModifier and IPartCostModifier interfaces to add additional methods with undocumented parameters.

So... taking a break for the night before I literally break something; I don't much feel like mucking through the 80+ compile errors that now show up in my project due to their interface changes; especially without documentation on WTF the new methods/parameters do.

Will start looking into this again tomorrow when my head is a bit clearer (really I just wanted to finish up and test the resource stuff... not fix 80 unrelated errors first...).

Wow.. didn't realize I was using such simple code for updating the RCS on those (too used to the overly-complex MEC setup... having to force-reload through config nodes...).

Anyhow, have updated the MUS module to support multiple ModuleRCS; of course these changes won't be available until the next release (the initial 1.1 testing release). Still awaiting a 1.1 pre-release build with the root-part-procedural-drag-cube fix.

Have added re-exporting the module and updating the configs to my pre-testing-release TODO list; will likely get those cleaned up sometime this weekend.

The interface changes are actually just to give simulation mods a better idea of how these modifiers will change. Nothing in KSP actually uses the new features, but MechJeb and KER will almost certainly rely on them.

I created a new forum topic attempting to document the changes here (combination of compiling available data and badgering NathanKell on IRC)

Model has been re-exported, plugin recompiled, configs updated; testing now.

Seems to work now. Thanks!