Search the Community

MandatoryRCS This plugin revisit the stock balance between the overpowered reaction wheels and RCS thrusters which are useless outside of docking situations. It does not propose a more realistic simulation of reaction wheels but is a collection of tweaks aimed at limiting their functions and balancing the gameplay. Reaction wheels are turned into stabilizers, preventing your vessel to spin out of control and keeping it pointed at the direction you choose in the SAS autopilot. But they have a very low (and somewhat realistic) torque power when the pilot or the SAS request a pitch, roll or yaw rotation. This mean that like in real life, most crafts always need a few RCS thrusters (and propellant) to have orientation authority, but you still get most of the playability benefits of overpowered reaction wheels. As a side benefit, the plugin also fix the "timewarp rotation stop" stock behavior, and introduce a few related features like keeping the vessel oriented toward the SAS selection in timewarp and when switching vessels / reloading the game. Features Reaction wheels nerf Reaction wheels have two different torque power, the stock one and a heavily nerfed, somewhat realistic one. Nerfed torque provided on pilot or SAS rotation requests. Stock torque when SAS "Stability mode" is turned on. Stock torque when the vessel has reached the SAS selection (prograde, normal, target, etc). Torque output is affected by the vessel angular velocity : the faster the vessel rotate, the weaker reaction wheels are. Pods and cockpits built-in reaction wheels can't be controlled (they don't respond to pilot/SAS input) but still provide SAS stabilization. Reaction wheels in probes cores and independent parts can be controlled. Hiding of irrelevant reaction wheels right-click menu options and action groups. Rotation persistence trough timewarp and reloading Timewarping will not stop the vessel from rotating. Rotation is restored after timewarping, switching vessels or reloading. Rotation is not continuously calculated for unloaded (on rails) vessels, for minimal performance impact and code complexity. SAS autopilot persistence trough timewarp and reloading The vessel will keep its orientation toward the SAS selection when timewarping, switching vessels or reloading. The SAS selection is remembered and restored when switching vessels or reloading. Customization Features can be enabled, disabled or tweaked in the ingame "Difficulty Settings" menu. Download and detailed info Current version : v1.8 for KSP 1.8 Latest release and source from github MandatoryRCS Part Pack Small part pack to provide more RCS thrusters in a stockalike fashion Tiny thrusters (0.25 kN) With tiny exhaust effect RV-105 variations Download and detailed info Current version : v1.4 for KSP 1.2 to 1.7 Latest release and source from github

I've installed Realism Overhaul for a couple of days.I found that the torque of 'small inline reaction wheel(0.625m)' is awfully small,which is only 0.0001. In comparison,the torque of 'advanced inline stabilizer(1.25m)' is 1,and the torque of 'advanced reaction wheel module,large(2.5m)' is 10 Checking others' post,I found that the torque of the 0.625m reaction wheel in RO should be 0.1. Is that a bug,or a intended torque setting?

I'm starting a new thread for the SRW mod I have recently rebuilt for a relativelly new KSP version 1.10.1. The mod has been abandoned by @Crzyrndm few years ago and then was kept rebuilt in a fork of @HebaruSan. I found out that fork being more updated and featuring a couple of improvements only after rebuilding the mod on my own with a change that is critical for me. If I find more time to spend on the mod - the first thing I will do is adding the QoL tweaks from that fork. The only reason for the first version released by me to be called 2.0.0 is to prevent the mod's version names from being confusing. (Semi-) Saturatable Reaction Wheels Dependency - ModuleManager Download from GitHub or via CKAN License - GPL v3 Features Reaction wheels accumulate momentum with use, torque output is modified based on the current stored momentum Stored momentum "magically" (ie. no basis in real physics) slowly decays over time, recovering the parts torque capabilities. The rate is configurable in the part configuration files (ie. you can turn it off, decrease the rate, or increase the rate to suit your play style) Stored momentum can also be discharged at the expense of propellant. Not enabled by default, change the file extension of ResourceDrain.txt to .cfg to enable Before you download I have not done much testing. Please report any problem you encounter with the mod. I have not marked KSP 1.8.1 as compatible but I use it in my 1.8.1 heavily modded career and I'm sure I'll have a reason to explicitly declare compatibility after some time. Changelog v2.1.3 Added: New custom ico for toolbar button (by @Tedd_Deireadh, thanks!). v2.1.2 Fixed: Non-EN KSP versions throwing exceptions or even failing to load. v2.1.1 Fixed: Each time you entered flight scene, you got one more toolbar button. v2.1.0 Added: RCS Fuel icon for "propelled" discharge toggle button. The button is now also red when the discharge is active. For-propellant discharge availability is now toggled not via file renaming, but mod's difficulty settings. Reasonless discharge can be both toggled and scaled in the difficulty settings (from no discharge up to 10 times faster than "default legacy speed"). Icon in mod toolbar to toggle RW Window (so you don't need to search for an RW part to access it). As of now the icon used is the icon of vessel controll science node found in GameData/Squad. Its copy is put in the modfolder, a "better" icon is planned. Fixed: RW Window is now a bit better spaced (the close button). RW Window treated in-physics craft with same names as a single one (probably it had some severe side-effects). v2.0.0 Built vs KSP 1.10.1 Added a patch to remove SaturatabeRW module if we find a part lacking ModuleRecationWheel on zzz_ prefixed pass Fixed severe NRE spam if ModuleReactionWheel is removed (in a wierd way) by SETI mods.

ASHARK's INDUSTRIES a.k.a Hzcary's industries parts 1.3 release this is my first mod this mod provides few parts that increase stability for space shuttle or planes. DOWNLOAD: SPACEDOCK known bugs(history and fixed version): Intake doesn't work for the engine remember to report bugs here *P.S. I'm not good at modeling.so pls forgive me for copying some of the part's texture and objects thanks for @Warsoul for helping me to find problems and teach me how to model parts Read this BEFORE asking for support(except bugs) http://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/ NOTICE:Do not change the name of the mod folder otherwise mk3 reaction wheel won't work

A note to start off: This is quite a long post with stuff that might be boring for some of you. If you just want to know the conclusion, skip to the end. So this all started while I was reading through this thread in the game-play questions. Being a bit of a turbohead myself, I figured I could help out at least a little bit with the aerodynamic efficiency of the propellers, even if electric engine types weren’t really my thing. As I read through, I encountered @Geschosskopf who believed from his extensive experience with Kraken and Ladder drives, as well as his (excellent as you will find out) spidey senses for potato physics that stock propellers must exploit physics somehow, his hypothesis being that they were taking advantage of some kind of artifact of the game’s collision physics that ignored Newton's 2nd and 3rd laws. The idea being that the propeller was dragging the plane along without “feeling” the plane. The very good reasons for this idea are summed up in the following argument. “How many RTGs do you put on a shaft? 4-6 at most, maybe less? Each RTG makes 0.8 EC/sec. The accepted conversion rate to real units is 1 EC = 1 kJ, so 1 EC/sec = 1 kW ~ 1 hp. Thus, you're only putting 3.2-4.8 hp into the shaft, which is the about what you get from a small lawnmower engine. How are you even going to taxi, let alone fly, a multi-ton aircraft with that little power?” - Geschosskopf I knew ladder drives and kraken drives took advantage of some strange physics, but I couldn’t wrap my mind around the idea that the physics of collisions between basic craft (like the propeller shaft and the plane) could be messing with things, because that would imply some very wonky effects would be seen any time two crafts were in contact. That being said, I may have been a bit biased since I regularly work on stock turboshaft helicopters. We struck up a lively debate in a private chat, which took place over the course of 3 days. His arguments usually went into the workings of the game, looking at how it (probably) models collision, trying to insure that the collision meshes two parts on different vessels are not clipping into each-other, and moving them a bit if they are. Meanwhile mine usually stayed more on the player side of things, using thought experiments such as a caged jet (this will be followed up on later) to show why it didn't make sense that the propeller was pulling the plane in ignorance of Newton's 2nd and 3rd laws. Eventually I decided to actually run a few KSP experiments to determine the viability of the wonky physics idea, and otherwise determine what was going on. The first experiment was with a Mallard carrying an orange tank. The Mallard had the orange tank inside the cargo bay mounted on a decoupler, with cubic struts and I-beams positioned around it so as to act as a cradle for the orange tank, preventing it from moving when decoupled. The configuration can be seen here. The idea being that, if collision physics work properly, the plane should take off at exactly the same speed if the orange tank remains attached to the plane as if I decouple the orange tank and let the cradle of cubic struts keep it from moving. If the collision physics are wonky like Geschosskopf theorized, then the plane should take off at a lower speed when the orange tank is decoupled, because the game will think the plane is only lifting itself, and will only teleport the tank along to prevent clipping. I made the first run with the orange tank still directly attached to the aircraft. I was a little late with the screenshot, but it took off at 76.1m/s. I made the second run with the orange tank decoupled and held in the cradle. I made this screenshot on-time to see the takeoff once again at 76.1m/s. Exactly the same as the previous takeoff. Sequential trials produced almost identical results, thus appearing to imply that the collision physics worked properly, obeying Newton’s 2nd and 3rd laws. But I wanted to be extra sure, so I devised a second experiment. The second experiment I called the “Caged Jet Experiment”. The idea was to simulate the pushing of a stock propeller on an airframe using a jet engine. Just in the same way a prop-shaft is restrained to the airframe of a stock plane or helicopter by a bearing, a jet engine would be restrained to the airframe of a Mallard by a “cage” once again composed of cubic struts. The idea being that a jet engine would stand in for a propeller shaft. If the collision effects ignore Newton’s 2nd and 3rd laws in the way Geoschosskopf theorized, then a jet held in a cage should make the plane move much faster than one directly attached to the plane, because the jet engine doesn’t realize that it is pushing the big heavy plane. I didn’t take many pictures of this one because I didn’t have an autopilot installed to allow me to hold a certain altitude precisely, so as to be able to quantitatively measure the performance of the plane. However I testify that it performed nearly if not exactly the same when the engines were decoupled and trapped in the cages as when they were still directly connected to the plane. The only difference was that with the decoupled engines, I could not reduce throttle for landing afterwards. Good thing the Mallard was a seaplane! Another experiment I proposed, but did not perform, was to attach a 5 ton trailer to a 3 ton rover using a stock pin-in-hole joint. If the collision physics work correctly, the setup should behave exactly like what it is. A rover pulling a heavy trailer, with all the associated performance losses. However if the collision physics are wonky, the rover should still have the same performance as if it were driving on its own, and pull the trailer along as if it is nothing. I’m guessing the people I see on here building semi trucks every now and then that a truck most definitely is affected by carrying a trailer behind it. So, the collision physics didn’t seem to be the root of the problem, so another idea came up. That was that KSP didn’t know how to properly get the thrust of a stock propeller, however this was quickly disproved by the point that a propeller is quite literally a number of wings moving a circle. KSP doesn’t have to do anything to find the thrust of a propeller or lift of a rotor that it doesn’t have to do to find the lift of a plane going into a slip-turn. So then there was my hypothesis that the 1EC = 1kJ standard was incorrect. I devised an experiment to try to prove or disprove this. So how it went in my head was that I would measure the torque output of a reaction wheel in relation to the angular velocity. Using these values I could determine the power output by the equation power = torque x angular velocity (P = τω). By comparing this to the electricity drawn (EC/s) by the reaction wheel, I could find the energy content of a unit of electricity. For the experiment I created a kOS script which can read the angular velocity, and use that to determine various other statistics. I also created a special vessel with which to perform the experiment There is a probe core, a fuel tank, a reaction wheel (the 0.625m type, which has a constant electric charge draw of 0.25 EC/s), and two spider engines on the sides directed so as to create torque. The engines are a known constant source of torque, calculated to be 7740 newton-meters. So what the script does is activate the engines, and then take a reading of the angular velocity and labels it Ang_vel0 at a time desginated T0. It then waits a short period, and measures the angular velocity and labels it Ang_vel1 and takes the time as T1. It can now calculate the angular acceleration as (Ang_Vel1 - Ang_Vel0)/(T1 - T0). It can then calculate the moment of inertia of the craft in the roll axis using α = τ/I => I = τ/α. Moment of Inertia = Torque / Angular Acceleration Note that I use the infinite propellant cheat during this experiment to make sure the moment of inertia doesn't change as the engines fire. Anyways, so the script shuts off the engines again, since it needs no disturbances for the next part of the experiment. I use timewarp to bring the spin back to a halt, so as to have no influence from the previous bit that determined the moment of inertia. The script now locks the ship's roll control to full clockwise (would work counterclockwise just as well, that's just what I picked), and uses the same procedure of finding angular acceleration using = (Ang_Vel1 - Ang_Vel0)/(T1 - T0). It displays this value as well as the angular velocity** Since it now already knows the moment of inertia, it runs it the other way to find what torque the reaction wheel is producing. τ = I*α It displays this value** Now with the torque and the angular velocity, it can calculate power via P = τ*ω It displays this value** **All these are updated over time, allowing changes to be observed By plugging all the displayed values into a spreadsheet, I was able to create charts displaying various items such as torque curves. To my intrigue, at near-zero angular velocity, the 1EC = 1kJ conversion rate was true (so in the graph I put EC/s as W for watts), but as angular velocity increased, the reaction wheel appeared to be developing more and more power from the same constant power input. I and probably a lot of people here knew reaction wheels were broken due to lack of conservation of momentum, but this demonstrates just how badly they are broken. At just 9 radians per second, the reaction wheel is multiplying the power input by a factor of 150. Thus you can give an electric plane spitfire performance with the electric power equivalent of dinky little lawnmower. I have yet to perform the experiment up higher angular velocities, however it would be interesting to see how the trends continue. I want to add some more tests into the experiment as, now that I think about it, I'm wondering if torque is actually constant, and the apparent change is due to the spider engines stretching away from the tank due to centrifugal forces, thus changing the moment of inertia slightly. Perhaps I can devise a method of testing that does not require any off-axis parts.* Current conclusion: Stock propellers in of themselves are not exploitative, however electric props take advantage of broken reaction wheel physics to generate power a couple orders of magnitude greater than what is put in! So neither Geschosskopf nor I were entirely correct! *Update: After further testing using a reaction wheel and a tank with no radial engines, I have found that the torque output of reaction wheels is constant. Using this I plan to calculate the MOI of numerous parts, which could be useful for the construction of mechanical contraptions. Thanks for reading! Also thank you Geschosskopf for the fun debate and the push to question the workings of the game. This all was quite interesting to work out. For anyone interested in examining the script I used you can find it below. The order of the display of values and their labels have been modified slightly to be more user-friendly, but all the math is the same. Not that the variable labeled "Torque" is used twice in the script. In the first section it is a fixed value, designating the torque from the two engines. In the second section it is overwritten and is the calculated torque output of the reaction wheel.

I have a space telescope that's a tad difficult to train on a target that's far off... when I maneuver the telescope, there's a bit of drift back and forth as SAS tries to settle it on target. I was thinking I need to add more reaction wheels to make the training a bit more precise, but perhaps I'm going the wrong direction? Might I actually be overpowered with my reaction wheels? (What I have right now is the HECS probe's internal reaction wheels...)