JadeOfMaar

The air tight seal around the joints will (by my guess) consist largely of the lubricant for the bearings and other contact surfaces where the spinning section meets the static section. The lubricant itself will have enough viscosity and cohesion that it also won't eventually try to escape too.

Thanks for the text. Sterling Structural

No. There are no Waterfall configs currently.

Try re-downloading and reinstalling B9PS and maybe also NF Construction. Sometimes B9PS spotaneously corrupts and misbehaves like this.

Howdy. I can give you a few reasons why this actually isn't an attractive idea: This kind of idea is incredibly subjective. Everyone has a unique preference. What particular combination qualifies to you might not to the next guy. Merely releasing (let alone maintaining after) clones of parts (even the exact same part) across multiple mods is automatically a chore and likely not fun at all. It's far easier for you the player to install the mods you want then delete or hide the parts you don't want. Either manually or through Janitor's Closet mod. I can argue that "Near Future Technologies" on the whole is a mod (well, it's definitely a mod suite). It's also definitely a universe because it's vast and pretty complete. The small "universe" that you're trying to describe reads more like a starter kit. True enjoyers of Near Future suite do not fear the size of it. They embrace it!

@RedDwarfIV Nice. It's good to know that folks will turn around now concerning the engines. It's a weird and uncofortable place to know that a whole notable fraction of players avoid them. I don't play with Antimatter at all, with or without FFT so, sorry, I have no experience to lend you with that popup window.

I just tried this mod again (v 1.1.2.99 from CurseForge, a little over a week ago and 1.1.25 beta 4 today) (downloads, all versions here) and the same problem I found a few years ago appears to still be there. The kuddle time estimate just keeps climbing and isn't promising. A coder friend pointed out that the accident chance RNG is using its value improperly which leads to 1% or less likelihood of actually getting moar kerbals. I remember that @linuxgurugamer did something for this mod but his work seems to fallen through the cracks in the floor here.

Holy Graham crackers, Batman! ... Nah

Did you make sure to do a clean install of the 3 OPT folders? Delete and replace, not merge the new into the old/existing. It helps to delete GameData/ModuleManager.ConfiigCache when lots of MM problems happen. If the B9PS problems happen to be really bad, consider re-downloading and re-installing B9PS too. The OPT downloads could have possibly corrupted too. Somehow it seems like your OPT install got completely busted and I don't put out that bad of an update.

Congrats on that! Currently there isn't a way but users of my other mods: Rational Resources Nuclear Family or Sterling Systems will have thermal power producing devices. I've wanted to rewrite the OPT power spheres to be sources of ThermalPower but I've been beside myself about it.

The question might be specifically trying to dodge the need for fusion processes. Unfortunately for the OP, I'm quite certain there's no dodging fusion tech.

Per some certain knowledge of the Periodic Table it is a given that the higher the atomic number, the less likely the given element is to even want to exist if synthesized, let alone occur naturally so forget about finding it in the wild. Fortunately, there is a thing called the Island of Stability where "Super Uranium" can possibly exist -- certain atomic numbers are predicted to be stable. There is a certain balance and two extremes to keep in mind when considering anything that is "powerful." These extremes are: Specific Energy: The energy density. How much total energy per unit of mass or volume can be extracted. Specific Power: The impulse. How quickly it charges or discharges per unit time. A fissile material with great sepcific energy has a longer half-life and a slower release rate is safer or more tolerable. A fissile material with great specific power has a shorter half-life and a faster release rate and is increasingly deadly. I would expect such a substance to have an extreme weight (like 2x Lead), to have a "generous" half life of only a year and it would pour out enough gammas to visibly ruin any material and environment within a few hundred meters (in atmosphere) of an unshielded sample and within a few hours of existing. From what I've been told and what I learned for myself we'd only really use this Super Uranium in giant reactors that could power whole continents or for torch drives for huge space colonies like in the Gundam anime metaverse. As for producing this Super Uranium it's anyone's guess. Whatever plausible device you might be able to think of that can produce this would need to be able to withstand the combined energy released by the newly formed sample's radioactivity and the energy of fusion at the moment of production. I imagine that this foundry, this production device, wouldn't last long if were to make respectable amounts of the stuff. That all said... We don't have so much need for a better fissile resource as we have need for nuclear reactors that can use it better. Current reactors use < 1% of their fuel rods, and in turn, produce other fissiles that we don't have the technology to make use of at all so we treat that as waste.

@Scotskerb You say MetalOre but you clearly have MetallicOre highlighted in your first screenshot and there's no MetalOre gauge. The "resource is full" message also comes up when all your tanks for it are all locked or (in this case) you have no tanks at all. I don't see anything in your mod list that suggest something makes the EL functions ask for MetallicOre so this may just be a case of "Oh, I misread. I'm tripping over two resources with very similar names."

A transform (or GameObject) is any object within your model hierarchy that has a position and orientation in 3D space. Some of these can be nulls or empties, having no geometry to speak of. The thrust transform is usually an empty but can be otherwise. You may use an object that geometry or is an empty. You can make an empty in Unity or Blender but you can't (afaik) do model construction in Unity as you can in Blender.

@KspNoobUsernameTaken It's a good start but just two things: Your pipes have too high a number of sides for how thin they are and the reflective surface of the mirror absolutely doesn't need a PV cell texture. It should just be black. In the config the transforms that you name will rotate around Y and point at Sun with Z+. The transform at pivotName (which rotates) and at secondaryTransformName (which points and is counted for resource production) can be the same, or not. You may need to swap Y and Z in Blender (rotate around Z, point with Y) since Blender does that.

@KspNoobUsernameTaken Omnistorage supports part variants (using the stock mesh switcher). Some Buffalo 2 parts have length switch and Omnistorage ties into that. At the least we can pretend that any Omni tank will have the proper internals added in order to support whatever resource is chosen. It doesn't concern itself with adding dry mass, dry cost, containment cost etc. Those things just weren't relevant when the code was written. It might be better to stick to existing B9-powered tanks if you care about those details. I'm familiar with template tagging (to lock recipes in or out of some omniconverter parts). I will do so where AntiMatter is concerned. Here's an example solar thermal panel for space ships and a member of my planned suite. It's based on the IRL parabolic trough variant and includes a generator. Included but apart from it is a 2.5m cylinder (see: Rockomax tanks) for scale. It's designed so that the mirror can do a 360 around the focal section (black pipe) (without clipping itself) while sun-tracking.

I just tested that mod and experienced a very familiar problem from when I last tried it long ago. It's a very bad logic error in the code. A coder friend said the accident chance is being used wrong, which effectively guarantees 99% (not 100%) failure rate. If I remember right, LinuxGuruGamer was made aware of it and even fixed it but that fix must have been lost somehow.

I haven't considered such a ratio since it does not compute to me to convert PV output directly to ThP output. But I do have a formula to use anyway. That is: Get the surface area and multiply by 0.00625 (that is, 0.625%) for the ThermalPower value. This ratio intentionally applies a nerf because in this case I would count on using a highly absorptive surface material, not a highly reflective one. I would hope for it to overheat under casual sun exposure in orbit and pair it with a very small, high efficiency generator. Such a panel will probably only ever make sense as a low temperature heat source (see: @Manul statement on temperature and waste heat). If you're going to make a proper concentrator model (or get someone else to) which involves a parabolic reflector and a focal point then get the surface area and multiply by 0.05 (5%) for the ThermalPower value. I have a special handling planned for fusion and antimatter reactors. I've learned a lot since making the original fusion engines that are already out so it's a good thing I didn't release more already. WBI integration This is on hold until ISRU parts arrive. I'm at odds with the Omniconverter system since it currently doesn't integrate with System Heat and that I found a pretty worrisome bug with its efficiency scaling. That bug can be avoided, I just need to look back and see what not to do with it. However, I'm going to need it because I don't want to spam the PAW of the refineries with the buttons for every recipe I'm going to write for them. I rather like the idea of having slots and swapping recipes in them. I'd like to make an Omnistorage compatible tank suite as well but it will have to have less options for diameters and variants. I'd rather not do a load of repeat work just to be cautious of another fuel switch plugin. At the very least, the SULEU has more dry mass and it has equal heat production base value so while it produces more thrust it will produce as much more heat and you should see the need for radiators much sooner when you do a very long burn with it (and this is without the System Heat mod). With System Heat you absolutely need it to be in a heat loop and it will ask for some radiator capacity. But the demand is currently way excessive, which will be fixed soon-ish.

@Oaterson I'm glad you like. Per your question: Sterling's SULEU engine. It's not that it's OP (and it could be so, even thrustier, but that would absolutely turn people away and even threaten the relevance of other engines I've made). Rather, the stock NERV is underspec and for two reasons: To not far outclass the stock LFO engines (which is what you actually want when you go nuclear) and that there are known design faults that plagued it and caused it to underperform IRL. The SULEU draws from updated NERV or NERV-alike designs (American in origin or otherwise) which escape these faults and employ newer knowledge that may not have been widely available at the time and was certainly not available to Squad. Part of the vision of my mod is "Plausible high thrust concepts preferred" because as much as anyone, I don't like the idea of crawling through the stars in-game and there are enough mods that provide largely low thrust engines. Sterling's thermal nozzle family. They are OP by nature, however, you have to look at them from a new angle and apply new understanding. They are "What if you took the immense heat generation capability of your nuclear reactor and used that as the combustion source?" The angle here is "Rather than worry about insufficient power (TWR) and spamming engines, you keep a big reactor and take stock of your surplus power (thermal) and limit it (throttle limit the nozzle) to suit your needs." You only think my engines are "cray-cray" because you didn't know yet that there are concepts for high thrust solid-core NTR. If we can have gas-core NTR and NSWR, certainly we could improve the NERV itself and make it amazing.

Yes to both.

You're right. ExoticMinerals is missing. I'll fix and release that very soon. Rational Resources doesn't have anything in itself to do with that so it didn't seem important and it faded in priority.

If I remember right, MM doesn't like it when you do a node creation (there's no operator prefix on the node) but you're doing an edit inside (there's an operator prefix on a key). Your edit operations must exist inside a node edit. These examples should be helpful. // bad MODULE // Has no prefix. This is an insert, not a patch { %name = Tweakscale // why is a patch action here? scaleType = Free otherKeys = ok } // good %MODULE[Tweakscale] // Has prefix. This is a patch operation. Also, if this node accepts a name key, skip it and put its value in the [] here { %scaleType = Free otherKeys = ok } A root node is any node that is top level and isn't a child of another node, like all the PART nodes, the EVE_CLOUDS node (used by the same visual mod) and so on. // bad %PART[someName] // MM might not like it when you % create a root node with or without a name { ... } // good PART { name = someName otherKeys = ok } @PART[someName] { newThing = this @otherKeys = stillOK }

Heck yes. Also yes. If you're curious to what the engineering differences are and why I won't touch the stock parts, let me know and I'll give a quick answer.

I did not encounter this error for myself and I have no other guesses for what the cause might be. Once you have no ModuleManager errors, send me your GameData/ModuleManager.ConfigCache, your KSP.log and your Logs/ModuleManager/<files>

Hah. Well using Methane is still simple, I'd like to think. I have plans, and very different plans for sail propulsion but it'll be quite a while before I start doing anything about that. As for solar thermal panels, no. As much as possible I now avoid adding to or changing stock parts. If I have the drive to, I'll make my own models for the job.