ShotgunNinja

@Torih Sorry, the individual aspects of this mod can't be turned off.

About KSP 1.1: this will get updated for 1.1 as soon as I get my hands on it. About disabling part of the mods: early in the design i through about making separate mods, but then choosed to go fully integrated. This was painfull code-wise, but in the end it allowed me to make all mechanics interact with each other and have a common user interface.

Version: 1.2.9 Download: github, spacedock, CKAN Source: github Documentation: wiki License: Unlicense Require: KSP 1.3.0, MM 2.8.0 INTRODUCTION Go beyond the routine of orbital mechanics and experience the full set of engineering challanges that space has to offer. This mod extend KSP by simulating the crew, the components, the resources and the environment in a more complex way. All mechanics can be configured to some degree, or even disabled if you don't like some of them. A big part of the mod is fully data-driven, so that you can create your own customized gameplay with only a text editor and a minimal amount of espresso. Or simply use the set of rules already included, or the ones shared by other users. What follow is a summary description of the capabilities of the mod, and for a more detailed documentation the user is invited to read the wiki. ARCHITECTURE Contrary to popular belief, the observable universe is not a sphere of 3km radius centered around the active vessel. All mechanics are simulated for loaded and unloaded vessels alike, without exception. Acceptable performance was obtained by a mix of smart approximations and common sense. The computational complexity is by and large independent from the number of vessels. RESOURCES This isn't your classic post-facto resource simulation. Consumption and production work for all vessels, all the time, and is coherent irregardless of warp speed or storage capacity. Complex chains of transformations just work. Enjoy designing missions without the luxury of stopping the flow of time. No suspension of disbelief required. ENVIRONMENT The environment of space is modelled in a simple yet effective way. Temperature is calculated using the direct solar flux, the indirect solar flux bouncing off from celestial bodies, and the radiative infrared cooling of their surfaces. The simulation of the latter is especially interesting, and contrary to popular models it is able to reproduce satisfatory results for both atmospheric and atmosphere-less worlds. Radiation is implemented using an overlapping hierarchy of 3d zones, modelled and rendered using signed distance fields. These are used to simulate inner and outer belts, magnetospheres and even the heliopause. Solar weather is represented by Coronal Mass Ejection events, that happen sporadically, increase radiation and cause communication blackouts. HABITAT The habitat of vessels is modelled in terms of internal volume, external surface, and a set of dedicated pseudo-resources. These elements are then used to calculate such things as: living space per-capita, the pressure and co2 level of the internal atmosphere, and radiation shielding. Individual habitats can be enabled or disabled, in the editor and in flight, to reconfigure the internal space and everything associated with it during the mission. Inflatable habitats are driven directly by the part pressure. BIOLOGICAL NEEDS Your crew need a constant intake of Food, Water and Oxygen. Failure to provide for these needs will result in uncerimonious death. Configurable supply containers are provided. PSYCHOLOGICAL NEEDS The era of tin can interplanetary travel is over. Your crew need some living space, however minimal. Failure to provide enough living space will result in unforeseen events in the vessel, the kind that happen when operators lose concentration. While not fatal directly, they often lead to fatal consequences later on. Some basic comforts can be provided to delay the inevitable mental breakdown. Nothing fancy, just things like windows to look out, antennas to call back home, or gravity rings to generate artificial gravity. Finally, recent research point out that living in a pressurized environment is vastly superior to living in a suit. So bring some Nitrogen to compensate for leaks and keep the internal atmosphere at an acceptable pressure. ENVIRONMENT HAZARDS Your crew evolved in particular conditions of temperature, and at a very low level of radiation. You should reproduce these conditions whenever your crew go, no matter the external temperature or radiation at that point. Or else death ensue. The vessel habitat can be climatized at the expense of ElectricCharge. Environment radiation can be shielded by applying material layers to the hull, with obvious longevity-mass tradeoff. ECLSS A set of ECLSS components is available for installation in any pod. The scrubber for example, that must be used to keep the level of CO2 in the internal atmosphere below a threshold. Or the pressure control system, that can be used to maintain a comfortable atmospheric pressure inside the vessel. In general, if you ever heard of some kind of apparatus used by space agencies to keep the crew alive, you will find it in this mod. GREENHOUSE No life-support-like mod would be complete without a greenhouse of some kind. The one included in this mod has a relatively complete set of input resources and by-products, in addition to some more unique characteristics like a lamp that adapt consumption to natural lighting, emergency harvesting, pressure requirements and radiation tolerance. ISRU The stock ISRU converters can host a set of reality-inspired chemical processes. The emerging chains provide a flexible and at the same time challenging system to keep your crew alive. The stock ISRU harvesters functionality has been replaced with an equivalent one that is easier to plan against, as it is now vital for long-term manned missions. The means to harvest from atmospheres is also present, given the importance of atmospheric resources in this regard. A planetary resource distribution that mimick the real solar sytem complete the package. RELIABILITY Components don't last forever in the real world. This is modelled by a simple system that can trigger failures on arbitrary modules. Manufacturing quality can be choosen in the editor, per-component, and improve the MTBF but also require extra cost and mass. The crew can inspect and repair malfunctioned components. Redundancy become a key aspect of the design phase. SIGNAL An alternative to the stock CommNet system is provided. Theres is a difference between low-gain and high-gain antennas: the former used for short-range inter-vessel communications, the latter always implicitly pointing at DSN. Transmission rates are realistic, and scale with distance to the point that it may take a long time to transmit data from the outer solar system. Data transmission happen transparently in loaded and unloaded vessels, as usual. The resulting communication system is simple, yet it also results in more realistic vessel and mission designs. Tiny hypnotic science-blue spheres travel the link lines to represent data transmission. SCIENCE Data is collected and stored in the vessel solid state drives, instead of the stock science containers. Moving data around the vessel doesn't require extra vehicular activities. Some data can be transmitted back directly, while other data need to be analyzed in a lab first. Analyzing take a long time, happen transparently to loaded and unloaded vessels alike, and can't be cheated to create science out of thin air. An interesting method is used to bridge existing stock and third-party experiments to the new science system, that work for most experiments without requiring ad-hoc support. AUTOMATION Components can be automated using a minimalist scripting system, with a graphical editor. Scripts are triggered manually or by environmental conditions. You can create a script to turn on all the lights as soon as the Sun is not visible anymore, or retract all solar panels as soon as you enter an atmosphere. USER INTERFACE The UI provided by this mod took more than 5 minutes to write. A planner UI is available in the editor, to help the user design around all the new mechanics introduced. The planner analysis include resource estimates, habitat informations, redundancy analysis, connectivity simulation, multi-environment radiation details and more. To monitor the status of vessels, the monitor UI is also provided. This look like a simple list of vessels at first, but just click on it to discover an ingenuous little organizer that allow to watch vessel telemetry, control components, create scripts, manage your science data including transmission and analysis, and configure the alerts per-vessel. MODULES EMULATION Most stock modules and some third-party ones are emulated for what concerns the mechanics introduced by the mod. The level of support depend on the specific module, and may include: simulation of resource consumption and production in unloaded vessels, fixing of timewarp issues in loaded vessels, the ability to disable the module after malfunctions, and the means to start and stop the module in an automation script. SUPPORTED MODS Most mods work together with this one, others don't. Such is life. For a non-exaustive list of supported mods have a look inside the Support folder. Some of the interactions deserve a special mention: SCANsat: - sensors consume EC in background and their cost is evalued by the planner EC - sensors are shut down and restarted in background depending on EC availability DeepFreeze: - all rules are suspended for hibernated Kerbals - the vessel info window show frozen Kerbals with a different color NearFuture: - curved solar panels, reactors, fission generators and RTGs produce EC in background and are considered by the planner PlanetaryBaseSystem: - the coverters will work in background and are considered by the planner OrbitalScience: - experiments data size has been tweaked for background data transmission OPM/RSS/NewHorizons: - custom radiation definitions for these planet packs are provided CONTRIBUTIONS This project wouldn't have been possible without the contributions of an awesome community of people, too many to mention individually. Thanks guys. And special thanks to the artists that provided all the part: mehka: gravity ring Nazari1382: geiger counter, small supply container tygoo7: medium and big supply containers, radial pressurized container zzz: greenhouse, active shield FAQs I may have found a bug Try to reproduce it consistently, then provide me with a savegame that demonstrate the issue. Include log files, screenshots, and reproduction steps. Post the report here, or raise an issue on github. I want to add support for this to my parts Add the appropriate modules to your parts. Check the wiki on github for the module specifications. I want to interact with this mod in code Have a look at System/API.cs source code on github. Raise an issue to request more functions. SCREENSHOTS CHANGELOG

@TaintedLion The small drogue parachute, in the development version on github. You unlock it with basic rocketry, looks like the standard one but different color.

This mod is awesome. If you are using the development version (1.9.2) you may have noticed that there is an inline 1.25m drogue paracute, that is a bit unbalanced. Also, the 1.25m inline standard parachute and its radial counterpart have different specs, but same mass. You can use this MM patch to fix these minor problems: You'll notice this also increase crash tolerance of the heatshields. This is because, using the 1.25m inline standard parachute, you now go down at about 10m/s in the early game and that damn headshield was exploding all the time! Cheers.

Some of the problems of a manned Mars mission: prolonged exposure of the crew to cosmic radiation, a few coronal mass ejection hits along the way, the weaker magnetosphere of Mars the mass of long-term supply of food, water, oxygen for the crew Mars atmospheric pressure at zero-level is 0.6% that of Earth, requiring more mass to accomplish the landing in a way or the other Mars gravity is much stronger than Moon gravity, requiring more mass to accomplish the ascend stages of the mission all of this requirements lead to a mission mass profile of unprecendented scale, requiring possibly thousands of LEO launches and rendezvous for assembly the failure of a non-redundant system will mean the complete failure of the whole project and death of the crew, with consequent political fallout

@jamespicone I got a more robust solution for the fact that PhysicsGlobal.SolarLuminosity is zero before loading a vessel, quite easy stuff actually: // return sun luminosity public static double SolarLuminosity() { // note: it is 0 before loading first vessel in a game session, we compute it in that case if (PhysicsGlobals.SolarLuminosity <= double.Epsilon) { double A = FlightGlobals.GetHomeBody().orbit.semiMajorAxis; return A * A * 12.566370614359172 * PhysicsGlobals.SolarLuminosityAtHome; } return PhysicsGlobals.SolarLuminosity; } This doesn't assume anything about the sun, so it has no drawbacks in case the user is using some planet mods. Posting it here in case you come out of hybernation for the 1.1 fanfare.

Hey, I'm developing a mod that does just that. Essentially, there are some limitations in the game if you want to kill Kerbals on EVA (vessel markets remain on screen, etc...) so I designed around those limitations and make Kerbals enter an 'EVA death' mode where they are in an unescapable 'freezed' state (the default ragdoll state was too tricky to work with). So you get the bodies floating around in space, or stay on the surface of planets. The 'blue' look and 'recover dead kerbals' contracts are interesting ideas, didn't through of that. Those things may be in a future update, as the mod is in private beta now and will be released to the public in a few days. Cheers!

@jamespicone James, I found another problem. When a vessel is orbiting the Sun, and the user switch from Flight to SpaceCenter scene, for a single tick, vessel.GetWorldPos3D() return the Sun position!!! When this happen, the following events take place: sun_dir vector became [0,0,0] sun_dist became 0 normalizing sun_dir lead to NaN values removing the sun radius from sun_dist generate a negative distance solar flux calculations lead to NaN values EC amount on the vessel became NaN mass calculation for the vessel go wild and return -INF mass loading the vessel destroy the universe! The solution I found is to obtain unloaded vessel positions by resolving the orbit directly, eg: "vessel_pos = vessel.orbit.getPositionAtUT(Planetarium.GetUniversalTime())"

@Snark @RoverDude Hi guys. A bit of necro perhaps, sorry if that is the case. I was thinking, if the ModuleResourceConverter and ModuleResourceHarvester are simulated 'post-facto' at vessel loading time, using the lastUpdateTime module data (correct me if I'm wrong), then of course it is possible that this is the reason of so many apparently random problems people encounter after off-rail time of ISRU vessels. Let me explain: you got a complex system (composed of multiple interacting parts: in this case sources, sinks, and storage) and the game engine perform a single update, at a single point in time (loading time). Then it is impossible for the system to be modelled accurately, or even approximately, if not only for the simplest cases, because there is only one integration at the end. The solution is to mimic what physical integrator does to maintain stability: perform multiple simulation steps over time. Eventually, you can also compute all the steps still at vessel loading time, in succession. I hope this is clear and maybe even helpful. Cheers!

Hey @JPLRepo, I've updated my interim version... now do ad-hoc raycasting against celestial bodies, instead of relying on the game engine raycasting capabilities. I believe that was the reason of multiple problems. Right now it seems to work fine. No further changes are in plan from my side, promise Cheers!

@jamespicone Hey, I digged harder into that vessel position problem and the more I dig the more spurious problems turns out! At first i trought KSP was doing some funny things with the vessel.GetWorldPos() function, then that either that or the planet positions were in what KSP call 'ScaledSpace', then I got random occlusions from GameObjects around the launchpad, dependent of camera position!, but only in some circumstances. Hell basically. Long story short, I just reached my patience limit and reimplemented raycasting myself. We just have to trace against a bunch of spheres after all. So now I got a solid, stable and fast function that return if a point is in direct sunlight! Yeah If you are interested let me know.

Sure. This is my interim version of BackgroundProcessing with some fixes for KSP 1.0.5. All credits goes to the original author, @jamespicone. Please report any problems you may found. BackgroundProcessing for KSP 1.0.5 EDIT [March 07 2016]: updated, now do ad-hoc raycasting of celestial bodies, instead of using KSP game engine EDIT [July 26 2016]: obsolete link removed

Great! By the way I've done some painfull extensive testing in 1.0.5 and except for the previous things I reported this is a pretty solid piece of work.

@KvaNTy I understand hard-coding the solar luminosity is not ideal, but right now you notice that there is no EC generation after starting/loading a game session (because PhysicsGlobal.SolarLuminosity is set to 0). Only after a vessel (any vessel) became active that constant is set by the game engine. Maybe a compromise may be to use the hard-coded SolarLuminosity only if the game engine is returning 0 for it. In this way there is only the minor inconvenience that the value is wrong (but still some EC is generated) only if these two conditions are met: no vessel was ever active from the start of the game session another planetary/scaling/rebalance mod is used I think it is a good compromise. For your second question, honestly I'm not sure myself. But you can verify this by orbiting a vessel with a solar panel and printing the EC amount in the log. You'll notice that the sun raycasting isn't really working unless you convert the vessel position to scaled space.

Hey James, I'm developing a mod that use your awesome BackgroundProcessing and have found some problems in the code, that went on and fixed in my version: off-rail vessels position must be converted to ScaledSpace (maybe this changed recently...) fix: in solar panel HandleResource(), replace any occurence of 'v.GetWorldPos3D()' with 'ScaledSpace.LocalToScaledSpace(v.GetWorldPos3D()) ' PhysicsGlobal.SolarLuminosity is 0 (zero) before loading first vessel in a game session fix: hard-code solar luminosity value (3.1609409786213E+24) load-only-most-recent-version machinery doesn't work if the MonoBehaviour class names are the same fix: rename the MonoBehaviour class 'BackgroundProcessing' to 'BackgroundProcessing_MAJOR_MINOR_REVISION_BUILD' In any case, I want to take the chance to thank you for your work. Best regards!