Nertea

This is a test release for 1.1. It should not be considered fully operational. I will not push the AVC file or the official update links in the OP until post-official KSP 1.1. KSP 1.1 repack Updated CRP version Updated bundled MM version Deprecated IFS in favour of B9PartSwitch Added part search tags for parts https://github.com/ChrisAdderley/CryoEngines/releases/tag/v0.3.0

This is a test release for 1.1. It should not be considered fully operational. I will not push the AVC file or the official update links in the OP until post-official KSP 1.1. KSP 1.1 repack Updated CRP version Updated bundled MM version Deprecated IFS in favour of B9PartSwitch Added part search tags for parts In basic mode, trimodal NTRs no longer generate power when firing Fixed missing AFTER tag in LiquidFuel extra patch https://github.com/ChrisAdderley/KerbalAtomics/releases/tag/v0.2.0

Just the easy ones...

New version, with 1.1 prerelease compatibility. Only minor changes otherwise. KSP 1.1 prototype Added part search tag fields to all radiators Added VS-3750 and VS-1000 fixed heat radiators

Small update. "Official" 1.1 prerelease compatibility. Latest Changelog (2.4): KSP 1.1 version Adjusted some node connections and prerequisites from community input Fixed node cost of Experimental Nuclear Propulsion

That is about out of scope yes. It would involve quite a bunch of tracking which isn't very interesting. I did want to have rep penalties stuff at some point And yes, still working on this, but it's strictly a after-1.1-is-stable project.

You are on the right track there with PassiveEnergy. That just specifies the heat that should be generated into the core heat bucket at a given part core temperature; ie. 500 kW is generated at 0K, 1 kW is generated at 250K and 0 kW are generated at 350K (these numbers are in uh... let's call it Heat Space, where you put in the number in kW multiplied by 50, so to generate 10 kW you put 5000).

Uh, I know most/all of them, if I have some time in the next few days I might try to write up a guide.

Well, it does similar things to IFS/Firespitter, but the cfg setup is much friendlier and easier to MM.

@blowfish's part switcher kicks butt, I'm evaluating it now.

Lowest on my priority list at the moment. Will take probably 2-4 weeks to get started.

1.1 update is almost good, just putting the finishing touches on the heat animations for these guys...

The main changes that will be necessary are: a repack of DeployableEngines (done), an update for all cfgs to get tags right (not done), an update to the model/fuel switching plugins (not done, i'm probably moving away from IFS) a couple all-in tests to verify the basics (very not done).

So many struts! Must have been a bit of a bleep to unwrap!

There are necessary simplifications to reduce the computational load. Simulating many points in order to simulate a volume rapidly becomes computationally nasty.

I kinda think I'd rather do SI units than bananas, but it would be (relatively) trivial to make that a flag in the settings, and it's amusing enough that maybe it's a thing I could justify! Throw in an MM patch to make Banana For Scale a radiation emitter and you're good :P. I'm glad you like the sound of this. I hope it gets to the point where it's nice and stable, right now there are still many issues to fix up. There was some hope for useable development versions by the end of the week, but that ship seems to have sailed.

Yes, it's visible in the VAB, though some kinks need to be worked out. And yes, the tank on the right is empty. Yeah, I don't plan to do that (gets complex fast, and adds a bunch more connections to monitor), but the system would be extensible enough for that to be done later by myself or someone else. You'd just need to put a RadiationSink on the engine and write a module implementing IRadiationAbsorber to apply the effects.

Not planned at the moment, there is only one attenuation constant specified (at a medium gamma energy level). In the future this might be replaced by a floatcurve field where attenuation is specified for many energy levels, but I don't think this is massively important. In terms of modeling more radiation types, neutron radiation is imo more interesting, so I would do that first. Thanks :). I don't think this approach is better, it's just more deterministic. I already had a look actually, 'cause I was curious ;).

I think I'll probably rework the Dosimeter section to have the maximum dose displayed as a kind of progress bar, with icons representing the different statuses. Maybe something like this (excuse my ascii): ==================-------- 0.4 mSv/hr 0 Sv 20 Sv 50 Sv

I haven't really decided on units yet. I want to present something relatively easy to understand (radiation doses and fluxes can get confusing quite fast) and consistent across the board, and also be representative of approximately what you would get if you moved a kerbal towards that source.

I mocked up approximately what I want to do with the UI. What do we think?

Yup, it's a 3.75m NSWR. Everything except the approximate plumbing is totally a guess, doesn't seem to be many concepts hanging around.

Almost unwrapped the open cycle gas core, and also made this:

Yes, that's basically what I'd want. I implement a very simple system as described before that can be disabled via MM, then anyone can use these fields to do things with more complexity. Radiation exposure from the sun should indeed be attenuated by LoS. I plan on defining this more or less via a simple curve, so flux at a ship would be computed by scaling the flux at a planet's orbit by the appropriate attenuation value sampled from the curve. Curves defined per planet, and in config files for easy editing. Initial test release will just be point radiation though. I'm hoping it will add some nice design considerations for people who like to deal with the real nasty problems of all those super-fancy atomic engines!

I don't maintain the mods that use it, all I know is that colonization-style nodes were requested during initial planning. The community would have to answer that ;).