• Content count

  • Joined

  • Last visited

Community Reputation

1446 Excellent

About ShotgunNinja

  • Rank
    Senior Rocket Scientist
  1. Mmm, no that is not intentional. I didn't think of this. The greenhouse has to be an habitat for the pressure threshold of growth, but the implementation was a bit rushed at the time. The only solution available for now is to disable the greenhouse during the storm. The crop will not grow during those few hours but that's it, there are no other side effects.
  2. Consider this: radiation when CME hit a vessel is 5 rad/h, so in 5h they were subjected to environment radiation of 25 rad before shielding is applied. With max shielding, you get only 5% of the environment radiation. So they accumulated 1.25 rad during the storm. Given the tolerance of 50 rad total that a crew member has, it means they were supposed to degenerate only 2.5% on their radiation bar, so to speak. So something must be wrong, can you please double-check that you are not using custom settings for the storm radiation? With the default settings, the mean time between storms is 250 days. That's as much as you are going to get in term of information about solar events, the actual ejection time is generated at random. It does already, with the exception that it doesn't take into consideration free Food capacity at time of harvest. If you bring some Food to get the crew up to time of harvest, that container alone should have enough free capacity when the time comes. If you are seeing an error in planner instead, then provide a test case and I'll look at it. @chaoseclipse01 No problem. In fact the lighting icon is not really appropriate, I'm thinking of changing it to some kind of 'spiral' icon at the next refactor (to represent solar plasma in general). Also the enabling/disabling of habitats is maybe the least intuitive aspect of the mod.
  3. @chaoseclipse01, @aluc24 Some clarifications. The storm problem indicator (the lighting icon) appear after a CME has been ejected from the Sun and is predicted to hit the vessel (yellow icon) and then when it actually hit the vessel (red icon). It isn't related to ElectricCharge. There was never an alternative indication for this, is has been in this form since the beginning. Also there is no difficulty setting in the KSP menu, for various technical reasons. To deal with storms, you need a small pod dedicated to be a 'storm shelter'. Choose a small one, and set its shielding to the max. For the rest of the vessel you can choose a lower amount of shielding. When the CME is ejected, you are notified by warning message and by the yellow storm icon. Both of these also show the estimated time to impact. In that time, you have to move your crew to the 'storm shelter' pod. Then 'disable' all other habitats in the vessel. You will see in the telemetry panel that the shielding factor is now entirely determined by the Shielding amount in that storm shelter pod. In this way, the crew can survive quite a few storms. You can reuse the shelter approach even when crossing radiation belts. You don't simply keep the crew in the shelter all the time because living space is also determined from the set of enabled habitats. For greenhouse, the current one is in fact overpowered. It will take a much bigger biomass to sustain even a single crew. A single greenhouse can now sustain 2 kerbals, provided that you have enough free Food capacity when it is harvest time.
  4. @the_machemer Sorry, somehow I have misunderstood your post. Yes, the issue in your case is simply that nuclear engines emit radiation. You can see the amount of radiation emitted locally in the planner 'radiation' section. For your second question, what you see in the planner is a good indication of what you will experience in flight. The math is the same.
  5. @chaoseclipse01 The problem is that, in a process, either the input rates adapt to output capacity left or they don't. So if I put 'dump = false' in the monoprop fuel cell, it always work at full regime (and that is not desiderable). If I put 'dump = true', it will stop when one of EC/Nitrogen/Water is full (and that too is not desiderable). So now I reworded it's description to clarify that is meant to be used as an emergency EC generator, and set it to 'dump = Nitrogen,Water'. Probably I'm going to get rid of it altogether in the next refactor.
  6. @chaoseclipse01 The SCO of NH3 into N2 is just a perfect fit with the rest of the chemical processes. It was a very good idea In last version I've also added the means to explicitly set orientation of radiation fields, maybe that could be useful in your case with KSS. There is some info about that in the release post.
  7. It does calculate it based on the amount of Shielding resource per-m² of habitat surface. More precisely, any part that has capacity for Shielding resource will influence the calculation. That is because nuclear engines emit radiation No, the waste is dumped overboard if there is no storage capacity.
  8. Probably you have figured it out by now, but in your MM patch you should use 'rate' instead of 'Ratio'. All modules that leverage KSP resHandler (like the greenhouse above) use 'rate', while only the stock resource converter/harvester modules use 'Ratio'.
  9. @JadeOfMaar The FlightGlobalIndex. However if not specified it default to 0, so no changes are required for GPP.
  10. New version released: 1.2.8 Changelog: - rebalanced atmosphere leak rate from ISS data - new process in chemical plant: SCO (selective catalytic oxidation of NH3 to N2) - radiation fields can now be oriented using a specific reference body - lowered abundance thresholds of ore and co2 harvesters - scale part icon of pressurized radial containers - custom order of part icons in our category - Coatl Aerospace support patch (@dieDoktor) - fix: properly detect if drill head intersect ground - fix: no more signal warnings on prelaunch - fix: false detection of incoherent oxygen production - fix: try to not break AmpYear/BonVoyage solar panel output detection Rebalanced atmosphere leaks rate There isn't much real-world data on leak rates. I started from this ISS analysis here, assumed 10 EVAs from the US and 10 from the Russian sections per-year, and that most experiments leaking atmosphere are on all the time. Strangely NASA doesn't associate leak rates with surface extension. Anyway some more educated guess laters I ended up with these numbers: ISS volume (2011): 899 m³ ISS surface (assume a spherical station, what else): 425.39 m² measured structural leak rate (2011): 0.227 Kg/day estimated leak rate from activities: 1.543 Kg/day total ISS leak rate: 1.77 Kg/day considering leak rate to be linear with surface: ~0.004 Kg/m²/day final leak rate used, assuming equivalence with 6h day-length: 0.000000148 unit/m²/second New process: SCO Now the fun stuff: there is a new late-game process, the Selective Catalytic Oxidation of Ammonia to Nitrogen (simply SCO for the friends). It plays quite well in this chain: Radiation field orientation It is now possible to specify the celestial body that should be used in determining the radiation field orientation. This is useful for planet packs that add multiple stars, and want to align the magnetopause of each body with the right star. RadiationBody { name = Proxima Centauri B [...] reference = 16 //< the index of the star Proxima Centauri }
  11. Kopernicus author is working on fixing the multiple stars panel issue (see here). The multi star hack in Kopernicus already work for thermal simulation stuff, so the issue must be related to ModuleDeployableSolarPanel internals. I'm confident this will be fixed in a way or another. In the worst case, that module can be replaced with a custom one that is directly aware of multiple stars.
  12. @aluc24 Yes, unfortunately that is also my fault. BV is not finding any generator in the RTGs because I replace it with something else, with equivalent functionality but no warp issues. So I would suggest to use maja's fix, to keep the rovers rolling.
  13. Apologies guys, the next version of Kerbalism should solve the issue (I hope!). Meanwhile you can grab the updated dll here.
  14. @TheUltimateKerbonaut Try this: double ScienceValue(string subject_id, float size) { ScienceSubject subject = ResearchAndDevelopment.GetSubjectByID(subject_id); if (subject == null) return 0.0f; return ResearchAndDevelopment.GetScienceValue(size, subject) * HighLogic.CurrentGame.Parameters.Career.ScienceGainMultiplier; } float CountScience(Vessel v) { float credits = 0.0f; foreach(IScienceDataContainer c in v.FindPartModulesImplementing<IScienceDataContainer>()) { foreach(ScienceData sd in c.GetData()) { credits += ScienceValue(sd.subjectID, sd.dataAmount); } } return credits; }
  15. @killbotvii That answer is really good. To extend on that, it is rather complex to determine how much shielding you need for a mission. There is a planner in the VAB (if you didn't find it already) that is more or less indispensable. So you setup your vessel and the shielding, set a target body in the planner and it tell you life estimates in the various radiation environments encountered toward or upon arrival to the target, or in case of space weather events. @chaoseclipse01 Do you still have the issue with wrong orientation of radiation fields? If yes, try cleaning up all kind of cache files from your GameData folder (MM or Kopernicus ones). Assuming you are not using planet packs that remove the main star (eg: binary star mods or the like), if the issue persist please raise an issue on github or post log/modlist here. @Drew Kerman I'm going to put a label on that icon in next version.