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

[Autolyzed Yeast Extract]

Not functioning properly in 1.9. Reaction wheels of any kind cannot be controlled and do not provide stability assist. I want nerfed reaction wheels but I still want them to actually exist as a gameplay element.

[Corax]

10 hours ago, Autolyzed Yeast Extract said:

Not functioning properly in 1.9. Reaction wheels of any kind cannot be controlled and do not provide stability assist. I want nerfed reaction wheels but I still want them to actually exist as a gameplay element.

Here's what I use... or used to use, haven't tested yet later than KSP1.7.3:

////////////////////////////////////////////////////////////////////
//
// 1. reduce capsule/probe/cockpit torque forces by 99% ---
//    that should take care of the probes, too ---
//
// first pass, *all* reaction wheels to 0.5 = 50%
@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:BEFORE[Corax]{
  @MODULE[ModuleReactionWheel]{
    @PitchTorque *= 0.5
    @YawTorque *= 0.5
    @RollTorque *= 0.5
  }
}
// second pass, non-dedicated parts to 0.5*0.02 = 1%
@PART[*]:HAS[@MODULE[ModuleReactionWheel],@MODULE[ModuleCommand]]{
  @MODULE[ModuleReactionWheel]{
    @PitchTorque *= 0.02
    @YawTorque *= 0.02
    @RollTorque *= 0.02
  }
}
// finally, (airplane) cockpits usually don't have reaction wheels at all
// create exceptions for non-airplanes if/when necessary
@PART[*ockpit*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL{
  -MODULE[ModuleReactionWheel]{}
}

Unless something changed in MM, I don't see why it shouldn't still work. I'm just slowly catching up with all the changes since 1.7 ; )

[Autolyzed Yeast Extract]

On 3/4/2020 at 3:19 AM, Corax said:

stuff

I appreciate it but I'm not very handy so I'll wait until the mod is updated.

[Corax]

1 hour ago, Autolyzed Yeast Extract said:

I appreciate it but I'm not very handy so I'll wait until the mod is updated.

No worries. All you should need to do is open a text editor (probably called Notepad if you're on Windows), copy the code I posted into it, and save as a new file under KSP/GameData, with a file extension of ".cfg". I suggest having a directory under GameData for your own, local patches. You might name it "LocalPatches", or "AutolyzedYeastExtract", for example. For good measure, when you are done, copy (not move) that directory somewhere else where you can find it later, because when KSP updates it might get removed.

If you have ModuleManager installed, which is likely if you have any mods installed at all, it will pick it up automatically the next time you launch KSP. If you don't have MM installed, the patch will just sit there, and nothing will change in your game.

PS.:

Oh, and when you save the file as something.cfg, you may or may not get a warning about the file extension (ignore it), I haven't used Windows in over a decade, and no idea at all about MacOS if that's what you're using.

Edited March 12, 2020 by Corax

[Agustin]

I am orbiting mun and after docking my probe with another probe, my reactions wheels seem to provide rotation although I have the settings set to NONE. Is it a bug?

I didn't have rotation before docking.

I am 1.8.1

Edited April 15, 2020 by Agustin

[Jognt]

Just now I realized I commented about problems I encountered but did not come back to properly thank you for fixes @Gotmachine  

So thank you.  

Edit: Sadly I cannot help or say anything regarding problems encountered by others here as I haven’t played since 1.7. 

Edited April 15, 2020 by Jognt

[Parallax9]

Hi @Gotmachine, does this mod compatible with remote tech flight manager +(signal delay) ? 

It seems flight manager still use rcs even after it's already in correct attitude, wasting so many monoprop. 

Maybe I just disable the rcs and use the reaction wheel and wait the vehicle turning, or its better to use stock sas and get a probe with higher sas capability? 

Edited April 30, 2020 by Parallax9

[Gotmachine]

40 minutes ago, Parallax9 said:

does this mod compatible with remote tech flight manager +(signal delay) ?

Any mod that use it's own attitude controller instead of the stock SAS will indeed not benefit from the craft reaction wheels (MechJeb, TCA, kOS...)
Not sure how the RT flight manager does it, so I can't say for sure but it is probable that it will run into the same issue as those mods.
So yep, try to use the stock SAS as much as possible.

[eberkain]

I am playing in 1.10.1.  There seems to be a bug with the "realistic" mode setting.  If you are locked onto an SAS setting, and then push a different SAS button, you will get an immediate kick in that direction with the full reaction wheel torque.  Then the torque gets scaled down and the craft can't stop spinning.   

I have been playing on the "none" setting to avoid those issues, which creates its own issue.  That basically just removes reaction wheels from the game, you need RCS to have any attitude control.  But I would still like to have small lightweight satellites rely on just reaction wheels.  

I kind of wish there was another setting, call it "hardcore".  It would just blanket scale down reaction wheels all the time regardless of SAS activity.  I suppose I could do that with a MM patch and then disable the reaction wheel rebalance in the mod.  Would that be safe to do mid game?  How would it effect vessels in-flight?  Would the saturation feature still function correctly if I did that?

 

[RyGuy_McFly]

I'm also having eberkains issue mentioned above, with probes getting a small, un-counterable burst of speed when switching SAS modes (I am in 1.8.1), I'm wondering if this has always been an issue and how you guys get around it as it is pretty debilitating to me. I would like to be able to use the small, reaction-wheel only probe cores, but they're constantly flicking themselves out of control. It seems like the reaction wheels' torque needs to be cut off a tick or so sooner. Is this possibly just caused by game lag?

Edited January 11, 2021 by RyGuy_McFly

[RyGuy_McFly]

EDIT: Also, is there any way to get a body to consistently track the sun, like you could with Persistent Rotation? Or should I just also install PR for sun-tracking and disable the persistent rotation factor of this mod?

Edited January 13, 2021 by RyGuy_McFly

[garwel]

Hi, there is a compatilibity issue between MandatoryRCS and kOS (since its last update). Below is a description by kOS' author. Do you think it's something you could address on your side?

2 hours ago, Dunbaratu said:

Reading through the MandatoryRCS code on github, it appears that its nerfing of reaction wheels is done in a way that is problematic for other mods that also have an OnFlyByWire() pass like kOS.

I say this because the order of events seems to be this:

1 - In its Update(), kOS queries the sum of all torque capability provided by all parts (RCS, reaction wheel, engine gimbal, etc).
2 - In its OnFlyByWire(), kOS uses that value to choose how it should set the pitch/yaw/roll controls.
3 - In its OnFlyByWire(), MandatoryRCS nerfs the reaction wheel capability now that it's too late for kOS to see the change.
4 - Now the stock game physically affects the ship by applying the pitch/yaw/roll controls  that kOS assigned in step 3 above.
5 - Now the stock game resets the reaction wheels' torque back to stock values for the next pass.
6 - Back to step 1.

This order of events makes the nerfing that MandatoryRCS does be invisible to kOS, since that nerfing only exists temporarily in between kOS's passes.  By the time kOS queries the values again next pass, they're back to their stock settings again, and won't get re-nerfed until after kOS's OnFlyByWire() control settings have been locked in.

It might be possible to work around this by having kOS move its torque capability query to its OnFlyByWire() instead of its Update(), and also continually check the Delegate dispatch chain order of OnFlyByWire()s and if kOS's hook comes before MandatoryRCS's hook, have kOS move it's hook to the end of the chain to guarantee it lets MandatoryRCS go first (swapping the order of step (2) and step (3) in my above description.)  But that's a weird ad-hoc fix to a problem I'm not really sure is kOS's fault.

[Gotmachine]

@garwel@Dunbaratu
In the posted chain of events, there is no step 5 : the stock RW torque is never restored.
Therefore, the worst that can happen from the kOS POV is that it, in case the torque doesn't stay constant, the available torque that kOS uses for it's attitude control PID will be the one from the previous step.
With MandatoryRCS, this mainly happen if the stock SAS is active. From what I understand (am I wrong ?), kOS rely on it's own attitude controller and disable the stock SAS.
So I have some doubts that there is actually any torque change happening while kOS has the attitude control in its hands.

However, what will definitely happen is that while kOS is in control, the RW torque will be locked in the very heavily nerfed one, essentially providing next to no effect.
From some experimentation I did a while ago, I remember that most KSP attitude PID controllers (stock, kOS, mechjeb...) have a very hard time achieving stability with only RCS.
The PID parameters are often quite aggressive and that doesn't play well with RCS, which are always at least slightly unbalanced, which is especially an issue when the RCS available torque is high.
Which would explain why reducing artificially the PID aggressiveness by forcing  it to see only 10% available torque get ride of the oscillation issue.
Easy way to test that : disable the RW nerf in MandatoryRCS settings, reload the craft, set all the craft RWs torque to zero through the stock PAW slider : does the craft also has trouble stabilizing ?

All this being said, as a general rule, MandatoryRCS doesn't play well with non-stock attitude controllers (kOS, MechJeb, TCA...), as the whole nerf is made to work in conjunction with the stock SAS state.
This has always been a major issue. And TBH, that plugin is in zero effort maintenance mode, and I have a very low motivation to work on it.

If I were to decide to work on it again, I would likely rewrite it from scratch (the overall code quality is... poor).
I have a few ideas that would make it work a bit differently, and would allow much better compatibility with other mods.

Edited January 28, 2021 by Gotmachine

[Dunbaratu]

1 hour ago, Gotmachine said:

@garwel@Dunbaratu
In the posted chain of events, there is no step 5 : the stock RW torque is never restored.
Therefore, the worst that can happen from the kOS POV is that it, in case the torque doesn't stay constant, the available torque that kOS uses for it's attitude control PID will be the one from the previous step.
With MandatoryRCS, this mainly happen if the stock SAS is active. From what I understand (am I wrong ?), kOS rely on it's own attitude controller and disable the stock SAS.
So I have some doubts that there is actually any torque change happening while kOS has the attitude control in its hands.

However, what will definitely happen is that while kOS is in control, the RW torque will be locked in the very heavily nerfed one, essentially providing next to no effect.
From some experimentation I did a while ago, I remember that most KSP attitude PID controllers (stock, kOS, mechjeb...) have a very hard time achieving stability with only RCS.
The PID parameters are often quite aggressive and that doesn't play well with RCS, which are always at least slightly unbalanced, which is especially an issue when the RCS available torque is high.
Which would explain why reducing artificially the PID aggressiveness by forcing  it to see only 10% available torque get ride of the oscillation issue.
Easy way to test that : disable the RW nerf in MandatoryRCS settings, reload the craft, set all the craft RWs torque to zero through the stock PAW slider : does the craft also has trouble stabilizing ?

All this being said, as a general rule, MandatoryRCS doesn't play well with non-stock attitude controllers (kOS, MechJeb, TCA...), as the whole nerf is made to work in conjunction with the stock SAS state.
This has always been a major issue. And TBH, that plugin is in zero effort maintenance mode, and I have a very low motivation to work on it.

If I were to decide to work on it again, I would likely rewrite it from scratch (the overall code quality is... poor).
I have a few ideas that would make it work a bit differently, and would allow much better compatibility with other mods.

Dangit I had a long reply but lost it because of the forum's editor.  (It pulled focus out of the text area for some odd reason, changing the meaning of backspace to the browser's default "prev browser page" meaning instead of the textarea's "remove a letter" meaning.... grrr.)

Anyway, the gist of it is this - regardless of WHY, the fact is that when kOS queries the reaction wheels for what torque they are able to provide, the answer they get back is the stock value, and this is at the core of why kOS is steering all wrong in this case.  Whatever MandatoryRCS is doing to change the reaction wheels' behavior, kOS isn't seeing it when it queries them.

I also turned on a feature in kOS that has the steeringmanager dump a lot of stats on the terminal screen while it steers (set steeringmanager:SHOWSTEERINGSTATS to true.)  Using this I was able to prove that if I use a stock install without MandatoryRCS, and suppress the reaction wheels myself with the stock toggle button on the PAW, kOS is capable of steering with the RCS alone just fine, and the stats on screen correctly reflect that the reaction wheel torque is missing from the sum of all torque, with just the torque the RCS supplies remaining.  But when using MandatoryRCS, and *it* suppresses the reaction wheels, that same stat shows the full stock value, even though when steering manually with WASD keys instead of with kOS, I can't make the vessel turn at all when RCS is off and I'm relying on the reaction wheel alone (conclusion, the reaction wheel actually provides zero torque, as one would expect MandatoryRCS to be doing, but the query kOS sees is still claiming it's working at full stock magnitude and is not disabled.)

(The reason a false reporting of how much torque the wheel is capable of providing causes kOS to steer all wrong is that kOS is predicting how many seconds it would take to stop rotating from this information.  When the value is reported higher than it really is, kOS thinks the vessel is capable of stopping rotation quickly when it really isn't, so it keeps overshooting the target facing.)|

I should say that older versions of kOS *did* have the problem you mention where it was bad at steering with RCS alone.  But the latest version is much better at it (because it now rolls its own GetPotentialTorque() like all the other autopilot mods had to resort to doing because the stock one is all wrong when it comes to RCS thrusters).  With older versions, what you say would have been true (that even without MandatoryRCS, the kOS mod is just bad in general at steering by RCS alone), but with the latest release it's not anymore.  Now it's only got problems when it's MandatoryRCS that's disabling the reaction wheel instead of doing so through stock means.

I should also point out that the user who reported this to me was installing MandatoryRCS on a KSP 1.11 install even though MandatoryRCS is only *advertised* as being good up to KSP 1.8, so perhaps that has something to do with it?  I don't know.

Do you know of anything I could query from kOS's side  to discover whatever it is that MandatoryRCS does to suppress reaction wheels so I can report the proper number to myself when querying the torque?  Our Torque calculation for reaction wheels is this: https://github.com/KSP-KOS/KOS/blob/d308fae5a92eaf834013fbfaf8259f4889fc9aab/src/kOS/Control/SteeringManager.cs#L733

[Gotmachine]

Okay...
Well, the only real answer I can give is that MandatoryRCS was never made to behave correctly when a non-stock attitude controller is used.
Reading the code you linked and re-checking the MandatoryRCS code, I fail to understand how the stock non-nerfed stock could be returned by your method while having the actual torque being consistently different.
The RW torque is set in a single atomic operation, so the only way that could happen if is MandatoryRCS is applying full torque in a step, then zero in the next one, and so on. Which could maybe be triggered in case vessel.Autopilot.Enabled is also flickering.

35 minutes ago, Dunbaratu said:

I should also point out that the user who reported this to me was installing MandatoryRCS on a KSP 1.11 install even though MandatoryRCS is only *advertised* as being good up to KSP 1.8, so perhaps that has something to do with it?  I don't know.

Well, as I said, I more or less stopped maintaining that plugin actively a long time ago. It might indeed be broken is some way in recent KSP versions.

[SiCaRiO31]

is there a way to make probes only have stability control with external reaction wheels instead of having one build into them by default? I miss that the most from the original Unmaned Before Maned

[snakeru]

For all that miss that mod in latest KSP versions: I found this solution for myself:

1) "Mandatory RCS Parts Pack" mod
2) "Reaction Wheel Rebalance" mod
3) "Persistent Rotation" mod

For me the "Mandatory RCS" mod was almost exclusively about nerfing reaction wheels so that I'm forced to use RCS and maintaining rotation in time warp. The mod combo referenced above achieves exactly that.

"Reaction Wheel Rebalance" mod is even older, but it works with latest KSP and will probably always will, given how trivial its implementation is - it is just a single config file that decreases the wheels torque. These that want to nerf the wheels even more could just edit this file directly.

UPDATE:
After playing with this combo some more I notice the following differences:
* as the torque of the RW doesn't change - there is no dedicated "stabilisation mode" - on the plus side there is no "kick" bug, on negative - you more-or-less must have additional RW modules for more fine grained control of the vessel
* if SAS is on then the rotation is stopped in timewarp which is unfortunate

Edited June 6, 2021 by snakeru

[FastAsHeck]

Using the part pack, the standard size RCS parts have no texture. The small ones are fine. Anyone know a fix?

[Mick_B]

On 6/30/2023 at 9:13 PM, FastAsHeck said:

Using the part pack, the standard size RCS parts have no texture. The small ones are fine. Anyone know a fix?

It seems this mod was using textures from old version of original rcs, which as at some point been removed.

I've managed to restore it by downgrading to version 1.7 and copying file rcs.dds

GameData/Squad/Parts/Utility/rcsBlockRV-105

to

file into

GameData\MandatoryRCSPartPack\Parts\RCS_RV105Variants

 

[bigyihsuan]

On 6/30/2023 at 3:13 PM, FastAsHeck said:

Using the part pack, the standard size RCS parts have no texture. The small ones are fine. Anyone know a fix?

On 11/13/2023 at 2:02 PM, Mick_B said:

It seems this mod was using textures from old version of original rcs, which as at some point been removed.

I've managed to restore it by downgrading to version 1.7 and copying file rcs.dds

GameData/Squad/Parts/Utility/rcsBlockRV-105

to

file into

GameData\MandatoryRCSPartPack\Parts\RCS_RV105Variants

 

Another fix is going into the MandatoryRCSPartPack/Parts/RCS_RV105Variants/DepreciatedRV105Fix.cfg file, and editing the path to the RCS texture.

Change "@texture = rcs, Squad/Parts/Utility/rcsBlockRV-105/rcs" to "@texture = rcs, Squad/Parts/Utility/rcsBlockRV-105_v2/rcs". Note the added "_v2".

[Mick_B]

On 11/18/2023 at 4:24 AM, bigyihsuan said:

Another fix is going into the MandatoryRCSPartPack/Parts/RCS_RV105Variants/DepreciatedRV105Fix.cfg file, and editing the path to the RCS texture.

Change "@texture = rcs, Squad/Parts/Utility/rcsBlockRV-105/rcs" to "@texture = rcs, Squad/Parts/Utility/rcsBlockRV-105_v2/rcs". Note the added "_v2".

The reason i went digging for old texture file is because for me this does not work.

As far as i can tell v2 textures are in a different format, there is no rcs.dds files at any rate, and the parts remain blank.

Edited November 19, 2023 by Mick_B

[kspkat]

My situation: I have a station in orbit, and I send up a tanker to refuel. Problem is when rocket is off balance, if SAS/reaction wheels are on it shakes the rocket and explodes. For now I just transfer with the SAS off but it would be nice if I could go into a mode where only the station (with all the new weight) is the one with working reaction wheels, and the other end just swings around.

What I need: I am looking for a way to list every reaction wheel on the vessel , ordered by ship ID, so I can pick a bunch and turn them off or adjust torque limit. I am not sure if this mod has this functionality or not.

• If this mod has this functionality, can I do it without nerfing the reaction wheels?
• If this mod does not have this, is there a mod that does have this?
• If there is no mod that has this, can I suggest that as a feature?

Thanks for another mod LGG  my you've got a lot on your plate doing the community a favor

Edited March 9 by kspkat
I'm an idiot

[Clayel]

@kspkat You can probably go into your .sfs save file and find the reaction wheel part for that specific vessel.

 

Unrelated, what is the difference between this mod's stock rotation fix and PersistentRotation's stock rotation fix?