Nertea

You could make PDEs and RDEs by patching some jet engines to have slight bumps in capabilities. Though they barely exist, it seems clear that in most contexts they would look very similar to existing jet engines. It's fundamentally like making different models for engines with slightly injectors, which isn't really interesting to me. Ultimately I model what I like... I encourage discussion but really the final choice of what to include is driven by what I want to create in terms of gameplay. There is some lip service to realism but most of these engines require major engineering or physics breakthroughs to work. If I twist it a little, I'm not very concerned. I have mostly wrapped up texturing (earlier image was mostly plume) for the second fusion engine, the Spherical Tokamak. A classic, really.

If you only want to change that option (and leave the rest of the options alone), I can't give you a quick guide. It is nontrivial and you're better off just turning off fairing replacements if you're not familiar with module manager. I think the aero parts are fine, we're not going to be replacing them beyond adding some normal maps to the ones that lack them. That list of parts is certainly not going to happen. Mk3 expansion/ Mk2 expansion probably have most of those.

If you installed a different tech tree halfway through a career game this may happen. If the mod in question copies the stock relay after NFX I'd expect that, so yeah, but with a name like ExtendedAntennaProgression I'd expect it to run before NFX. Cool, yeah that just happens sometimes. I think it's related to drag cube rendering or something and seems harmless.

God no.

So yes, I am working on FFT again. I seem motivated and no more KSP2 for a year gives me some time to finish it. However, a major scope and content restructuring will be happening to make this reasonable. Expect little to no compatibility between older versions and this one. All antimatter mechanics are getting removed: this is necessary to keep the scope reasonable. All inertially confined engines are getting removed for a considerable rework and should not be even considered part of the mod for the time being. This includes the z-pinch driven engines. Magnetically confined fusion engines are being reworked artistically as can be seen, but also mechanically with different sizes and capabilities. Probably more on that as they get done. Fusion reactors are sticking around and should stay largely the same as they are currently. Exotic fission propulsion systems are getting strongly reworked but should still be in the mod. This means the NSWR and FFRE. Metallic hydrogen propulsion might be going away.If not it's getting a similar treatment to the inertially confined engines and getting taken out for a heavy conceptual rework. ISRU equipment is being revised and edited where appropriate. Some of the models are salvageable, others will need a rethink conceptually and artistically. I'm concurrently developing three utility mods that are required to make the mod work the way I want. These will not be optional. SystemHeat, which overhauls heating Waterfall, which is something I and a few others have been working on to drive better engine effects SpaceDust, which is a piece of work to overhaul the buggy garbage mess that is atmospheric and exoatmospheric harvesting in stock. An initial release will be available when the fusion, fission and ISRU systems are done, and the three support mods have reached a sufficient level of stability.

Not really the right thread, it's not hard to do that (see many examples in my mods). However do consider that 'because it is like this in RL' is rarely a good gameplay mechanic.

Well, I just want to ensure you have the latest version of both mods installed. I can't reproduce this error in my current install (1.9.1, with most recent version of Near Future Electrical and Dynamic Battery Storage installed, nothing else except Restock). I have to assume at this point that there's some kind of mod interaction going on that isn't clear, especially since there are lots of non-NF related errors in your log. To get more help, you could post: Your ModuleManager cache file Go into the Dynamic Battery Storage folder in GameData and find this file. Change DebugMode to True, then try the game again and post your log. Definitely don't see this kind of thing in my install. I'll check the log when I'm off work but you could try clearing your MM cache and your part database. I assume you're running the latest version of the mod and fully updated versions of all the dependencies (particularly B9PS).

It makes a DOOF noise.

I'll try to summarize... It would be more accurate to say that thermal issues come from the systems on the spacecraft, not the solar panels. Sure, the solar panel is only 30-40% efficient based on insolation, but this inefficiency is misleading - the panel also re-radiates on the rear, and is coated to reduce the absorption of energy that can't be transformed to electrical power. That gets rid of most of the excess. The end result of this is that most modern spacecraft don't need dedicated radiating hardware for their solar panels - even the ISS's prominent TCSes are primarily designed to radiate to the interior. The real need for radiation comes from components that take that power generated and use it - whether that is for life support or other functions. That heat is usually generated inside the component and needs to be moved somewhere outside to be radiated. To top that off the inside of spacecraft are very sensitive, usually containing electronics that have a death threshold in the range of -60 to 60 C, and functional temperature ranges that are only 10-20 C wide - which incidentally also applies to humans. So overall the problem is less about getting the heat from the solar panels dealt with, but the heat from the things that use the power the panels provide. Still though most unmanned spacecraft don't have radiators - this is because overall, it's pretty easy to do thermal control without active systems - you put a heat conducting surface from your electronics to the outside of the spacecraft and the bus does the radiating. With clever design you can do this well and really minimize your total mass. Caveat is when you move inwards from Earth you change this heat balance equation - but usually, you will not add cooling to your solar panels, instead you will just cant them or design your ship with an appropriate sun shield, which is more mass efficient and mechanically simpler. If you move outwards, you have the opposite problem, but you still avoid active cooling if you can, and rely on louvers or similar surfaces to help limit heat loss. Functionally though, humans generate so much heat, what with them being complex chemical reactors that need all sorts of feedstock, that it's hard to do this passive heat rejection work. Almost all manned spacecraft have some kind of active thermal control, even if it's simply a roll maneuver. Any time you have high power electrical systems you probably need to do this. Hopefully that explains things better, I am not a spacecraft thermal engineer, but I need to deal with their decisions sometimes No major environmental interactions, and no changes to crew mechanics, through the door will be open to others to add that.

Boop.

Yes, you did not answer my question when you last posted this report.

So you are describing the thinking I took when I started, which is an example where order matters and is critical for functioning. If you go Reactor (+1000) -> High Temp Radiators (-1000) > Processor (+1000) -> Low Temp Radiators (-1000) -> Reactor, that works. If you go in any other order, it doesn't work. The two options would then to create a system where the user has to do ordering, or you solve the ordering algorithmically. I don't love either of those solution. So... Instead, I'm saying in this concept that all heat producing systems always exist in a virtual sequence before radiators - it's Reactor (+1000) > Processor (+1000) -> Radiators (-2000)-> Reactor. In this model, your 3000K reactor flow goes into a 300K snack machine and cooks it. Or, if the order is reversed, your processor dumps already-heated coolant into your reactor which is probably bad. It's a simplification of the same system which lets you order by creating two loops: [1] Reactor (+1000) -> High Temp Radiators (-1000) > Reactor, and [2] Processor (+1000) -> Low Temp Radiators (-1000) -> Processor. I guess you could say that operating temperature is the temperature of the coolant before it gets to the radiator. It's true that you could also say that temperature doesn't matter - if there is no concept of ordering in any way, then this is all pointless. Just balance the fluxes and you're good... and now you're basically back to Core Heat, but maybe with variable temperature radiators. So... not a mod i want to make.

Not really, I'm not going to rewrite everybody's systems to work with this. If they want to do this that's up to them. I will provide appropriate adapters for all stock modules as well as my own. Under certain circumstances, sure. If the hot part runs all the time though, when we're thinking about orbital transfer times of thousands of hours, you would need a truly shocking amount of loop volume to stop it from heating up. Water heats up, for example, at about 0.20 K/kW/kg, and a decent size NFE reactor outputs about 1 MW of waste heat. That would heat up 1t of water by almost 800 K every hour. There's no reason you need to use any type of radiator to achieve appropriate heat transfer, but that might be inefficient in terms of mass and cost. It's really important to note that number and type of radiators have no effect on the temperature of the loop if there is enough radiative capacity. I'll try enumerating it another way than the OP: A loop has an operating temperature, which is derived from the various systems in the loop. You could think of it as the average of all systems contributing, if there is something at 3000K and something at 300K, the loop will be operating at somewhere in between. It's a little more complicated than that but it's good enough for this. This operating temperature already might be too high or too low for some systems that are part of the loop. If the loop temperature is too high for a system in the loop, it will have negative consequences. If the temperature is too low for a system in the loop, there might be negative consequences (haven't decided yet, this might make things too complex). When systems are on in the loop, it will slowly increase from its current temperature (starting at ambient) to the operating temperature (regardless of amount of radiative capacity) The speed of this is dependent on the amount of energy going into the loop and the total volume of the loop (realistically that's basically the number of systems in it) A loop increases in temperature above the operating temperature only if there isn't enough radiative capacity. A loop never decreases below operating temperature (currently) This way, you have two mostly orthogonal problems to solve. Regulate the operating temperature of the loop, and regulate the radiative capacity of the loop. If you mix these problems too much, you end up with an undergraduate level thermodynamics course. There are some couplings in that radiators are more effective at higher operating temperatures, but they are intentionally minimized. It's not like it's hard to do. I just don't think it adds a ton to gameplay - it's effectively a nerf to all solar panels. I could also go into why this is less of a problem than people tend to think. Hard to stop all the cheesing really - i mean, consider radiator occlusion in general...

Good thoughts, let me see if I can explain them. There is no directionalilty to the loop. The colour is currently the loop ID. There are other indications not shown there An icon shows up on each system if the loop is too hot for that sytem The loop line glows red if the loop has a net positive flux. Yes, and this will work very well as long as all the systems in the loop can operate at the same temperature (more below). So where this breaks down is 4. If you placed everything on the same loop, the life support systems, that operate at a low temperature (~300-400K) are in the same loop as the nuclear reactor, which operates at maybe 3000 K. That's bad. The systems in a loop determine its operating temperature in proportion to their volume contributed - a small LS processor would contribute a low volume and probably a low temperature, whereas a nuclear engine contributes a high temperature and volume depending on how big it is. Loops want to get to their operating temperature. This loop' operating temperature determines the 'bad' effects on the parts connected to it. If the loop is very high temperature (involves a nuclear engine, maybe), and life support is on that loop, the life support parts will experience negative effects of overheating. This does mean that the most efficient way to build systems is to have a different loop for each system of different operating temperatures. However as you point out, that's probably not the most mass efficient way to do things. This is the design trade of the mod overall - how many different loops, and with what parts, provide the best experience for your ship? Is it one loop, where you run your nuclear engine and rely on a large amount of coolant volume to not cook your kerbals during a burn and shut it down right after? Is it a pair of loops, one with specialized high temp radiators for the reactors, and one with low temp radiators for the LS? Yes, no issues there. However, lower temperature radiators don't radiate as much heat away, so you will need more. More radiators is a linear increase in radiative capacity, but running at higher temperatures is a quartic (^4) increase.

Actually that's already supported. Systems add volume to loops, more volume makes the loop heat up and cool more slowly. You could easily make a system that added and subtracted no heat, but had a large volume, which would be added to the loop.

It is not. One of my top reasons for doing this is communicating exposure elegantly to the player is fairly challenging. It's also going to be computationally expensive. Currently the minimum temperature that a heat loop can have is the local environmental temperature. Because most of these temperatures are below the operational temperatures of most parts, it's not really a major gameplay thing. There is no distance effect - this is assumed to be a perfectly efficient. Or that it has enough margin built-in I guess. That's correct!

I'll check out the first two, the latter is kinda... well, I know about it, it's a fair bit of effort to fix but it's harmless. You can make those yourself using parts already. Yes.

System Heat [0.8.0] Replacing KSP's Core Heat system This mod is intended to provide a better experience for heat management, particularly geared towards resource extraction, high energy engines, and nuclear reactors. With this mod, I want to represent a couple of design challenges that come up in spacecraft design. Spacecraft usually have to deal with a number of different thermal systems for different purposes, due to the varying heat generation requirements of various things on them. Humans make heat, electricity makes heat, nuclear engines make heat... and they tend to do so at different rates and in different ways. You usually can't just put 50 Thermal Control System (large) parts on the ship and have everything work - you have to think a bit. Gameplay Concepts Heat Loops In this mod, all parts on your vessel that generate a lot of heat are part of a Heat Loop. This is a representation of the flow of heat via hidden coolant pipes through the functional components of those parts. Heat producers include reactors, life support processors, ISRUs, drills and that kind of thing. Radiators and similar things are consumers. Your job, as the spacecraft engineer, is to construct Heat Loops such that they have a balance of heat production and heat consumption by placing the right parts in the right loop. There can be several different Heat Loops on a vessel with different parts assigned to them (though a part can only belong to one loop at a time). If the loop is not balanced, it will heat up and its Loop Temperature will increase. At a high enough temperature, systems in that Heat Loop will stop working or even be damaged. Heat Flux Any part that produces or reduces heat has a Heat Flux associated with it - that's effectively the amount of heat produced or consumed by the part. Generally, parts that are more complicated produce more heat, and radiators that are larger and more technologically advanced remove more heat. Within a Heat Loop, you want to balance the Heat Flux added by parts with the Heat Flux removed by parts. Temperature Parts that produce heat have a Outlet Temperature that is associated with the Heat Flux it produces. You can think of this temperature as the temperature of the insides of the part, like a reactor core. Once coolant comes out of those insides, it will be quite hot. Every system connected to a Heat Loop contributes their Outlet Temperature to the loop's Loop Temperature. If the Loop Temperature hotter than a part's Outlet Temperature, that part will generally function badly. Within a Heat Loop, you want to make sure all of your heat producers can handle the nominal Loop Temperature - a very hot nuclear reactor in the same loop as a sensitive resource processor may melt its insides. Loop Temperature also affects the effectiveness of any connected radiators - more heat is radiated when a radiator is very hot, and different radiators may be better for higher temperatures. User Interface and Overlays TBW Documentation I am expanding the GitHub wiki with what I hope is solid documentation. Currently the basic gameplay is covered. Part Types This mod supports the following part types: Converters: resource converters work just like stock parts, but they contribute Flux at a Temperature to heat loops Drills: resource harvesters, asteroid drills have been adapted to contribute Heat Flux at a Temperature too Radiators: radiators are of course supported, and now not only have different outputs, but different effective temperatures. Basic stock radiators work at a low temperature so might be best supplanted by mod radiators for fancier systems Engines: though most engines dont produce heat in this model, some might Fission Reactors/Engines: reactors and engines that produce heat, power and thrust from fissioning of fissile materials Fusion Reactors/Engines: reactors and engines that produce heat, power and thrust from fusing light materials Cryogenic Tanks: tanks that slowly heat up without some form of cooling, causing their contents to boil off Downloads Please note that the package download only affects radiators immediately and is fully reverse compatible. However, it contains several Extra packages to do affect stock parts. These may affect your save - they won't break anything but ships flying with hot parts may not work. Extras Several Extras packages exist SystemHeatHarvesters: Converts resource harvesters to use SystemHeat SystemHeatConverters: Converts resource converters to use SystemHeat SystemHeatFissionReactors: Converts mod nuclear reactors to use SystemHeat SystemHeatFissionEngines: When installed, nuclear engines will have integrated reactors that may require cooling at high power levels SystemHeatCryoTanks: When installed, tanks configured by CryoTanks will not use power and instead require cooling Frequently Asked Questions Q: Can I add this to a save in progress? A: Yes, if you use the base mod. However, if you use any of the Extra packages to adjust existing converters, reactors, and such, your existing vessels might overheat as the balance is different and the gameplay paradigms are not identical. Dependencies (Required and Bundled) Module Manager Licensing All code and cfgs are distributed under the MIT License All art assets (textures, models, animations) are distributed under a All Rights Reserved License. All bundled mods are distributed under their own licenses. Download Mirrors Primary (GitHub)

Your log doesn't present any immediate suspects. Are you using the latest version of all the mods, specifically DBS and NF Electrical?

I just released CryoTanks 1.5.1 with the one-line fix for this.

I left the testing flag for banning cooling on in that patch. Goddamit.

Well... not really. You just made it there! I'm not planning on BDB-alike things, but there are engine plates and interstages in the mod now, and very good generic ones in Restock now Log file minimum please. It sounds like you have installed things incorrectly, useful to provide a log, maybe a screenscap of what your GameData looks like...

No parts are replaced in this way - internal names are always preserved.

Cool, maybe Squad actually fixed something in the last couple patches lol. I believe (not totally sure) that you need to copy the effects block for the other mod to make all the effects (including sound) work. So adding a new fx-lch4 block, then changing the effect in your newly added LCH4 ModuleEnginesFX.

I would go look at the ConfigCache to see what your patch actually resulted in next.