Nertea

Thanks! The only way this is going to get release-forum-ready is if I get some solid testing done, so it is much appreciated :).

Talk to TweakScale people. I don't really... like... tweakscale but support is easy enough for them/you to add, I think.

Yes that's something I've been meaning to do for a while, ever since I switch to a part switch module that allowed that without causing some problems.

Let's... see how this goes? I've written up a wiki type thing for documentation and tutorials. Do not use this on a save you really care about. It might kill your Kerbals. 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. Reproduction steps 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, first test release!

Minor update: Balance tweaks to NTRs Added some model features and patches for Radioactivity dev Fixed an issue with cryogenic boiloff never turning off if cooling failed

Small update: Fixed bug that caused propellant to keep boiling off even if power was restored

I'll remember to quote that next time someone complains about me changing a part name and breaking stuff :P. It's always about simplifying naming schemes.

That'd be it then

I think you would have to change engines. Even if the flameout percentage is zero, the engine will still run out of "fuel" (IntakeAir) if it isn't present. As far as I know, the flameout percentage is there purely to keep flameouts symmetric.

Logically if you have HeatControl present I don't think NEEDSHeatControl] is needed (:P), but I'm not an MM expert, might not make any difference. I'm definitely not doing anything weird though. You might want to post your patch, to have a look, or possibly post in the MM thread, you would be more likely to find such a wizard there.

Slowly squashing bugs and fixing edge cases. There are still some but we're coming close to a point where the NREs are manageable for a test release. Here's some VAB shots, with new overlay UI. The connector is a placeholder radiation shield made of "lead" - ie, the proper attenuation constant and high density. Works pretty well.

I'd be kidding if I said the jet engine stats from Mark IV were balanced by any kind of logic :P, so I can't speak to atmosphere beyond "play around with numbers". KA is mostly balanced as follows: take RL engine, add 10% Isp if LH2, match TWR to "tech level" of the engine, where LV-N = 0, determine approximate desired thrust (based off diameter, mostly) and work back from that to get mass. There isn't a huge amount of math or equations involved there, so I'd just start with something you like and reduce if too easy, increase if too hard.

Bug in RealPlume, evidently. Someone probably put @description = blabla instead of @description += blabla

Probably not, but the interface should be open enough that there wouldn't be any trouble adding such a module.

I wouldn't recommend using a heavily beta mod in your nice career yet :P. I make no stability promises. Glad you enjoy it. This mod doesn't model ramifications. There is a plugin that I am kinda working on as part of Radioactivity that generalizes ingame areas as "sensitive" and gives you a reputation penalty per second when running the engine there. So you use your 7 NSWRs to lift off and you no longer have any reputation as a space program. That's more or less the extent to which I aim to deal with this. I have given it a thermal emission that more or less corresponds to a 99.95% efficient nozzle (hah). That means that you do need quite a large stack of radiators to make it work. Easily customizable if you feel like you need to have more... The last one is more of an open question because Radioactivity is a gameplay mod with no balance specifications yet. The idea will be to first balance it to work with stock parts then start extending things in a logical way. The answer to that last question though is pretty easy to tell. Assume some given dose rate at the surface of the engine, then apply the concepts in the Radioactivity document (https://github.com/ChrisAdderley/Radioactivity/wiki/Attenuation-Concept) to discover the attenuation that's needed. They should match up pretty well.

Made some more progress yesterday: Instruments now take a science penalty depending on the dose rate they're exposed to. This is configurable based on the instrument so some (gravimeter) might be very sensitive, others (goo experiment) might not be as sensitive Drone cores now take a computational penalty depending on the dose rate they're exposed to. Higher dose rates reduce SAS level by some number. Configurable to simulate rad-hardened electronics. In-part shadow shields are implemented as a PartModule, in which is specified the position and geometry of the shield (location, facing, radius) and its parameters (thickness, density, attenuation constant). All shields are modeled as cylinders (this seems a valid assumption) and the positional data is converted into the appropriate angular data at runtime. All rays cast through the angular volume defined by the shield will be pre-attenuated by the shield's parameters. This should cover all the scenarios I can think of. Got a better UI paradigm running, much easier to interpret and read Bunch more tweaks to how exposure works Optimization

Indeed, we need to strike a balance between precise realism and gameplay ease. Though do consider.... if engine A produces 1 instadeath of radiation at its surface and engine B produces 10 instadeaths, that does have consequences in terms of attenuation. So engine B will be much more lethal at longer distances. It starts getting icky when you talk about probe cores and instrumentation that should be measured in Grays. Yeah, but we have to do some simplification for gameplay purposes, and I don't like probabilities, i prefer deterministic systems :P. When I started thinking about this, I was all for considering acute sickness, long term damage, etc. It got messy real quick. Seems best to just track a total dose with simplistic mechanics, and have them be easy to disable if another mod wants to piggyback and extent. That's be good to see some ships. The balance I want to strike is that it would be a valid design option to build a long, spindly ship with a small shadow shield or a denser ship with a lot of mass for shielding. I want to calibrate numbers so that the length required to do distance attenuation doesn't run too hard into the "long ksp ships are crazy wobbly" problem. In Nertea-land, LF is kerosense, but I think NathanKell said it was some sort of storable biprop. Currently Radioactivity assumes everything is aluminum in terms of attenuation constant (:P), because apparently for gamma, using mass attenuation constants, the great majority of materials are similar for 'average' gamma energies. That means attenuation is more proportional to the total mass between source and sink, which lets me get away with not tracking attenuation constants for everything ;). That being said, I have a PartModule you can add to a part to tell the system that it's made of a different attenuation constant carrying material if this ends up failing in practice. To some extent I'd follow what the models look like - all my FFT engines have pretty well-defined shadow shields in the model, and most of my NFE reactors do too. Come to think of it, so do the KA models (it's just textured differently). Knowing that, those parts will all probably have moderately effective shadow shields :P. Something in the range of "this shield, plus 20m, will protect your Kerbals well enough".

Well so I have the following stuff pretty much working now! Persistent radiation exposure tracking for kerbals Full emitter/sink simulation in both the VAB and flight A roster UI that is almost competent A overlay UI that is terrible and not very useful Functional emitter modules for radioactive engines and radioactive resources Functional sink modules for crew containers, generic rad tracking What still remains: Catchup/background processing of radiation exposure Shadow shields inside parts Redo the overlay UI to be better and more useful Many tweaks to exposure and sink functionality Emitter modules for other things (NFE reactors) Sink modules for probe cores, science instruments Placeholder parts for radiation shields, geiger counters I've also normalized units on Sv for everything. Not the most valid assumption but I have to simplify. The thing I need to start thinking about is plugging values into things so I can start calibrating stuff for balance. I'd like to open the floor to any input from people here. I've established a few general constants that seem like they will make sense Threshold for radiation sickness: 2 Sv total Threshold for radiation death: 10 Sv total Heal rate for radiation damage on-mission: 0.1 Sv per year Heal rate for radiation damage at KSC: 5 Sv per year Some starter questions: What should be the dose rate for an unshielded Kerbal beside a reactor when it's running (like an LV-N)? Should the kerbal die instantly (given death at 10Sv that would be more than 10 Sv/s) What does a reasonable ship using this mod look like? Given the limitations of KSP in terms of part rigidity and such, this is important to calibrate the absorptivity of parts What kind of mass penalties occur when adding radiation shadow shields? What parts have integrated shadow shields? Lastly, I did make another plugin which is separate from Radioactivity called GlowingReputation, which in a simple aspect supports Radioactivity by introducing reputation penalties for destroying radioactive parts in sensitive environments, and reputation penalties for operating certain engines in sensitive environments. This is almost ready for testing too.

Works like a charm, thanks guys!

I have a few times asked for help, but everybody who can model IVAs to any kind of skill that I'd like has a nice stack of their own projects, as far as I know. It's the modeling. Prop placement is pretty trivial and while boring, isn't frustrating like this.

The complexity derives from the need to update more than one mod if some component changes - eg when I change a value for LH2 tanks, I need to update CryoEngines and KerbalAtomics. Splitting out more stuff into more GameData root folders does make it easier to create zips, but doesn't really stop the main pain point. I will probably try something clever with the lithium tanks. Completely separate, but complementary

You can use ModuleAeroReentry iirc: https://github.com/ChrisAdderley/NearFutureElectrical/blob/master/GameData/NearFutureElectrical/Patches/NFElectricalDRE.cfg

I'd like to access some part drag cube parameters in the VAB to show things to the player. Specifically I'm looking for: part.DragCubes.WeightedSize part.DragCubes.WeightedArea However, these two fields are only populated in flight. Can these be force-calculated in the editor, or does anyone understand how I might go about calculating them manually? Might need to page @NathanKell here, I expect he knows the most...

I hate IVAs with a raw and unending passion. I'll make those tweaks to the electric fans, but don't hold your breath for the other two ;).

Just increase the Isp by 50%, that should do what you want :). I would leave it to Kerbalism to do that, as last I checked, Kerbalism messes around with a lot of balance-related things that I'm not comfortable supporting. Alternately, the one that @TheSaint made there seems good!