ShotgunNinja

@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!