TBenz

More or less. LH2 engines make for good upper stages, and LF makes for good launch stages. Normally the resource amount just slowly decreases. Every LH2 tank can cool itself using EC is you enable the coolers, and the cryogenic tanks cost less power to cool LH2 than normal tanks. What I like to do is design stages of my rocket using different engines and fuels and compare their statistics. Whatever best fits my needs gets used. But you can use the lower stage LF and upper stage LH2 as a nice general rule.

The original Project Deadalus proposition was meant to reach 0.12 c and we know that engine design is going to be in KSP. While that doesn't necessarily mean we will be seeing the same level of performance, I don't believe it is off the table. I also think it's very likely that the distances will be cut down to "kerbal scale".

That looks like a typo of "size0p5, size0". I also imagine all the #p#'s stand for #.#. I'll also throw my support behind this: Although @CobaltWolfcould probably best answer how the BDB sizes should be named.

Well you have FAR installed, which isn't actually compatible with 1.11, but as far as I can tell, that incompatibility shouldn't be breaking the parachutes. But only that and Restock are playing with the parachutes, from what I see in the logs. You may need to downgrade KSP to 1.10.1, and pick versions of the mods built for that. You probably also should bring this issue up in the FAR thread, since it almost certainly isn't kerbal atomics.

Something is deleting the parachute module from the parachute. We need to know what other mods you have installed, Kerbal atomics shouldn't be touching the parachutes at all. A look at your player.log would be very helpful as well. See the instructions below.

KIS 1.28 isn't compatible with any KSP version before 1.11, you either need to update KSP to 1.11 or get a previous version of KIS (1.27 should work). Are you also on a KSP version older than 1.11?

IIRC, this is something that stock does to make the heat shield fit nicely, and restock does the same thing in order to not deviate from stock form.

Oh for sure. I've definitely been thinking about whipping up some patches for modded fuels on the production to hopper side of things. What I was more getting at was that transfer credits are created with LFO, to cover the fuel aspect, but you can setup routes using vessels that use much more exotic fuel sources without needing any supply chain for that fuel.

That one's a toughie. Part of the reason for making you do all of those journeys to build up your transport network is a balance function. Here are my thoughts. There's already a decent amount of work in establishing the depots with the necessary supplies to support a transport network. Not to mention designing and testing the transport. I don't want to suggest that anything after the first flight is going to be completely routine for every flight, but only the most extreme routes are going to be interesting after 4-5 flights. If someone is setting up a large network of multiple smaller vessels running the same route, it's going to get boring. A case could be made for that being a balancing factor meant to favor a smaller number of larger vessels, but lots of videogame players will grind out boring things if it gives them some benefit. They'll willingly subject themselves to that, and in some cases even have the audacity to blame the designers for designing it in that way (even though they are the ones who chose to play it that way). I'm not so sure that balance by tedium is the best approach. I'd vouch for letting a single journey count as a test flight that can be used for multiple duplicate routes. Also, while I'm here, I'd also like to put support behind having transport routes be more considerate of the fuel burnt. The current system works well enough for LFO, but it breaks down with xenon and modded fuels. And not just in terms of cost, but also availability. Right now all we need is WOLF-ized LFO production to field vessels fueled by xenon, karborundum, or even the crazy FFT fuels. I understand if this is too complex or otherwise beyond the scope of WOLF, and I definitely don't want to suggest you need to worry about supporting all the different mod fuels out there. Just wanted to put my thoughts out there about something I think would be cool to see.

The github has a decent wiki describing various aspects. https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook Here's an example of a MM patch doing something similar to what you want. @PART[USI_Nuke_*]:FINAL { @MODULE[ModuleResourceConverter]:HAS[#ConverterName[Reactor]] { @OUTPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]] { @Ratio *= 10 } } } This will look for every part that has an internal name starting with USI_Nuke_, find the module for the resource converter with a ConverterName set to Reactor, find the output resource of that converter with a ResourceName set to ElectricCharge, and then multiply the output ratio of that resource by 10. And the :FINAL tells it to run after everything else (FINAL is typically reserved for user created patches, as opposed to patches that get distributed with mods for compatibility support). To get a patch to work, all you need to do is put the patch in a file with a .cfg extension somewhere in the GameData folder. Edit: I should probably note that I haven't tested this patch, so for all I know there could be some stupid syntax error present that I overlooked. Also, the practice of patching everything that matches a name with wildcards might not be the best, there is a chance that something not a reactor could slip in. It would probably be better practice to look for every part named "USI_Nuke_*" that had a Reactor module, but I was feeling lazy.

The textures for the nosecone aren't in the same directory as the .cfg and .mu files. Instead they are in: Squad/Parts/Utility/rockomaxAdapters/Assets/ You could whitelist the entire directory for simplicity, but that will also load in the 3d models for the two 1.25 to 2.5 adaptors. Not that big of a deal, but it will unnecessarily increase the load time by a bit. If that matters, you could selectively whitelist the following 5 files: Squad/Parts/Utility/rockomaxAdapters/Assets/Rockomax_Adapters_diffuse Squad/Parts/Utility/rockomaxAdapters/Assets/Rockomax_Adapters_diffuse_O Squad/Parts/Utility/rockomaxAdapters/Assets/Rockomax_Adapters_diffuse_W Squad/Parts/Utility/rockomaxAdapters/Assets/Rockomax_Adapters_normal Squad/Parts/Utility/rockomaxAdapters/Assets/Rockomax_Adapters_normal_O

Why not just disable the KSPI-E override and create your own patch to give the reactors comparable output to what they had with KSPI-E? It'd be a heck of a lot easier to do than what you are messing with. A MM patch to increase the OUTPUT_RESOURCE Ratio key would be dead simple to do.

It's come to my attention that the sabatier part's ModuleResourceConverter has a 'converterName' key in lower camel case, while the convention I've seen in the stock parts is 'ConverterName' in Pascal case. I don't know if KSP is case sensitive in regards to the ConverterName, but module manager is case sensitive. Any MM patches that look for a 'ConverterName' key in the sabatier will throw an error, for example: the generic converter patch for System Heat. Would it be possible to get this key changed?

The US2 Sabatier's converter has a 'converterName' key and not a 'ConverterName' key. Since module manager is case sensitive, this causes an error. I'll make a post about it in the US2 thread.

WOLF is a new feature in MKS that allows for more abstract base building and logistics that doesn't have the same limitations as actually leaving dozens of vessels with stock resource loops everywhere.

Windows 10 should absolutely have a LocalLow folder. Can you at least find the Local and Roaming folders in AppData? Space Dust doesn't change the stock resource system, it adds new ways to harvest resources. It comes with configurations for many stock resources and some moded ones (liquid hydrogen, antimatter, ect) and can be expanded by other mod makers to include even more resources.

What operating system is your computer?

I believe your best bet for kickstarting production would be to establish a depot on Kerbin that can produce Transport Credits, and then set up a transport route from Kerbin to Minimus. (In fact, I assume that is one reason that Depots on Kerbin get material kits by default, to overcome the bootstrapping issue). Once you have established yourself better on Minimus, you can see about cutting off your reliance on Kerbin entirely. The way WOLF works and the way the stock resource system works means that "reverse hoppers" would be very easy to cheat with.

It looks like you have Kerbalism and Snacks installed at the same time, which is causing multiple different conflicts in the way SSPXR patches life support. Kerbalism actually lists snacks as mod that is "major[ly] incompatible", so if you do have both installed it is a small miracle that SSPXR was the only mod with serious patching conflicts. And even if you could get MM to choke through the patches for both, the two would end up seriously stepping on eachother's toes during gameplay, which would result in a lot of strange and undesirable behavior. Since Kerbalism has its own implementation of food, you are probably best just dropping Snacks entirely. Also, Kerbalism is very, VERY, aggressive about overwriting the contents of other mods. It essentially scrapes out all the game mechanics of other part mods to inject its own modules. Which means that, if those parts break, it's typically Kerbalism's fault. If you have any more issues while using it, you will probably want to check with the people at Kerbalism first, they tend to have a better idea of what these kind of "Kerbalism-ized" parts are up to. Generally I'd recommend only using Kerbalism with a small and carefully curated set of mods that you can be sure Kerbalism properly patches.

MKS comes bundled with Global Construction (ground construction) which allows on site construction of vessels. Edit: Also, now that WOLF is live, can we get an easier to find description of how it works and what it does? I know there is one floating around somewhere, I've read it before, but I can't for the life of me track it down again.

There is absolutely something going wrong if you weren't getting any CO2 on Duna or Eve. I don't see any harm in posting logs for us to take a look at. Additionally, resource definitions for Kerbalism (including CO2 distribution) are handled by Community Resource Pack, so you might want to check out that thread.

Can't do much with that little of info. I'd suggest following the steps here.

Pendulum fallacy assumes a fully rigid rocket. Which is a fair assumption in real life, but KSP rockets can get a lot more flexible. So for this use, the "pendulum" design has benefits to stability.

It's not a bug so much as a consequence of how KSP is handling inventory images now. The images for parts a pre-rendered, so restock would need to replace the stock thumbnails with restock versions.

That would probably be miniAVC which has no idea whether or not Mech Jeb won't work, and just claims incompatibility because MechJeb isn't listed as being compatible with 1.11 yet, which in turn is probably only because the mod maker hasn't gone and verified compatibility yet. It may actually work fine.