Nertea

My policy is that mod update time ~ x + (time factor) * (number of people who ask), where time factor is proportional to frequency of being asked and x is unknown.

There is a IRadiationEmitter class that is polled by RadioactiveSources. All you should need to do is implement GetCurrentEmission in that class according to your reactor implementation. The system should take care of the rest.

Nah that's not true. The post you quoted indicates this - if you specify the emission point as behind the engine it'll work exactly like that (plume emission) All fields are totally configurable, but I'm not doing anything related to lifespans. Out of scope, and breeding is really really out of scope.

@Captain Sierra, that's more or less what I said above ;). Good progress today, I got the main components of the system working in the editor (at least not crashing things) and ensured that recalculation of attenuation values occurs properly with geometric and mass based changes. I also optimized the raycaster some more... starting work on kerbal tracking.

Haha, I've been listening to that while deving!

Fullness already matters (attenuation is based on the amount of mass in the raypath), but RTGs will not generate radiation, they should be fully contained by their casing. That's good to know - I was hoping to avoid doing more occlusion checking. I'll investigate this. At the moment, that would be pretty easy, assuming that the KSPI engines are all based on ModuleEngines. RadioactiveEngine just scales its output flux according to the engine's throttle setting or flow rate (cfg field), and multiple emission points can be handled (say for reactor and thrust plum). I can add more types of scaling as well, and am planning a passive rate emitter component as well.You can let me know if that doesn't match your needs and I can add some stuff. That might be a little more complex than what I want to do with effects right now. Dont' quote me here, but I think a kerbal can be "missing" or killed, so they could be flagged as missing until a certain time had passed. You can kinda see a rough system in the screenshots, but I don't want to spend much effort on this until after 1.1, as the UI will become obsolete. One of the problems is that I don't test every single part for occlusion so Most of my engines, reactors and such do have a limited shadow shield built into the top of the reactor housing (see http://www.aerospaceprojectsreview.com/blog/wp-content/uploads/2012/08/nerva-art-63.jpg ). This would be for free in the mass, and provides quite a narrow cone of attenuation and reduces the outgoing flux somewhat. I haven't implemented this yet in this plugin but I plan to. You'd therefore get a small shield for free, and could construct a large shield with fuel tanks, structural panels, or dedicated radiation shield parts. Heat shields would not be great as they are designed to be as light as possible, wheras gamma attenuation is basically 100% proportional to the density of the material. Ah but I am! Probe core efficiency will decay with lifetime dose as well ;).

Yes, it's mentioned in the post. The goal is to have a code-defineable shadow shield block that you can insert into a RadioactiveSource module by defining a position, a radius and a direction. This allows any part to have a built in shadow shield. And yeah, docking a nuclear craft would certainly need some complex maneuvers. It depends on how things end up being set up, but in the current implementation the reactor doesn't produce radiation when it's off, so you'd have to approach completely under RCS power or plan your burns to be far enough away and drift in. In a different implementation an idle reactor might be radioactive too (in NFE radiation will be tied to amount of waste in the reactor) so would require orientation constraints. I would like to avoid adding any parts at this stage, though a storm shelter is definitely a concept that is valid. Code-wise you can do that already, RadiationCrewContainer already contains a field for reducing exposure, so you would just set that to 90% or something. Ideally if I achieve my goals you should be able to work with radiation without introducing any new parts at all.

Cool yes, you can do this if you're brave :P. You could close/turn off some radiators for the burn. As to explosions, well, there are still some known issues with the stock heat system that cause some explosions sometimes. It would help if you provide any logs, pictures, debug menu open, etc... This is a bit of a problem... the radiators (including the exhaust "raidiator") don't cool any more than the goal temp. So you could heat up the reactor to full, turn it down and it would take a long time for the core to cool down, when really running fuel through it would cool it really fast. The reason that this happens is due to power level differentials. The DRE architecture specifies a 50 kWe (maybe 300 kWt) or so generator, and the reactor's actual thrust power is going to be measured in the 10s of MW. So you're running it at like 0.1% for electricity generation. If I make the actual reactor produce so many MWs, there's going to be a problem with the thermal system. I would like the fuel burnup to be relatively high when running engine mode, so I don't want to decrease it too much. I might go a factor of 3 higher, which would put core life at around 3 years, which is similar to the NFE reactors,

The MFT support probably needs to be adjusted for this.

Radioactivity Raycast radiation for KSP Test Release 0.1.1, September 7th 2016 This is a plugin whose goal is to add a relatively realistic radiation simulation system to KSP. The idea is to construct a reasonably comprehensive and informative system that will tackle the challenges of managing radiation exposure. You can read some stuff on the wiki. I'm developing three components: Local, Solar and Planetary (probably in that order). Local is focused on the simulation of radiation inside the physics bubble. So sources of radiation like nuclear reactors, engines, etc. Solar will simulate radiation from stars, properly attenuated by planetary atmospheres, magnetic fields, etc. Planetary would deal with radiation belts and trapped charged particles. Local operates on a source-sink concept. Sources of radiation, such as nuclear reactors, compute line of sights to sinks of radiation, such a crew pods. Radiation is emitted by these sources and attenuated along the ray paths and added to sinks. It's pretty simple! Here's a few talking points... Radiation is attenuated by distance (inverse square law), part material (radiation attenuation constant) and part density (when it moves through a part) Denser parts attenuate more radiation per unit length Parts can have a specific material specified, with a particular radiation attenuation constant. Terrain is currently opaque, so you can hide a reactor behind a hill This means that most planned methods of actually dealing with radiation are possible. You can distance a source from a crew compartment, create a radiation shield out of dense materials, etc. I know that this is not fully realistic, so here's some caveats. Only one energy level of radiation (500kEV gamma) is simulated. This might change (just needs more attenuation constants) but for now it's sufficient The peculiarities of raycasting result in some geometric bugs Terrain being fully opaque is a simplification No scattering, activation or embrittlement. A test release with the Local component is ready. Read on to get it! Test release Info Do not use this on a save you really care about. It might kill your Kerbals (by accident). If you find a bug, please log it on GitHub, and for heaven's sake provide information! output_log.txt from the KSP_Data directory (this mod is currently very log-verbose so this very much helps) List of installed mods, if any. If it's a bug with the geometry of the situation (like a ship not recalculating ray paths correctly, or something not attenuating right) please provide screenshots of the ship with the overlay open Balance Not much has been balanced. Performance I've tested this a bunch with sets of up to 10 radiation sources and 10 radiation sinks constantly changing position. Performance hit seems negligible here Mod Compatibility Not compatible with Kerbalism. Most recent release of Kerbal Atomics and Near Future Electrical (forgot to include the shadow shields for NFE reactors though) contain the right stuff and patches to enable emissions from reactors and engines, but that's about it. New crew containers, science instruments and the like from other mods are not integrated. If you want to write patches to add things to mods, please consult the documentation on the wiki, and keep in mind the fluctuating balance state. Known Issues The radiation overlay doesn't always load correctly when entering the VAB or loading a vessel in the VAB. To fix this, just move the root part around a bit. Probe core degradation is not really in (my hacks have not worked yet) but probes do track exposure Science experiment degredation is not well tested Testing in career has been limited up to this point Radiation sickness doesn't do anything, only death Some elements of the UI aren't quite done so I'm aware of that, but I welcome suggestions on improving communication and stuff. After such a big stack of disclaimers, the latest test build can be acquired from the github page. Source is on the Git page there. Licensed as ARR for now, until stability.

Just let it load for a bit. It takes about 10s to appear (I think when you load it, in renders the whole diagram to an image or something).

Thanks, I'll look into it. I think the :AFTER mm tag is missing there. I did a call out for other packs a week or two ago and ensured the ones people responded to were in. I'll add those eventually. I would leave this the way it is. They're not "wrong" like all the other NTRs ;).

Two-point-five metres! Glad you like! I'm personally not really looking forward to the unwrap. It was a bit of a headache handling full plumbing for dual turbopumps with open exhausts, along with the somewhat peculiar plumbing required to cool the ridiculous thing. I'm doing a pretty cool plumbing system for the NSWR that you should enjoy if you like this one :).

Whoops. See this is why I hate updating. Takes me like 3 hours of modding. Maybe I'll make msyelf a damn jenkins server to build things. I'm not going to make a new release to fix that, so have an open-cycle gas-core engine.

Kerbal Atomics 0.1.2 Reduced power generation of trimodal engines Tweaked descriptions for some engines Patched LV-N now uses ModuleEnginesFX, new FX Added optional patch to unlock fancier NTR functionality with NF Electrical: Engines have integrated reactors, reactors must heat up to nominal temperature in order to produce good thrust and Isp Engines act as core heat radiators, cooling the core as a function of thrust fraction. Full thrust will cool the core completely. Without thrust or lots of radiators the core will overheat Reactors will run out of fuel eventually; use much more fuel than long-term power reactors Trimodal reactors have a generator component that takes priority over the engine. It will use a small amount of heat to create power. Keep reactor power low to use it separate from the engine Engine heat production cut by factor of 10 Only applies to KerbalAtomics engines and the LV-N at the moment This update primarily applies to people wanting to synergize KA and NFE. The patch seems pretty stable now and I mostly like how it works. Let me know how it goes.

Arright. v2.4 will probably be post 1.1 though

Maybe, but it's so low on my priority list that it could be never. As you indicate, it's trivially easy to do for the end user (delete the module or edit the tank patch).

Removed KS link, added CurseForge and dropbox mirrors. Please use Curse over Dropbox unless you really have to due to bandwith considerations. I'm aware that the github repo is out of date, it probably needs to be sycned on my modding computer, will do it when I get home sometime. Will be adding a third mirror on Github which might become the main download at the moment. 1. I don't really see it that way. Initial fusion engine technologies (such as magnetized target fusion engines) don't need to be built on the most advanced fission engine technologies. 2. I'll consider this one. 3. As you're the only consumer of that node, sure. 4. Ok that is indeed a bug.

Yeah... without the dev build of 0.6.2 that patch doesn't really do much beyond break the engine! That's 95% of what it is, so you are probably in for a good time there! Well, I have a bunch of time at work that sometimes sits idle. I thought I'd start working out an algorithmic approach to radiation handling in KSP that would be both efficient and simple. It is the last piece of the puzzle with respect to all the development I'm doing on nuclear-based systems and there's no mod to handle it. My code skills are probably good enough to deal with it now. I want to handle, in order of priority: Point source radiation (from reactors, engines, engine plumes, nasty fuels) Solar radiation (and attenuation of such by planetary magnetic fields) Planetary radiation belts (for jool and such) Global background radiation (cosmic rays) No promises though. We'll see how far i get!

Sorry about that, that engine was seriously under-specced though!

Kerbal Atomics 0.1.1 Updated bundled CRP to 0.4.9.0 Fixed ISRU patch ratios Fixed ISRU patch not affecting the mini ISRU Fixed tech locations for nuclear rockets Increased Neptune thrust to 67 from 62.5 When converted to LH2, most NTRs now benefit from a mass reduction Reduced boiloff cooling cost to 0.08 Ec/1000u from 0.1 Ec/1000u Added new Extras patch converting engines to LF-only. LF-only engines have reduced Isp and TWRs, comparable to those from Atomic Age and Stock

I'm pretty sure you're doing something wrong. The stock system is very simple at heart, it only gets complex when you poke around with plugins. You want to avoid equlibrium temperatures at all costs; instead use the core goal temperature, which will ensure that the core gets to that temperature and then will only heat up past that if there is not enough radiator capacity. Needed radiator capacity is simple: X kW are generated by the core, so X kW of capacity are needed to remove heat. Lets examine SolidFission.cfg. You set a CoreTempGoal of 3000. That means no radiators will be used until the core hits 3000K. However, your TemperatureModifier specifies that heat output at 2000K is zero! So you'll never hit the nominal temperature at all, and radiators will never be used. That's going to cause you problems for sure. Another point: you're generating, at a core temp of 1000K, 800 kW of heat (40000/50). You're also generating 765 units of MWt at this point. This is quite a mismatch - you're adding 800 kW of heat to the vessel while making 765,000 kW of useable heat available to generators and stuff. Shouldn't you be adding the same amount of MWt as you are adding to the vessel? And if you do go that route, I will tell you that putting GW-level heat fluxes into the core heat system will break it. Irrevocably.

0.2.1: Balance tweaks and other minor fixes. This tested pretty well last night, should make cryo a lot more attractive given the boiloff parameters. Updated bundled CRP to 0.4.9.0 Moved ISRU patch into CryoTanks folder, fixed ratios to new 15:1 mode from 0.2.0 Fixed ISRU patch not affecting the mini ISRU Reduced mass of Volcano to 1.6 from 1.8, decreased thrust to 230 from 275, increased SL/Vac Isp to 385/422 from 360/410 Reduced mass of Chelyabinsk to 0.7 from 0.8, increased Vac Isp to 465 from 455 Reduced mass of Odin to 5.75 from 7.25, increased SL/Vac Isp to 385/420 from 365/415 Reduced mass of Tunguska to 2.75 from 3.45, increased Vac Isp to 455 from 450 Reduced mass of Mars to 13.25 from 12.5, increased SL/Vac Isp to 365/415 from 355/405 Reduced mass of Yucutan to 8.65 from 8.95, increased SL/Vac Isp to 245/445 from 235/435 Reduced boiloff cooling cost to 0.08 Ec/1000u from 0.1 Ec/1000u

Cheers guys, I'll make sure at least all of those get the handcrafted (heh) treatment. I think I view the modulegenerator approach as the bad thing in this case. It's really not very good in terms of balance with stock, much less with any pack that cares about electricity consumption. In any case, at the very least, NTRs won't really generate waste heat under thrust. The exhaust will carry around 95% of the reactor heat, which means that the lower power engines won't need any kind of radiators.

USI and NFE are pretty close, due to coordination between RoverDude and me. It is an important point though - you will indeed need to work balance a bit. Your converter shouldn't behave like that though. It's a bit mystifying - there shouldn't be any equilibirum achieved as the core should heat until the temperature goal and then start being cooled.