[1.8] MandatoryRCS 1.8 & Part Pack 1.4 - Reaction wheels nerf, SAS persistence, rotation in timewarp

[b0ss]

what sort of config edits do i need to make so that reaction wheels use the most realistic nerfed strength at all times, regardless of SAS being on or off?

Also, what's the recommended difficulty for the most realistic behavior?

[Gotmachine]

That depend on what you call "realistic", this mod isn't made to make reaction wheels behave like in real life. It only balance their capabilities so you can't use them in an unrealistic way, most of the time.

Real reaction wheels are VERY weak. The ISS CMR weight 1100 Kg and output only 0.258 kNm of torque, the small reaction wheel in KSP weight 50 kg and output 5 kNm of torque. In short KSP reaction wheels are about 300 times more powerful than real life reaction wheels.

In real life, as soon as a vessel is large enough and/or need to make relatively quick attitude adjustments, it require either control surfaces in atmosphere, RCS thrusters or engine gimbaling. But for maintaining the attitude in space (making small adjustments continuously), reaction wheels are the way to go. This is what this mod try to achieve : reaction wheels are useless when you want to turn, but they are very powerful when you want to keep you current attitude (trough SAS).

Over the versions I made the default settings a bit more powerful, if you want the hardest and maybe most realistic experience, go to the difficulty settings and set all sliders in the "reaction wheels rebalance" section to the far left.

The reason I didn't nerf the torque strength in SAS mode is because after a lot of testing I concluded that it would make the game unplayable :

• The stock SAS is not designed to handle a low torque situation, it just can't stabilize a vessel that has realistic or even a bit nerfed reaction wheels. Especially with large and heavy vessels.
• For the same reason (the stock SAS is very basic and unoptimized), RCS fuel consumption is unrealisticly high when there is no "magical torque" from reaction wheels.
• Stability in atmospheric situations is a LOT harder when there is no free magical torque. Since KSP is inherently limited in its aerodynamic model and in how you can adjust the aerodynamic profile and weight distribution, it seems fair to me to have some "magic torque" to balance the gameplay.
• Real spacecrafts turn at a very low speed, they usually have the luxury of taking their time. Because of that, they need far less torque power than a KSP player who can't wait hours to make a basic maneuver.

If you really want to nerf the reaction wheels, you can always edit the parts config by writing this patch in a text file, renaming it to *.cfg file and dropping it anywhere in your GameData folder :

@PART[*]:HAS[@MODULE[ModuleReactionWheel]:FINAL
{
	@MODULE[ModuleReactionWheel]
	{
		// Change 0.1 (=10%) to whatever you seem appropriate
		@PitchTorque *= 0.1 
		@YawTorque *= 0.1
		@RollTorque *= 0.1
	}
}

 

Edited February 28, 2018 by Gotmachine

[eberkain]

I wanted to use this mod for the persistent rotation feature, so when I returned to visit my station it would be facing a proper direction, but it seems to have a conflict with Mechjeb.  Landing Guidance works perfectly, but with the persistent rotation feature active MJ cannot successfully timewarp without going off course.  

[Jognt]

Hiya! Absolutely love this mod as it adds more depth to builds and gives me a use for RCS.

One thing I've been wondering about after perfecting every build's RCS to be perfectly balanced: Is it possible to add code that auto-balances RCS output? Kinda like RCSBuildAid, but on the fly?

[symmeclept]

Thanks for the update! I love this mod. 

[Errol]

What is the difference between this mod and the persistent rotation mod? Why would I pick one over the other?

EDIT: PIng @Gotmachine

Edited April 12, 2018 by Errol

[DracoSilverpath]

39 minutes ago, Errol said:

What is the difference between this mod and the persistent rotation mod? Why would I pick one over the other?

I came by to ask the very same question!

[Gotmachine]

15 hours ago, Errol said:

What is the difference between this mod and the persistent rotation mod? Why would I pick one over the other?

MandatoryRCS main purpose is to change the stock choice of reaction wheels being so unrealisticly overpowered that you don't need a RCS system on your vessel. It does so by adapting the available torque from reaction wheels depending on the situation, and it determine what is the situation is using the stock SAS state (Hold, prograde, etc...). In other words, reactions wheels works in conjunction with the SAS, helping stabilizing the vessel and preventing it from spinning like crazy. But the reaction wheels can no more be used to initiate a rotation. In fact they still can, but they have a very low and not too far from realistic torque output when you use them to rotate.

The SAS and rotation persistence are "bonus" features. The persistent rotation part is here because it would completely defeat the purpose of the mod if you were still be able to stop the vessel rotation by going into timewarp or switching vessels.

The Persistent Rotation mod does essentially the same thing as my persistent rotation feature, but has features specific to that part  :

• It will calculate the rotation for unloaded vessels
• It has a GUI for choosing a target to keep your vessel oriented toward, which allow a few more options than my current system of using the SAS state
• It will consume some EC when unloaded/timewarping if you use the above feature
• It can force a constant rotation rate, this can be used to make "rotating habitats"

This said, I'm currently giving the final touch MandatoryRCS version 2, a complete rewrite of my plugin that will include a brand new SAS that completely and seamlessly replace the stock SAS, with some very useful new SAS modes and an implementation of the MechJeb PID controller as a replacement for the stock SAS PID controller. No release date, but I'm getting close. Here is a sneak peak :

Edited April 12, 2018 by Gotmachine

[CobaltWolf]

@Gotmachine any thoughts on adding magnetorquers to the mod as a high tech third option?

[Errol]

20 minutes ago, Gotmachine said:

Here is a sneak peak :

Wow...that is awesome looking! 

[Jognt]

23 minutes ago, Gotmachine said:

The Persistent Rotation mod does essentially the same thing as mine, but has more features :

• It will calculate the rotation for unloaded vessels

 

 

So if one were to want your SAS rebalance but also wants Persistent Rotation, will they conflict?

In regards to the new features you're working on: Improved SAS is always welcome, but that's a lot of SAS buttons... Don't underestimate the value and power of simplicity

Edited April 12, 2018 by Jognt

[Gotmachine]

@CobaltWolf Yes, I've read about the various means of attitude handling in real spacecrafts, and I've thought about how I could implement them is KSP. The idea could be to have reaction wheel as the powerful, controllable but limited option, implementing simulation of the saturation issue and desaturation using RCS. Magnetorquers could be the low maintenance, non controllable mean of just attitude keeping. But this is a lot of complexity and in my opinion, it would not be very fun to play with. Not being able to turn when you want to, or having to wait a whole minute to do a 90° turn is just frustrating.

@Jognt No they will not conflict, my plugin is designed to automagically disable its persistent rotation feature in favor of Persitent Rotation when the plugin is detected in your game. But this will also disable the SAS persistence feature. And note that I don't intent to keep that option in the next version. About the KISS part, I honestly think I could not have done simpler than that, it's the whole MechJeb SmartASS feature (and a few more) packed in the good old SAS UI.

 

[CobaltWolf]

1 hour ago, Gotmachine said:

@CobaltWolf Yes, I've read about the various means of attitude handling in real spacecrafts, and I've thought about how I could implement them is KSP. The idea could be to have reaction wheel as the powerful, controllable but limited option, implementing simulation of the saturation issue and desaturation using RCS. Magnetorquers could be the low maintenance, non controllable mean of just attitude keeping. But this is a lot of complexity and in my opinion, it would not be very fun to play with. Not being able to turn when you want to, or having to wait a whole minute to do a 90° turn is just frustrating.

Gotcha. Well, if they want to be fast then they should put RCS on no? From my POV it sounds like the easiest implementation would be something like a weaker version of the stock reaction wheels, but the power scales inversely to the distance from a major planet. Remotely accurate magnetorquers would indeed be a bit too much for enjoyable gameplay.

[Gotmachine]

The problem is that the plugin is already making the reaction wheels super weak so you are forced to use RCS, in order to force the player to make a realistic choice. You can still do a reaction wheels only craft, but only on very small crafts (probes, satellites...), anything bigger than that requires a RCS system.

Magnetorquers as a weaker option would be totally useless, and even more if they have some restrictions. The problem here is that stock players are used to totally unrealistic free torque, and as I said before in this thread, it is indeed a necessity to have that power, because real spacecrafts have the luxury of taking forever to turn while a KSP player can't possibly wait that much time.

This said, a revamp of the stock reactions wheels and introduction of others options is still on my mind. Maybe sometimes I will try something but for now I have others plans for the plugin.

[Gotmachine]

MandatoryRCS 2.0 BETA 1 - FOR THE BRAVE !

Beta release with extra logging of debug information to the KSP.log

• Complete rewrite of the whole plugin
• The reaction wheels nerf has been simplified, control variations are no more since this was confusing and not very relevant
• Target persistence
• Stock SAS PID controller is replaced by a MechJeb derived PID-controller
• Complete in-house reimplementation of the stock SAS UI, with new modes and simple options within the UI.
• Added a way to target the Sun
• Added a RCS-auto mode
• Ingame settings are useless for now, don't try to use them
• Many bugs !

Download & source

 Download from GitHub

Instructions & notes

Spoiler

SAS user manual

Reaction wheels lock

The background color of the selected mode will change depending on the reaction wheels state. When the background is yellow, this mean that reaction wheels are not yet locked on the required direction and are providing a very low, semi-realistic torque. When the background turn green, the reaction wheels have acquired a lock and will provide their full torque power. It also mean that the SAS direction will be kept trough timewarps and reloads.

Roll control

Clicking on the middle button will enable Roll Lock. This force the SAS to hold the roll attitude relative to a predefined reference. Each click on the left and right buttons will offset this roll attitude by 45°, and the middle marker will update its icon to reflect that. The roll references depend on the current mode and on the selected navball context :

• Orbit/Surface context :
  • In RadialIn/RadialOut modes, the reference is the main body north direction.
  • In other modes, the reference is the radial out direction. This will keep your vessel in the same orientation relative the main body horizon.
• Target context :
  • In Parallel/AntiParallel modes if a body is selected, the reference is the body "east" direction.
  • In other cases, the reference is the target north direction for bodies, and the radial direction for vessels and parts (exact direction depend on the part/vessel).

A few things to note :

• Roll lock is disabled in the Kill Rotation mode.
• Roll lock will disable itself if your vessel is near aligned with the roll reference. This is to prevent a sudden and nasty 180° roll turn when going from one side of the reference to the other side.

Modes
	Kill rotation : In this mode, the SAS only action is to counteract any angular velocity, it does not try to hold an attitude. The most efficient mode for RCS fuel consumption, and also the one where your reaction wheels will help you the most.
	Fly By Wire : This mode is whole new way of controlling your vessel. When activated, a green marker will appear on the navball at your current attitude. As long as the Fly By Wire mode stays activated, your pitch/yaw input (using the WASD keys) will no longer directly control your vessel but will instead move this marker on the navball. The SAS will then steer your vessel toward the marker. Note that if you click again on the Fly By wire SAS button, your current attitude will be registered.
	Parallel / Antiparallel : Only available when the "target" navball context is selected, this mode will maintain your vessel parallel to you target. Great for docking, or for keeping your solar panels toward the Sun if used in conjunction with the roll lock mode.
Options
	SAS Aggressivity : Clicking on this button will cycle the SAS settings from a low to high angular velocity limit. A lower limit will make the SAS turn less quickly, improving precision and lowering RCS fuel consumption when in space. A higher limit may be useful in atmospheric flight.
	Target Sun : Allow you to set the Sun as your target. Alongside with roll lock and the target context, this will allow you to keep your solar panels perfectly aligned with the Sun.
	RCS Auto : In this mode, the RCS toggle is in the hands of the SAS. It will enable it when the pilot request a pitch/roll/yaw or translation command, and at the discretion of the SAS when reaction wheels aren't locked on their target

Licensing

Due to the integration of MechJeb-derived code, this plugin is released with mixed licensing. The plugin as a whole is released under the unlicense, meaning public domain, meaning do as you wish. Individual source files contains a header indicating their license situation. Most files are released in the public domain, at the exception of the following source files that contains code derived from the MechJeb plugin and are licensed under the GNU General Public License v3.0 :

• ComponentSASAutopilot.cs
• Lib\MathExtensions.cs
• Lib\Vector6.cs
• Lib\VesselPhysics.cs

Edited April 17, 2018 by Gotmachine

[Errol]

14 minutes ago, Gotmachine said:

• ... control variations are no more since this was confusing and not very relevant

What is this is reference to?

[linuxgurugamer]

Looking forward  to a full release

[Gotmachine]

@ErrolThose features are gone in the current beta release :

On 07/01/2017 at 10:12 PM, Gotmachine said:

• Torque output is affected by the vessel angular velocity : the faster the vessel rotate, the weaker reaction wheels are.
• Pods and cockpits built-in reaction wheels can't be controlled (they don't respond to pilot/SAS input) but still provide SAS stabilization.
• Reaction wheels in probes cores and independent parts can be controlled.

The first bullet may be back at some point, but I need to think of another solution. The intent was to limit the infinite capacity of the "Hold" SAS mode to stop a vessel rotation using only reaction wheels. The problem was that it could brick your mission since you would have no way of stabilizing a vessel that for some reason is spinning out of control. So I made the effect very faint, to the point it was not noticeable at all, so to conclude : useless feature.

The two other points were a bit of an arbitrary decision to balance the gameplay, and I had some comments that make me think that this was not a good solution. I implemented this because I wanted to prevent the ability to magically control reentry pods and light manned vessels without having RCS onboard. The problem is within the stock balance : pods have super-strong reaction wheels that were probably added so in most cases you don't need an additional RW part. Without the control distinction,  even when strongly nerfed by my plugin they are enough to orient yourself as you please.

At the time, I did the control distinction because I was reluctant to provide a MM patch to rebalance the pods vs individual RW, but maybe I will go this way for the final release of this new version.

Another potentially much simpler and efficient way of achieving the goal would be to dynamically adjust the "nerfed" reaction wheels torque according to the vessel mass, this is something that I need to playtest. This would result in a fixed "turning capacity of reaction wheels" for all vessels, and maybe I could add some bonus torque for independent RW parts, so it's still useful to put some onboard.

At some point, I may do a few new flat inline part for each size that combine a reaction wheel, a small RCS fuel tank and an integrated 8-nozzle RCS block, and maybe also a 0.625m and 1.5m nose cone with RCS+RW+parachute.

I was also thinking of a patch for the stock pods to add integrated RCS thrusters on them, like the new 1.4 Mk1-2 pod now has, might be possible by MM-combining the stock model and a single scaled RCS thruster model with the proper transforms. Then I could safely get ride of the integrated super-powerful reaction wheels in the pods, but again I'm a bit reluctant to do that because it would likely require making and maintaining patches for countless other pods from the various mods out there.

 

[Errol]

Could just leave it simple and allow people to used RWsaturatable if they want something more in depth. 

EDIT: By the way, thank you for the detailed reply. I really enjoy this aspect of this community. When you want to learn something, there is often someone there who is willing to give you the fine details. 

Edited April 17, 2018 by Errol

[Gordon Dry]

@Gotmachine 2.0 Beta 1 looks good, as it seems you mismatched the radial in and radial out buttons.
(I'm used to "radial out" meaning the nose shows up and the bottom shows down regarding the celestial body orbiting)

[Gordon Dry]

No issue, just some feedback

Patience is needed. Some tiny maneuvers don't like RCS to be used.

I just built a triple-stack GeoSat vessel, I deployed all three Comm/Relay satellites at best possible nearly 0° inclination and best possible nearly 2863.3 km apogee/perigee each 120° away from the previous one in one launch.

The satellites got RCS which is set to "fore by throttle" to make the final adjustments.
I also disabled the upper stage main engine and only used the satellites' RCS to do maneuver burns.

The engine was enabled again for the "resonant orbit 2/3" burns.

My goal was that the surface speed is best possible 0.0 m/s, max. 0.1 m/s.

Of course the geostationary contract was already fulfilled before I even deployed the first satellite.

 

The rotation of the whole upper stage incl. all 3 satellites was a long run, like 5 minutes without RCS. If I used RCS, the node totally went away and removing the node and doing a new one was even not better.
So rotating without RCS was the best possible way.

[Errol]

38 minutes ago, Gordon Dry said:

No issue, just some feedback

Patience is needed. Some tiny maneuvers don't like RCS to be used.

I just built a triple-stack GeoSat vessel, I deployed all three Comm/Relay satellites at best possible nearly 0° inclination and best possible nearly 2863.3 km apogee/perigee each 120° away from the previous one in one launch.

The satellites got RCS which is set to "fore by throttle" to make the final adjustments.
I also disabled the upper stage main engine and only used the satellites' RCS to do maneuver burns.

The engine was enabled again for the "resonant orbit 2/3" burns.

My goal was that the surface speed is best possible 0.0 m/s, max. 0.1 m/s.

Of course the geostationary contract was already fulfilled before I even deployed the first satellite.

 

The rotation of the whole upper stage incl. all 3 satellites was a long run, like 5 minutes without RCS. If I used RCS, the node totally went away and removing the node and doing a new one was even not better.
So rotating without RCS was the best possible way.

Do you use RCS build aid? It is possible to build a craft with well-enough balanced RCS that they can be used for attitude control without messing up maneuver nodes, but it takes a bunch of finagling. Also, you have to basically take your craft's stages appart in VAB, so you can balance them with RCS in reverse order as you add stages to them (this is not necessary if the only part of the craft that has/uses RCS is the final stage).

https://forum.kerbalspaceprogram.com/index.php?/topic/166546-141-rcs-build-aid-continued-new-dependencies/

Edited April 23, 2018 by Errol

[Gordon Dry]

@Errol Yes, I use RCSBuildAid.

For this specific vessel I could have used action groups to trigger certain RCS units at the satellites, but this way also is okay.

With the final stage the orbits don't need to be so perfect, I can finetune them with the RCS the satellites got, so it's okay.

[Gotmachine]

Yup, radial in/out is reversed, silly mistake, thanks for the feedback.

Well, the whole point of the plugin is to force you to use RCS for attitude, and yes, one major consequence is that your orbit will change every time you turn. There are a few thing that you can do to use RCS and avoid translational deviation :

• Balance your RCS configuration before launch using the RCS Build Aid plugin. You should place your RCS thrusters evenly around the center of mass. You can nearly eliminate unwanted translation by doing that properly.
• Use a lower thrust setting in the "Thrust limiter" tweakable of your RCS parts (or use the micro-RCS parts provided in the MandatoryRCS part pack). The stock 1 kN thruster is way overpowered for vessels under 5-10 tons.
• If you are using the part pack, don't use a 2x4 setup of four way thrusters, that's horribly inefficient. The best setup if you don't need translational forward/backward authority is two rings of 4 two ways thrusters (the "I" or "IV" variants), with ring at each side of your vessel, centred on the center of mass. If you need translation, use the same setup but with the the "IL" or "IVL" variants.
• Another thing to think about is that after turning, you can correct your orbit very precisely using the RCS translation controls. This is a bit tricky at first, but oncce you  master it it is unvaluable for fine tuning your orbit.

If you really need non-RCS control authority... add more reaction wheels...

This said, I'm aware that the current system is not very good. I have in mind a revamp of the stock reaction wheel module, but currently I got no time to work on it.

The idea would be to have three types of non-RCS control systems :

• Magnetorquers :
  • Provide only stabilization (Kill Rotation and SAS lock), can't be used to initiate a rotation.
  • Very low mass, available as an optional module in existing parts (reaction wheels, probe cores, pods...)
  • Can be used as a passive (no EC consumed) or active (EC consumed) system for extra torque power.
  • The available torque depend on the distance to the main body (lower orbit = more torque)
• Reaction Wheels :
  • Provide large stabilization torque and low active torque (like the current nerf does)
  • Replace the stock module
  • The active torque would be subject to a realistic saturation mechanism
  • The stabilization torque would be subject to a non-realistic saturation mechanism (the saturation would magically vanish when the wheels are not used).
• Control Moment Gyroscope :
  • Provide large stabilization torque and medium active torque.
  • Heavier and bulkier than current parts, also larger EC consumption.
  • Would come in a set of all-in-one configurable inline parts with optional EC/MP storage, integrated RCS thrusters, probe core...
  • Same saturation mechanism, but the active torque saturation would induce a permanent EC consumption.

To avoid having to micro-manage the saturation :

• The saturation would be calculated vessel-wide, not per part, and a colour-gradient saturation indicator would be added somewhere on the navball for the two types of saturation.
• For the "realistic" saturation, an auto-desaturation SAS button would be added. By toggling it, the SAS would let the wheels desaturate. Doing so would produce a torque which rate would be auto-adjusted so the onboard magnetorquers and RCS thrusters (if the auto-RCS button is toggled) can counteract this torque.

The design goals are :

• To give the player the ability to choose between a RCS or non-RCS attitude system depending on the mission profile
• Balance these options so neither is overpowered
• Still keep the "magical free torque" but avoid the "look I can stand on a 45° slope" situation
• Not to add to much complexity and keep the gameplay simple.

Edited April 23, 2018 by Gotmachine

[Tyko]

On 11/8/2017 at 11:01 AM, Gotmachine said:

Hi guys,

I would like to have some feedback and opinions on a few new features I'm currently trying to implement. Picture first :

This is a replacement for the stock SAS. It's build on top of MechJeb and will probably require MechJeb to be installed (the other option being repackaging MechJeb as a library and distribute it with the plugin, which I want to avoid). But this SAS (and possibly other features built on top of MechJeb) will be independent from the MechJeb parts and GUI. The MechJeb GUI and parts will still be available, but not visible if you don't use them.

I'm doing this because :

• The stock SAS is struggling with large and heavy vessels, to the point it is impossible to stabilize them.
• The stock SAS is atrociously inefficient and imprecise, leading to astronomical RCS fuel consumption
• The stock SAS lack some very useful features.

I did a lot of tests to compare the MechJeb SAS to the stock SAS, in various situation and with various vessel sizes. For the same sequence of events, the MechJeb SAS is between 25 % and 200 % more efficient with RCS fuel, especially with large vessels. I also did test using the TCA SAS, which is even better but unfortunately TCA is build in a way that make it very hard for me to use it as a dependency, plus it is missing a few features that MechJeb have and that I want to use.

Now back to the screenshot. The new SAS modes are :

Hold :
  Used to precisely hold an orientation, this is the default MechJeb Hold. The orientation is defined in two possible ways:
  - When hold mode activated, hold the current vessel orientation at time of activation
  - On pilot input key release, register the current orientation and then hold it

HoldSmooth (Default mode):
  Same as Hold, but on input key release angular velocity is killed and once the vessel has stabilized, the reached orientation is registered. The stock SAS Hold mode behave a bit like this.

KillRot :
  Don't hold any orientation, just keep angular velocity to zero. Great for consuming less RCS fuel.

ForceRoll (3 horizontal markers) :
  - center marker : toggle that activate/deactivate force roll. Icon change to reflect the current selected roll angle
  - right / left markers : buttons with arrows icons, add / remove roll angle by 45° increments
  Roll angle is relative to the current reference (ORBIT, SURFACE OR TARGET)

PitchOffset (3 horizontal markers + value) :
  Add a pitch offset to the current selected orientation. Disabled if Hold, HoldSmooth, KillRot or Maneuver mode is active.
  Useful for managing attitude in atmosphere, especially for reentry
  - center marker : reset pitch offset and set mode to HoldSmooth
  - right / left markers : increase / decrease pitch offset (2.5° increments)

ProgradeCorrected (target mode marker)
  To target, correcting lateral velocity
  This is the orientation you need to burn to so Prograde become aligned with Target
RetrogradeCorrected(target mode marker)
  Against target, correcting lateral velocity
  This is the orientation you need to burn to so Retrograde become aligned with AntiTarget
Parallel + & Parallel - (target mode marker)
  Keep the vessel parallel to the target, great for docking using lateral RCS movement

There are some other features I want to add, but maybe not in next release because it will involve a lot of navball GUI hacking and this is the most horrible task I've done since I begun modding for KSP.

• SAS aggressively slider : basically how hard the SAS try to turn, less aggressive = less RCS fuel consumption (MechJeb functionality integration)
• RCS auto mode switch : automatically disable the RCS toggle when reaction wheels are enough to do the job
• Global RCS throttle slider
• Maneuver autopilot : a basic autopilot that will execute the next maneuver node (Mechjeb functionality integration), to be used in conjunction with commnet
• Navball markers for the new SAS modes

All these thing would be available from a nice stockalike popup menu accessed by right-clicking the SAS and RCS toggles on the navball.

Also, I'm thinking about redoing how the reaction wheels nerf is working. This could involve :

• A "realistic torque output", available all the time for the pilot or SAS to use.
• This realistic torque output would involve realistic reaction wheels saturation, meaning fully saturated wheel = no torque available.
• A on request auto-desaturate function, that would involve automatically firing RCS thrusters to desaturate the wheels.
• A "magical torque output", saturation free, available only for stabilization when the SAS is used.

 

I've been playing with MandatoryRCS all evening and just read your plans for the next version. A couple of questions/comments.

1. Will I have to install MechJeb in its entirety as a dependency or will the RCS portion be either included with your mod or downloadable separately? Just asking because I don't use MechJeb and don't really want all of the MJ screens all over the place just to use this one item.
2. Love the SAS aggressively slider idea - when I was playing around with it I found I could save a lot of fuel by just reducing thrust. One idea would be to have two settings - a much lower, slower setting for SAS controlled RCS and Full Power for user input. The thought here is that in normal operations speed isn't as important as fuel consumption. If the user is docking or taking other actions they may want access to full power.

Thanks for all the work. I'm pretty excited and see a potential to experience a whole new dimension of KSP through you mod.