Jump to content

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


Recommended Posts

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 ; )

Link to post
Share on other sites
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 by Corax
Link to post
Share on other sites
  • 1 month later...

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 by Agustin
Link to post
Share on other sites

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 by Jognt
Link to post
Share on other sites
  • 2 weeks later...

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 by Parallax9
Link to post
Share on other sites
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.

Link to post
Share on other sites
  • 6 months later...

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?

 

Link to post
Share on other sites
  • 1 month later...

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 by RyGuy_McFly
Link to post
Share on other sites

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 by RyGuy_McFly
Link to post
Share on other sites
  • 3 weeks later...

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.

Link to post
Share on other sites

@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 by Gotmachine
Link to post
Share on other sites
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

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...