ShotgunNinja

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

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

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

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.

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'.

@JadeOfMaar The FlightGlobalIndex. However if not specified it default to 0, so no changes are required for GPP.

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 }

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.

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

Apologies guys, the next version of Kerbalism should solve the issue (I hope!). Meanwhile you can grab the updated dll here.

@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; }

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

You can use multiple antennas in a vessel to transmit and receive. The total data transfer rate will be the sum of the ones for each antenna. But having multiple antennas will not increase the distance at which you can transmit. In the VAB, look at the 'signal' panel in the planner. It will show you both the transmission distance and the data transfer rate determined by the antennas you have added to the vessel.

Yes, change this line and recompile.

@RocketBlam Do you have ModuleManager 2.7.5+ installed? Do you see an 'heartbeat' category icon in the VAB?

Magnetospheres (and the active shield) will block plasma elements to various degrees, but will not block photons at all. Radiation belts will represent the trapped particles population, with values inspired by reality (after some semplification, and some serious assumptions for bodies others than earth/kerbin). In general, radiation fields act as a 'zones in which there is a certain flux', even a negative one. Similar to how it is now, except that it will be differentiated by the aforementioned EM bandwidths and plasma element types. There is no implicit modeling of photon->plasma interactions, but you will be able to hard-code explicit ones in the flux values if you like. You devise your own 'storm shelters', it is already possible. Just set shielding to an high amount in some part that you want to use as shelter. Better choose a cramped part to minimize shielding mass required. When the solar event start, transfer the crew inside your shelter and disable all other habitats. Then after the solar event re-enable the other habitats. Right now it is impossible to shield completely (at least using the default settings). That was always meant to represent secondaries. The objective down the line is to implement these directly instead. I considered having arbitrary resources (eg: fuel, water, the internal atmosphere, etc.) interact simply with radiation by shielding incoming flux (and emitting secondaries). Without regards to position in the vessel, just absorbing/generating radiation based on the amount of that resource. I think that's a nice idea, worth exploring, but right now this part of the design is still in flux.

It is planned. Radiative fluxes will be modeled quantized for electromagnetic bandwidth, and for plasma elements. There will be 2 or 3 types of shielding, each one with different effects on radiation. There may be secondaries or not, I haven't decided yet about that. The user will still see a simple metric for radiation level, but the underlying model will become a little more varied. The sun will emit plasma (aka: solar wind), and the emission will be anisotropic in space and time (aka: solar events). Emissions dangerous to living things are in italic. electromagnetic emissions radio (3Hz -> 3GHz) microwave (3GHz -> 300GHz) infrared (300GHz -> 430THz) visible (30THz -> 750THz) ultraviolet (750THz -> 30PHz) xray (30PHz -> 30EHz) gamma (30EHz -> 300EHz) plasma emissions electron (free electrons, aka: beta particles) proton (hydrogen nuclei) helium (helium nuclei, aka: alpha particles) hze (high-z nuclei) neutron (free neutrons) shielding low-z (eg: water) high-z (eg: lead) graded-z (see here) I just tried, there is nothing wrong.

@chaoseclipse01 1) The GeigerCounter model size is similar to the stock thermometer and barometer. By the way, its author is forum user Naazari1382. 2) The radiation fields orientation already match the sun -> body vector.

@Drew Kerman That is right, 'nominal' radiation just mean the value is below 0.001 rad/h. @Andrea Galimberti I am not messing with crew transfer at all, it is unlikely to be caused by this mod. I would suggest to try reproduce the problem with a minimal set of mods. @Deplaisant Yes RT is supported: the Signal system disable itself and the RT connected status is used instead. To show the radiation fields press 1-2-3-4 on the numeric keypad, or toggle the rendering in the window that pop out when you press B in map view or tracking station. @MaxL_1023 Yes, the easiest way is to lower the field 'degeneration' inside the 'radiation' rule of the Default profile (or Classic, if you are using that one).

@RoverDude It wasn't my intention to derail this thread. I was pinged and clarified a misconception about performance with a one-liner. Then I merely replied to questions. Feel free to delete any posts that doesn't belong here.

@RoverDude Man I wasted a lot of time then! I made it fully modular so people can keep using older mods for love or inertia or both. I am emulating all stock and the most used non-stock modules in background (to an acceptable degree for most mods). And I am maintaining compatibility patches for 36 different mods at the moment. Every time I design something new, usually 80% of the work goes into keeping other mods working. So your last comment was a bit unfair.

The equation for trait/experience based bonus was fixed by a contributor recently, it is now equivalent to the stock one. The drill head collision with the ground is evaluated when the vessel is loaded, then its state re-used when it is unloaded (as the vessel has to be landed and can't change lat/long in that case). I agree with what you say in general. Stock has different constrains, so different solutions were designed. None is 'right' in absolute term, just 'right' for the job required.

The stock thermal system is still not emulated for unloaded vessels, and is unlikely it ever will. The relations between inputs and outpus is fully supported (eg: inputs depending on output capacity left, and outputs depending on input amount, at the same time) is fully supported. I never got the point of non-mandatory inputs, so I just assume all inputs to be required. Never eard of depletion nodes (I assume they are part of the internal stock machinery for resources). I forgot to mention in the previous reply that the computation is agnostic on the number of vessels, O(1). One vessel is processed for each simulation step. Scaling number of vessels only result in a delay in updating the vessel data in my own caches, but the cost per-step stay the same. Inter-relations between vessels (eg: communication network) is also amortized so in the end it average to O(1). I was referring to the mechanics introduced by the mod. The only stock mechanic that is emulated for unloaded vessels is resource consumption/production. Recently I had to replace stock panel output calculations for loaded vessels too, to fix the issues at extreme timewarp speed.

FYI: Kerbalism run at about 300 microseconds per simulation step on a single AMD Athlon X4 core, and this include all mechanics.

@Cheesecake There are definitions for the celestial bodies in RSS, but these have a ModuleManager :NEEDS[RealSolarSystem] statement. So, even if that planet pack you are using has the same body names these have no radiation field definitions. The solution is very easy for you: create a copy of the file Support/RSS.cfg. In that copy, replace all occurrences of NEEDS[RealSolarSystem] with NEEDS[QuarterSizedRSS] (or whatever the directory for that mod is called). You don't need to change the actual field definitions because everything is expressed in body radii so it will scale automatically.