Nertea

Not at all. Lots of work debugging for a one line fix. This is nearly ready, i just need to fix a couple more issues, will post when it's up.

Make a tested pull request.

Heat Control is just parts, they don't do anything special at all. The NFT Systems Manager was not designed to work with FFT because FFT is crap and old. You should follow this thread to see how things will work with SystemHeat. I don't have much to share, it will effectively function the same way as stock but not have infinite bugs.

Thanks, that's very useful feedback. I'm glad the overlay work paid off! I do need to do a balance pass for sure - I'd like to normalize the heat rejection by radiator area for sure. I recently learned that the stock radiators are massively broken in terms of thermal ability for mass - that needs to be adjusted. There are probably some edge cases to handle with the overlay, please let me know if you find anything definitive in terms of reproduction steps.

New update has been pushed to the repo. Notable improvements Fixed several null reference exceptions in the VAB Dealt with an edge case where ambient temperature could become equal to float.Max() at random times (lolsquad) Thermal simulation values in the VAB are no longer propagated to the pad Fixed several cases where the overlay could go haywire in the VAB

Both stock legacy particles and SmokeScreen particles are running on the Unity shuriken system. Stock uses maybe 1% of that system's capabilities, SmokeScreen uses more like 50%. These mesh-oriented FX are better for some kinds of effects than particles are - they will complement each other well.

The antimatter parts suffer from the same thing as the rest of the parts; they are fundamentally bad. They will need to be completely redone, along with everything else in the mod. The problem with the antimatter stuff is 4 large (3.75m+ engines), which are each 20+ hours of work. 3-5 unique tanks, which are also a bunch of work. Plugin work (I'm not really happy with how it functions now) That's a lot of work. So don't hold your breath. The concepts are still cool, and particularly I'd like to bring back the two antimatter-initiated engines, but I'm not scoping it. And no, I will not be leaving the old code/models in the mod. Ignore everything you know about heat, it will all be better with the newer releases. Eh, their gameplay is meh, not worth keeping around. I'd dedicate the effort to the IC fusion if I was going to spend more time. Some things for progress: the other day I rewrote the fusion reactor and engine code based on SystemHeat, and to be honest it is pretty great compared to the old stuff. Getting away from Core Heat has natively removed so many bugs. I guess I should also share a picture of the revised 2.5m fusion reactor, which is shown in that image. Last, but not least, working on some cool plume stuff.

Please submit it as a pull request on GitHub and it will make it into the next release This helped me track down the issue, thanks! SSPX 1.3.5 Fixed an issue where EPL being installed without CRP would cause the game to complain Adjusted some manufacturer names.

Yes, it's actually mostly done: There is a complete roadmap on Github now. Scope additions are unlikely.

The idea is that it's a higher thrust engine. If you want to use it in the atmosphere or in vacuum you can make that choice :).

That was a bug and was fixed less than a day after release.

A couple of variants for the NSWR, plus a heat glow version.

Do you have something else that conflicts? This mod disables itself if you have some kind of other fuel switcher running, like IFS or similar. I'm not 100% sure what you mean. If you mean 'you shouldn't have deleted the old parts', I gave people several months before I removed them. I'm not keeping garbage floating around in mods, particularly ones that are RAM-constrained.

Models were changed some time ago, new models have different dimensions. You can download an older version of the mod (check the changelogs for which one), install it, and use that to remove the old engines. Ensure you have installed the CryoTanks addon (packaged with the mod).

This is more about the backend of the system - what values are allowed for a loop. Convection in stock is garbage as well. Garbage is mean, it's functional for simulating re-entry, but again has issues when talking about timewarp and long-term things. Anyways I'm releasing this now for alpha alpha feedback. I need to start having people gather edge cases, report bugs, think about balance, etc. Be gentle, this is not at the polish level of any of my usual mod releases. Current feature list: A new heat system as described Some UI tools (overlay) to help with building ships Stock radiators, harvesters, converters and the LV-N have been patched to use the new system Things that are not done/known issues/planned: Anything in the Issues section of the repo Radiators always say they're overheated in flight None of the settings in the settings file work. More overlay fine tuning including tooltips and better cues for heat rates Support for my other mods (notably Near Future Electrical and Heat Control) Things that could use testing The utility of the UI and how well it communicates information The robustness of the thermal simulation in different situations Balance-type things You will notice a ridiculous amount of debug messages in the log, this is intended and helpful for debugging. If you do get some error please make sure you provide the following Logs Screenshots of thermal overlay and ship Screenshots of the thermal debug window, if possible To get it, you'll need to download the repo and install it by dropping the included GameData folder into your KSP install. I'm not making official testing releases. I'll post here when I've committed fixes or updates.

You can add as many keys as you want, it's a standard FloatCurve. It means that you can never cool a part below the ambient temperature, really, which isn't strictly true (say, a refrigerator). You're on Eve, so all your cooling loops are now at ~450K, which might have negative implications for life support and stuff that fundamentally would have temperature goals that could be either higher or lower than ambient. I don't support Kerbalism with any of my mods: they tend to do their own thing and replace the modules and code I make.

Yes, both are possible, but I won't be making either as part of the base mod. Yep. Yeah, I don't know how well this will react to 7 orders of magnitude, heh, I've only really been testing up to 5 figures, but it seems stable there! I'm always glad to see interest. The current model is deterministic. I have a mental note to provide a more physical temperature model for radiators, but the advantage of determinism is that the numbers can be cooked properly to account for KSP garbage, or to tune balance. Right now it looks like this for a low temperature radiator: temperatureCurve { key = 0 0 key = 350 150 } The keys are the temperature, the values the amount radiated. Nothing blows up if the loop is above the temperature, you just don't get benefits. A high temperature radiator might look more like this: temperatureCurve { key = 0 0 key = 1000 2500 } Again, it'll still work if you only supply it with low temperature coolant, but not as well. You could as an end user tweak it very easily as well. As you're coming from RSS, this is less relevant, but the idea will be to spec the stock radiators as ISS-like, with radiators that don't work well about 400K or so, and design the ISRU/drills to operate in a similar regime. This makes the system's interaction with stock very low footprint, you can deal with all heat generation and rejection generated by stock parts with other stock parts. When I get into reactors, nuclear engines, etc, it will make more sense to install radiator packs to get high temperature things. I actually have some experience in doing thermal modeling for smallsats, so I'm fairly aware of where I'm throwing out realism for gameplay. The best way to help is going to be hanging around, testing and providing feedback :). One thing that I'm struggling with right now is how much to make ambient temperatures affect the simulation, could use some input here. Right now I have it so that the minimum temperature of a loop can never go lower than ambient, which is an ok assumption sometimes, but it runs into trouble on planets and such.

Yep. For some reason CoreHeat configuration is in kW*50. You're correct, max cooling is drag cube calculated surface area*Stefan-Boltzmann constant* T^4. It's effectively unused ingame. Oof they're actually all off (the static ones). Apologies for that, but that's utterly ridiculous. The fixed radiators have 5x the mass ratio of the deployable ones. There's functionally no reason to ever use another radiator. - even with the localized cooling only, you can just spam them all over whatever unit you need with no penalty at all! Well, if you want to min/max to that degree, I can't really stop you. I'd have to bring all the things below 5000 kW/t, which would probably have the side effect of making all electric engines and nuclear power generation massively, massively OP from the current baseline. Yet another example of awesome Squad balance....

Thanks! I will have a look into this, it would be nice if you could provide the Module Manager cache file as well.

Might be Kerbalism, I don't support installs with Kerbalism because it changes the mod a lot.

I don't think that's correct. All stock radiators have a base mass ratio of 1000 kW/t radiated energy. HC basic radiators have 1750 kW/t, and the large black ones have 2250 kW/t. Stock statics are even worse and don't even hit 1000 kW/t. Part Mass (t) Heat Transfer (kW) Ratio (kW/t) Radiator Panel (large) 0.280 200 714 VR-270 'Tau' Heat Radiator 0.120 150 1250 XR-1800 High Temperature Heat Radiator 0.571 1000 1751 If you're seeing something else please go into detail. It's possible the balance spreadsheet I'm looking at is not up to date with ingame but that seems a little unlikely...

That's not really the whole picture, in LANTRs the additional oxygen propellant is injected in the nozzle throat or at the bottom of the actively cooled region, so you are only potentially increasing the efficiency of cooling anything downstream of that. The mass flow through the heating region (the reactor) is fully LH2 and identical in either case. I would be curious as to the trade off of any additional cooling effect - you are increasing the mass flow, but you are also adding a new combustion region that will add heat to the system as well. This might negate the cooling benefits. Injecting the oxygen into the reactor itself is not something that should be contemplated. Injecting in oxygen when it's gasified but not at very high temperatures would minimize the problem of oxygen corrosion, which is what the Triton system (the one whose papers I've actually read, other might differ). Such as system will actually be less taxing on components than a traditional rocket full flow combustion rocket engine because it limits the amount of hot GOX you're moving around. Can you explain what you mean here? There are some changes that will happen with the new heating stuff I'm developing, always good to get inputs.

Mmm, I'd disagree. The subcomponents of some fusion propulsion systems (notably mirror and magnetic inertia systems) have been tested to a degree that I think it's clear they would work with sufficient investment (note that these kind of systems are fundamentally easier to build than self-sustaining fusion power reactors). They're certainly at the same TRL as Orion systems, which have a large amount of internet wankery thrown at them as 'possible to build soon', typically based on the idea that sub-scale testing has been completed. Which is silly, it's the same scaling problem: can you scale a lab experiment up by several orders of magnitude with no issues? Really though - they're all FAR future. Whether you need a breakthrough in plasma physics, material science or heat radiators is immaterial to me. Can you build something that can withstand the fiery radioactive death cloud of an NSWR in atmosphere? Can you build a pusher plate and shock absorbing machinery that can survive a hundred nuclear explosions? Can you build a magnetic nozzle that can survive years of neutron activation and still function? They're all pretty messy. Anyways here's a thing that's cool, I hope.

Yeah this will need to be the case. I will probably keep the stock balance similar in terms of radiators per ISRU or whatever, but the second you throw my other mods in I'll be doing more exotic things Plus, in the near term this will be highly experimental. Things are getting close to useable...

So currently, the loops are fixed when you leave the VAB. When you dock two ships, their loops get merged - Loop 1 objects in Vessel 1 are now part of Loop 1 obejcts in Vessel 2. I had thought in the future to make it so loops are automatically incremented when docking so that loops wouldn't auto-merge. Maybe a good solution however, not the cleanest, is to preserve the merging behaviour but allow the player to increment loop IDs in flight, so you any changes to loops are applied to all members of the loop. That would allow you to create systems where you want to merge loops (docking radiators to engine), and systems where you don't (docking engine section to ship). Thoughts?