• Content count

  • Joined

  • Last visited

Community Reputation

194 Excellent

About Gotmachine

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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 :
  3. 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.
  4. @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.
  5. 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
  6. 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 :
  7. @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.
  8. 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.
  9. @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.
  10. 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 :
  11. 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 : 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 :
  12. 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 } }
  13. Gotmachine

    [1.3.0] Kerbalism v1.2.9

    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.
  14. @Oneiros No, this plugin is abandoned. But you can use this one, which provide similar features and is up to date :
  15. @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.