Nertea

It's Nehr-Tay-Ah, but I'm really not bothered :P. I've designed it to work 90% like existing KSP systems, so shouldn't really need a huge tutorial - there are engines, you put them on your craft. They work like other engines, with a few minor gotchas (some need to charge up before starting, etc). Read the engine descriptions! The key new feature you will need to really learn is SystemHeat, which has a small tutorial here. https://github.com/post-kerbin-mining-corporation/SystemHeat/wiki. For atmospheric harvesting, SpaceDust has some additional things to learn as well, but that's not really a key feature.

Doesn't look like this has much to do with this mod. This mod ships a tankType called 'SSPXFood' and manages it, it doesn't do anything with a tank called 'Food'. You have a lot of other mods present, might want to check which one of them does Food tank types.

CryoEngines 1.2.1 Updated CryoTanks to 1.5.6 Deconflict Waterfall and CryoEngines configs (zorg) Fix cargo parts for KSP < 1.11 Rework how engine fairings work in general to be more robust Recompress some normal maps to improve visuals of engines

CryoTanks 1.5.6 Fix for cargo in KSP <1.11

What KSP version are you using (and the most recent version of the mod, I assume)?

Hmm well it's hard to say what worked and what didn't. I took a look at your config and I don't see any evidence of anything other than 3 effects (flare, inner beam, outer beam). So it's hard to even say what may or may not be working. I'm going to need more info. I guess we can look at your steps: Ok, so far so good. Ok, well it could be in the file, yes, but it has to be outside of the PART {} block. Cleaner to put it in a different config and less likely to cause mistakes. The billboard shader is very sensitive to the model itself, if you want a billboarded plane I suggest using the builtin billboard model.

Yes, that is what would cause the challenge. You derive your converters from stock modules, I also derive the SystemHeat converters from stock values (and replace the thermal interface). To support your derived converters, I would need to layer on top of your derived classes, which poses some implementation challenges. However, I'm more concerned about solving gameplay before solving that, interoperation is just software challenges, that do need to be traded against the time available for modding. I don't think I could create an appropriate SH-driven user experience for MKS without a lot of work to match up the gameplay concepts, basically, which doesn't particularly motivate me to solve the software bits. Fundamentally MKS's use cases don't hugely benefit from the problems SH solves anyways. I suppose that could change, and probably would change with high demand.

I recall from development, and not including SH in a test install, that not adding it to your game will just cause mysterious loading crashes! I can say the nuclear fuel transfer system won't, for sure, but I had reports that the rest of the mod is fine.

MKS support is complicated. There's two things - technical and gameplay - that need to be considered. Technical: all MKS modules have their own implementation in software. As I don't expect MKS to take SH integration into its own codebase, you would need to build 'mirrors' of the modules in SH that include features like converter slots and swapping. That's a lot of work and very hard to maintain, as well as not likely not reverse-compatible with existing MKS saves. Gameplay: MKS modules have their own 'way' of working. They operate like stock converters in that they have a pattern where they modulate their effectiveness according to temperature and don't have SH styles of hard cutoffs. There's also a whole set of efficiency and general MKS mechanics you'd have to look at . Overall, you'd have to develop a technical SH implementation of the MKS converters, as per the first bullet, and validate that works with the rest of MKS gameplay, which is nontrivial. That would include busy work like assigning relevant fluxes and temperatures to a whole swath of MKS parts. Now you basically own support for all of MKS' converters. So to address this SH does preserve all basic stock heat functions of the radiators so it at least can be used alongside mods that use the stock heat system. A thought I had in the past would be to hack up the core heat module, so it acts as a mediator between the two systems. Somehow disable core heat consumption and stuff so old stock radiators can't pull from it, and have the heat module transmit its fluxes to SH. SH would then do simulation and push the SH temperatures back into the core module, and other mods using the Core Heat system would be none the wiser about which system was doing the heat integration. I didn't do this because: This would result in some pretty gnarly UX problems as the, e.g. MKS modules would still be 'talking' CoreHeat and that might be bad for the player's understanding. CoreHeat might still try to do some of its stranger mechanics with the values pushed into it by SH, resulting in explosions and the like, which is really the whole point of SH. CoreHeat internals are difficult for modders to work with at all. Other than those it would probably work. Generally, it's not impossible, but definitely a lot of work for limited gain. I'd rather spend the dev-hours on useful roadmap things, like atmospheric convection modeling for radiators.

But it looks so... dated :(.

No, it's the AR-1.

Nah, they are just modulated versions of the stock engine effects with fade in/out so they pulse.

Do you have KIS or something?

Hopefully people will let me know so I can add them to the OP.

Correct, I was trying to make the overlay also visible in the tracking station at one point, but the tracking station's weird.

I turned on the sound on my game, just for you, and didn't hear anything offensive. It's a repeating explosion sound that I guess if you're doing a long burn will indeed become... repetitive. Hmm, that used to work (maybe around 1.3...). I'll have to make an adjustment.

No radiator emissive support right now. I'll look at the Loop ID thing when I can.

It's an idea, but I think what people keep asking for is a really basic, from-zero 'how do i put an effect on an engine' guide. Which I can provide eventually.

This is the 'intended' model. Unless something changed in the way fuel flow is defined, the converter is set to be able to pull from other parts, which overrides the default fuel flow settings.

The wiki assumes you have config editing or MM patch authoring experience which might be a mistake, seems like some people are wanting to start without knowing how configs and KSP work to the extent I thought. You will need to learn this but I can try to add an overview. There are many examples in the WaterfallRestock distribution.

Check the wiki, the 'getting started' sections are up to date. Basically before you can play with things ingame, you do need to tell the game that the part will use Waterfall, by creating the appropriate Module in the config file.

Feedback is really appreciated. I have been meaning to do some kind of video overview but haven't found the time.

There's no Waterfall configuration for that engine, so did you create one? use a template?

It's compatible. Chances are whatever effect you're editing has something the editor doesn't like, what effect is it?

I mean, the NFLV engine mounts are 'only parts' too, so I'm at a loss.