RoverDude

Thanks, glad you dig the parts. Arsonide did some amazing work on the contract for it too!

yeah we'll need snjo to fix up the models and such as I do not have access to those

This has zero to do with a need to 'defend my baby' and everything to do with making sure folks are not declaring 'facts' that are not factual. And it seems the only corner I am having to put these fires out in are people who were passionate about other radiator mods (or, dare I say it, trying to defend their own babies). In any case. As noted by the mod author, stock mechanics are more than sufficient for this engine and are not 'inadequate' as previously asserted.

Listen. I totally get that some people are a bit bent out of shape because we now have stock radiators. But given I've been using them with this specific engine without issue, and given the fact that the author of this mod feels stock radiators are so effective he has to actually increase the heat of his parts... any FUD about stock radiators somehow being inadequate for the job of the nuclear lightbulb engine is just flat out misinformation.

Sorry, but with all due respect you are completely incorrect. I've been doing some streaming and use the Nuclear Lightbulb as my main interplanetary engine with some very long burns, and have no issue using it with (in most cases) a pair of the medium deployable radiators. I expect if I wanted some insane burn times I could swap to four mediums or even the large ones. The stock radiators are more than capable of handling the heat generation of this engine.

Modders are free to do whatever they like, but the stock system does not in any way use heat as a resource. And I kinda agree with that sentiment.

** the comments below are my personal thoughts as a modder, not as someone who subcontracted for Squad - do not take anything I say in any way as some 'official' statement!!! ** RE Orthagonal: My point was that even if 1.0.4 did not add radiators, Nertea already had to do adjustments, as has already been noted. And sorry, this is not a 'bugged stock simulation' issue. Using the stock mechanics and stock parts, with stock configs you're fine. this is squarely a mod issue. Stock ISRU had heat mechanics pulled in 1.0.1 specifically because I needed to noodle over how to better handle them in analytics mode without explosions or exploitations (I should know - I did it), so poking it with a stick and calling it a bug is a bit disingenuous. I am saying this not to be pedantic, but to make a pretty clear separation between what is supported in stock vs. what is not. i.e. your demo above, Fraz86, basically says 'I can edit a config to include non supported values that are not used in any generators in the entire game, and cause things to explode!'. Of course you can... that's why those mechanics were tabled. Right now, there are no stock mechanics that I am aware of that generate heat and operate in analytics mode (engines and reentry heat are both limited to physwarp). So naturally whatever Nertea does for his mod will have to account for this. That's not a bug, that's pushing the boundaries of what we have right now. Now, if at some time stock heat in analytics mode makes a comeback, then Nertea can likely piggy back off of that. But there's absolutely no guarantee what shape that will take. And that's the rub. You're extending a major (and newish) subsystem, and asking it to do some interesting things that it simply is not (currently) designed to do. And I expect there will be future occurrences of having the rug pulled out (i.e. if Nertea makes a plugin that does X, then stock ends up doing Y, there will end up being more rounds of reconciliation).

This would go back to why Nertea is going to need to sort out 1.0.4 compatibility which is completely orthagonal to radiators.

Ahh. So now 'modders are selfish bad guys'. Ad Hominims aside, this has little to do with feelings, and more about signal to noise, as Ferram4 has already noted (and experienced). He's delt with forks, unfixers, etc. - and promises by the community to keep the support issues away have been repeatedly broken. People who used a fork and were supposed to stick to that thread kept coming to his thread, etc. - it wastes time he could spend supporting users who are utilizing a supported product. That's pretty much it. And it's been played out repeatedly. And re-labeling the mod with a new name isn't going to quite cut it, since it's going to be a pretty obvious fork. And you will likely get locked licensing. As has been said repeatedly.. it's one thing to do this on your own save and peel off the labels. But actively circumventing protections modders put in place to help you folks by reducing said noise is, as noted, ultimately destructive to the community. Nobody's going to stop you, but don't look shocked when the result is not quite what you expect.

See note above RE doing this without HC parts, since you're asking a question about stock mechanics and tossing a plugin into the mix

Given that HC is a plugin, I can't speak for plugin code. But do a similar experiment with your basic stock parts - run a bunch of NERVs, let them cook, then watch what happens when you timewarp to 1000.

Congratulations. You have an anecdote. This does not in fact change the reality, no matter how many times you repeat an anecdote. You are confusing anecdotes with data. And the fun thing about this... the real proof in the pudding is the jokers hopping over to the mod support threads who are in fact crashing and having weird non-mod-related bugs. I strongly suspect Ferram4 is not a big mean liar and in his install, this thing is still crashing. As it is for me. My install of Win64 crashed pretty reliably, so I no longer use it because the crash to game ratio was too high, and a Linux partition makes a lot more sense for me. As folks have stated (and what seems to be repeatedly ignored), there will always be lucky folks who, through a combination of hardware/drivers/blind luck get this to work reliably enough. And then there will be the rest of the people who, experience has shown, will try to ask for support and intentionally hide the fact that they are using Win64 and having Win64 crashes - who are completely convinced that it's the mod's fault, despite it being Win64 instability. The publishing of an 'UnFixer' is damaging to the community, disrespectful to the people providing you free content, and ultimately will result in less modders, less mods, and a push for more restrictive licensing (and we've already seen this start to happen). Now, if you feel that your personal crusade is worth that cost, nobody can stop you. But don't be surprised at what the end result is.

Kinda the point with CTT is that you use it in it's entirety as your sole tech tree, since it's whole thing is to provide an established node framework that modders can then populate without having 'surprises' or the headache of a dozen interpretations. It's what makes it a reliable foundation for mods (and why we don't have to bother including it in the bundle). i.e. I assume all of my stuff properly interops with CTT (so I include a config for this) or stock (as an intelligent fallback). Easy Peasy.

Whoah... No idea where you guys are getting the idea that there is some magical, random 'reference part'... but that's completely false. The point I was making is that once you're at or above 1000x warp - regardless of what heat mechanic you use - KSP switches over to analytic mode, and you'll see the heat distributed across the entire ship. And note that this has been this way since 1.0 - this is not a new thing.

Heat pipes possibly. Insulators would require no code, just low conductivity.

Close but not quite. Delpoyable/animated is a separate property from shipwide cooling. Just that the static panels in stock have no partmodules.

Funny. Was streaming over the weekend and ended up using radiators in their various flavors on pretty much every launch. Currently engine heat is the one relevant mechanic, but I personally like the idea that it buys options, for both squad and for modders.

Between CKAN, KSP-AVC, and the incredible ease of mod installation in KSP, ModPacks are unnecessary, and just cause headaches for the mod developers. You may want to look at how the previous modpack threads turned out btw

Hopping in briefly. Stock Radiators do not pull from the hottest part - as noted, they pull from all parts that have essentially said 'hey, I am getting too warm!', and distribute this accross all deployed radiators that have not yet reached saturation. The temperature at which a part starts dumping heat is purely configurable tho it comes with some intelligent defaults. At the end of the day, unless you model dumping coolant, all you are really doing is moving energy around. So if you want a part to reach a higher temp before radiators kick in, just tweak the config. I'd also add that insulators would still be useful for keeping a part configured to operate at a very high temperature from bleeding through to other parts. Also as touched on in mikegarrison's post, any mechanic that relies on localized temperature levels will have a bit of an issue when you go to 1000x warp as the ship will have it's temperature equalized across all parts, regardless of the conductivity, etc. of the components - so I would not consider mechanics based solely on maintaining a steady-state temperature overly reliable (this is one of the reasons I removed drill overheat as a mechanic in 1.0.1 - it was too easy to circumvent by simply going into high warp).

Ah! I thought my ears were burning. You do realize that for your specific example, using KSP-AVC as recommended would solve your entire issue. It's kinda why a lot of us use it. And it's a lot easier to have someone who sees an AVC warning just grab the latest FireSpitter vs. deal with the support issues of requiring a separate install and cries of 'why do you want me to install biplane parts??!' Side note: The only difference in FireSpitter versions from the one you have in Karbonite and the one I just updated a day ago (as I also assist with FireSpitter) is the KSP version. So in short, bundling will continue because some of these dependencies (CRP, FireSpitter, CTT, etc.) expect a certain folder. But the nice part is that all of these use KSP-AVC, so there's no reason to wonder whether you have the current version or not. - - - Updated - - - Side note - I do not 'force my own FireSpitter' - I use the one that we all share (and that I help maintain). So when KSP-AVC warnd you, you just delete the folder, and dump in a new version. Problem solved.

Because most people looking for support, after ignoring the warnings, are careful to not admit they have Win64 until they get caught. Same way people will tell you they have the latest version, have no other mods, did a clean install, or any number of things thinking they know better and that it must be a mod issue, not pilot error.

Mulch->Supplies is lossy. Mulch+Fertilizer->Supplies is lossless

Actually quite the opposite. Just like when there was a 'Fork' of FAR, they kept going to Ferram's thread to ask questions. So the net effect is that in order to prevent redistribution of software that ultimately causes the modders support issues, they end up having to resort to restrictive licensing (ala RealChutes). The most productive thing? Respect the wishes of the folks providing you free content. Pretty simple, really. If folks can be neighborly, we get to have nice things.

It's on Github but not in my repo look at the original one, not a fork.

Thing is, it's not your call whether a modder does or does not allow something. You can of course ask nicely, and as it turns out, several have said no. So your choice is to either respect their wishes, or wind up with restrictive licensing.