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

[Gordon Dry]

13 minutes ago, Tyko said:

and don't really want all of the MJ screens all over the place

The screens are not hardcoded to the UI, in the OP they're shown all in a screenshot just as a showcase example.

[Tyko]

5 minutes ago, Gordon Dry said:

The screens are not hardcoded to the UI, in the OP they're shown all in a screenshot just as a showcase example.

Thanks for explaining that...I guess I'm still concerned about any additional overhead and/or possible conflicts adding MJ will have. It's a pretty complex piece of coding and I'm not really sure all that it may impact.

[Gotmachine]

6 hours ago, Tyko said:

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.

MechJeb isn't required, and the new SAS features are not dependant on it. I was initially planning to use it as a dependency, but it proved to be hard to do so in the end I integrated the portions of the MechJeb code that I needed.

6 hours ago, Tyko said:

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.

The SAS aggressivity "slider" (this : )doesn't affect the available torque from RCS thrusters (it isn't like the RCS throttle in the part tweakables). It affects only the maximum angular velocity the SAS will reach when going from an orientation to another. In detail, when the SAS has to turn the vessel, it does it in three phases : accelerate the rotation until a predefined angular velocity is reached, then wait until the desired orientation is near-reached, then counteract the angular velocity to coast and stop. The slider affect this predefined angular velocity.

What you are thinking about would be a "global throttle" on RCS thrusters (like the stock one vor regular engines). This is something that I wanted to add initially but it is a bit tricky to do, both internally in the code and from a UI standpoint. The idea could be to add a second throttle marker on the existing throttle slider, and a button to switch the throttle controls to RCS/engine, something like that :

[Errol]

Could just have it as a high/low option instead of a 0-100 throttle.

[Gotmachine]

7 hours ago, Tyko said:

Thanks for explaining that...I guess I'm still concerned about any additional overhead and/or possible conflicts adding MJ will have. It's a pretty complex piece of coding and I'm not really sure all that it may impact.

There is some low overhead to every attitude PID controller out there (KOS, MechJeb, TCA...), honestly I don't think this is noticeable. The main overhead is because we are forced to recalculate some basic variables that are borked beyond repair in the stock code (moment of inertia and available torque from RCS modules). If you wonder why the stock SAS is so inefficient with RCS, that's why.

About compatibility problems, potentially that could happen since the stock SAS is permanently deactivated. I think it is impossible for a plugin to use the stock PID controller instance to do custom orientations (I tried and failed), so this should be safe. I have a doubt about Principa, this has to be tested.

Also, I'm in the process of mapping the stock SAS modes to mines, so theoretically a plugin trying to set the stock SAS to "Prograde" would still work as intended (KOS for example).

1 hour ago, Errol said:

Could just have it as a high/low option instead of a 0-100 throttle.

But there already is the stock "fine controls" mode for that, so it would not add much value and still require me to hook on the the stock RCS modules somehow.

I will think about the RCS throttle at some point in the future, because I might try to add an RCS auto-balancer feature. But don't take my word on that because this is horribly complex, and it might prove even more complex to make it work correctly with the PID controller (this thing doesn't like having to deal with dynamic variations in the available torque).

[Tyko]

2 hours ago, Gotmachine said:

The SAS aggressivity "slider" (this : )doesn't affect the available torque from RCS thrusters (it isn't like the RCS throttle in the part tweakables). It affects only the maximum angular velocity the SAS will reach when going from an orientation to another. In detail, when the SAS has to turn the vessel, it does it in three phases : accelerate the rotation until a predefined angular velocity is reached, then wait until the desired orientation is near-reached, then counteract the angular velocity to coast and stop. The slider affect this predefined angular velocity.

 

This is perfect. If you're not in a hurry to turn you can dial it down and turn at a leisurely, fuel-efficient speed. Thanks   :) 

[debaker02]

Great mod!

[Errol]

@Gotmachine Could you add a toggle to switch between stock PID and mechjeb PID? There are some edge cases where one is better than the other, and being able to switch them on the fly would be handy. 

[Gotmachine]

14 hours ago, Errol said:

Could you add a toggle to switch between stock PID and mechjeb PID? There are some edge cases where one is better than the other, and being able to switch them on the fly would be handy. 

Yes, this is a feature that is already in place but there isn't any UI for it in the beta release, I think I will add as an additional state of the "SAS aggressivity slider". Note that the stock PID can't control roll, so this option will be unavailable when using the stock PID.

This said, could you elaborate about the specifics of these edge cases ? My own tests show that the mechjeb PID always performs a lot better in non-atmospheric situations, but it doesn't perform well with aero control surfaces, and in aero situations in general. Also, I suggest not to use the roll lock mode in low atmo flight, the extra constraint is just to much for the already struggling in atmo situations MechJeb PID code.

I tried to make a few tweaks to the aero control surfaces torque handling, but in its conception the MechJeb PID isn't the best solution for aero situations because he tries to find the theoretical "perfect" response using the theoretical data. In aero situations this isn't good because the external forces acting on the vessel are huge and hard to account for. This result in slow response followed by overcorrections and auto-oscillation issues.

In comparison, the stock PID don't rely much on the situation data, use over-aggressive basic responses and depending on the stability situation, enter a special "self-correcting" mode to smooth those response and allow the vessel to reach near-stability. This make it react quick and fast in broader range of situations, but remove its capacity to be exact. This is why it struggle to keep a stable vessel stable but is good at getting out of an unstable situation, and aero flight in KSP is a very unstable situation.

[Errol]

14 hours ago, Gotmachine said:

...

Yes, these types of oscillations in very light craft, or in atmosphere are what I'm talking about. To be honest, because of waiting for updates and such I haven't actually gotten to the point of setting up and using mechjeb in about two years, so I don't really have a super solid sense of specifics. 

[msnbcorp]

Hi, just a small question for the creator of the mod : in your intro your write that the mod doesn't do he rotation calculation continuously for unloaded vessel.

But what does it mean, that it do it sometimes ? At which rate ? Or that it does no calculation at all on unloaded vessel and restore a simulated state when loading ? 

 

I ask that because a lot of other mods (life support, background processing etc...) use background calculation, but they use the static default rotation and very few mod make clean calculation about the rotation when unloaded. Persistent rotation seems to have the same problem and does not fit well with theses mods ...

To conclude : if it's actually not calcultated at all, is it possible to include an option to make this calculated while unloaded despite the performance hit ? 

 

Edited April 30, 2018 by msnbcorp

[Gordon Dry]

@Gotmachine actually my install is borked as it seems and I try to find the culprit.

There are several mods affected, and the weirdest is that the Mandatory RCS icons are not shown up when I enable SAS and there is also no functionality ...
... AND there is nothing serious written to the log about that when I toggle SAS on/off...

Log and actual craft in flight:
https://www.dropbox.com/s/xh3sdek8na68r3m/2018-05-26_2 KSP.log.7z?dl=1

 

Edit:

 

Well, I fixed it - I just had to remove the relatively fresh added "Landertron" mod, which was still the old DLL but newer configs ...

Edited May 26, 2018 by Gordon Dry

[Gordon Dry]

@Gotmachine I found another issue:

After launching a crewed vessel I got full SAS control, prograde hold and roll hold.

Then I went back to SPC and after that back to the vessel, I could no more set roll hold, but only prograde (and retrograde) hold.

I found this in the log for one time:

InvalidCastException: Cannot cast from source type to destination type.
  at MandatoryRCS.VesselModuleMandatoryRCS.UpdateVesselState () [0x00000] in <filename unknown>:0 
  at MandatoryRCS.VesselModuleMandatoryRCS.VesselModuleUpdate (Boolean fromCallback, .FlightCtrlState ctrlState) [0x00000] in <filename unknown>:0 
  at MandatoryRCS.VesselModuleMandatoryRCS.OnPreAutopilotUpdate (.FlightCtrlState s) [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)
  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)
  at Vessel.FeedInputFeed () [0x00000] in <filename unknown>:0 
  at FlightInputHandler.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Log and craft:
https://www.dropbox.com/s/n6oc7t1hqogra3i/2018-05-28_1 KSP.log.7z?dl=1

Edited May 27, 2018 by Gordon Dry
Opened Github issue

[DSM20T]

I've just installed this mod via CKAN on a heavily modded install.  The mod seems to be working correctly but I don't have any options in the difficulty menu.  Any guidance to figure out why that is?

 

Thank you!

Edit:  Uninstalled and reinstalled via ckan a few times, same result and I don't think the mod is doing anything at all.  Installed manually, everything is working.  Ckan issue?

Edited May 28, 2018 by DSM20T

[walterdunst]

Love this mod, and have been using it for some time now. This mod really punishes you for putting on too few RCS ports or having an unbalanced craft. No more relying on stock's insane SAS. The future developments are also very welcome, having new controls on the NavBall is a great idea and it looks like something I would quickly be unable to play without.

Two things for if you ever decide to add new parts, though:

The game could really do with extra-big RCS thrusters, although I currently just use tweakscale to fix this, so not urgent at all.

Spaceplanes are overly nerfed with this mod. This is because they are already slow to maneuver in Stock, normal RCS thrusters have a low heat tolerance, and they end up needing many parts to cover all directions with 2 way symmetry. This means they have a more parts and less torque, which doubly slows things down on less-than-ideal machines. Personally i think you could do with a B9 Aerospace-style, plane RCS port that is aerodynamic, a five-way thruster, more powerful, and maybe a little heavier to compensate. That way SSTOs wouldn't take such a hit.

Thanks for the mod, it turns running out of RCS from minor inconvenience to a high alert problem, great for adding tension to any easy mission.

[Gordon Dry]

I've used the Beta release for some weeks now, but because of quirks here and there I decided to remove it for now.
But the part pack is still in service

As kinda replacement I added this patch:
GameData\zFinal\zzz_ReactionWheelsLessPowerful.cfg

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels]:FINAL
{
    @MODULE[ModuleReactionWheel]
    {
        @PitchTorque *= 0.05
        @YawTorque *= 0.05
        @RollTorque *= 0.05
    }
}

 

Edit:

For some reasons I changed the above config to this:

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:NEEDS[!RWSaturatable,!MandatoryRCS,!SETIrebalanceReactionWheels]:FINAL
{
    @MODULE[ModuleReactionWheel]
    {
        @PitchTorque *= 0.1
        @PitchTorque *= #$/mass$
        @YawTorque *= 0.1
        @YawTorque *= #$/mass$
        @RollTorque *= 0.1
        @RollTorque *= #$/mass$
		
		@RESOURCE[ElectricCharge]
		{
			@rate *= 0.1
			@rate *= #$/mass$
		}
    }
}

because I also did this:

Spoiler

GameData\zFinal\zzz_10xLessEC.cfg I scrapped that because background processing vs. RealBattery is still a bummer

Spoiler

@PART[*]:HAS[@RESOURCE[ElectricCharge]]:NEEDS[!RealBattery]:FINAL
{
	@RESOURCE[ElectricCharge]
	{
		@amount /= 10
		@maxAmount = #$amount$
	}	
}

@PART[*]:HAS[@RESOURCE[ReservePower]]:NEEDS[AmpYear]:FINAL
{
	@RESOURCE[ReservePower]
	{
		@amount /= 10
		@maxAmount = #$amount$
	}	
}

@PART[*]:HAS[@RESOURCE[StoredCharge]]:NEEDS[RealBattery]:FINAL
{
	@RESOURCE[StoredCharge]
	{
		@amount /= 10
		@maxAmount = #$amount$
	}	
}

 

and this
GameData\zFinal\zzz_SolarPanelsProvide2xLessEC.cfg also scrapped for now for the same reason

Spoiler

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
	@MODULE[ModuleDeployableSolarPanel]
	{
		@chargeRate /= 2
	}	
}

@PART[*]:HAS[@MODULE[KopernicusSolarPanel]]:NEEDS[Kopernicus]:FINAL
{
	@MODULE[KopernicusSolarPanel]
	{
		@chargeRate /= 2
	}	
}

 

and the 2 above I did because Kerbalism (dev repo) introduced this for a reason (in KSP the power consumption of antennas is about 500x to 1000x higher than what is realistic):
GameData\Kerbalism\System\Signal.cfg

...

// ============================================================================
// Reduce EC consumption
// ============================================================================
@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[DIRECT]]]:NEEDS[!RemoteTech]:FOR[Kerbalism]
{
	@MODULE[ModuleDataTransmitter]:HAS[#antennaType[DIRECT]] { @packetResourceCost /= 1000}
}

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]]]:NEEDS[!RemoteTech]:FOR[Kerbalism]
{
	@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]] { @packetResourceCost /= 1000}
}

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[RELAY]]]:NEEDS[!RemoteTech]:FOR[Kerbalism]
{
	@MODULE[ModuleDataTransmitter]:HAS[#antennaType[RELAY]] { @packetResourceCost /= 500}
} 

also for RemoteTech now with
GameData\Kerbalism\Support\RemoteTech.cfg

...

// ============================================================================
// Reduce EC consumption
// ============================================================================
@PART[*]:HAS[@MODULE[ModuleRTAntenna]]:NEEDS[RemoteTech]:AFTER[zzzKerbalism]
{
	@MODULE[ModuleRTAntenna]:HAS[~DishAngle[],#Mode1OmniRange[>0]] // omni
	{
		@EnergyCost /= 100
		@TRANSMITTER
		{
			@PacketResourceCost /= 1000
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleRTAntenna]]:NEEDS[RemoteTech]:AFTER[zzzKerbalism]
{
	@MODULE[ModuleRTAntenna]:HAS[#DishAngle[>0],#Mode1DishRange[>0]] // dish
	{
		@EnergyCost /= 50
		@TRANSMITTER
		{
			@PacketResourceCost /= 500
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleRTAntennaPassive]]:NEEDS[RemoteTech]:AFTER[zzzKerbalism]
{
	@MODULE[ModuleRTAntennaPassive] // probe core internal antenna
	{
		@TRANSMITTER
		{
			@PacketResourceCost /= 1000
		}
	}
}

and finally I just did this:
GameData\zFinal\zzz_AddElectricChargeToPodsWhoDontHave.cfg

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!RESOURCE[ElectricCharge]]:NEEDS[!RealismOverhaul,!RealBattery]:FINAL
{
    RESOURCE
	{
		name = ElectricCharge
		amount = 20
		@amount *= #$/mass$
		@amount += 5
		@amount ^= :\.\d+$::
		maxAmount = #$amount$
	}	
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!RESOURCE[ReservePower]]:NEEDS[!RealismOverhaul,AmpYear]:AFTER[AmpYear]
{
    RESOURCE
	{
		name = ReservePower
		amount = 5
		@amount *= #$/mass$
		@amount += 1
		@amount ^= :\.\d+$::
		maxAmount = #$amount$
	}	
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!RESOURCE[ElectricCharge]]:NEEDS[!RealismOverhaul,RealBattery]:BEFORE[RealBattery]
{
    RESOURCE
	{
		name = ElectricCharge
		amount = 20
		@amount *= #$/mass$
		@amount += 5
		@amount ^= :\.\d+$::
		maxAmount = #$amount$
	}	
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[RealBattery],!MODULE[KerbalEVA],@RESOURCE[ElectricCharge],#CrewCapacity[<1],#mass[<0.501]]:NEEDS[!RealismOverhaul,RealBattery]:AFTER[RealBattery]
{
	@title ^= :$: <color=green>(RealBattery)</color>:
	@description ^= :$: <color=green>(pimped by Real Battery Inc.)</color>:
	EC_maxAmount = #$/RESOURCE[ElectricCharge]/maxAmount$
	@RESOURCE[ElectricCharge]
	{	
		@name = StoredCharge
		@amount = #$/EC_maxAmount$
		@amount /= 1000
		@amount ^= :\.\d+$::
		@maxAmount = #$amount$
	}

	MODULE
	{
		 name = RealBattery
		 
		 BatteryType = 3 // 1 = Lead_Acid; 2 = Lead_Acid_singleUse; 3 = Li_Ion

		 HighEClevel = 0.8
		 LowEClevel = 0.2
	}
}

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel],!MODULE[RealBattery],@RESOURCE[ElectricCharge],#mass[<0.501]]:NEEDS[!RealismOverhaul,RealBattery]:AFTER[RealBattery]
{
	@title ^= :$: <color=green>(RealBattery)</color>:
	@description ^= :$: <color=green>(pimped by Real Battery Inc.)</color>:
	EC_maxAmount = #$/RESOURCE[ElectricCharge]/maxAmount$
	@RESOURCE[ElectricCharge]
	{	
		@name = StoredCharge
		@amount = #$/EC_maxAmount$
		@amount /= 1000
		@amount ^= :\.\d+$::
		@maxAmount = #$amount$
	}

	MODULE
	{
		 name = RealBattery
		 
		 BatteryType = 3 // 1 = Lead_Acid; 2 = Lead_Acid_singleUse; 3 = Li_Ion

		 HighEClevel = 0.8
		 LowEClevel = 0.2
	}
}

@PART[*]:HAS[!MODULE[RealBattery],@RESOURCE[ElectricCharge],@RESOURCE[MonoPropellant],~CrewCapacity[],#mass[<1.001]]:NEEDS[!RealismOverhaul,RealBattery]:AFTER[RealBattery]
{
	@title ^= :$: <color=green>(RealBattery)</color>:
	@description ^= :$: <color=green>(pimped by Real Battery Inc.)</color>:
	EC_maxAmount = #$/RESOURCE[ElectricCharge]/maxAmount$
	@RESOURCE[ElectricCharge]
	{	
		@name = StoredCharge
		@amount = #$/EC_maxAmount$
		@amount /= 1000
		@amount ^= :\.\d+$::
		@maxAmount = #$amount$
	}

	MODULE
	{
		 name = RealBattery
		 
		 BatteryType = 3 // 1 = Lead_Acid; 2 = Lead_Acid_singleUse; 3 = Li_Ion

		 HighEClevel = 0.8
		 LowEClevel = 0.2
	}
}

 

 

Edited July 24, 2018 by Gordon Dry
some updates

[kurgut]

Great job!

[Gordon Dry]

I just wanted to mention that I just updated my post two posts above.

[dlrk]

Is there a CFG option or anything to let reaction wheels in pods work like other reaction wheels?

[JH4C]

2 hours ago, dlrk said:

Is there a CFG option or anything to let reaction wheels in pods work like other reaction wheels?

Yes; if you check in the mod folder, you'll find ModuleTorqueControllerPatch.cfg. This is the basic patch that makes the mod work, and it also includes instructions for the codes you need to use to re-activate reaction wheels in selected command pods again. I've not done it myself but it looks straight-forward enough to use.

If you just want them all to work again, or you wnt to vary how much control they offer, those settings are available from the Pause menu.

Edited September 17, 2018 by JH4C
extra thoughts

[dlrk]

8 minutes ago, JH4C said:

Yes; if you check in the mod folder, you'll find ModuleTorqueControllerPatch.cfg. This is the basic patch that makes the mod work, and it also includes instructions for the codes you need to use to re-activate reaction wheels in selected command pods again. I've not done it myself but it looks straight-forward enough to use.

If you just want them all to work again, or you wnt to vary how much control they offer, those settings are available from the Pause menu.

Thanks. Just wondering, what was the reasoning for disabling the pod reaction wheels?

[linuxgurugamer]

@Gotmachine 

Couple of things.

First, just wondering where you are in the beta.  

Second, I have a request/suggestion:    It makes sense that the reaction wheels are nerfed, it's why I love this mod.  But, as time goes on, I was thinking that there could be levels at which reaction wheels  will gradually become more effective.  I was wondering what you think about this, and if you could put it in, maybe as a configurable option?

 

[Gotmachine]

On 9/17/2018 at 3:26 AM, dlrk said:

Thanks. Just wondering, what was the reasoning for disabling the pod reaction wheels?

Note that the reaction wheels are not disabled, they still provide passive stabilization when the SAS is enabled. But they are not "controllable", meaning that they don't react to your input. I explained the rationale somewhere in this thread. In short, it is done so to force you to use RCS thrusters when it would make sense from a realism standpoint, while still allowing you the cheaty stabilization from KSP massively nonrealistic reaction wheels.

You can disable the "not controllable" part by changing the ModuleTorqueControllerPatch.cfg  to this :

@PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[ModuleTorqueController]]:FOR[MandatoryRCS]
{
	MODULE
	{
		name = ModuleTorqueController
		isControllable = True
	}
}

For it to be effective, you also need to go into the mod settings in KSP settings menu and check the "SAS & pilot control customization" box.

On 9/17/2018 at 3:01 PM, linuxgurugamer said:

First, just wondering where you are in the beta.  

This is on standby for now as I haven't got much free time to work on it, but I've been playing with it a quite a lot. It's kinda playable as it is, but there are a few things that need to be done before release and TBH I'm having a hard time fixing those :

• The UI is a bit quirky and have some bugs that need to be sorted
• There are some physics/timewarp/transforms related bugs in the persistant rotation/SAS part that are bothering me and that I don't fully know how to fix
• The overall structure of the code is a ugly mess, I'm probably at the peak of my "I don't really know what I'm doing but let's try this" motto
• The RW nerf need to be polished
• The settings menu need to be redone
• I need to allow switching between the mechjeb and stock SAS because while being a lot better in space and for rockets in general, the mechjeb autopilot is not so great for planes, there is some work to be done to allow that (wiring the stock SAS to my custom SAS UI).

On 9/17/2018 at 3:01 PM, linuxgurugamer said:

I was thinking that there could be levels at which reaction wheels  will gradually become more effective.

I'm not sure I understand. Do you mean like a tech tree related progression ?

The thing is, the plugin doesn't make the RW less effective, it just prevent you from using it in an unrealistic way, only the SAS can do so. The goal is to force you to put RCS thrusters on your (heavy) spaceship, and the SAS part is here so you don't need to pack huge unrealistic amounts of RCS fuel. This also why in the new version I'm integrating the mechjeb SAS and a better SAS UI : to allow you to consume less RCS fuel and have more precise (less wasteful) control.

In the end, this is a binary problem. Either you can't turn using only your reaction wheels and you have to add RCS, either you can and RCS are useless.

But as many pointed out, the whole controllable/non controllable hack is counter-intuitive. I want to test another idea : the "controllable" available torque could be adjusted in an exponential relation with the vessel mass, something like this :

• A 1 t vessel with 1 kN of "stock torque" would have 0.1 kN of "controllable torque", resulting in the ability for the pilot to fully control the vessel using only reaction wheels
• a 10 t vessel with 10 kN of "stock torque" would only have 0.5 kN of "controllable torque", resulting in a very low ability to control the vessel

This would automagically balance the available torque so "light" vessels in the 0-5 t range are controllable using a stockish amount of reaction wheels while larger ones would need more, or to switch to using RCS.

I also want to experiment something akin to what the (Semi-)Saturatable Reaction Wheels plugin was doing, implementing a basic saturation mechanism with auto-desaturation when the wheels are idle.

 

[dlrk]

7 minutes ago, Gotmachine said:

Note that the reaction wheels are not disabled, they still provide passive stabilization when the SAS is enabled. But they are not "controllable", meaning that they don't react to your input. I explained the rationale somewhere in this thread. In short, it is done so to force you to use RCS thrusters when it would make sense from a realism standpoint, while still allowing you the cheaty stabilization from KSP massively nonrealistic reaction wheels. 

You can disable the "not controllable" part by changing the ModuleTorqueControllerPatch.cfg  to this :

 

 

But aren't they still nerfed and subject to saturation like the other reaction wheels? The non-controllable pod wheels make it so that they can't control attitude during reentry (which IRL capsules can do with some sort inertial mechanism)

Edited September 18, 2018 by dlrk

[linuxgurugamer]

13 minutes ago, Gotmachine said:

I'm not sure I understand. Do you mean like a tech tree related progression ?

Yes.  See below

13 minutes ago, Gotmachine said:

But as many pointed out, the whole controllable/non controllable hack is counter-intuitive. I want to test another idea : the "controllable" available torque could be adjusted in an exponential relation with the vessel mass, something like this :

• A 1 t vessel with 1 kN of "stock torque" would have 0.1 kN of "controllable torque", resulting in the ability for the pilot to fully control the vessel using only reaction wheels
• a 10 t vessel with 10 kN of "stock torque" would only have 0.5 kN of "controllable torque", resulting in a very low ability to control the vessel

 This would automagically balance the available torque so "light" vessels in the 0-5 t range are controllable using a stockish amount of reaction wheels while larger ones would need more, or to switch to using RCS.

That sound good.

I'm using this in my main game which I broadcast on Sunday nights.

So what I'm thinking is that what you mention about the 1t vessel, etc in the above paragraph would essentially scale in steps, so as you get more science the reaction wheels become somewhat more effective.

Just a thought