Nertea

I'm not sure you understand what I'm saying so I'll be more detailed. USI converters and harvesters are both derived from ModuleResourceConverter (and thus BaseConverter). SwapOptions provide different sets of parameters for that converter. When you select an option, those parameters are baked into that converter. The adapter module doesn't replace or touch the USI converter. It communicates with any module derived from BaseConverter, which encompasses the USI converters. It does this in a very primitive fashion: it causes the linked converter to add heat to a loop at a temperature, and causes the converter to be shut down if the max temp is exceeded. Nothing fancy. None of this directly conflicts with the swap system, which just changes out pieces of the converter (resources converted, rates, etc). The link between adapter and converter is unchanged. Like I said though, testing I did here was not a lot. So someone who knows USI needs to validate this.

Oh my bad I was going to add a comment about functional scoops there. Basically it seems you need to build something more plane-like.

It's hard to take these totally seriously without any mention of thermals or other things. Seems like you want more thrust in everything. Probably not happening! KER is going to have to be pseudo-recommended at this point, because stock DV also can't handle the Clarke for some reason....

If things work as expected coding is not needed. ModuleSystemHeatBaseConverterAdapter is specifically designed to NOT require replacing the target module - it just talks to any module derived from BaseConverter to translate heat values. The only unknown is SwapConverter, which this should handle in theory too.

Nope!

As long as you abide by the terms of the license you are probably fine. You should review: https://creativecommons.org/licenses/by-nc-sa/4.0/ You can generally set a shader param using an out of range value, those are more for the UI.

Thanks I'll check that Thanks for the note, not really an issue with either the way I've set up the repos or the repos themselves.

Not an easy thing to add but I'd accept a PR for it.

Doesn't for me. If you're using MKS there is a material kit requirement, which is not a repair kit.

Reviewed the linked thread, doubt that is the case.

I am modding about 1 evening a week now (which is tonight). So far I have not got many/any comments about the development version of NFE. I was guessing from that one of two things: (1) there's not much interest and/or (2) it's perfect. So make of that what you will. For that thing I still need at minimum to unwrap/texture the 1.875m reactor.

Unfortunately I have to point you to the FAQ.

In my opinion, the best solution is the one that does not require SWFE or WFR to be aware of each other. What you propose requires SWFE to be aware of Restock. The currently implemented solution does not. As to your questions. Yes that was the original effect, all patches were like that. It is common for users to disable restock patches, or more than I would like :shrug: Yes this is generally easier than trying to patch the very complex templates with MM.

I don't make mods for replicas so that's expected, yes.

Yes they use a custom module so it would have to be coded for.

I did not make it so I can't say, but you shouldn't need to change any textures or models, the props just need to be repositioned.

Sorry, not from me. That mod runs it's own heat system and generally is not very compatible with my stuff,.so spending effort adding compat stuff is odd.

Why on this green earth would that be intentional? Not authoratively.

It's an improvement based on the user need of wanting to have effects for non restock edited engines. This request is more common than all other requests so it should not be discounted. The prior options were to ask users to do config surgery if they wanted this, which was not ideal. You're right that it creates a possible issue in a certain combination of mods, but that combination is fundamentally an installation error so I am not concerned about handling that case. Other options included upstreaming SWFEs templates into the base mod, replicating those effects in WFR or creating new custom effects for WFR for those engines. All of those options require more maintenance work than the new model. In this way, both WFR and SWFE can continue to evolve and iterate without stepping on any toes.

The Ulysses is anomalously powerful for an upper LH2 engine. It's the outlier not the other way around.

Why the goddamn hell does this keep getting reverted?

There's a story for adding a user-editable field for 'additional' drain/draw at some point... but not soon.

Some kind of 2.0.5 release happened with things repackaged.

An update has been issued, with more generic bugfixes.

You can do this with a MM patch pretty easily, but can't really do this automatically, you would need to know the part names. Realism-wise, it might not be accurate, certainly MLI is used to cover tanks that are not ZBO frequently!