Skip to content

Added "DEADBAND" suffix to RCS parts#2811

Merged
Dunbaratu merged 1 commit intoKSP-KOS:developfrom
marianoapp:feature/rcs_deadband
Nov 18, 2020
Merged

Added "DEADBAND" suffix to RCS parts#2811
Dunbaratu merged 1 commit intoKSP-KOS:developfrom
marianoapp:feature/rcs_deadband

Conversation

@marianoapp
Copy link
Contributor

This suffix can modify the default 5% deadband that exist in all RCS thrusters and thus allowing for much finer control.

The field that controls the deadband is called "EPSILON" and resides in the ModuleRCS class, but since it's a private field it cannot be accessed directly. As a workaround, the field is read and written using reflection.

@Dunbaratu
Copy link
Member

I have spent a long time agonizing over the fact that I can't figure out where the heck the 0.05% dead area on RCS thrusters comes from in the game. If this is it, then THANK YOU for finding where the heck it was coming from. is this a Field on ModuleRCS that isn't user-facing so people can't see it normally when playing the game?

@marianoapp
Copy link
Contributor Author

Exactly, it's not user facing although for some reason it's marked with the KSPField attribute anyway. If it weren't for the fact that the field is private it could be changed using ModuleManager.

@Dunbaratu
Copy link
Member

Ahh it's private, that's why the reflection stuff.
Okay I think, because it's private and thus not guaranteed to always exist in the future, I'd like to start from your PR but add some protection code around the reflection so we won't throw exception if the field goes away, changes type, etc. (So the error will be "nothing happens" instead of "script crashes" if that kind of change occurs.)

@Dunbaratu
Copy link
Member

BTW even some things that are not user facing still get marked with KSPField because the game walks all KSPField members when doing a number of tasks on scene changes and game-saves. If they want something to get dumped into the persistence file, they will sometimes make it a KSPField even if the user never is supposed to see it.

@marianoapp
Copy link
Contributor Author

Sure, feel free to make any changes you see fit.

@Dunbaratu
Copy link
Member

I'm getting more and more wary of using this. I can't seem to adjust the EPSILON field using ModuleManager or by editing a Part.cfg file. It also does not persist in the savegame file, so it resets ot 0.05 every time you leave the scene and return.

This is all pointing to the idea that we really should treat this as an internal flag that mods shouldn't mess with.

@Dunbaratu
Copy link
Member

Okay I had a lot of discussion with other modders over on a KSP modder discord about the "sin" of using Reflection to bypass private access limits in this one case, and I think it'll be okay as long as there's big Warnings in the documentation for it. Because we tried to reverse engineer why the stock game even has this EPSILON in the first place, and with some testing it turns out it's this:

We think SQUAD added the EPSILON to RCS thrusters because it was a quick and dirty way to make SAS stop wasting monoprop holding your heading still. Remember what SAS used to be like in the old Alpha versions of KSP, where it would wiggle the RCS back and forth forever? At some point they made it stop doing that, and it turns out we think this EPSILON is what they did. They just put that in there so that when the aim is nearly right the steering inputs will be small enough that RCS ignores it and only the reaction wheels (which don't have an EPSILON) respond.

@Dunbaratu Dunbaratu merged commit d184b28 into KSP-KOS:develop Nov 18, 2020
@marianoapp marianoapp deleted the feature/rcs_deadband branch May 25, 2021 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants