[WIP] Radioactivity - test release 0.1.1 (Sept 7, 2016)

[TiktaalikDreaming]

4 hours ago, steeeal said:

Banana scale?

No, it's all SI Sieverts.  Just take the micro-sieverts and multiply by ten for Banana Equivalent Dose Scale.  So, lowest yearly dose clearly linked to Cancer is 100mSv, which is 1MB, average yearly background radiation 40kB.  Fatal dose, regardless of treatment, 80MB.  Being on the wrong side of the shadow shield on my crazy engine, 9.5x10^10 Bananas per second.   The weight alone of all that banana would be dangerous.

[RedParadize]

Hi Nertea. So far I like it allot. I am looking foward for a full NFT FFT integration. I have two thing on my wish list: It would be cool to have tweakable Shadow shield. Like diameter and mass. It would be cool to be eable to remove it completely as well. The second thing might not come from you but a Kerbalism integration would be realy nice. The two would work realy well together I believe. One for ambiant radiation and one for local.

Anyway, nice work, as always.

[TheSaint]

Okay, I broke it. The craft in question is actually an old design of mine, I've been using one or another iteration of it for a couple of years now. But it has a Mk1-2, a science lab, four hitchikers, and a probe core for sinks, and twelve LV-Ns for sources. Only mods are KER and IFS. UI got very tweeky:

Then when I exited and reentered the VAB the overlay wouldn't come up at all. Log is here, craft file is here if you want it. 

[TiktaalikDreaming]

That reminds me, I should really test in a bar bones install.

[Nertea]

On 9/3/2016 at 9:51 PM, TiktaalikDreaming said:

I got confused and killed my output_log.  Loaded back into game, and accessed the craft already in orbit.  Similar display issues when engine was running, but the ray display just skipped drawing altogether this time.

https://www.dropbox.com/s/ewzgzpqs19x8n2m/output_log.txt?dl=0

Oh, and the config I created for my engine; 

(OuterShell is the mesh for the central radioactive source, and I matched the shield to the mesh dimensions for the shield, nice, easy to understand values, thanks Nertea)

@PART[GCnuclearEngine6kRev]:NEEDS[Radioactivity]
{
    MODULE
    {
        name = RadioactiveSource
        SourceID = OuterShell
        IconID = 0
    }
    MODULE
    {
        name = RadioactiveEngine
        SourceID = OuterShell
        EmissionAtMax = 950000
    }
    MODULE
    {
        name = RadiationShadowShield
        ShieldRadius = 10.6
        ShieldPosition = 0,5.5,0
        Density = 1.2
        Thickness = 0.4
        MassAttenuationCoeffecient = 15
    }
}

 

I'm pretty sure this is something to do with connecting the rays to the ship. I thought I was doing this correctly, but this wouldn't be the first time a KSP API field does something completely different than described :P.

On 9/3/2016 at 8:30 PM, steeeal said:

[LOG 20:24:10.165] Radioactivity > UI: Start
[LOG 20:24:10.165] Radioactivity > Editor: Starting monitor
[WRN 20:24:10.181] Radioactivity > Sink: Couldn't find Source transform, using part root transform
[WRN 20:24:10.197] Radioactivity > Source: Couldn't find Emitter transform, using part root transform
[LOG 20:24:10.197] Radioactivity > Shadow Shield: created new with position (0.0, 0.8, 0.0), radius 1.0, angular size 33.7
[LOG 20:24:10.200] Radioactivity > RadioactiveEngine: Using legacy engine module

Hope this will help

I need the actual log, guessing what part I might need doesn't help - that chunk is completely nominal :).

On 9/4/2016 at 4:05 PM, RedParadize said:

Hi Nertea. So far I like it allot. I am looking foward for a full NFT FFT integration. I have two thing on my wish list: It would be cool to have tweakable Shadow shield. Like diameter and mass. It would be cool to be eable to remove it completely as well. The second thing might not come from you but a Kerbalism integration would be realy nice. The two would work realy well together I believe. One for ambiant radiation and one for local.

Anyway, nice work, as always.

As the dimensions of the shadow shield are parameters of the model I don't want to do that. The separate shadow shield part could become tweakable though.

As for Kerbalism compatibility, I've hopefully made the database easy to understand, so anyone can build off it somewhat easily. I will be building my own model for ambient radiation as well, but I want to lock down this first, it's much harder . 

14 hours ago, TheSaint said:

Okay, I broke it. The craft in question is actually an old design of mine, I've been using one or another iteration of it for a couple of years now. But it has a Mk1-2, a science lab, four hitchikers, and a probe core for sinks, and twelve LV-Ns for sources. Only mods are KER and IFS. UI got very tweeky:

 

Then when I exited and reentered the VAB the overlay wouldn't come up at all. Log is here, craft file is here if you want it. 

Thanks for the craft file, this helped me determine that there was a UI overflow when drawing a part with very low, but not zero dose rate, so that will be fixed soon.

[Nertea]

Here is a new build. It should fix... all? most? of the bugs reported so far, notably the ray overlay disappearing if the ship is moving and the UI detonating sometimes. It still does not fix the overlay not being set up properly when a vessel loads in the VAB. 

Bugs fixes:

• Fixed rendering of overlay rays in non-static situations
• Fixed UI overflow with very small dose rates
• Fixed overlay info windows being shown in the map view
• Added placeholder Geiger Counter (thermometer) science part, which can track current and total radiation doses (resettable)
• Added placeholder Storm Cellar part, which has 85% radiation shielding but roughly 3x the mass of a standard hitchhiker

Edited September 7, 2016 by Nertea

[TiktaalikDreaming]

5 hours ago, Nertea said:

Here is a new build. It should fix... all? most? of the bugs reported so far, notably the ray overlay disappearing if the ship is moving and the UI detonating sometimes. It still does not fix the overlay not being set up properly when a vessel loads in the VAB. 

Bugs fixes:

• Fixed rendering of overlay rays in non-static situations
• Fixed UI overflow with very small dose rates
• Fixed overlay info windows being shown in the map view
• Added placeholder Geiger Counter (thermometer) science part, which can track current and total radiation doses (resettable)
• Added placeholder Storm Cellar part, which has 85% radiation shielding but roughly 3x the mass of a standard hitchhiker

And all (apparently) working.  :-)

http://imgur.com/a/p24ZP

[Nertea]

31 minutes ago, TiktaalikDreaming said:

And all (apparently) working.  :-)

http://imgur.com/a/p24ZP

Sweet!

So I've been doing a bunch of thinking about ambient radiation modeling, and I will now share my thoughts. Essentially, there are four main natural sources of radiation that make up the ambient situation. I have to deal with them all to some extent.  We have

• Solar (primarily coronal mass ejections)
• Galactic cosmic rays
• Planetary radiation belts
• Surface radiation

Solar: 

Let’s begin by not modelling solar. It’s mostly CME based, which requires a simulation of solar weather, which doesn't seem hugely interesting, or does it!

I could have a readout, with a graph, activated by a part, which would give you a nice prediction... that'd be pretty cool. Let's table it though, it would be very complex. 

GCRs: 

Ambient radiation from GCRs is more or less an omnidirectional increase in radiation flux, attenuated by the local planetary magnetic field. Anywhere in the universe, your exposure to cosmic rays is primarily a factor of your magnetic field and the amount of the sky that is not occluded by a gigantic massive planet. 

To work out the complete solution you would essentially have to raycast outwards from the part in all directions with a decently high angular density, attenuate those rays through the parts, and from that figure out the total exposure of the crew pod. Additionally, scale the total flux by the strength of the planet’s magnetic field at that point. Essentially...

If (Sv/s) = I0 (Sv/s) * tau* sum(rayIf)/nRays

• If = dose at part surface
• I0 = GCR mean dose, as from MSL (say 300 mSV/year)
• rayIf = final attenuation of ray once propagated (0-1)
• nRays = number of rays cast
• tau = attenuation scalar of magnetic field at vessel distance

This would allow full simulation of using parts to attenuate GCRs. It’s conceptually doable but adds a bunch of computations. Every time a vessel is changed or moves relative to another set of parts, the ray burst has to be recalculated for accurate simulation, which could be quite lag-inducing (though conceptually you could spread this out over a few frames and optimize it a bit). Not ideal.

I believe that a simpler model is to have each part work out the approximate visible size of the local celestial body and use that to scale the total flux from cosmic rays, as that is the main driver of cosmic ray exposure (attenuating GCRs sucks without a lot of mass). Additionally, scale the total flux by the strength of the planet’s magnetic field. This would be kinda...

If (Sv/s) = I0 (Sv/s) * ((4*pi) - Psr (steradians) )/ 4*pi * tau (scalar) 

• I0 = GCR mean dose, from MSL (say 300 mSV/year)
• If = dose at part surface
• Psr = size of planet in steradians at vessel distance
• tau = attenuation scalar of magnetic field at vessel distance

This is computationally simple so that’s great. The problem with this solution is that of course it does not take into account parts of any kind. This means that you have to rely purely on the crew pod’s shielding and the planet’s magnetic field. Another approximation might be calculating the "real" sky visibility from a part, but then that would not take into account the ray path through parts, which means it's pretty much inaccurate too. 

I’m leaning towards the second option, mainly because i’m already heavy on raycasts for the point simulation and want to save that power.

Surface radiation:

This can be bundled with GCR simulation pretty easily using the inverse of the second method, it’s easily possible to calculate the fraction of the sky that is “planet” and use that to scale the total radiation. Local radiation could easily be sampled on a per-biome basis (eve’s seas could be radioactive, for example). Seems pretty straightforward. 

If (Sv/s) = I0 (Sv/s) * ( Psr (steradians) )/ 4*pi

• I0 = dose when surrounded by the radioactive surface material 
• If = dose at part surface
• Psr = size of planet in steradians at vessel distance

Radiation belts (and magnetic fields)

This one is in the same vein as GCR. If you’re in the radiation belt, it can be assumed that the incoming radiation is omnidirectional. This can therefore piggyback off whatever GCR model is being used. The issue is how to model the seed value for the strength of the radiation belt. Typically the radiation belts are weirdly shaped depending on the magnetic field distribution of a planet (Kerbalism has good examples). What’s the value in semi-accurately shaping the magnetic fields versus modeling them with a altitude based curve? A curve can be sampled easily which makes it pretty simple. Arbitrary shapes are harder to evaluate and visualize, but could make for some interesting gameplay.

Thoughts?

 

 

[TheSaint]

Solar

I don't see where this needs to be so complex. Sure, if you're going to try to model it ultrarealistically. But if you're just going to throw random CMEs that spike the background radiation levels around certain bodies, it shouldn't be too difficult. You may offend any players who have graduate degrees in astrophysics, but I'm pretty sure that somehow you'll find the strength to carry on. You could even try modeling it as a cloud moving X direction at Y speed expanding at Z rate, etc. If you aren't going to have space weather, why do you have a storm shelter part? Just sayin'....

GCRs

The second option sounds good. Couldn't you generate a ray-casted GCR shielding value for each sink based on the current configuration of the ship, then only update it based on configuration changes (docking/undocking, staging, etc.)? It wouldn't be perfect, but it would be better. 

Surface Radiation

Hadn't even occurred to me actually. Radioactive oceans would definitely be nature's way of saying, "Keep Out". The only problem with going this direction is then you start asking questions like, "Well, what about contamination?" And then you're really stuck between "Unrealistic Simulation" or "Staggering Complexity". 

Radiation Belts

This is actually the one piece of Kerbalism that made me say, "Wow." (Not to imply that I don't like Kerbalism, I do. But everything else he has done to date has mostly been bundling functionality that was already present in other mods.) His radiation belt modeling is most impressive, and it doesn't seem to be a performance drag at all. I get the impression that you're not much of a collaborator, but ShotgunNinja has done a lot of work in this area. Having a chat with him might save you some time. 

I might have some time to test the new build tonight. If not I probably won't get to it until Friday. 

 

[Nertea]

14 minutes ago, TheSaint said:

Solar

I don't see where this needs to be so complex. Sure, if you're going to try to model it ultrarealistically. But if you're just going to throw random CMEs that spike the background radiation levels around certain bodies, it shouldn't be too difficult. You may offend any players who have graduate degrees in astrophysics, but I'm pretty sure that somehow you'll find the strength to carry on. You could even try modeling it as a cloud moving X direction at Y speed expanding at Z rate, etc. If you aren't going to have space weather, why do you have a storm shelter part? Just sayin'....

 

I think integration itself is simple, but producing an interesting gameplay experience is not. I dislike having random events with very painful consequences, but I think that there's room for something interesting here! Maybe there's a basic solar weather randomizer (deterministically driven with the KSP game seed) that produces infrequent semi-random events. Let's say there's a solar observatory part or something, and using that part brings up a prediction of solar weather for the next 60 days. Then you might create some interesting gameplay from that, build a solar observatory to get data, plan missions accordingly.

Plus there are many reasons to have a storm shelter, like having a place to hide sensitive crew during a burn, or during a radiation belt transit :). 

15 minutes ago, TheSaint said:

GCRs

The second option sounds good. Couldn't you generate a ray-casted GCR shielding value for each sink based on the current configuration of the ship, then only update it based on configuration changes (docking/undocking, staging, etc.)? It wouldn't be perfect, but it would be better. 

That's what I describe in the first option. It could be rather computationally expensive, because in the case of one ship things are ok. The list of events to listen to is low. In the case of more than one ship, the list of events is potentially quite high... consider how frequently the geometry between two nearby ships changes. With something like an absolute minimum of 16 rays needing to be cast per sink (and realistically in the 48-96 level), that would get very unpleasant fast. 

To do this I probably need to (at minimum) get a major optimization done, which is to exclude crew-containing parts that do not contain crew from the simulation. That will drastically improve the performance for many ships, particularly those that decorate with a lot of hitchikers or other usually uncrewed crewed parts. 

29 minutes ago, TheSaint said:

Surface Radiation

Hadn't even occurred to me actually. Radioactive oceans would definitely be nature's way of saying, "Keep Out". The only problem with going this direction is then you start asking questions like, "Well, what about contamination?" And then you're really stuck between "Unrealistic Simulation" or "Staggering Complexity". 

I considered contamination too! Probably not something I'm interested in doing, but really wouldn't be that hard to keep a database of all "contamination points" that is added to when you do something horrid with 100t of nuclear waste. Merely check whether you're close to one of those and work from there. 

31 minutes ago, TheSaint said:

Radiation Belts

This is actually the one piece of Kerbalism that made me say, "Wow." (Not to imply that I don't like Kerbalism, I do. But everything else he has done to date has mostly been bundling functionality that was already present in other mods.) His radiation belt modeling is most impressive, and it doesn't seem to be a performance drag at all. I get the impression that you're not much of a collaborator, but ShotgunNinja has done a lot of work in this area. Having a chat with him might save you some time. 

My reluctance to do too much collaboration comes more from time constraints than other things. When my activity is very peak-based, I don't want to commit really to joint projects and I particularly don't want to spend a large amount of effort ensuring that everything stays exactly compatible. It can be quite frustrating. 

Will probably talk to him at some point though :).  

[TheSaint]

4 hours ago, Nertea said:

I think integration itself is simple, but producing an interesting gameplay experience is not. I dislike having random events with very painful consequences, but I think that there's room for something interesting here! Maybe there's a basic solar weather randomizer (deterministically driven with the KSP game seed) that produces infrequent semi-random events. Let's say there's a solar observatory part or something, and using that part brings up a prediction of solar weather for the next 60 days. Then you might create some interesting gameplay from that, build a solar observatory to get data, plan missions accordingly.

Plus there are many reasons to have a storm shelter, like having a place to hide sensitive crew during a burn, or during a radiation belt transit :). 

That does sound more interesting. 11-year sunspot cycle? I'd just be wary of it becoming too onerous, like the game just turns into Kerbal CME-Avoidance Program.

4 hours ago, Nertea said:

That's what I describe in the first option. It could be rather computationally expensive, because in the case of one ship things are ok. The list of events to listen to is low. In the case of more than one ship, the list of events is potentially quite high... consider how frequently the geometry between two nearby ships changes. With something like an absolute minimum of 16 rays needing to be cast per sink (and realistically in the 48-96 level), that would get very unpleasant fast. 

To do this I probably need to (at minimum) get a major optimization done, which is to exclude crew-containing parts that do not contain crew from the simulation. That will drastically improve the performance for many ships, particularly those that decorate with a lot of hitchikers or other usually uncrewed crewed parts. 

I explained myself poorly. I was thinking of something halfway between the two options. Instead of calculating everything in realtime and taking into consideration everything in the entire physics bubble, it would only calculate shielding for background radiation on your ship (neglecting other objects around the ship), and it would only calculate it at each configuration change. How much time in an average KSP mission do you spend with other ships floating around you in the physics bubble? I'm pretty sure the amount of background radiation shielded by those ships in that short amount of time is negligible.

4 hours ago, Nertea said:

I considered contamination too! Probably not something I'm interested in doing, but really wouldn't be that hard to keep a database of all "contamination points" that is added to when you do something horrid with 100t of nuclear waste. Merely check whether you're close to one of those and work from there. 

I just think it would turn into an unholy nightmare of paranoia and second-guessing. (Which isn't odd, since that was what dealing with contaminated surfaces was like in real life. Dunno, maybe I'm just scarred. ) Think of it this way: Eve has radioactive oceans. Bob Kerman (not the sharpest tool in the shed) goes wading in Eve's ocean. Now Bob is covered in contamination. Now Bob is both a source and a sink. And he now transfers contamination to everything he touches. Everything he touches becomes a source. Now Bob climbs back into his capsule and contaminates the inside of his capsule. His capsule becomes a source that is dosing its occupants inside of its shielding. (Which I am guessing would be a whole new case in your code.) Now you have to come up with routines and parts for decontamination. It seems like you would spend a ton of time writing a ton of code to cover a bunch of bizarre edge cases that would only come up if people did mind-numbingly stupid things. But the alternative would be to ignore contamination entirely, so Eve's radioactive oceans somehow magically don't contaminate things that enter them. So, as I said, "Unrealistic Simulation" or "Staggering Complexity". The idea of surface radiation is sort of intriguing, but out of everything here I would put it furthest to the rear.

4 hours ago, Nertea said:

My reluctance to do too much collaboration comes more from time constraints than other things. When my activity is very peak-based, I don't want to commit really to joint projects and I particularly don't want to spend a large amount of effort ensuring that everything stays exactly compatible. It can be quite frustrating. 

Will probably talk to him at some point though :).  

Well, I wasn't really thinking about interoperability or compatibility. I was just thinking that if you looked at his code and picked his brain for a bit it might save you some time and heartache when it came time to write your own radiation belt module.

[TheSaint]

I messed around with the new build a bit. Works pretty good, couldn't break it. I did find one nit pick. After a couple of burns and scene changes with a live ship I lost the shadow shields in the overlay view:

Log is here. I added some additional mods, mostly for missing information and so the stock graphics wouldn't make my eyes bleed while i was flying around.

Edit: Was thinking about this after I went to bed. The exposures on that ship just seem crazy low. Am I that good at shielding my Kerbals? At one point I sent Bob back to take a nap in one of the Hitchhikers during a 1,000 m/s burn, and all he got was one mSv. Maybe if I have time this weekend I'll try something a little more crazy, like a 1-2 pod, a pancake tank, and an LV-N. 

I did send Bob back to inspect the engines then fired them up to test the instadeath. He died instantly. But it's okay, it was for science. 

One other minor thing: The exposure numbers are a bit confusing. I'm a ginormous science nerd, and even I'm having to go google the difference between a ySv and a pSv when they come up on the displays. But I know that both of those are basically negligible amounts of radiation. Maybe have a symbol for a negligible amount of radiation until it gets up to some arbitrary amount, like mSv or something? 

Edited September 8, 2016 by TheSaint
More thoughts

[Nertea]

18 hours ago, TheSaint said:

That does sound more interesting. 11-year sunspot cycle? I'd just be wary of it becoming too onerous, like the game just turns into Kerbal CME-Avoidance Program.

Yeah it's a balance for sure. That'd be why I'm not touching it yet

18 hours ago, TheSaint said:

I explained myself poorly. I was thinking of something halfway between the two options. Instead of calculating everything in realtime and taking into consideration everything in the entire physics bubble, it would only calculate shielding for background radiation on your ship (neglecting other objects around the ship), and it would only calculate it at each configuration change. How much time in an average KSP mission do you spend with other ships floating around you in the physics bubble? I'm pretty sure the amount of background radiation shielded by those ships in that short amount of time is negligible.

Ah I see. Yes that would decrease the amount of 'casting needed. However, you'd still need to do complex updating in a few cases, ie individual kerbals on EVA. I'm going to implement the simplified method first then move on to the more complex implementation if need be. 

18 hours ago, TheSaint said:

I just think it would turn into an unholy nightmare of paranoia and second-guessing. (Which isn't odd, since that was what dealing with contaminated surfaces was like in real life. Dunno, maybe I'm just scarred. ) Think of it this way: Eve has radioactive oceans. Bob Kerman (not the sharpest tool in the shed) goes wading in Eve's ocean. Now Bob is covered in contamination. Now Bob is both a source and a sink. And he now transfers contamination to everything he touches. Everything he touches becomes a source. Now Bob climbs back into his capsule and contaminates the inside of his capsule. His capsule becomes a source that is dosing its occupants inside of its shielding. (Which I am guessing would be a whole new case in your code.) Now you have to come up with routines and parts for decontamination. It seems like you would spend a ton of time writing a ton of code to cover a bunch of bizarre edge cases that would only come up if people did mind-numbingly stupid things. But the alternative would be to ignore contamination entirely, so Eve's radioactive oceans somehow magically don't contaminate things that enter them. So, as I said, "Unrealistic Simulation" or "Staggering Complexity". The idea of surface radiation is sort of intriguing, but out of everything here I would put it furthest to the rea

Ah. Reminds me of the stuff with the Ymir in Seveneves, if you've read that :P. I was just thinking of something that caused virtual surface contamination via biome-like maps. 

18 hours ago, TheSaint said:

Well, I wasn't really thinking about interoperability or compatibility. I was just thinking that if you looked at his code and picked his brain for a bit it might save you some time and heartache when it came time to write your own radiation belt module.

I came up with some crazy simple math model on the bus and knocked it out in Python at work

I was way overthinking it :P. Visualizing this will be fiddly, but I have some ideas on that front too.

17 hours ago, TheSaint said:

Edit: Was thinking about this after I went to bed. The exposures on that ship just seem crazy low. Am I that good at shielding my Kerbals? At one point I sent Bob back to take a nap in one of the Hitchhikers during a 1,000 m/s burn, and all he got was one mSv. Maybe if I have time this weekend I'll try something a little more crazy, like a 1-2 pod, a pancake tank, and an LV-N. 

I did send Bob back to inspect the engines then fired them up to test the instadeath. He died instantly. But it's okay, it was for science. 

One other minor thing: The exposure numbers are a bit confusing. I'm a ginormous science nerd, and even I'm having to go google the difference between a ySv and a pSv when they come up on the displays. But I know that both of those are basically negligible amounts of radiation. Maybe have a symbol for a negligible amount of radiation until it gets up to some arbitrary amount, like mSv or something? 

I've noticed that attenuation seems a bit strong sometimes. I have done some excel math to test things in simple situations so they seem to match up, but nothing hugely complex. It might be true, to some extent, because KSP objects are so dense (if that is the case, we can arbitrarily reduce the standard attenuation constant), but it could also point to some problems. I'll have to do some testing to be more sure. If you make a ship (simple as possible, please) that has something that looks odd going on, please send me a log and the craft, I'll try to manually calculate the attenuation paths. 

The small exposure numbers are going to get a time-shift - below 1 mSv/s or something they'll change to minutes, then hours, then days. 

[TheSaint]

42 minutes ago, Nertea said:

Ah. Reminds me of the stuff with the Ymir in Seveneves, if you've read that :P. I was just thinking of something that caused virtual surface contamination via biome-like maps. 

Oh, been a huge Stephenson fan for years. All those scenes in Seveneves hit a little close to home. A reactor accident in that tight of quarters would be the stuff that horror movies are made of. 

But if you were going to go with a surface biome, you'd either have to explain why the biome was radioactive while its surface dust wasn't, or you'd be in exactly the same boat.

42 minutes ago, Nertea said:

I've noticed that attenuation seems a bit strong sometimes. I have done some excel math to test things in simple situations so they seem to match up, but nothing hugely complex. It might be true, to some extent, because KSP objects are so dense (if that is the case, we can arbitrarily reduce the standard attenuation constant), but it could also point to some problems. I'll have to do some testing to be more sure. If you make a ship (simple as possible, please) that has something that looks odd going on, please send me a log and the craft, I'll try to manually calculate the attenuation paths. 

Not really raising a flag, I guess. If the math checks out, then the math checks out. It just seemed weird that it would go from kSv to ySv in such a seemingly short distance. Although, now that I think about it, doses on the boat went from thousands of REM inside the RC to micro-REM on the outside of the secondary shield in just ten or fifteen yards, so I guess anything is possible. But there was a lot of shielding involved there too.

I'm not going to have a lot of time for games tonight, but I'll try some not-so-logical designs tomorrow night and see what churns out.

42 minutes ago, Nertea said:

The small exposure numbers are going to get a time-shift - below 1 mSv/s or something they'll change to minutes, then hours, then days. 

See, that's why you get paid the big bucks!

[TiktaalikDreaming]

On 9/8/2016 at 4:48 PM, TheSaint said:

Maybe if I have time this weekend I'll try something a little more crazy, like a 1-2 pod, a pancake tank, and an LV-N.

 

I was flying about with heaps of extra power for running my radiators when the engine was stopped and thought "RTG".  I just need to get some numbers on KSP scale RTGs to feed into the "are my kerbals cooked?" simulation....

 

Or not.  Radiation dosage from the average RTG pretty much requires vapourizing them (which is extremely difficult) and then inhaling the plutonium.  Pretty much all alpha decay, which you can stop with a decent sheet of paper.

Stupid, someone should be locked up for it, design it is then.  :-)

Also, mobile browsers plus posting on the ksp forums sucks mules. 

Spoiler

EDIT: Corrected nested spoiler of nothing from desktop

 

 

Edited September 9, 2016 by TiktaalikDreaming

[TiktaalikDreaming]

OK, just for the purpose of seeing if it would handle lots of sources, I configured RTGs as basic sources with no radiation.  Lots of lines.  No further radiation, but a lot more interaction.

 

And, I built a fairly daft, short fat craft.  And still my kerbanauts were OK.  But, not when staging away from the section with the nuclear thermal engine.  Line of sight, even at a goodly distance, and my kerbanauts weren't doing so well.  To achieve that though, the NTR's throttle was still at max, but the propellant was exhausted.  So, it's "running", but not going anywhere.

[TheSaint]

Another thing occurred to me this morning. One last bit of serious unrealism in your simulation: When you turn the engines off, the radiation drops to zero. Oh, if only that were true.  (It would have made maintenance periods on the boat so much easier.) Any plans for tapering/lingering radiation from shutdown reactors/engines? 

[Nertea]

5 hours ago, TiktaalikDreaming said:

OK, just for the purpose of seeing if it would handle lots of sources, I configured RTGs as basic sources with no radiation.  Lots of lines.  No further radiation, but a lot more interaction.

And, I built a fairly daft, short fat craft.  And still my kerbanauts were OK.  But, not when staging away from the section with the nuclear thermal engine.  Line of sight, even at a goodly distance, and my kerbanauts weren't doing so well.  To achieve that though, the NTR's throttle was still at max, but the propellant was exhausted.  So, it's "running", but not going anywhere.

 

So uh, how was the performance with that? :P.

1 hour ago, TheSaint said:

Another thing occurred to me this morning. One last bit of serious unrealism in your simulation: When you turn the engines off, the radiation drops to zero. Oh, if only that were true.  (It would have made maintenance periods on the boat so much easier.) Any plans for tapering/lingering radiation from shutdown reactors/engines? 

Just like a stock system, the basic system is simplistic. There is an undocumented, untested module called RadioactiveConstantSource which does more or less what it says on the can. There's also an undocumented, untested parameter in RadioactiveEngine called EmissionDecayRate and EmissionMinimum which are supposed to specify the rate at which emission decays and the minimum emission from an activated engine. Looking at the code it's not fully implemented but I'll make sure to include that in the next build.

Incidentally, the next build will probably be the last 1.1.3 build as I start targeting the 1.2 experimentals. 

[TiktaalikDreaming]

3 hours ago, Nertea said:

So uh, how was the performance with that? :P.

Performance was actually OK.  Ability to make out which lines were which was minimal, but it seemed to draw it all at a reasonable rate.  I really should get in the habit of displaying frame rates etc when testing this sort of thing.  But it "seemed" fine.  :-)
 

Quote

 

Just like a stock system, the basic system is simplistic. There is an undocumented, untested module called RadioactiveConstantSource which does more or less what it says on the can. There's also an undocumented, untested parameter in RadioactiveEngine called EmissionDecayRate and EmissionMinimum which are supposed to specify the rate at which emission decays and the minimum emission from an activated engine. Looking at the code it's not fully implemented but I'll make sure to include that in the next build.

Incidentally, the next build will probably be the last 1.1.3 build as I start targeting the 1.2 experimentals. 

 

I think you can keep making this more detailed for ever and never get it perfect.  But a simple base-line for zero throttle would work fine for most situations.

I really should get off my cheeks and learn C#.  I have that Orion mod to maintain, and it hasn't worked properly since 0.25, or at all since 1.0.5, and it'd make for some pretty awfully hilarious (or hilariously awful) interactions with this.  The fission rate may exceed the norm for NTRs.  But then the shielding may exceed the norm as well.  It'll be vitally important to get your kerbals into the storm cellar before lighting the engine. But the zero throttle emission should be fairly low.

[Nertea]

Made a quick model yesterday that seemed like it went very well!

 

[TheSaint]

The weekend was koo-koo crazy-nuts, so I had no chance to even fire my computer up. I do have some time tonight though. For future reference, this is a very ill-advised vehicle design:

[TheSaint]

So I did get more testing done last night, all sorts of unwise spacecraft designs. (Sorry, no screenshots, Thing #2 had a bad dream and by the time we got him settled again it was time for bed.) I even did one of those tractor designs that everyone seems to love that always make me cringe when I see them. Dose rates were about what I expected to see, and everyone died like good little guinea pigs. No crashes, nothing unexpected. It all looks good.

[lajoswinkler]

@Nertea If I had any decision making authorities at Squad, I'd hire you immediately. You are one of the rare modders that made a significant contribution to the game. There, it had to be said. This idea you're working on will make realistic designs (putting fission engines on basically long sticks away from the important payload) possible.

 

Now, on topic. Have you considered simulating skyshine in atmospheres?

Your raycast model works fine in vacuum, but it's almost completely unrealistic in atmosphere. Don't get me wrong, I'm not pooping on your work, this is just constructive criticism. Skyshine would pose incredible problems to activating nuclear engines and power producing reactors in vicinity of radiation sinks such as Kerbals, probes and instruments. It would effectively destroy the chances of manned flight of fission powered atmospheric vehicles, unless we're talking about those insane big and heavy aeroplane designs of the 50s and 60s. (here's an idea for nutty designs with superheavy payloads)

It can be reasonably simplified by ignoring the radiation shielding of anything and just using the inverse square law from the point of origin to the sink. Actually it is less complicated because of this.

It could be modified by following the atmospheric pressure - the lower the pressure, the greater the bubble of skyshine. Outside the atmosphere, modelling switches from unobstructed raycast to raycast with shadows.

 

(IMO, distinction between neutron, gamma, beta and bremsstrahlung is unnecessary and overly complicated.)

[Nertea]

On 10/15/2016 at 6:22 AM, lajoswinkler said:

@Nertea If I had any decision making authorities at Squad, I'd hire you immediately. You are one of the rare modders that made a significant contribution to the game. There, it had to be said. This idea you're working on will make realistic designs (putting fission engines on basically long sticks away from the important payload) possible.

 

Now, on topic. Have you considered simulating skyshine in atmospheres?

Your raycast model works fine in vacuum, but it's almost completely unrealistic in atmosphere. Don't get me wrong, I'm not pooping on your work, this is just constructive criticism. Skyshine would pose incredible problems to activating nuclear engines and power producing reactors in vicinity of radiation sinks such as Kerbals, probes and instruments. It would effectively destroy the chances of manned flight of fission powered atmospheric vehicles, unless we're talking about those insane big and heavy aeroplane designs of the 50s and 60s. (here's an idea for nutty designs with superheavy payloads)

It can be reasonably simplified by ignoring the radiation shielding of anything and just using the inverse square law from the point of origin to the sink. Actually it is less complicated because of this.

It could be modified by following the atmospheric pressure - the lower the pressure, the greater the bubble of skyshine. Outside the atmosphere, modelling switches from unobstructed raycast to raycast with shadows.

 

(IMO, distinction between neutron, gamma, beta and bremsstrahlung is unnecessary and overly complicated.)

Aw shucks, but I already have a dayjob

I have considered skyshine, and that's a good idea for how to do it, but I need to work on how to present that information to the player, and I would rather spend my dev-time-dollars (which are pretty rare) improving the space side first, because I really do prefer working in space in general ;). 

[Probus]

Awesome idea @Nertea!  Now whose making the radiation shields mod?  

OOOH...  Can things glow green when they start getting high doses of radiation?

Edited October 17, 2016 by Probus