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

[blu3wolf]

1 hour ago, jlcarneiro said:

@ABZB has already proposed that here. Unfortunately, it seemed to have some problems with the launch clamps and with the maxAmount property (it was scaled turning the RTG into some kind of battery).

Tell me if you find something wrong, please...

Giving it a go now, will report if I find any issues. @Zhetaan I believe it is from NearFutureSpacecraft, yes. 

[Zhetaan]

@jlcarneiro:

I'm certainly not the greatest patch-writer who ever lived, and do please keep in mind that my preference is to write patches for individual parts (I've never had a need to change a few dozen parts at a time, though, either), but it looks as though it is good MM code.  As a rule, I would advise against modifying the efficiency.  A smaller RTG doesn't produce less power because it's less efficient; it produces less power because there's less fuel.  Fuel mass translates directly into thermal mass:  less total fuel equals less total heat equals less total electricity.

Efficiency is simply the conversion factor from heat to electricity and is based on the design of the thermocouple.  It has absolutely nothing to do with the type or amount of fuel.  Real RTGs are between 5% and 7% efficient, (some older designs are closer to 3%) because thermocouples have really terrible efficiency (their advantage is their reliability; they have no moving parts).  Some advanced RTGs get 7% by employing various forms of physics trickery, but the basic designs (which is nearly all of them) stay close to 5%.  I suggest letting the efficiency be 0.05 and leaving it that way.

My other suggestion is to pay no attention to the mass of the RTG.  I can think of two parts off the top of my head (NFT's Itinerant Service Container, and USI's PackRat Exploration Rover--Back) that add RTG modules but are not exclusively electrical generators.  The mass that is used as crew cabin, chassis, suspension, or whatever has nothing to do with its being an RTG; these parts include the RTG module instead to reduce part count or for other reasons that shouldn't factor into your patch.

Instead, the only variable you should be changing is the initial volume of fuel, and it should be based on the original electrical output of the part.  Take the original output ('rate = x') and multiply it by 28 / 3 (9.33333333...) and that is your initial volume.  This has the advantage of being a simpler patch to write.

Edited August 3, 2016 by Zhetaan

[jlcarneiro]

2 hours ago, Zhetaan said:

@jlcarneiro:

I'm certainly not the greatest patch-writer who ever lived, and do please keep in mind that my preference is to write patches for individual parts (I've never had a need to change a few dozen parts at a time, though, either), but it looks as though it is good MM code.  As a rule, I would advise against modifying the efficiency.  A smaller RTG doesn't produce less power because it's less efficient; it produces less power because there's less fuel.  Fuel mass translates directly into thermal mass:  less total fuel equals less total heat equals less total electricity.

Efficiency is simply the conversion factor from heat to electricity and is based on the design of the thermocouple.  It has absolutely nothing to do with the type or amount of fuel.  Real RTGs are between 5% and 7% efficient, (some older designs are closer to 3%) because thermocouples have really terrible efficiency (their advantage is their reliability; they have no moving parts).  Some advanced RTGs get 7% by employing various forms of physics trickery, but the basic designs (which is nearly all of them) stay close to 5%.  I suggest letting the efficiency be 0.05 and leaving it that way.

My other suggestion is to pay no attention to the mass of the RTG.  I can think of two parts off the top of my head (NFT's Itinerant Service Container, and USI's PackRat Exploration Rover--Back) that add RTG modules but are not exclusively electrical generators.  The mass that is used as crew cabin, chassis, suspension, or whatever has nothing to do with its being an RTG; these parts include the RTG module instead to reduce part count or for other reasons that shouldn't factor into your patch.

Instead, the only variable you should be changing is the initial volume of fuel, and it should be based on the original electrical output of the part.  Take the original output ('rate = x') and multiply it by 28 / 3 (9.33333333...) and that is your initial volume.  This has the advantage of being a simpler patch to write.

I understand what you say about writing specific patches. Problem is: I end up forgetting about them when I add (or remove) a part for whatever reason. So a patch that acts on all parts of that type is preferred...

So, about the MM patch, you suggest I only alter the initial fuel volume, makes sense. AFAIK, I shouldn't need to alter the mass because KSP would take care of it, since I've altered the volume, right?

So, would it become something like this:

//hits all parts with module generator that has no inputs and outputs EC. runs on the final pass to avoid parts with specific configs
@PART[!launchClamp*]:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE[ElectricCharge],!INPUT_RESOURCE[*]],!MODULE[ModuleDiminishingRTG]]:FINAL
{
    @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 // stock RTG volume roughly, in deciliters. ("units")

	//scale volume compared to the stock RTG mass
        @volume /= 0.08
        @volume *= #$../mass$
    }
    //use the replace-if-not-create to avoid duplicate resource node
    %RESOURCE[ElectricCharge]
    {
        %isTweakable = true
        @amount = 1
        @maxAmount = 1
    }
    !MODULE[ModuleGenerator]{}
}

 

Edited August 3, 2016 by jlcarneiro

[Zhetaan]

@jlcarneiro:

Right.  If you tell it how much volume of fuel to add, KSP will calculate the additional mass according to the density given in RTGResources.cfg.

The overall idea is that the part mass represents the empty case (80 kg for the stock RTG); you just add the fuel module you like before launch and the mass is updated accordingly.  Note that this means the actual liftoff mass is a bit higher than the stock RTG for this reason.  Going with the 7dL standard, the Krontium90 launches at 94 kg, Kyandere210 launches at 109.4 kg, Kitsunium launches at 115 kg, and the Kuudite241 launches at 122.7 kg.  If you change the volume, then the mass will be updated to match.

This mirrors reality pretty well:  RTGs are built to be assembled empty and the fuel added later.  This makes sense because the power pack might need to be tested against a probe's on-board electronics years ahead of launch, but for obvious reasons, the nuclear fuel is best added as close to launch as possible (for testing, they'd often just put an electric heater where the fuel pellets would go).  This was taken to some extremes when they used RTGs for manned missions:  the SNAP-27 RTG that powered the ALSEP experiments left by the Apollo program went to the Moon as an empty case; the fuel was carried in a container on the outside of the lander.  The astronauts added the fuel modules to assemble the complete RTG only after they were on the lunar surface.  Apparently, someone at NASA thought it was a bad idea to have a red-hot, radioactive fuel pellet that represented six different kinds of toxic death floating about the crew cabin (actually, they were afraid of raining nuclear fuel throughout the countryside if the rocket blew up in the upper atmosphere, so they put it in a protective cask).

In fact, on the subject of mass, the only drawback for me with this mod is that as the fuel is depleted, the mass is lost, so without a mass of inert material that increases to match the lost fuel, it violates conservation--this is a problem NFE's DecayingRTG doesn't have, but DecayingRTG doesn't model select-able fuel types or thermocouple efficiencies, either.  Unfortunately, the only ways I have seen to overcome this are either to avoid a fuel resource in the first place (what NFE DecayingRTG does) or to include a waste resource (what NFE and USI nuclear reactors do).  I don't know whether a waste resrouce would be difficult, coding-wise, but it may not be practicable.

[jlcarneiro]

3 hours ago, Zhetaan said:

@jlcarneiro:

Right.  If you tell it how much volume of fuel to add, KSP will calculate the additional mass according to the density given in RTGResources.cfg.

The overall idea is that the part mass represents the empty case (80 kg for the stock RTG); you just add the fuel module you like before launch and the mass is updated accordingly.  Note that this means the actual liftoff mass is a bit higher than the stock RTG for this reason.  Going with the 7dL standard, the Krontium90 launches at 94 kg, Kyandere210 launches at 109.4 kg, Kitsunium launches at 115 kg, and the Kuudite241 launches at 122.7 kg.  If you change the volume, then the mass will be updated to match.

This mirrors reality pretty well:  RTGs are built to be assembled empty and the fuel added later.  This makes sense because the power pack might need to be tested against a probe's on-board electronics years ahead of launch, but for obvious reasons, the nuclear fuel is best added as close to launch as possible (for testing, they'd often just put an electric heater where the fuel pellets would go).  This was taken to some extremes when they used RTGs for manned missions:  the SNAP-27 RTG that powered the ALSEP experiments left by the Apollo program went to the Moon as an empty case; the fuel was carried in a container on the outside of the lander.  The astronauts added the fuel modules to assemble the complete RTG only after they were on the lunar surface.  Apparently, someone at NASA thought it was a bad idea to have a red-hot, radioactive fuel pellet that represented six different kinds of toxic death floating about the crew cabin (actually, they were afraid of raining nuclear fuel throughout the countryside if the rocket blew up in the upper atmosphere, so they put it in a protective cask).

In fact, on the subject of mass, the only drawback for me with this mod is that as the fuel is depleted, the mass is lost, so without a mass of inert material that increases to match the lost fuel, it violates conservation--this is a problem NFE's DecayingRTG doesn't have, but DecayingRTG doesn't model select-able fuel types or thermocouple efficiencies, either.  Unfortunately, the only ways I have seen to overcome this are either to avoid a fuel resource in the first place (what NFE DecayingRTG does) or to include a waste resource (what NFE and USI nuclear reactors do).  I don't know whether a waste resrouce would be difficult, coding-wise, but it may not be practicable.

See why I'm telling you to create a tutorial thread?

[Zhetaan]

@jlcarneiro:

Sure, but it's only for one mod; I'm not sure it should be posted there if it's so specific.  I'll have to look at adding NFE, at the least.

Anyway, I think you're better off not considering mass at all in your patch.  Is there a way for ModuleManager to find the output rate of the part so you can use that?

[jlcarneiro]

1 hour ago, Zhetaan said:

@jlcarneiro:

Sure, but it's only for one mod; I'm not sure it should be posted there if it's so specific.  I'll have to look at adding NFE, at the least.

Anyway, I think you're better off not considering mass at all in your patch.  Is there a way for ModuleManager to find the output rate of the part so you can use that?

It's possible, what do you suggest again (more details)?

I mean, you told me to multiply the original rate by 28/3... Why these numbers? Sorry didn't get it.

Shouldn't it be to divide the original rate (0.75) by the original volume (7 deciliters) and the multiply the results by the output rate of the desired part?

Edited August 4, 2016 by jlcarneiro
Added the question

[Zhetaan]

@jlcarneiro:

Here's the idea:

//hits all parts with module generator that has no inputs and outputs EC. runs on the final pass to avoid parts with specific configs
@PART[!launchClamp*]:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE[ElectricCharge],!INPUT_RESOURCE[*]],!MODULE[ModuleDiminishingRTG]]:FINAL
{
    @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 output of stock RTG config (0.75 EC/sec)
    MODULE
    {
        name = ModuleDiminishingRTG
        efficiency = 0.05 // factor (0..1) of 'pep' into ElectricCharge 
        volume = 7 // stock RTG volume roughly, in deciliters. ("units")

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

I'm not much of an MM coder, so I have no idea whether that patch would even work, but that's the notion.

Nice catch on the launch clamps, by the by.

Anyway, the efficiency remains a standard 5% (anything different should have a custom config) and the volume starts as a standard 7 (which, for most parts, is probably going to stay the same:  there aren't many mod RTGs out there, and most of the ones that I've seen copy the stock values).

Then the volume divides itself by the stock RTG output, and after that it finds and multiplies itself by its own original output--assuming that I got the lookup right.

The mathematical reasoning is this:

(Fuel Volume Given to Stock RTG by the Mod)     (Fuel Volume of Other RTG)
-------------------------------------------  =  --------------------------
          (Stock RTG Output)                        (Other RTG Output)

This should make sense.  Whatever the outputs may be, you would expect that other RTGs, whatever their size, would have proportionally similar performance to the stock RTG after this mod is through with them.  A bigger RTG should get more fuel; a smaller one should get less.

With a little algebra, the proportion rearranges into this:

(Fuel Volume Given to Stock RTG by the Mod) * (Other RTG Output)
----------------------------------------------------------------  =  (Fuel Volume of Other RTG)
                       (Stock RTG Output)

Substituting with values we know:

   (7 dL)
----------- * (Other RTG Output)  =  (Fuel Volume of Other RTG)
(0.75 EC/s)

And finally, 7 / 0.75 = 28 / 3 or 9.3333333...--but I suspect it's easier to follow if it's done in two steps.

[jlcarneiro]

Thanks, @Zhetaan!

I'll try this. I'm not an MM patcher myself, but your lookup looks like ABZB's, so I think it's ok.

[KwirkyJ]

Massive kudos to @Zhetaan for putting up the breakdowns/analyses here, as well as providing thoughtful support while I be a terrible forum community member. Much of the math behind what works when and where should be intuitive or at least derivable—I did show most of the work relevant to isotope decay (of current resources) in the first post—but providing context as zi has is of great value and is not exactly trivial to compile. (I am, tangentially, monumentally pleased that my 'yeah, that seems about right' fiddling with the balance worked out almost exactly as I intended, in kind if not in precise detail… with their being more or less 'placeholder' values for initial balance, I think I nailed it.)

 

For the launch clamp, I am fairly certain that this  is a result of how I am updating the part. I had not considered that people would place RTGs on such sensitive parts. Fortunately, the correction is should fairly straightforward and I may push it into a quickfix for the plugin.

 

Additionally, I am working on a fork of this mod, splitting its functionality into two modular components: generalized (radio)isotope decay of resources and thermocouples to interact separately. This change may or may not come with re-balancing of the resources, for which I apologize in advance.

[Zhetaan]

9 hours ago, KwirkyJ said:

For the launch clamp, [...] I had not considered that people would place RTGs on such sensitive parts.

In fairness, people aren't putting RTGs on launch clamps per se; it's just that ModuleResourceGenerator works as an infinite power source simply by failing to specify an input.  Doing this to the launch clamp makes a good simulation of the electrical umbilical that real launch towers have (after all, pad power may as well be infinite).  Of course, using the same configuration for RTGs (unfortunately and in fairness to you, the lack of input is the only thing that distinguishes RTGs from any other electrical generator) merely serves to further highlight this mod's usefulness to my mind.

KSP has functions for exponential decay:  you see it in the research rate of the mobile processing lab, and possibly in a very approximate form in the diminishing science return of repeated science experiments.  Why Squad chose not to implement this code for RTGs, even with cartoonishly long half-lives, escapes me.

Quote

Additionally, I am working on a fork of this mod, splitting its functionality into two modular components: generalized (radio)isotope decay of resources and thermocouples to interact separately. This change may or may not come with re-balancing of the resources, for which I apologize in advance.

Cool!

*Looks back at the research now rendered obsolete*

Still cool!  I'm looking forward to see what you do with it.

The reason I like this mod so much, and the thing it offers that no other mod offers, is its uniquely final time limit on missions.  There are plenty of nuclear power and life support mods out there, but for all of them, the challenge is one of bringing enough supplies:  in the end, it's about launching larger rockets, and once it's in orbit, it's halfway to anywhere.  Take ISRU and it's halfway to everywhere.  This mod, on the other hand, brings about an entirely different logistical challenge.  With only x days to complete the mission, including travel time, and no replacement fuel units, no rare finds of funny mineral deposits, no anything other than the RTG and the fuel load it got at the factory, it becomes more attractive to look for alternative flight plans and mission profiles.  It puts pressure on you to pack the most mission into the shortest time possible, and I've had some amazing ones (to me, at least).  Everything is a trade-off in a way that neither 'moar boostrz' nor time warp can fix, and that has a lot of appeal to me.  So thank you very much.

[APlayer]

Humm, not wanting to be rude or impatient, just asking... Is this still being worked on? KwirkyJ wasn't here since August, 22th, when he last posted here...

[jlcarneiro]

Wondering the same here...

Edited January 17, 2017 by jlcarneiro

[blu3wolf]

Well, does the 1.1.3 version still work in 1.2.2?

[jlcarneiro]

On 23/01/2017 at 4:19 AM, blu3wolf said:

Well, does the 1.1.3 version still work in 1.2.2?

To be honest, since it has a compiled DLL, I haven't tried it... 

EDIT: Well, just did it... Unfortunately, it does not work on 1.2.2...  

Edited January 25, 2017 by jlcarneiro

[Lord_Stimpy]

On 1/23/2017 at 7:01 PM, jlcarneiro said:

To be honest, since it has a compiled DLL, I haven't tried it... 

EDIT: Well, just did it... Unfortunately, it does not work on 1.2.2...  

A Shame, definitely the unsung hero of realism mods. 

[danielboro]

NFE by nerta has an option to make RTG Decay

i dont know if you need all the mod to use it or if you can use that only

 

 

[jlcarneiro]

11 hours ago, danielboro said:

[...]

i dont know if you need all the mod to use it or if you can use that only

[...]

That's a good question!

[Drew Kerman]

13 hours ago, danielboro said:

i dont know if you need all the mod to use it or if you can use that only

2 hours ago, jlcarneiro said:

That's a good question!

It's a patch that only adds a module, so you will at least need the NFE DLLs. The parts and stuff you can toss if you want

 

[Zhetaan]

You need the Near Future Electrical DLL, but the Decaying RTG stuff is built in to that--there's no additional plugin.  I actually use NFE, so I don't know what the minimum install is.

If you have NFE, however, then take this, as well:

+PART[rtg]:FOR[NearFutureElectrical]
{
	@name = rtgKitsunium238
	@title = Kitsunium-238 Radioisitope Thermoelectric Generator
	@description = Through exploitation of radioisotope decay, this elegantly simple power generator can provide reliable-but-diminishing power for years. Not to be used for providing heating during emergency rover excursions.
	@cost = 23860 //Stock is 23,300 Funds; Kt-238 adds 7 units at 80 Funds/unit (560)
	@mass = .115  //Empty stock casing is .08; Kt-238 adds 7 units at .005 tonne/unit (.035)

	!MODULE[ModuleGenerator] {}

    @MODULE[ModuleRadioisotopeGenerator]
	{
		@BasePower = 0.7315 //For other RTGs, multiply their base power by .9753 (Stock = .75 ec/s; Kt238 = .7315 ec/s initial) to convert to Kt-238.
		@HalfLife = 2.30
		@EasyMode = false
	}
}

+PART[rtg]:FOR[NearFutureElectrical]
{
	@name = rtgKrontium90
	@title = Krontium-90 Radioisitope Thermoelectric Generator
	@description = Through exploitation of radioisotope decay, this elegantly simple power generator can provide cheap and reliable-but-diminishing power for a few years. Not to be used for providing heating during emergency rover excursions.  May be used to power warning beacons.
	@cost = 23405 //Stock is 23,300 Funds; Kr-90 adds 7 units at 15 Funds/unit (105)
	@mass = .094  //Empty stock casing is .08; Kr-90 adds 7 units at .002 tonne/unit (.014)

	!MODULE[ModuleGenerator] {}

    @MODULE[ModuleRadioisotopeGenerator]
	{
		@BasePower = 0.245  //For other RTGs, multiply base power by .3267 to convert to Kr-90.
		@HalfLife = 1.84
		@EasyMode = false
	}
}

+PART[rtg]:FOR[NearFutureElectrical]
{
	@name = rtgKyandere210
	@title = Kyandere-210 Radioisitope Thermoelectric Generator
	@description = Through exploitation of radioisotope decay, this elegantly simple power generator can provide a tremendous amount of reliable-but-diminishing power for a short time. Not to be used for providing heating during emergency rover excursions.  May be used to broil snacks.
	@cost = 23608  //Stock is 23,300 Funds; Ky-210 adds 7 units at 44 Funds/unit (308)
	@mass = .1094  //Empty stock casing is .08; Ky-210 adds 7 units at .0042 tonne/unit (.0294)

	!MODULE[ModuleGenerator] {}

    @MODULE[ModuleRadioisotopeGenerator]
	{
		@BasePower = 1.911  //For other RTGs, multiply base power by 2.548 to convert to Ky-210.
		@HalfLife = 0.113
		@EasyMode = false
	}
}

+PART[rtg]:FOR[NearFutureElectrical]
{
	@name = rtgKuudite241
	@title = Kuudite-241 Radioisitope Thermoelectric Generator
	@description = Through exploitation of radioisotope decay, this elegantly simple power generator can provide reliable-but-diminishing power for decades. Not to be used for providing heating during emergency rover excursions.  May be used to warm hands.
	@cost = 23755  //Stock is 23,300 Funds; Ku-241 adds 7 units at 65 Funds/unit (455)
	@mass = .1227  //Empty stock casing is .08; Ku-241 adds 7 units at .0061 tonne/unit (.0427)

	!MODULE[ModuleGenerator] {}

    @MODULE[ModuleRadioisotopeGenerator]
	{
		@BasePower = 0.1708  //For other RTGs, multiply base power by .2277 to convert to Ku-241.
		@HalfLife = 6.33
		@EasyMode = false
	}
}

!PART[rtg]:NEEDS[NearFutureElectrical]:AFTER[NearFutureElectrical] {}

 

I disclaim that it actually works; I just wrote it.  I would prefer that @KwirkyJ come back, but until then, this (or, if it doesn't work, a modified version that does work) should duplicate most of the JDiminishingRTG functionality à la NFE.

Further disclaimers:

• This only addresses the stock RTG; if you have others, you're on your own to modify the CFG.  I did comment my calculations so you don't have to guess.
• It does nothing with heat generation.  Sorry.  I may modify it a bit for that, but again, remember that this is intended as a stopgap until the real mod can be updated.
• It has no tank-switching functionality; in other words, yes, this makes four different versions of the RTG.  Sorry for the part clutter.  There's no way around that without requiring another mod.  NFE uses B9PartSwitch, so that's the obvious choice if I try to extend this further--and assuming B9PartSwitch can do what I want.
• I didn't bother to change the unlock cost.  This means that you have to unlock four different RTGs.  I suppose one could make three of them cost zero or divide the cost equally, but I don't think the expense is prohibitive enough to make the change.

Since all of the information in this CFG was harvested directly from JDiminishingRTG's files, I am rather certain that it counts as a derivative work according to the licence.  Therefore, it, too, is CC BY NC 4.0, inspired by 'JDiminishingRTG', KwirkyJ's derivation of Gribbleschnibit8's 'Realistic RTGs'.

Edited February 9, 2017 by Zhetaan
Fixed .cfg

[Lord_Stimpy]

Interesting, I didn't know NFE had that, thanks chaps!

[jlcarneiro]

On 07/02/2017 at 2:51 PM, Zhetaan said:

You need the Near Future Electrical DLL, but the Decaying RTG stuff is built in to that--there's no additional plugin.  I actually use NFE, so I don't know what the minimum install is.

If you have NFE, however, then take this, as well:

[...]

I disclaim that it actually works; I just wrote it.  I would prefer that @KwirkyJ come back, but until then, this (or, if it doesn't work, a modified version that does work) should duplicate most of the JDiminishingRTG functionality à la NFE.

Further disclaimers:

• This only addresses the stock RTG; if you have others, you're on your own to modify the CFG.  I did comment my calculations so you don't have to guess.
• It does nothing with heat generation.  Sorry.  I may modify it a bit for that, but again, remember that this is intended as a stopgap until the real mod can be updated.
• It has no tank-switching functionality; in other words, yes, this makes four different versions of the RTG.  Sorry for the part clutter.  There's no way around that without requiring another mod.  NFE uses B9PartSwitch, so that's the obvious choice if I try to extend this further--and assuming B9PartSwitch can do what I want.
• I didn't bother to change the unlock cost.  This means that you have to unlock four different RTGs.  I suppose one could make three of them cost zero or divide the cost equally, but I don't think the expense is prohibitive enough to make the change.

Since all of the information in this CFG was harvested directly from JDiminishingRTG's files, I am rather certain that it counts as a derivative work according to the licence.  Therefore, it, too, is CC BY NC 4.0, inspired by 'JDiminishingRTG', KwirkyJ's derivation of Gribbleschnibit8's 'Realistic RTGs'.

Hey, great news!

Let me see if I got it: I have to download NFE, toss everything but the DLL away and put this MM patch of yours on Gamedata folder? Is that all?

[Zhetaan]

1 hour ago, jlcarneiro said:

Let me see if I got it: I have to download NFE, toss everything but the DLL away and put this MM patch of yours on Gamedata folder? Is that all?

I believe so, but let me emphasise that I have not tested the minimum install.

Also, in the interest of stirring up more interest in realistic RTGs, @oren is working on a much better implementation than my hyper-complicated MM patch:  it's called More RTGs and is delightfully what it says on the tin.  If you decide to try that, do please keep in mind that it uses the DecayingRTGs extra from NFE (that provides the Pu238 configuration) and only adds the three missing ones.  Also, if you want something a little less forgiving, you'll need to modify the .cfg files so that all of the RTGs have 'easymode = false'.  Still, it's worth a look.

[linuxgurugamer]

I've adopted this mod, new thread is here:

Please move discussion there