Gotmachine

Did you solve it ? I'm having the exact same issue.

You can't do something like that trough ModuleManager. Even trough a plugin, the KSP API doesn't seem very helpful. The easiest way would be to subscribe to the OnTechnologyResearched GameEvent and "undo" the tech unlock if your custom conditions aren't met, but this is likely to require a bit of hacking around to properly revert the game state. But maybe the RDTech.OperationResult object exposed by OnTechnologyResearched can be modified when the event is fired, this would be great. Otherwise, maybe there is a way to force the "available" state of the RDTech objects, that would be the cleanest approach and maybe it's the easiest way if the stock code that handle this state is cooperative. Also, there is a third option : hack the RnD tree GUI GameObjects to override the click events and call your own method.

I like the idea, the forced merging of docked vessel is quite annoying. But from a coding perspective it's really not easy to do because you can't have connected parts on different vessels, that's just impossible. This basic fact takes away every stock behavior that is normally available for connected parts. Keeping the vessels somehow attached together is much more complicated than it looks, and would require doing very hacky things. When loaded, maybe this can be done using standard unity joints, but there are many potential kraken-level issues in doing that because KSP actively expect vessels to be independent entities. And anyway those joint only exists when the vessel is loaded / not timewarping. This mean a lot of position handling/correction when switching from/to loaded/packed/unloaded vessel because they will drift away from one another due to floating point precision issues and reference frame switching. This would also make it incompatible with any mod that manipulate vessel coordinates/orientation This will also mess up with the SAS, because the attached mass will be unaccounted for (I'm quite curious to see the outcome of 2 SAS fighting each other) Resource transfer is less unknown territory (KAS and EVA transfer by Dmagic are doing it), but the UI side of it is quite a bit of work. Crew transfer is probably the easiest feature to do. Edit : actually, I think KAS is pretty much doing most the above but I don't think it is capable of rigid docking, and I'm not sure how well it behave for non-landed vessel.

@Gordon Dry This is stock behavior. MandatoryRCS has zero influence on atmospheric flight physics. It only apply angular velocity to vessels that are in space in non-physics timewarp.

@JogntPlease try the latest release. And thanks for your log, although I can't reproduce the issue it helped in figuring what was (probably) happening.

MandatoryRCS does rotation persistence and allow using the SAS during timewarp. You can disable the reaction wheels nerf in the difficulty settings if you don't want it.

Yes, that is what I was talking about. I can't predict the logic implemented by the user and that could make the nerf rules inconsistent. But now that I'm thinking about it, it's not that much of an issue as those small increments would still probably always be in a station keeping intent, even if the station keeping is using a slow-moving reference. After all the mod currently allow it when using the various stock SAS references. The real issue is that the KOS PID controller is not very good at achieving a stable state. Combined with the fact that it very sensitive to available torque changes, I'm pretty sure that would lead to major stability issues. At least this what I remember from the testing I did way back using the MechJeb version of the KOS PID controller.

I already responded, yes. ITorqueProvider.GetPotentialTorque() will return the torque as adjusted by MandatoryRCS. Otherwise the stock SAS PID would also have a very hard time As a matter of fact I already tried adding support for MechJeb (which can optionally use the same PID controller as KOS) and TCA and that's why I'm confident when I say that supporting others PID implementations is problematic. The thing is : the KOS PID controller don't like huge swings in the available torque. In many situations it simply is not able to handle it, resulting in an uncontrollable vessel. This is an even bigger problem than with others "fixed mode" controllers because it's very likely that it is used by continuously updating the desired orientation, which mean that those torque swings will be "perpetual". And also, this simple fact make the whole strategy used by MandatoryRCS inapplicable. For the nerf to work, I need to know the angle error, but also the "final intention" to differentiate a slow attitude change control output from a stability correction control output. In both case, the angle error is small. In comparison, the stock PID fares much better because it don't rely much on the ITorqueProvider.GetPotentialTorque() results. The "torque nerf" is fine-tuned against it : I'm actually lerping the torque changes and I use a few tricks to avoid issues, but it still is quite negatively affected. As for the MechJeb PID controller, it is very efficient in most situations (it can be slightly better than the stock one) but it can struggle to achieve a stable state in many cases, and it also struggle in aerodynamic intensive situations. The (new) TCA attitude controller performs very well in every situation, it's probably the best non-specialized PID code.

Indeed KOS (and others) will work fine, as in "they won't throw errors or become inaccurate". 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.

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.

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)

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.

@Runolite Ok so forget about the first edit, revert it to the initial syntax. The bug with Sigma Dimensions is a silly one : SigDim should be applied after SVT, but since the loading order is alphabetical things get screwed up. The fix should come from SigDim but Sigma88 is waiting for BlowFish to implement a :LAST ModuleManager feature so he can fix this. What you need to do is open ALL *.cfg files in the SVT\configs folder and edit the first line : change the "[SVT]" label to "[RSVT]".

@Runolite Try this : Edit this file with text editor : SVT\configs\Kerbin.cfg At the end of the file, change this : SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds } to this : %SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds } If this doesn't work, please open your "ModuleManager.ConfigCache" file with a text editor, search for the "SpaceCenter{...}" node and post it here. Also do you have Sigma Dimensions installed ? There is known issue with it.

@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

To me, the most exciting thing in this update is the shiny "VesselDeltaV" class ! As for the shiny parts... not fond of that, I find that it doesn't fit well with the overall "matte" style of KSP.

But then how to get the part at the origin of the action ? This is running from a KSPAddon, not a PartModule... I also managed to get a KSPEvent working, this is easier : private void OnPartActionUICreate(Part part) { // Get the PAW window UIPartActionWindow paw = UIPartActionController.Instance.GetItem(part); // Prevent the button to be re-added once created if (paw.ListItems.Exists(p => p is UIPartActionButton && ((UIPartActionButton)p).Evt.name == "MyButtonID")) { return; } BaseEventDelegate del = new BaseEventDelegate(delegate { OnPawClick(part);}); BaseEvent baseEvent = new BaseEvent(null, "MyButtonID", del, new KSPEvent()); baseEvent.guiName = "My button title"; baseEvent.guiActive = true; baseEvent.guiActiveEditor = true; paw.AddEventControl(baseEvent, part, null); } private void OnPawClick(Part part) { // do something with the part }

As a memo for myself, and as a quick guide for others : Add PAW buttons to all parts from a KSPAddon, using KSPField decoration : [KSPAddon(KSPAddon.Startup.EditorAny, false)] public class MyClass : MonoBehaviour { [KSPField(guiActive = true, guiActiveEditor = true, guiName = "Some boolean"), UI_Toggle(enabledText = "Enabled", disabledText = "Disabled")] public bool someBool = false; private void Start() { GameEvents.onPartActionUICreate.Add(OnPartActionUICreate); } private void OnDisable() { GameEvents.onPartActionUICreate.Remove(OnPartActionUICreate); } private void OnPartActionUICreate(Part part) { // Get the PAW window UIPartActionWindow paw = UIPartActionController.Instance.GetItem(part); // Get the attribute System.Reflection.FieldInfo fieldInfo = typeof(MyClass).GetField("someBool"); if (fieldInfo == null) return; object fieldObject = fieldInfo.GetCustomAttributes(false).FirstOrDefault(p => p is KSPField); if (fieldObject == null) return; KSPField field = (KSPField)fieldObject; BaseField baseField = new BaseField(field, fieldInfo, this); // Add a callback, using the part as arg1 baseField.uiControlEditor.onFieldChanged = delegate { MyCallback(baseField, part); } ; // Add the field to the PAW paw.AddFieldControl(baseField, part, null); } private void MyCallback(BaseField field, Part part) { // Do something with the part when the toggle is used } }

I think this should work : !MODULE[ModuleResourceConverter],* {}

A bit of a post necro, but : when loading a vessel, several physics related things are initialized in the first few fixedUpdates. For a lot of things, checking FlightsGlobals.ready is not enough. The thermal handling of vessel is done by the FlightIntegrator class. It's a VesselModule and can be accessed trough the Vessel.vesselModules List. It can be fully initialized rather late after vessel loading. If you have any code that has to do with thermal properties, you need to check those two conditions first : FlightIntegrator.isRunning is equal to true FlightIntegrator.firstFrame is equal to false

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. This is already in the plugin, and it's been expanded to allow to target the sun in the beta version. See my previous post : 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. 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.

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

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.

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

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. 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 :