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)

Due to the nature of the system, it is not a gradient on a single part; rather, it is the gradient between parts. A single-part vessel will, unfortunately, always generate zero power with this implementation. Unfortunately, calculating heat flux across a single part in isolation is a bit beyond what I intended to model Somewhat by design, it is intended for use with other mods that generate heat (JDiminishingRTG, for example, or perhaps NearFuture Electrical or KSPI-extended) or, in stock, heat-generating parts such as LV-Ns or drills. By supporting compound parts such as struts, one can get some significant gradients indeed. ...Will see what comes of it, anyway, and thanks for the consideration.

Not sure how feasible, I've not given it more than a passing thought, but a heat sink that can 'vent coolant' once or twice to reset its eagerness to absorb heat has been bumping around it my head. Seems interesting, and applicable to the intent of the mod, anyway.

I changed my mind regarding the heat, now that I have played a bit and figured out how it works... The module now generates heat by default! Can to toggled by RTGFuelConfigs.cfg, "GenerateHeat = false" Both Electricity and Heat can be tweaked there as well -- among other things -- for those who want to experiment. Get it at the main page! (and while you're at it, consider grabbing JSeebeckUtils to better capitalize on this heat business) CHANGES: 2 May 2015 (v1.3) * Rebuilt on KSP v1.0.2 * Added global settings configuration * Added thermal component

General-purpose PartModule for all your heat-to-electricity needs. DOWNLOAD HERE With the introduction of a somewhat workable heat system, naturally comes the need to make use of it. Because it was exactly as straightforward as I expected, I present JSeebeckUtils. IMPORTANT FEATURES: As the name implies, approximates the Seebeck Effectâ€â€will generate ElectricCharge proportional to the greatest temperature gradient local to the part. Can be assigned to any part (including struts)! IS IN BETA: Balance is very much questionable at this point; feedback from play-testing is required. Consider using this alongside Nertea's (alpha/beta) HeatControl Mod: read more here. You might also be interested in coupling this with JDiminishinRTG. Just launched, sitting on the pad... Built up some heat! (overlay visible) Installation instructions: * download and unzip distribution * merge GameData contents with KSP/GameData * Requires ModuleManager for provided patches to operate. KNOWN BUGS: * High timewarp (warp ≥ 1000x ?) will change thermal modeling mode, possibly changing or eliminating temperature gradients. * ADDENDUM: because the generator works on a temperature gradient, "full power" is a curious notion. Parts launch at equal temperature, so power generation at launch will start at zero. For modders or super-users: * Just add ModuleSeebeck to any relevant part. CHANGELOG *** 2 May 2015 (v0.9) * Beta release (for KSP v1.0.2) * General-purpose PartModule * Provided sample configs for Squad parts * Provided ModuleManager configuration for JDiminishingRTG

This is among the highest praise a creator can receive -- thank you, I'm glad you like it. The reasoning behind 'weird names' is twofold: first, keeping it gamey and fun in line with the general whimsy and fictitious nature of KSP at large (the names themselves are something of easter eggs); second, as of 1.2 they have at best a tenuous connection to the real-world elements that they simulate, as the power densities and half-lives are congruent but minimally related to the realistic values. That being said, the mod is written in a way that allows (and encourages!) you do adjust things how you wish... the cfgs should be adequately documented, but I can expand on them.(Possible feature for future update: configurable units, so one could list power density as true-to-real-life W/kg as opposed to "Zolts" [which should be "Zot!s" anyway"]) There are a few ways this can be answered, so I will try to address them all (most of which simply rephrase Gribble -- thanks to zir for replying in my stead).The more indirect and useful answer is a question to itself: for what reason would simulating the heat be important? In pure-stock, the only effect would be to (1) cause a part that explodes upon creation or very nearly, or (2) make other parts hotter so they either explode spontaneously or sooner upon re-entry. Neither add positively to game-play. If you are using mods, the only relevant interplay I can think of would be RealFuels, where heat can impact boil-off; the license is permissive, one is free to add this feature and patch it to RF if they wish -- I have no interest in doing so, the payoff is too little. The more technical answer, as Gribble has provided, has two sides. On one, yes, they generate a fair bit of energy (heat), and it has to go somewhere and along the way we get useful work out of it. This means the the part gets a bit warm/hot, and that energy gets radiated out; the RTG parts have built-in radiators for this purpose (and, technically, the attachment part absorbs and radiates some...). On the other, because one can view it as resolving heat on its own, one can simplify matters by considering the part after it has radiated this heat -- in effect, the warmth of the part is of no relevance to the rest of the ship and thus not worth modelling. This ties in to reasons above, as there is quite literally no point. To be fair, the game should have mechanics in place to simulate the black-body and conductive radiation if one was so inclined, but I am not. (permissive license, yadda yadda.) This is not at all meant to be demeaning or condescending, but rather as an explanation of my rationale. I built this plugin with the intent of adding to play, not simulating reality for the sake of being parochial or pedantic.

Now updated with KSP 1.0 assemblies. Tweaked half-lives down, to make use more interesting and decisions a little more involved. Get it from the initial post!

The pictures reflect an older setup, so are waaaaay overpowered as shown. The Ec/min output display, as opposed to fractional seconds, was added in 1.1, as noted in both initial post and readme. Will update images "soon," as I'm still dubious about balance. As for the issue in your edit, all I can say without more information from you is "they work for me." What does the context menu report as output? Can you reproduce the apparent problem? (Also, ach! There/they're and double-negative.)

Technically, it is analogous to Watts/gram of nuclear decay. The term one would probably explore would be power density of a given isotope (e.g., 0.54 W/g for 238Pu). At the time I got going, I couldn't find the exact term for it that was simple and informative, so I went with a colloquial term that suggested how 'vivacious' the material was in terms of its thermal output... thus, "pep." (One will note that my mod also uses the imaginary unit "Zolts" in place of Watts.) Really, it's a whimsical name, but I took a liking to it, keeping it 'gamey' in a spirit similar to KSP at large while not being wholly wrong. I left comments in the configs that should suggest the nature of the units, but I seem to have been a bit too subtle. I'll revisit those, and may make some notes in the readme in the future. Hope this answers your question.

v1.1 RELEASED Fixes a couple subtle bugs, major balance tweak. Should break nothing, but vessels in-flight will not update their behavior, and any vessels from .craft will have the old performance as well unless you refresh the part by cycling through the settings again craft built with the v1.0 dll will probably eat all Ec ever, or just about; can be corrected by editing the density field (and, if applicable, pep and the resource's maxAmount) for each partmodule in the persistence file. - - - Updated - - - As noted by Gribbleschnibit, it is more complete, implementing most of "Realistic RTG's" design goals, with an aspect or two that may have been overlooked. This mod should be more stable, relying on "universal time" rather than vessel flight time (for those who dock/undock at all); it uses PartResources and an additional configuration file to determine the behavior, rather than being fully hard-coded into the part/partmodule; configurations can be tweaked in editor, a feature completely lacking from "R'RTG". Technically, yes. However, as I am using the provided PartResource mechanic to rely on cost it does not in practice due to the 'subtractive resource costs,' that the part costs a set amount and the resources provided in the config add to it. (this leads so some interesting behavior with modded or dynamic parts… have had KSPI craft that pay billions of funds upon construction because of empty antimatter containers.) I could presumably remedy this for the plugin, but as it is more fundamentally a failure on Squad's part I am content to simply wait for them to fix things. Apologies for the inconvenienceâ€â€I will make note of it in 'known issues.'

There is not, by design. The output at launch is contingent on the amount and type of fuel (and thermocouple efficiency), and diminishes over time, proportional to 2^-t. The mod does one thing, and (presumably) does it well.