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.

Update to KSP 1.1.3 compatibility (version 1.4.0). Should be stable, but feedback would be appreciated. Known bug regarding symmetry parts resetting when detaching/reattaching. Download HERE

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

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) }

Because Karborundum around the sun is wholly inaccessible because of heat, I decided to move the band. After some testing, I think I've found a good balance and created a patch. Download: ModuleManager patch file on pastebin // Requires ModuleManager, Karbonite // Written for KSP v1.0.2, // Karbonite v0.6.0, // KarbonitePlus v0.4.0, // ModuleManager v2.6.x // Move the Karborundrum belt around the sun to something more accessible. // Barely. // Densest at 150Mm altitude, reaches just short of 200Mm. // KPlus large collector tends to fail after any length of time spent // below 195Mm; plan accordingly. @PLANETARY_RESOURCE:HAS[#ResourceName[Karborundum]PlanetName[Sun]],0 { @Distribution,0 { @MinAbundance = 2 @MinAltitude = 1.14678899 @MaxAltitude = 1.14678899 @MinRange = 0.1911315 @MaxRange = 0.1911315 } }// Config by KwirkyJ 2015, CC BY-NC-SA 4.0

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.

I've encountered a minor bug(?) with NFE x4.14: when any of the deployable radiators are attached to a vessel, the debug log is spammed with one of the update() calls, a single "[Log]: 0.001", and each call thereafter "[Log]: 0.00100000004749745" (probably a rounding thing). This seems to appear only when the radiators are attached to and disappears when absent from the vessel. The value is identical for both 2250 and 550 models in all situations encountered thus far.

Update on my problems, after a series of tests: As related to later clarification, some of the problem was likely related to the manager thinking that the missiles were obstructed and could not fire -- I could fire them fine manually (most of the time), and this also came up with a number of gun configurations. This is likely 90% of the problem. A few other oddities: some weapons (I have not tried all) would not fire from ground to air, the instance at the forefront of my mind was the radial cannon would not engage air targets, even very low-flying ones (though I freely admit this could be one of those 'I think obscured' issues); the weapon manager also seems to be particular about its own obstructed field of view, so mounting it mid-wing will often have it 'miss' targets hidden by the wing -- I presume this is intended behavior, but is mildly irksome; SAMs would not engage my helicopter, though they would freely fly at other fixed-wing aircraft, with the same setup of guards for each case. Unrelated, pertaining to the proposed shot distribution: if a true normal distribution is too troublesome, you can cheaply approximate it with y = (x^2 - 1)^2… gives you a Gauss-like distribution across x = -1..1

You seem fixated on 'mission time,' so I will address that first: Your options include: 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 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 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.

I am having consistent issues with the weapon manager not recognizing missiles as valid weapons. In all test instances, inasmuch as I can be sure, I've passed into the field of fire and the log from the guarding craft reports "<vessel> is disengaging - no valid weapons." Most guns (though maybe not allâ€â€tried an airplane with the 30mm fixed gun pods on it and it was oblivious) seem to behave, however. Is there something obvious I'm missing, is this a bug, or are there further troubleshooting steps I might take?

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 ) 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.

It is actually this very thinking -- that the heat-generating reactor should be separated from the electricity-generation component -- that I created a Seebeck Generator mod. It may go against the way Nertea wishes to implement things, but this mechanic does exist.

shiny graph and other current images added to main page

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.)

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)