Gotmachine

Yup, radial in/out is reversed, silly mistake, thanks for the feedback. Well, the whole point of the plugin is to force you to use RCS for attitude, and yes, one major consequence is that your orbit will change every time you turn. There are a few thing that you can do to use RCS and avoid translational deviation : Balance your RCS configuration before launch using the RCS Build Aid plugin. You should place your RCS thrusters evenly around the center of mass. You can nearly eliminate unwanted translation by doing that properly. Use a lower thrust setting in the "Thrust limiter" tweakable of your RCS parts (or use the micro-RCS parts provided in the MandatoryRCS part pack). The stock 1 kN thruster is way overpowered for vessels under 5-10 tons. If you are using the part pack, don't use a 2x4 setup of four way thrusters, that's horribly inefficient. The best setup if you don't need translational forward/backward authority is two rings of 4 two ways thrusters (the "I" or "IV" variants), with ring at each side of your vessel, centred on the center of mass. If you need translation, use the same setup but with the the "IL" or "IVL" variants. Another thing to think about is that after turning, you can correct your orbit very precisely using the RCS translation controls. This is a bit tricky at first, but oncce you master it it is unvaluable for fine tuning your orbit. If you really need non-RCS control authority... add more reaction wheels... This said, I'm aware that the current system is not very good. I have in mind a revamp of the stock reaction wheel module, but currently I got no time to work on it. The idea would be to have three types of non-RCS control systems : Magnetorquers : Provide only stabilization (Kill Rotation and SAS lock), can't be used to initiate a rotation. Very low mass, available as an optional module in existing parts (reaction wheels, probe cores, pods...) Can be used as a passive (no EC consumed) or active (EC consumed) system for extra torque power. The available torque depend on the distance to the main body (lower orbit = more torque) Reaction Wheels : Provide large stabilization torque and low active torque (like the current nerf does) Replace the stock module The active torque would be subject to a realistic saturation mechanism The stabilization torque would be subject to a non-realistic saturation mechanism (the saturation would magically vanish when the wheels are not used). Control Moment Gyroscope : Provide large stabilization torque and medium active torque. Heavier and bulkier than current parts, also larger EC consumption. Would come in a set of all-in-one configurable inline parts with optional EC/MP storage, integrated RCS thrusters, probe core... Same saturation mechanism, but the active torque saturation would induce a permanent EC consumption. To avoid having to micro-manage the saturation : The saturation would be calculated vessel-wide, not per part, and a colour-gradient saturation indicator would be added somewhere on the navball for the two types of saturation. For the "realistic" saturation, an auto-desaturation SAS button would be added. By toggling it, the SAS would let the wheels desaturate. Doing so would produce a torque which rate would be auto-adjusted so the onboard magnetorquers and RCS thrusters (if the auto-RCS button is toggled) can counteract this torque. The design goals are : To give the player the ability to choose between a RCS or non-RCS attitude system depending on the mission profile Balance these options so neither is overpowered Still keep the "magical free torque" but avoid the "look I can stand on a 45° slope" situation Not to add to much complexity and keep the gameplay simple.

@ErrolThose features are gone in the current beta release : The first bullet may be back at some point, but I need to think of another solution. The intent was to limit the infinite capacity of the "Hold" SAS mode to stop a vessel rotation using only reaction wheels. The problem was that it could brick your mission since you would have no way of stabilizing a vessel that for some reason is spinning out of control. So I made the effect very faint, to the point it was not noticeable at all, so to conclude : useless feature. The two other points were a bit of an arbitrary decision to balance the gameplay, and I had some comments that make me think that this was not a good solution. I implemented this because I wanted to prevent the ability to magically control reentry pods and light manned vessels without having RCS onboard. The problem is within the stock balance : pods have super-strong reaction wheels that were probably added so in most cases you don't need an additional RW part. Without the control distinction, even when strongly nerfed by my plugin they are enough to orient yourself as you please. At the time, I did the control distinction because I was reluctant to provide a MM patch to rebalance the pods vs individual RW, but maybe I will go this way for the final release of this new version. Another potentially much simpler and efficient way of achieving the goal would be to dynamically adjust the "nerfed" reaction wheels torque according to the vessel mass, this is something that I need to playtest. This would result in a fixed "turning capacity of reaction wheels" for all vessels, and maybe I could add some bonus torque for independent RW parts, so it's still useful to put some onboard. At some point, I may do a few new flat inline part for each size that combine a reaction wheel, a small RCS fuel tank and an integrated 8-nozzle RCS block, and maybe also a 0.625m and 1.5m nose cone with RCS+RW+parachute. I was also thinking of a patch for the stock pods to add integrated RCS thrusters on them, like the new 1.4 Mk1-2 pod now has, might be possible by MM-combining the stock model and a single scaled RCS thruster model with the proper transforms. Then I could safely get ride of the integrated super-powerful reaction wheels in the pods, but again I'm a bit reluctant to do that because it would likely require making and maintaining patches for countless other pods from the various mods out there.

MandatoryRCS 2.0 BETA 1 - FOR THE BRAVE ! Beta release with extra logging of debug information to the KSP.log Complete rewrite of the whole plugin The reaction wheels nerf has been simplified, control variations are no more since this was confusing and not very relevant Target persistence Stock SAS PID controller is replaced by a MechJeb derived PID-controller Complete in-house reimplementation of the stock SAS UI, with new modes and simple options within the UI. Added a way to target the Sun Added a RCS-auto mode Ingame settings are useless for now, don't try to use them Many bugs ! Download & source Download from GitHub Instructions & notes Licensing Due to the integration of MechJeb-derived code, this plugin is released with mixed licensing. The plugin as a whole is released under the unlicense, meaning public domain, meaning do as you wish. Individual source files contains a header indicating their license situation. Most files are released in the public domain, at the exception of the following source files that contains code derived from the MechJeb plugin and are licensed under the GNU General Public License v3.0 : ComponentSASAutopilot.cs Lib\MathExtensions.cs Lib\Vector6.cs Lib\VesselPhysics.cs

So, I've been struggling with something for many hours, so maybe someone over here can help me : I need to get the direction vector of my vessel target, which is another vessel that implement ITargetable. To do so, I use this : target.GetTransform().position - myvessel.transform.position It works fine in the following situations : Both vessels are in the scene and NOT packed (they are close enough to each other and I'm not timewarping) Both vessels are in the scene and packed (happens when I'm timewarping) My vessel if either packed or not and the target vessel is unloaded (not in the scene) But in the situation where both vessels are in the scene, my vessel is not packed and the target vessel is packed (when the distance is greater than the physics-load distance, I believe this is set to 200 m by default), the direction vector I get is slightly offset, and the offset seems to gets worse the further my vessel is from the target vessel. I noted that the offset error seems to depend on the distance to the mainbody (or is it the orbital velocity ?) : it is barely noticeable in LKO but I get a 30-40° error when orbiting the sun. What is strange to me is that every stock value that I could find (including FlightGlobals.fetch.vesselTargetDirection, GetWorldPos3D, Orbit...) are giving me the same wrong result, but somehow the navball target marker isn't affected by the issue and is correctly updated with a consistent target direction. I guess there is some shifting reference frame correction to do, but I can't pinpoint it. Does someone have a clue at what may be happening ? Edit : @sarbian MechJeb is experiencing the exact same issue when using SmartASS. To reproduce, using the stock vessel mover cheat, rendez-vous a first vessel with an asteroid in sun orbit, then rendez-vous a second vessel with the first, this will place the two vessels 150m apart. Activate SmartAss and target the other vessel, everything should be fine. Then burn a bit to get further from the other vessel. As soon as the other vessel become packed, watch your attitude suddenly experience a 30-40° offset from the stock target navball marker. Edit2 : Okay I think I found why : it seems that for On Rails vessels, the vessels state is updated in Update(), not in FixedUpdate() (!?!#%!), so if you try to acquire another vessel position from a vessel FixedUpdate, you may be reading the values FROM THE LAST FRAME... I need to do some more testing, but the TCA autopilot is not affected by the issue and happens to be updating its autopilot directions in Update(). Moreover, if I substract the orbital velocity of the target to the direction (essentially computing were will be the target in the next frame), I get the correct direction : target.GetTransform().position - vessel.transform.position - (target.GetObtVelocity() * TimeWarp.fixedDeltaTime) Also, this description of the VesselPrecalculate Class from the API docs seems to confirm that packed and non packed vessels may not get their position update at the same time, but I have trouble understanding the exact implications :

@Gordon Dry Why that ? I have some doubt about it since the only thing MandatoryRCS is messing with is the reaction wheels partmodule, it has not interaction with the RCS partmodules. Looks like to me that the MechJeb cache for RCS thrusters got corrupt somehow when switching vessels (technically EVA is a vessel), and judging by the "RCSSolverThread" class name, I would say that some common threading mess is happening in MechJeb.

The problem is that the plugin is already making the reaction wheels super weak so you are forced to use RCS, in order to force the player to make a realistic choice. You can still do a reaction wheels only craft, but only on very small crafts (probes, satellites...), anything bigger than that requires a RCS system. Magnetorquers as a weaker option would be totally useless, and even more if they have some restrictions. The problem here is that stock players are used to totally unrealistic free torque, and as I said before in this thread, it is indeed a necessity to have that power, because real spacecrafts have the luxury of taking forever to turn while a KSP player can't possibly wait that much time. This said, a revamp of the stock reactions wheels and introduction of others options is still on my mind. Maybe sometimes I will try something but for now I have others plans for the plugin.

@CobaltWolf Yes, I've read about the various means of attitude handling in real spacecrafts, and I've thought about how I could implement them is KSP. The idea could be to have reaction wheel as the powerful, controllable but limited option, implementing simulation of the saturation issue and desaturation using RCS. Magnetorquers could be the low maintenance, non controllable mean of just attitude keeping. But this is a lot of complexity and in my opinion, it would not be very fun to play with. Not being able to turn when you want to, or having to wait a whole minute to do a 90° turn is just frustrating. @Jognt No they will not conflict, my plugin is designed to automagically disable its persistent rotation feature in favor of Persitent Rotation when the plugin is detected in your game. But this will also disable the SAS persistence feature. And note that I don't intent to keep that option in the next version. About the KISS part, I honestly think I could not have done simpler than that, it's the whole MechJeb SmartASS feature (and a few more) packed in the good old SAS UI.

MandatoryRCS main purpose is to change the stock choice of reaction wheels being so unrealisticly overpowered that you don't need a RCS system on your vessel. It does so by adapting the available torque from reaction wheels depending on the situation, and it determine what is the situation is using the stock SAS state (Hold, prograde, etc...). In other words, reactions wheels works in conjunction with the SAS, helping stabilizing the vessel and preventing it from spinning like crazy. But the reaction wheels can no more be used to initiate a rotation. In fact they still can, but they have a very low and not too far from realistic torque output when you use them to rotate. The SAS and rotation persistence are "bonus" features. The persistent rotation part is here because it would completely defeat the purpose of the mod if you were still be able to stop the vessel rotation by going into timewarp or switching vessels. The Persistent Rotation mod does essentially the same thing as my persistent rotation feature, but has features specific to that part : It will calculate the rotation for unloaded vessels It has a GUI for choosing a target to keep your vessel oriented toward, which allow a few more options than my current system of using the SAS state It will consume some EC when unloaded/timewarping if you use the above feature It can force a constant rotation rate, this can be used to make "rotating habitats" This said, I'm currently giving the final touch MandatoryRCS version 2, a complete rewrite of my plugin that will include a brand new SAS that completely and seamlessly replace the stock SAS, with some very useful new SAS modes and an implementation of the MechJeb PID controller as a replacement for the stock SAS PID controller. No release date, but I'm getting close. Here is a sneak peak :

The problem is in the stock MOI calculations that gets wrong when the control part isn't the default one, see the comments in the KOS source : https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Control/SteeringManager.cs#L632 I tried rebuilding Mechjeb replacing all stock MOI calls to the custom code from KOS, this completely fixes the issue (that I can confirm) described by @Starwaster :

That depend on what you call "realistic", this mod isn't made to make reaction wheels behave like in real life. It only balance their capabilities so you can't use them in an unrealistic way, most of the time. Real reaction wheels are VERY weak. The ISS CMR weight 1100 Kg and output only 0.258 kNm of torque, the small reaction wheel in KSP weight 50 kg and output 5 kNm of torque. In short KSP reaction wheels are about 300 times more powerful than real life reaction wheels. In real life, as soon as a vessel is large enough and/or need to make relatively quick attitude adjustments, it require either control surfaces in atmosphere, RCS thrusters or engine gimbaling. But for maintaining the attitude in space (making small adjustments continuously), reaction wheels are the way to go. This is what this mod try to achieve : reaction wheels are useless when you want to turn, but they are very powerful when you want to keep you current attitude (trough SAS). Over the versions I made the default settings a bit more powerful, if you want the hardest and maybe most realistic experience, go to the difficulty settings and set all sliders in the "reaction wheels rebalance" section to the far left. The reason I didn't nerf the torque strength in SAS mode is because after a lot of testing I concluded that it would make the game unplayable : The stock SAS is not designed to handle a low torque situation, it just can't stabilize a vessel that has realistic or even a bit nerfed reaction wheels. Especially with large and heavy vessels. For the same reason (the stock SAS is very basic and unoptimized), RCS fuel consumption is unrealisticly high when there is no "magical torque" from reaction wheels. Stability in atmospheric situations is a LOT harder when there is no free magical torque. Since KSP is inherently limited in its aerodynamic model and in how you can adjust the aerodynamic profile and weight distribution, it seems fair to me to have some "magic torque" to balance the gameplay. Real spacecrafts turn at a very low speed, they usually have the luxury of taking their time. Because of that, they need far less torque power than a KSP player who can't wait hours to make a basic maneuver. If you really want to nerf the reaction wheels, you can always edit the parts config by writing this patch in a text file, renaming it to *.cfg file and dropping it anywhere in your GameData folder : @PART[*]:HAS[@MODULE[ModuleReactionWheel]:FINAL { @MODULE[ModuleReactionWheel] { // Change 0.1 (=10%) to whatever you seem appropriate @PitchTorque *= 0.1 @YawTorque *= 0.1 @RollTorque *= 0.1 } }

Good to see that someone has taken on the continuation of this mod. I have my own own fork of Kerbalism but due to a lack of free time I can't really work on it to make it playable. Some aspects that I began to work on was habitat, comfort and radiation systems, because I don't like how they are implemented. Here are a few of my ideas straight from my dev notes, this a low effort post : Radiation : -> Separate radiation : low effect (simulate cancer probability) and high effect (simulate radiation poisoning) -> low effect : -> like current system, use radiation modifier, accumulate over time, non recoverable -> trigger a "trydeath" event : randomized, with probability of death increasing whith the rule accumulator level -> accumulate very slowly, balanced so there is no chance of dying in the first 15-20 years in an unshieded environnement -> high effect : -> use a "highradiation" modifier, only triggered when radiation level is above a treeshold, and value is exponential (starts low) -> if modifier = 0, accumulator level decrease Comfort - change comfort so it's like a resource, with level that can go up and down. - low comfort : kerbals have a probability of breakdown or becoming tourist - comfort modifiers : -> Living space -> Habitat enabled -> Surface bonus -> Not alone -> Comms -> comfort is a rule with an accumulator, we need to implement degen_modifier and regen_modifier Habitat : - Habitat can be enabled/disabled in parts - Enabled habitat provide : - living space (comfort modifier) - atmosphere control -> require Oxygen & EC -> simulation of pressure is abandoned - thermal control -> require EC or coolant resource depending on thermal conditions - Disabled habitat make Kerbals put on their EVA suit - This activate "EVA suit habitats" -> can the partmodule be alive independently from the part ??? - Helmet visibility is toggled in the "InternalSeat" module of the "Internal" partmodule - You can't EVA from an enabled habitat, excepted at kerbin if pressure difference is not too much - EVA suit has an habitat module, a small radiator module, a battery Note that the habitat revamp do mention a thermal system that I got mostly implemented (I got radiator module working fine and a very buggy and unbalanced habitat/rule framework system). You can check the fork on my github account if you want to see the code.

@Oneiros No, this plugin is abandoned. But you can use this one, which provide similar features and is up to date :

@LastStarDust As was said, you can switch the reaction wheels part off in the settings menu. @eightiesboi You can achieve relative orientation to anything by selecting it as a target in map view and then putting the SAS in "target" mode (click on the surface/orbit/target text on the navball) and then using the target/antitarget SAS markers. Note that depending of your solar panel orientation, you will need to have a control module (a part that has the "control from here" button) oriented the same way, I usually use a small docking port, it's cheap and light. Also note that unfortunately, kerbol/the sun isn't targetable and I didn't found how to change that in the code. As a workaround you can target Moho, that will approximate a sun targeting not too badly if you are at Kerbin. In my game in turned this in a mission and launched a probe to low solar orbit to act as targetable object. @eberkain I'm aware of this bug, but thanks for reporting. It happens when an asteroid changes SOI and may not cause too many problems, but I will fix this someday. I don't have much time to work on KSP modding currently, so for now this plugin is in maintenance mode, new features are postponed.

@azoz Go the github release page, you can get all the old versions from there. I suggest that you upgrade at least to KSP 1.1.3, since the Kerbalism version for 1.1.0 was a beta and had a lot of bugs. In all cases, these old versions are very different from the current one. Latest version for KSP 1.1.0 : Kerbalism 0.9.9.4 Latest version for KSP 1.1.2 : Kerbalism 1.0.2 Latest version for KSP 1.1.3 : Kerbalism 1.1.4

Interesting. I gave up on updating UpgradesGUI after 1.3 because I couldn't get a reliable way to manage the per-part status of upgrades. It's a big mess. Doing it with a partmodule is a good idea and may work in the end, but you haven't overcome what made me give up : they added some custom logic in the editor, upgrades are always reapplied to parts that gets loaded in the editor based on the current enabled/disabled status in the PartUpgradeHandler, regardless of what was saved. Try this : create a new sandbox game, set the difficulty settings to have all upgrades enabled (the effect would be the same in career mode with unlocked upgrades) go to the editor, add a part edit the upgrades save the craft open the craft all stats are reverted to non-upgraded state. I think this is because your plugin is setting AllEnabled to false in Start(). If AllEnabled was set to the default (true), all existing upgrades would be applied to all partmodules on the craft. This mean that when loading an existing craft in the editor, you need to iterate trough each module of each part, enable/disable upgrades in the PartUpgradeHandler according to the craft saved Upgrade confignode and apply them. Since you have gone the partmodule way, it shouldn't be too difficult. As for reverting to base stats when no upgrades are applied, it is indeed messy. Here is how I'm doing it. It won't handle sub-nodes but in my tests for a 1.3 version, I found a workaround : instead of copying the field values from the prefab partinfo confignodes, I instantiate the part, get the field values from it and then destroy it. A bit hacky but it works and will support every possible partmodule. License note : you can re-license my code under GPL, no need to release some part under the unlicense (it's an unrestricted public domain license). This said, I encourage you to release your work in the public domain too so others can freely reuse your code, in my humble opinion the license hell around here is getting awful.

Hi guys, I would like to have some feedback and opinions on a few new features I'm currently trying to implement. Picture first : This is a replacement for the stock SAS. It's build on top of MechJeb and will probably require MechJeb to be installed (the other option being repackaging MechJeb as a library and distribute it with the plugin, which I want to avoid). But this SAS (and possibly other features built on top of MechJeb) will be independent from the MechJeb parts and GUI. The MechJeb GUI and parts will still be available, but not visible if you don't use them. I'm doing this because : The stock SAS is struggling with large and heavy vessels, to the point it is impossible to stabilize them. The stock SAS is atrociously inefficient and imprecise, leading to astronomical RCS fuel consumption The stock SAS lack some very useful features. I did a lot of tests to compare the MechJeb SAS to the stock SAS, in various situation and with various vessel sizes. For the same sequence of events, the MechJeb SAS is between 25 % and 200 % more efficient with RCS fuel, especially with large vessels. I also did test using the TCA SAS, which is even better but unfortunately TCA is build in a way that make it very hard for me to use it as a dependency, plus it is missing a few features that MechJeb have and that I want to use. Now back to the screenshot. The new SAS modes are : Hold : Used to precisely hold an orientation, this is the default MechJeb Hold. The orientation is defined in two possible ways: - When hold mode activated, hold the current vessel orientation at time of activation - On pilot input key release, register the current orientation and then hold it HoldSmooth (Default mode): Same as Hold, but on input key release angular velocity is killed and once the vessel has stabilized, the reached orientation is registered. The stock SAS Hold mode behave a bit like this. KillRot : Don't hold any orientation, just keep angular velocity to zero. Great for consuming less RCS fuel. ForceRoll (3 horizontal markers) : - center marker : toggle that activate/deactivate force roll. Icon change to reflect the current selected roll angle - right / left markers : buttons with arrows icons, add / remove roll angle by 45° increments Roll angle is relative to the current reference (ORBIT, SURFACE OR TARGET) PitchOffset (3 horizontal markers + value) : Add a pitch offset to the current selected orientation. Disabled if Hold, HoldSmooth, KillRot or Maneuver mode is active. Useful for managing attitude in atmosphere, especially for reentry - center marker : reset pitch offset and set mode to HoldSmooth - right / left markers : increase / decrease pitch offset (2.5° increments) ProgradeCorrected (target mode marker) To target, correcting lateral velocity This is the orientation you need to burn to so Prograde become aligned with Target RetrogradeCorrected(target mode marker) Against target, correcting lateral velocity This is the orientation you need to burn to so Retrograde become aligned with AntiTarget Parallel + & Parallel - (target mode marker) Keep the vessel parallel to the target, great for docking using lateral RCS movement There are some other features I want to add, but maybe not in next release because it will involve a lot of navball GUI hacking and this is the most horrible task I've done since I begun modding for KSP. SAS aggressively slider : basically how hard the SAS try to turn, less aggressive = less RCS fuel consumption (MechJeb functionality integration) RCS auto mode switch : automatically disable the RCS toggle when reaction wheels are enough to do the job Global RCS throttle slider Maneuver autopilot : a basic autopilot that will execute the next maneuver node (Mechjeb functionality integration), to be used in conjunction with commnet Navball markers for the new SAS modes All these thing would be available from a nice stockalike popup menu accessed by right-clicking the SAS and RCS toggles on the navball. Also, I'm thinking about redoing how the reaction wheels nerf is working. This could involve : A "realistic torque output", available all the time for the pilot or SAS to use. This realistic torque output would involve realistic reaction wheels saturation, meaning fully saturated wheel = no torque available. A on request auto-desaturate function, that would involve automatically firing RCS thrusters to desaturate the wheels. A "magical torque output", saturation free, available only for stabilization when the SAS is used.

There are two things that can (and most likely will) go wrong when MechJeb is engaged : MechJeb seems to expect the stock behaviour of "timewarping kill rotation" in some cases. MandatoryRCS "fixes" that behaviour. This can cause MechJeb entering in an infinite loop of timewarping and correcting attitude. In my quick tests, this does happen sometimes, and can be avoided by unchecking the MechJeb auto-warp feature while a maneuver is being performed. MandatoryRCS reaction wheels "balance system" is dependant on the state of the stock SAS. If the SAS is off, reaction wheels are always in the "nerfed realistic torque output" mode. Since MechJeb force the SAS to the off state, reaction wheels are in this weak mode when MechJeb is engaged. This mean that every small attitude correction will be done by the RCS thrusters, causing huge RCS fuel consumption. For large vessels, this mean that they will be impossible to stabilize. A few recommendations to keep your RCS fuel consumption under control when using MandatoryRCS, and other playing tips : Have a good RCS thruster setup : Use the RCS build Aid plugin and pay attention to the yaw/pitch/roll "torque output" of your RCS setup. This will help you to learn how to do an efficient setup. Have your RCS trusters as far as possible from your vessel center of mass. Further away = exponentially more torque = exponentially lower RCS fuel consumption. If you have some thruster nozzles that can't follow this rule, use the advanced tweakables to disable Roll / Pitch / Yaw on the part. A RCS nozzle with its thrust vector aligned with the center of mass will consume RCS fuel for zero effect in attitude control. For in-space situations, don't have too many and too powerful RCS thrusters. A powerful RCS setup will allow you to rotate faster but at the cost of an exponential RCS fuel consumption. Tweak the RCS thrust limiter on small vessels. Have a balanced RCS setup : put an even number of RCS thrusters in symmetry around your vessel center of mass. Don't have RCS nozzles facing random directions, always have them aligned with vessel X, Y and Z axis. Add/keep a good ratio of reaction wheels, especially on large spacecraft. Micromanage the RCS on/off toggle ("R" key). Even when the vessel seems stable, keeping the RCS toggle ON will cause a rapid depletion of your RCS fuel. When maneuvering, engage RCS and as soon as you have reached the SAS target marker (or if you are in stability assist mode), reaction wheels will stabilize you vessel for free. Turn the RCS toggle off as soon as possible. If you have the patience, do your manoeuvring in fine controls mode ("Lock Caps" key). When in atmosphere or if landed, remember that reactions wheels will help you only in "stability assist" mode OR if you are already/still oriented toward the selected marker.

@Barcel@Wardstone111 Now updated for 1.3.1, and released the part pack as a separate download, should be available on CKAN soon.

@Barcel Probably, but not tested. I will do a proper release for 1.3.1 soon.

@vladutz26 Try this : open the Kerbalism/System/Misc.cfg file and comment the following : @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FOR[Kerbalism] { MODULE { name = WarpFixer } } by changing it to : //@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FOR[Kerbalism] //{ // MODULE // { // name = WarpFixer // } //} And restart a fresh game Also, delete the "ModuleManager.ConfigCache" file in GameData when you do some modifications to your mod setup. You can also try to search inside the "ModuleManager.ConfigCache". It is generated every time you launch KSP and have changed the mod setup. It contains the configs of all part with all the patch from all your mods applied. Launch the game with kerbalism then quit, backup this file somewhere. Relaunch the game without kerbalism and do the same. Do it one more time with no mods other than modulemanager. Open the three files, search for PART configs that have a "ModuleDeployableSolarPanel" and check if there are some differences. Kerbalism should add a module named "WarpFixer". If another mod is modifying the solar panels, they may add another module to the part. Edit : also, looking at your log, you have a copy of ModuleManager.2.6.25 (KSP 1.1 !!!) hidden somewhere causing a big mess, this is very likely to be the source of many problems. I'm pretty sure that ContractConfigurator is partially broken by this.

Kopernicus should work as long as you only use it to add planets (OPM is fine for example) and not to modify Kerbin or have multiple stars. Dynamic battery storage; AmpYear; Background resources generation are likely to cause issues Did you try to create a new game before testing without those? Adding / removing plugins on an existing save can break things badly. Also, the power consumption will fluctuate (but not like that) between day and night due to the climatization needs. In the VAB, you can see the nighttime estimated consumption by clicking on the sun icon at the top of the planner.

@Vila Restal@Magzimum Seems the custom category code is broken by the 1.3.1 update. Copypaste the following in a *.cfg file, and drop the file anywhere in your gamedata folder : @PART[kerbalism-activeshield]:NEEDS[FeatureRadiation]:FINAL { @category = Utility } @PART[kerbalism-gravityring]:NEEDS[FeatureComfort]:FINAL { @category = Utility } @PART[kerbalism-greenhouse]:HAS[@MODULE[*]]:FINAL { @category = Utility } @PART[kerbalism-chemicalplant]:HAS[@MODULE[*]]:FINAL { @category = Utility } @PART[kerbalism-container-*]:HAS[@RESOURCE[*]]:FINAL { @category = Utility } @PART[kerbalism-container-*]:HAS[@MODULE[*]]:FINAL { @category = Utility } I didn't test this (I'm still on 1.3) but his should add the missing parts to the stock "Utility" category. There may be other things that are broken by the 1.3.1 update, you should enable the debug info to see if there is any exception spam going on. I hope @ShotgunNinja is still around to update the mod but according to his profile he hasn't been on the forums since august 7 and has shown no signs of activity on github since that time either.

@goldenpsp But in this case, Kerbalism use the CRP definitions to avoid the issue, and I totally understand @ShotgunNinja not wanting to add CRP as a dependency. The difference I pointed out is due to CRP being updated with custom HSP values but Kerbalism defintions weren't updated to reflect these changes. This is a problem and must be fixed (Kerbalism definitions should match CRP ones), but from a quick testing the "duplicate resource" issue isn't happening anymore, looks like something changed in how KSP handle duplicated resource definition since the early days of CRP.

Seems my intervention caused a bit of confusion. What I know for sure is this : Kerbalism is designed to be compatible with CRP, no need to do anything for the two to work together. Kerbalism use some resources that are defined in CRP, but those resource are also defined in the Kerbalism files to avoid CRP being required for Kerbalism to work. I suspected this system could have been the cause of @Andrea Galimberti issue but it turned out that I was wrong.

Whoops... English isn't my native language so thanks for the corrections. I will fix this for next update.