KwirkyJ

[1.1.3] JDiminishingRTG v1.4.0 : Realistic, configurable radioisotope decay! [8 Jul 2016]

Recommended Posts

So what is the decay rate of the RTG? Voyagers RTG is about dead as in a few years the thermocouples will have decayed and the radioactive mass will have decayed enough to reduce voltages to below usable levels. How long can an RTG in game last using this mod?

Share this post


Link to post
Share on other sites
So what is the decay rate of the RTG?

The decay rate is 2^(-t/halflife), where halflife depends on the value given for the resource. It will last indefinitely, but with increasingly diminishing output. As there are more than one fuel type, your power requirements vary, heat gradients can vary, and the mod itself allows extensive reconfiguration (both in-game and in the configuration files), it is difficult to say. With a few assumptions made, the most long-lived provided isotope can power a probe core for at least seven years -- this is being made by recognizance more than anything else, as I am at the wrong computer and 1.3 overhauled the internal logic significantly, so don't take it as holy writ...

It is also worth nothing that the thermocouples themselves do not have modeled degradation, but that is a rather minor concern at the time being.

(at the risk of sounding dismissive, just give it a try)

Share this post


Link to post
Share on other sites
The decay rate is 2^(-t/halflife), where halflife depends on the value given for the resource. It will last indefinitely, but with increasingly diminishing output. As there are more than one fuel type, your power requirements vary, heat gradients can vary, and the mod itself allows extensive reconfiguration (both in-game and in the configuration files), it is difficult to say. With a few assumptions made, the most long-lived provided isotope can power a probe core for at least seven years -- this is being made by recognizance more than anything else, as I am at the wrong computer and 1.3 overhauled the internal logic significantly, so don't take it as holy writ...

It is also worth nothing that the thermocouples themselves do not have modeled degradation, but that is a rather minor concern at the time being.

(at the risk of sounding dismissive, just give it a try)

I will think on it as I do not typically use RTG's. But for you a small chart would be good to show in the OP depletion over time of the resources. There is not a lot of date concerning the mod so making an informed choice is hard. Like if the RTG will die in a month, year, 10 years game time...etc.

Share this post


Link to post
Share on other sites
I will think on it as I do not typically use RTG's. But for you a small chart would be good to show in the OP depletion over time of the resources. There is not a lot of date concerning the mod so making an informed choice is hard. Like if the RTG will die in a month, year, 10 years game time...etc.

Agreed, I should put one up now that I've settled somewhat on the (fictional) isotope values. Soon™…

- - - Updated - - -

Released hotfix for 1.3 (to 1.3a) so things should work properly now.

(So ashamed that I missed it; what I get for doing five things at once.)

Share this post


Link to post
Share on other sites

Interesting... Even though you can never have enough realism in your game, I would like to know - how can you preserve power in long periods of time? Lets say, for example, that I want to make an Urlum excursion, a trip that can take decades and has minimal access to solar power. Seeing that there is no way to throttle the RTG, or refuel it in any way (maybe worth a specialized part?), how am I supposed to provide charge -apart from getting a dozen or so RTGs and hope that each will compensate for the half life of the other.

Share this post


Link to post
Share on other sites
Even though you can never have enough realism in your game, I would like to know - how can you preserve power in long periods of time? Lets say, for example, that I want to make an Urlum excursion, a trip that can take decades and has minimal access to solar power.

This mod seems to be balanced to stock solar system. 6 years half life is enough to make anything reasonable (except maybe grand tours by using gravity assists). I hope also that there would be some long living element for planet mods. For example with half life of 20-30 years. It could be in larger and heavier unit (is it easy to scale the current model?).

What is purpose of kyandere and krontium? They are short lived and low powered. Are they cheap and KSP calculates the price wrong?

Share this post


Link to post
Share on other sites
Interesting... Even though you can never have enough realism in your game, I would like to know - how can you preserve power in long periods of time? Lets say, for example, that I want to make an Urlum excursion, a trip that can take decades and has minimal access to solar power. Seeing that there is no way to throttle the RTG, or refuel it in any way (maybe worth a specialized part?), how am I supposed to provide charge -apart from getting a dozen or so RTGs and hope that each will compensate for the half life of the other.

Hannu has partly answered this (and I will respond to that aspect) below, but the short of it is that it is balanced somewhat for KSP's system. That said, a single Kuudite generator will keep a larger probe core running, with its 0.5Ec/min requirement, past twenty-five years of mission time. RTGs cannot be throttled due to their nature: they generate energy by the decay of the radioisotope element in store -- unless you can change the laws of physics, you're stuck with the one curve. In theory, a device could be refueled, but the other side is 'what's the point, it's so radioactively hot... just replace the unit.'

(If you want to check my math, taken from the graph in original post: solve for x ---> 7 * 1.464 * 2^(-x/6.33) = 0.5 )

This mod seems to be balanced to stock solar system. 6 years half life is enough to make anything reasonable (except maybe grand tours by using gravity assists). I hope also that there would be some long living element for planet mods. For example with half life of 20-30 years. It could be in larger and heavier unit (is it easy to scale the current model?).

What is purpose of kyandere and krontium? They are short lived and low powered. Are they cheap and KSP calculates the price wrong?

The short answer is that the resources are based on real-world isotopes of the same number (strontium90, for example) balanced roughly for KSP (similarly, Kyandere is an analog for Polonium210). In terms of gameplay, Krontium is a bit lighter and Kyandere provides a lot of energy albeit briefly -- a single unit provides 1.8Ec/sec at launch. And yes, I think it was noted in 'known issues' that the cost mechanic is broken at Squad's end, in that the part's cost is fixed at being 'full,' rather than adding cost with additional resources; while this could be remedied within the scope of this mod, I assert that it should be their business to correct this faulty mechanic. The resource mass and cost are factored into the game at the gamedatabase level, so all the pieces are present (and, in fact, the mass is being calculated properly for the readout when switching configs, as well as being important for the calculation of output). If you are concerned about being stuck with one RTG model unit and its volume, all the necessary components are present and documented in the readme and configs, and I will refer you to them for editing things to your preference.

Share this post


Link to post
Share on other sites

Yeah, I totally agree with the throttling mechanic -or lack thereof -of RTGs. But seeing as all mounted RTGs start working from launch and never stop, Mission time is to heavily dependent on the number and type of RTGS mounted. A way to disable and reenable RTGs, or to store unused ones, or get the capability to be refueled (which is not worth it in Earth, as you mentioned, but might be useful in deep space -9-), will give them much more capabilities. Will, if it's not possible, I can get myself a workaround ;store unused RTGs in KIS containers, and possibly leave spent cartridges floating in space.

Share this post


Link to post
Share on other sites
A way to disable and reenable RTGs, or to store unused ones

Disabling an RTG makes no sense from a nuclear physics standpoint. There's no off switch on the elements used as RTG "fuel" - they start decay the moment they're synthesized, likely in the core of a nuclear reactor.

If you want something with an off switch, try a reactor instead.

Edited by billkerbinsky

Share this post


Link to post
Share on other sites
Yeah, I totally agree with the throttling mechanic -or lack thereof -of RTGs. But seeing as all mounted RTGs start working from launch and never stop, Mission time is to heavily dependent on the number and type of RTGS mounted. A way to disable and reenable RTGs, or to store unused ones, or get the capability to be refueled (which is not worth it in Earth, as you mentioned, but might be useful in deep space -9-), will give them much more capabilities. Will, if it's not possible, I can get myself a workaround ;store unused RTGs in KIS containers, and possibly leave spent cartridges floating in space.

You seem fixated on 'mission time,' so I will address that first:

Your options include:

  1. Don't use this mod. By nature and design, it limits mission time. The stock RTG works perfectly well for infinite low-level energy, or
  2. Use another mod, such as a NearFuture Electrical (which is nearing updated release at last check); it has its own decay mechanics, but might have a toggle that you are looking for, or
  3. Go into the provided config files (JDiminishingRTG/RTGFuelConfigs.cfg) and change the half-lives of the isotopes to suit your preference.

I've not used KIS, so I cannot say whether or not storing an RTG at launch or during flight will have the effect you desire.

TECHNICAL STUFF YOU SHOULD PROBABLY READ BUT CAN GET BY WITHOUT

RTG is an acronym that stands for Radioisotope Thermoelectric Generator. This means that it is a device that utilizes the heat from decaying radiological isotopes to do work… in this case, generate electricity. While many possible means for generating the heat exist, in this instance it is relying on decaying isotopes… an activity governed by the weak and strong nuclear forces. For all intents and purposes, that radiological decay will take place forever at a more-or-less known rate (for each isotope), whether or not any meaningful work is extracted from it. (protip: this is probably why the Earth has a hot interior, and all that comes with it.) It is for this reason that a toggle on an RTG has no effect on available power in the future, excepting possible degradation of the mechanism that converts the heat to electricity, which is not modeled in JDiminishingRTG and is a separate issue entirely.

All that being said, you can compute exactly how long your RTGs will supply a craft with sufficient electric charge to be operable with simple[1] math. In the VAB, the 'more info' tab for the RTG tells you the isotopes' half-lives, and output at time of launch is provided in the right-click menu for the part when added (along with fuel setup toggles). By solving a*c*2^(-t/q) = n for t[2], where a is initial output, c is the number of RTGs, q is the isotope half-life, and n is the minimum power requirement (e.g., 3.0 for a single RC-001S), you find the time in years that one RTG will keep the craft alive.

[1] Algebra, made messy only by the exponential bits.

[2] I advise letting wolfram alpha do this for you, as the approximate form by hand comes out with imaginary numbers and other such nastiness.

If this has somehow failed to address your concerns, please think carefully on exactly what is irking you and respond as precisely as you can.

Share this post


Link to post
Share on other sites

Hi, I work on a mod that implements processing / resource handling for parts in unloaded vessels. Someone just asked me whether or not your RTG mod has nasty interactions with mine, so I had a quick squiz at your source code to try and figure out what was likely to go wrong. I can't quite figure out what your module does in the background, though. From what I can see, the forced part activation in OnStart() for flight scene is what's there - which presumably allows for RTG output to fall over time by getting you FixedUpdates but doesn't allow you to actually generate ElectricCharge for unloaded vessels. Am I right in assuming that's what's going on? Thanks.

If it is that, incidentally, I know about this neat mod for background processing on parts you might find useful to support... :P

Share this post


Link to post
Share on other sites
Hi, I work on a mod that implements processing / resource handling for parts in unloaded vessels. Someone just asked me whether or not your RTG mod has nasty interactions with mine, so I had a quick squiz at your source code to try and figure out what was likely to go wrong. I can't quite figure out what your module does in the background, though. From what I can see, the forced part activation in OnStart() for flight scene is what's there - which presumably allows for RTG output to fall over time by getting you FixedUpdates but doesn't allow you to actually generate ElectricCharge for unloaded vessels. Am I right in assuming that's what's going on? Thanks.

If it is that, incidentally, I know about this neat mod for background processing on parts you might find useful to support... :P

My working understanding of FixedUpdate is that it is only called if the part is active, that is why it is forced to activate during OnStart (if in flight scene)…

As for operation itself, it should be fairly straightforward: for each physics frame (call onFixedUpdate): if we haven't taken the time, we take the time as our starting point (say, t0); find out how much time has elapsed since t0 (t_elapsed); adjust the amount of the isotope fuel based on t_elapsed; generate output of heat and electricity -- if applicable -- based on the fuel/isotope present in the part; finally, tweak the mass of the part so it doesn't become lighter as the isotope decays (though this call should probably be in updateRTGFuelAmount, upon reflection, not that it is hurting anything where it is…).

As the important aspect of operation -- generating electricity -- is governed by the call to onFixedUpdate, I suspect that determining whether this is called on unloaded craft (and forcing it to be called if not) is the crux of your issue here.

Share this post


Link to post
Share on other sites
My working understanding of FixedUpdate is that it is only called if the part is active, that is why it is forced to activate during OnStart (if in flight scene)…

As for operation itself, it should be fairly straightforward: for each physics frame (call onFixedUpdate): if we haven't taken the time, we take the time as our starting point (say, t0); find out how much time has elapsed since t0 (t_elapsed); adjust the amount of the isotope fuel based on t_elapsed; generate output of heat and electricity -- if applicable -- based on the fuel/isotope present in the part; finally, tweak the mass of the part so it doesn't become lighter as the isotope decays (though this call should probably be in updateRTGFuelAmount, upon reflection, not that it is hurting anything where it is…).

As the important aspect of operation -- generating electricity -- is governed by the call to onFixedUpdate, I suspect that determining whether this is called on unloaded craft (and forcing it to be called if not) is the crux of your issue here.

In unloaded vessels parts/partmodules don't actually exist - they won't get OnStart called, won't be forced active, etc. So if the force-active thing is the only thing, this definitely doesn't work on unloaded vessels. Maybe packed vessels - I'm not entirely certain how they would behave.

Honestly I think there are better ways of doing it, at the very least ways that have less potential side effects.

Share this post


Link to post
Share on other sites

It seems to me that in 1.0, the faster-burning JDiminishingRTGs will inevitably overheat and explode if heat generation is on. I don't think this has been noticed because one doesn't often spend a long time with a vessel focussed but without timewarping above 100x (when heat generation goes weird)...

Share this post


Link to post
Share on other sites
It seems to me that in 1.0, the faster-burning JDiminishingRTGs will inevitably overheat and explode if heat generation is on. I don't think this has been noticed because one doesn't often spend a long time with a vessel focussed but without timewarping above 100x (when heat generation goes weird)...

After our IRC conversation, I tested this in a stock+JDiminishingRTG game. Even with the most egregiously silly design, I can't get any RTGs to explode.

Then I tried it in stock+JDiminishingRTG+DRE. Boom! Conductive flux is lowered by a factor of about 5. I'm also reporting this in DRE's thread, but I thought I'd mention it here - no idea what's getting things wrong.

Share this post


Link to post
Share on other sites
After our IRC conversation, I tested this in a stock+JDiminishingRTG game. Even with the most egregiously silly design, I can't get any RTGs to explode.

Then I tried it in stock+JDiminishingRTG+DRE. Boom! Conductive flux is lowered by a factor of about 5. I'm also reporting this in DRE's thread, but I thought I'd mention it here - no idea what's getting things wrong.

This would seem to be a compatibility issue with DRE, and should be easily remedied with a config patch adjusting the thermal output factor in the global RTG confignode or by tweaking the part's heat tolerance; as I do not use DRE and am not keen to maintain it, I leave this as an exercise to those interested parties (e.g., you) to find a solution.

suggested ModuleManager code as starting point:

@JDIMINISHINGRTGGLOBALCONFIG[*]:NEEDS[DeadlyReentry],0 
{
@HeatScale = 0.33
//@GenerateHeat = false // an extreme alternative
}

// or

@PART[*]:HAS[ModuleDiminishingRTG]:AFTER[JDiminishingRTG]:NEEDS[DeadlyReentry],*
{
// triple the heat tolerance, e.g.
@maxTemp *= 3.0 // (I think that's correct, anyway)
}

Edited by KwirkyJ

Share this post


Link to post
Share on other sites

I like that you added compatibility with Near Future Electrical's rtg, but can you make a config for Near Future Spacecraft's PPD-1's small rtg. Wonderful mod btw.

Edit: Also Atomic Age has a small rtg engine so capatibility with that to please.

Edited by jtmcalli

Share this post


Link to post
Share on other sites

Also the RLA Stockalike mod have its own small RTG, so maybe some compatibility when the new version is released... or now if you can KwirkyJ.

Share this post


Link to post
Share on other sites
Also the RLA Stockalike mod have its own small RTG, so maybe some compatibility when the new version is released... or now if you can KwirkyJ.

You can try something like

@PART[*]:HAS[@MODULE[ModuleGenerator],!MODULE[ModuleDiminishingRTG]]
{
@description = By exploiting the 'natural' decay of radiological isotopes, electrical power can be generated for prolonged durationsâ€â€indeed, indefinitely, but the output tends to fall off over time. Accountants have also noted that different 'hot rocks' are hotter or cooler than others and tend to cool down a different rates, with the two aspects not necessarily being related.
!MODULE[ModuleGenerator] {}
MODULE
{
name = ModuleDiminishingRTG
efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge
volume = 7 // roughly, in deciliters. ("units")
}
RESOURCE
{
name = ElectricCharge
amount = 1
maxAmount = 1
isTweakable = true
}
}

Share this post


Link to post
Share on other sites

Progress report:

I am working on an update to this for 1.0.4+, but there is some major issue relating to the heat mechanics -- the RTGs have a penchant for exploding above 10x timewarp, which is naturally unacceptable. Hoping to find a solution eventually...

As for support of other RTG parts in part packs: there are a lot of parts packs. There is no guarantee I'll get them all on my own. That said, adding the DiminishingRTG module to the desired parts is very, very easy. MeCripp's solution is crude, but gets the job done of replacing all parts that generate constant flat output with the baseline setting of the stock RTG as I modified. One can fine-tune this by following my example modulemanager configuration files, replacing the name in the @PART[<part_name_here>] with the desire part's name as found in the cfg (name in .cfg as distinct from title, which is the name as given in VAB and right-click menu) and adjusting volume and efficiency of ModuleDiminishingRTG as needed. If you do the work for me and post the JDimRTG config for the part here, it will likely become officially supported in any subsequent update

Share this post


Link to post
Share on other sites

Any progress?

Why don't you upload it to Kerbalstuff.com? It allows the users to follow new releases by e-mail notifications.

Share this post


Link to post
Share on other sites
Any progress?

Why don't you upload it to Kerbalstuff.com? It allows the users to follow new releases by e-mail notifications.

yeah - and as long as you upload it as a zip file named 'GameData.zip', containing GameData/whatever it will be automatically made available on CKAN, as well.

- - - Updated - - -

You can try something like
@PART[*]:HAS[@MODULE[ModuleGenerator],!MODULE[ModuleDiminishingRTG]]
{
@description = By exploiting the 'natural' decay of radiological isotopes, electrical power can be generated for prolonged durationsâ€â€indeed, indefinitely, but the output tends to fall off over time. Accountants have also noted that different 'hot rocks' are hotter or cooler than others and tend to cool down a different rates, with the two aspects not necessarily being related.
!MODULE[ModuleGenerator] {}
MODULE
{
name = ModuleDiminishingRTG
efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge
volume = 7 // roughly, in deciliters. ("units")
}
RESOURCE
{
name = ElectricCharge
amount = 1
maxAmount = 1
isTweakable = true
}
}

I would recommend something like the following as a catch-all for any un-custom-cfg-parts (have not yet tested it myself, just threw it together)

@PART[*]:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE[ElectricCharge],!INPUT_RESOURCE[*]],!MODULE[ModuleDiminishingRTG]]:FINAL//hits all parts with module generator that has no inputs and outputs EC. runs on the final pass to avoid parts with specific configs
{
@description = By exploiting the 'natural' decay of radiological isotopes, electrical power can be generated for prolonged durationsâ€â€indeed, indefinitely, but the output tends to fall off over time. Accountants have also noted that different 'hot rocks' are hotter or cooler than others and tend to cool down a different rates, with the two aspects not necessarily being related.

//scale everything according to mass of stock RTG config (0.08)
MODULE
{
name = ModuleDiminishingRTG
efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge
volume = 7 // roughly, in deciliters. ("units")
@volume /= 0.08
@volume *= #$../mass$

//scale efficiency compared to the stock RTG electric output
@efficiency /= 0.75
@efficiency *= #$../MODULE[ModuleGenerator]/OUTPUT_RESOURCE[ElectricCharge]/rate$
}
//use the replace-if-not-create to avoid duplicate resource node
%RESOURCE[ElectricCharge]
{
%amount = 1000
%maxAmount = 1000
%isTweakable = true
@amount /= 0.08
@amount *= #$../mass$

@maxAmount /= 0.08
@maxAmount *= #$../mass$
}
!MODULE[ModuleGenerator]{}
}

Share this post


Link to post
Share on other sites

im not sure about using this, for a couple of facts.... like, what would i use for long-term power? i guess solar panels and batterys, big ones would work.... but one mod, SSTU labs, has a lander fuel tank part that can have a RTG as one of its configurations, and because of how its implimented, might not get picked up by the recently posted MM config... and i know this is a slight bump, but, hey. also, LLL adds in a salt reactor that generates EC out of nothing, and that would probably get detected by the MM patch. does the MM patch tune the output of converted-rtgs based on there original output? i might use it, but im not sure what repercussions it would have on how i play..

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.