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

[Gotmachine]

6 hours ago, Oneiros said:

A simple solution might be to only use RW's to remove all angular velocity once it drops below a certain (very low) threshold.

I already tried that. It doesn't work in practice because this mean RW are useless if you don't have RCS thrusters onboard, which should be the case on a lot of small sat / probes from a realism standpoint. The problem is that you are able to accelerate your angular velocity above the threesold and then you can't decelerate... This is absolutely not realistic, and would be very annoying. In fact the current version is already doing something like that : RW torque output decrease with angular velocity, but there uis a minimum value so you can't brick your craft.

6 hours ago, Oneiros said:

You could also have the feature of making small rotations over time (such as always pointing at the sun).

This is already in the plugin, and it's been expanded to allow to target the sun in the beta version.

6 hours ago, Oneiros said:

Basically each RW could have a maximum rated vessel mass that it can stabilise

See my previous post :

On 9/18/2018 at 9:37 PM, Gotmachine said:

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.

 

6 hours ago, Oneiros said:

The next easiest solution seems to be just nerfing them down to 1% of stock torque.

The current default setting is 0.5 % ("realistic" in the settings menu). But this only apply to pilot input. The SAS still has partially access to the default stock torque, this is the main feature of the RW nerf : allow easy cheaty stabilization using the SAS, have a realistic torque output for rotation requests. Judging from the comments, this works well. The part that i'm struggling with is that this 0.5% ratio apply to the stock torque balance which is all over the place. More precisely, the various pods usually have huge amounts of torque given their mass and size and compared to the individual RW parts and probe cores. In the current version my solution was to completely disable the "pilotable" torque from the pods, not very popular and a bit silly TBH. I think in the next version I will patch the pods to something like 25-50 % of the stock value, but I'm also exploring other means of balancing things like the idea above, and possibly a pseudo-saturation mechanism.

On 9/18/2018 at 11:16 PM, linuxgurugamer said:

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.

Well this isn't very realistic... a reaction wheel or control gyro is a basic tech that can't really be improved much in terms of their mass / torque ratio. If someday I introduce some progression it would be based on various attitude control related technologies (magnetorquers, reaction wheels, CMGs...), see this post for details of what I have in mind for the far future.  And to be fair I've totally given up on career mode, so not much interest personally.

[Drew Kerman]

On 9/20/2018 at 9:16 PM, Oneiros said:

RCS are too coarse and powerful

depends on how realistic it is to use the Thrust slider. Honestly not sure, but I would imagine even simple cold-gas RCS thrusters could adjust their ouput

[lajoswinkler]

Reporting that, on v1.5.1, this sometimes work and sometimes doesn't. I think it needs to be recompiled.

[Gotmachine]

@lajoswinklerCan you please point me to what exactly doesn't work ?

I will try to get back working on the version 2.0 soon, but I will probably do a bugfix release for 1.5 if needed

[lajoswinkler]

1 hour ago, Gotmachine said:

@lajoswinklerCan you please point me to what exactly doesn't work ?

I will try to get back working on the version 2.0 soon, but I will probably do a bugfix release for 1.5 if needed

Stopping the momentum by timewarping (stock behaviour) works, but torque is highly attenuated (mod behaviour).

[gamerscircle]

This might not make a whole lot of sense, I like this approach , so that Reaction Wheels get toned down, but can I omit the parts?  I am trying to get the minimum amount of parts in my game.

Thanks

[linuxgurugamer]

1 hour ago, gamerscircle said:

This might not make a whole lot of sense, I like this approach , so that Reaction Wheels get toned down, but can I omit the parts?  I am trying to get the minimum amount of parts in my game.

Thanks

You can, just delete the parts from the MandatoryRcs directory.

[Drew Kerman]

I'm about to plop this into my KSP v1.5.1 install. Will report if I notice any issues but anyone else see any? I saw lajoswinkler's post above and read back a page.

[linuxgurugamer]

On 10/29/2018 at 2:29 PM, Gotmachine said:

@lajoswinklerCan you please point me to what exactly doesn't work ?

I will try to get back working on the version 2.0 soon, but I will probably do a bugfix release for 1.5 if needed

@Gotmachine

What's the status of 2.0?  I see that there is a beta which has been there since April, is it ready for prime time yet?

[Raccoon]

Very much hoping there's eventually a recompile or update for recent versions, a must-have mod for me.

[Stone Blue]

1 hour ago, Raccoon said:

Very much hoping there's eventually a recompile or update for recent versions, a must-have mod for me.

Is current version not working for you?... what issues are you having?

[reviest]

2 hours ago, Raccoon said:

Very much hoping there's eventually a recompile or update for recent versions, a must-have mod for me.

Works pretty fine for me in 1.6.1.

[Raccoon]

1 hour ago, Stone Blue said:

Is current version not working for you?... what issues are you having?

My bad, I thought I had installed it and it wasn't working but I hadn't even put it into GameData, oops. Seems to work perfectly now that I've actually installed it.

[KSPrynk]

@Gotmachine,

Just tried MandatoryRCS Parts Pack in KSP 1.7.  The micro-sized thrusters seem to be fine, but the RV-105 variants are all missing their textures - although they seem to function normally.  I'm guessing this is due to Squad's revamp of the Stock RV-105 textures.

EDIT: I added an Issue in GitHub.

Edited May 3, 2019 by KSPrynk

[KSPrynk]

@Gotmachine,

I've confirmed the RV-105 Variant cfg files are pointing to a dead end for their textures.  KSP 1.7 did away with the old LinearRCS subfolder and now there are two new RCS Block subfolders.  The Squad revamped RV-105 is in one folder, but they also created a new folder with the old part, presumably in deprecation.

A quick fix is to edit all the RV-105 Variant cfg files with the following in the MODEL section:

texture = rcs, Squad/Parts/Utility/rcsBlockRV-105/rcs

This points to the old rcs.dds file in the new path name for the deprecated part.  As far as I can tell, it works just fine with this edit.

Just for fun, I tried pointing to the new part's diffuse texture, but it turned into an unholy mess.  The long term fix is all the RV-105 Variants likely need to be redone to match up with the new textures and effects that come with the revamped Squad model.

Edited May 4, 2019 by KSPrynk

[Jesusthebird]

@KSPrynk thanks! Im doing some part pruning with janitors mod and noticed this. I assumed it was because of the revamped textures too. shame the new textures dont work on them right now. maybe one of these days.

[Jognt]

I've been using Mandatory RCS (without the parts pack) for a week now in my 1.7 game. The functionality is there, but while tracking nullrefs from other mods I encountered a situation where I got about 10.000 NullRefs from Mandatory RCS in the timespan of one reentry..

Maybe I screwed up something, maybe not. I exited the game asap after the nullref flood.

https://www.dropbox.com/s/4h4b51ofl5xsbtg/Nullrefs4ever_output_log.zip?dl=0

Context: I just did a pretty big probe-only rocket that sent 6 probe-only commsats to the mun, landed, and came back. Lots of RCS had been used and decoupled, etc.

[Gotmachine]

There are definitely some bugs when using the latest version (1.5)  in KSP 1.6, and even more with KSP 1.7.
I will try to properly update the plugin (and the part pack) someday, but for now I have other things on my plate.

In the meantime, you can try to replace the dll in GameData/MandatoryRCS by this one : MandatoryRCS-1.5-HOTFIX-KSP-1.7
It's just a recompile but I know it fixes (some of) the nullref spam, and a few other quirks.

[Jognt]

2 hours ago, Gotmachine said:

There are definitely some bugs when using the latest version (1.5)  in KSP 1.6, and even more with KSP 1.7.
I will try to properly update the plugin (and the part pack) someday, but for now I have other things on my plate.

In the meantime, you can try to replace the dll in GameData/MandatoryRCS by this one : MandatoryRCS-1.5-HOTFIX-KSP-1.7
It's just a recompile but I know it fixes (some of) the nullref spam, and a few other quirks.

Cheers! I'll give it a whirl and let you know if it fixes the 10.000 Nullref Combo Breaker during re-entry (just had it again) .

With regards to the parts pack, I've been using the adorable mini RCS thrusters from ReStock+ so I do not how how they currently work in 1.7.

Ps. Man, figuring out how much RCS fuel to bring is a whole new challenge of its own. I'm getting into the habit of disabling SAS during RCS movement though since SAS likes to waste RCS like no tomorrow.

[Gotmachine]

3 minutes ago, Jognt said:

I'm getting into the habit of disabling SAS during RCS movement though since SAS likes to waste RCS like no tomorrow.

This is absolutely NOT the right way to play with this plugin. By doing that you essentially disable your reaction wheels, depriving yourself from the torque they can provide.
The right way to actively reduce your RCS fuel consumption is by micromanaging the RCS toggle and using as much as possible the various SAS modes.
First rule : keep the RCS toggle disabled as much as possible. When you want to change the attitude, proceed like this :
- select the orientation you want on the SAS (ex : prograde)
- turn RCS on
- wait for the vessel to start turning, then turn the RCS off
- let the vessel turn and reach the SAS position. Once reached, the reaction wheels will "kick in" and stabilize the vessel
- if while you are still turning, you feel that you will "miss" the selected orientation, cycle quickly the RCS on and off to do small corrections.

It's a bit more complicated than that but basically what the plugin does is
- disabling your reaction wheels when you are inputting an attitude control request.
- disabling your reaction wheels when the SAS is inputting an attitude control request, BUT ONLY in the following cases
    - the selected mode is NOT hold/killrot
    - in any other mode, only if the vessel isn't already "in position" (the crosshair is aligned to the marker on the navball)
 

[Jognt]

Yes, I'm at that point in my career where I don't have SAS advanced enough to have those buttons though :P. Therefore I have to move around manually which takes a lot of RCS if I keep SAS active (since it tries to stabilize if I let go of WASD).

The RW don't really do much anyway unless I'm in Stability mode or within the selected marker. So instead of disabling RCS while waiting for the probe to turn to the selected marker, I disable SAS with F and initiate the move while waiting for my direction to arrive to where I need to be, then I release F and Stability mode will settle me down :).

One question though: I was under the impression the pilot and SAS got the same amount of torque when SAS was not within a few degrees of the target orientation. If you're saying I'm depriving myself from the torque they can provide, is this not the case?

ps. With my smaller starter craft I kinda exploited Mandatory RCS's RW system by disabling SAS just when it was within a few degrees of prograde/retrograde so the momentum from the 'snap' would turn me 180° quicker . Nowadays I bring RCS like a good boy though .

Edited May 23, 2019 by Jognt

[garwel]

I wonder how MandatoryRCS works alongside kOS (specifically, kOS cooked control). Does it disable or lower power of reaction wheels when kOS tries to change ship's attitude and to stabilize it?

[Gotmachine]

Any plugin that use its own attitude PID controller and disable the stock SAS (MechJeb, TCA, KOS...) will cause reaction wheels to be permanently in the "realistic very low torque mode".
Unfortunately adding support for all those plugins would require a lot of hacking into their code at runtime, which is a lot of work and is likely to break anytime those plugins are updated.
Moreover the plugin is fine-tuned against the stock PID controller to prevent the torque output variations from making the algorithm act too weirdly, that would have to be done differently for each custom PID.

Edited May 24, 2019 by Gotmachine

[Dunbaratu]

19 hours ago, Gotmachine said:

Any plugin that use its own attitude PID controller and disable the stock SAS (MechJeb, TCA, KOS...) will cause reaction wheels to be permanently in the "realistic very low torque mode".
Unfortunately adding support for all those plugins would require a lot of hacking into their code at runtime, which is a lot of work and is likely to break anytime those plugins are updated.
Moreover the plugin is fine-tuned against the stock PID controller to prevent the torque output variations from making the algorithm act too weirdly, that would have to be done differently for each custom PID.

kOS uses KSP's own API call to query "how much torque can the vessel do right now if you pushed the controls to their max Yaw?  How about their max Pitch?  How about their max Roll?"  KSP has such a built-in API call that runs through summing up all the torques of all sources, such as reaction wheels, rcs blocks, and gimbals (multiplied by current engine throttle, so the gimbal is properly nerfed if throttle is low right now).  Then kOS uses the result of this to choose what PID gains to use.

So hypothetically it should work okay with your mod, provided your mod alters the reaction wheel's abilities in a manner that KSP's own API call can "see", trough tweaking the stock variables to new values.

(One place where KSP's API call is screwing up kOS is that when someone sets a reaction wheel to "SAS only mode", then it's NOT available to the autopilot control scheme, but *is* available to KSP's own internal steering with SAS, so their API call claims that torque is available for use (it is available, for *them* but not for us), causing kOS to choose bad values for its PID gains under the assumption that torque was usable.)

[Gotmachine]

5 minutes ago, Steven Mading said:

kOS uses KSP's own API call to query "how much torque can the vessel do right now if you pushed the controls to their max Yaw?  How about their max Pitch?  How about their max Roll?"  KSP has such a built-in API call that runs through summing up all the torques of all sources, such as reaction wheels, rcs blocks, and gimbals (multiplied by current engine throttle, so the gimbal is properly nerfed if throttle is low right now).  Then kOS uses the result of this to choose what PID gains to use. 

Indeed KOS (and others) will work fine, as in "they won't throw errors or become inaccurate".

3 minutes ago, Steven Mading said:

(One place where KSP's API call is screwing up kOS is that when someone sets a reaction wheel to "SAS only mode", then it's NOT available to the autopilot control scheme, but *is* available to KSP's own internal steering with SAS, so their API call claims that torque is available for use (it is available, for *them* but not for us), causing kOS to choose bad values for its PID gains under the assumption that torque was usable.)

That is the point. MandatoryRCS override the reaction wheels torque output (and consequently the "what torque is available ?" API call) based on the stock SAS selected mode and the control inputs. Basically, the "full torque" is only available when the SAS is in a specific state.

The reason is that the reaction wheels should only be in full torque mode when the PID controler (SAS) is killing the angular velocity (stabilizing the vessel), and in low torque mode when there is an attitude input request either from the SAS, the pilot or any other plugin playing with the inputs.
To achieve that, I need to know the state of the PID controller, specifically the orientation it is currently trying to achieve. In stock I'm doing that by reading the SAS mode and checking if the request orientation is "near".
To support others PID controllers, I would need to detect when they are active and read their own implementation of the "attitude modes". For KOS, I could probably read the value of "expression" when the "LOCK STEERING TO expression" instruction is used, but it would likely introduce new balance considerations that I'm unwilling to deal with.

So for now, deactivated stock SAS = reaction wheels always in low torque mode.