undercoveryankee

TAC Self Destruct is a little more versatile, but this is funnier. License?

The square-cube law also works against you in terms of strength versus mass, limiting how much acceleration a larger structure can take. For KSP tanks that survive in excess of 10 G at any size, full or empty, similar mass ratios at different sizes feel reasonable.

AM collection locations are based on the current size of Kerbin and the current planet's size and rotation rate relative to Kerbin. So they should remain safely in space under any RSS config unless you give a planet an atmosphere height of several times its radius.

Once a reactor design matures enough to where you can build several of the same model without a lot of project-specific engineering, the price should come down from "non-trivial percentage of GDP" to "too much to spend on an expendable stage, but attainable if it's going to be reusable." If somebody comes up with a couple of contracts that make it faster to acquire funds using the early Interstellar parts, I'd be happy with that overall.

As far as I've ever seen, your choices are the slide-out tab or blizzy78 toolbar. Personally, I've been using the slide-out tab long enough that I'm used to it, it doesn't take up that much useful real estate on the screen, and with the stock toolbar icons as big as they are I would probably keep the tab until we get a choice of button sizes.

I like it. I would probably name the top-level nodes something like ATMOSPHERIC_RESOURCE_PROFILE and OCEANIC_RESOURCE_PROFILE if it were up to me, but the concept is solid. Using ModuleManager to inject a resource into an existing pack or change a resource from information-only to extractable is possible, and a patch that specifically looks for and tries to modify a known pack will be easier to write without breaking anything than a patch for "any definitions that happen to be loaded." If we adopt this, it will be nice if pack authors try to keep up a wiki page with the names of published packs and try to avoid using the same name for different packs.

With respect to config files, what you're distributing is the source. Art assets (models and textures) are a more interesting question. The forum rules' requirement for source is specific to plugins, so distributing art assets only in the in-game format is fine for forum purposes if the models are obtained under a license that allows it. The GPL contains a definition of "source code" as "the preferred form for making modifications", which would require redistribution of editable versions of assets (e.g. Blender files or layered .psd textures) if the person who GPLed the assets provided them.

It's generally safe to have an older version-numbered ORS dll in the folder of a plugin that depends on it, as long as GameData/OpenResourceSystem/Plugins/ contains the most recent version and there are no duplicate resource keys. It worked to have UmbraSpaceIndustries/OpenResourceSystem_1_2_0.dll after WaveFunctionP released an ORS 1_2_1. But like RoverDude said, there are resource conflicts that still need to be resolved between CRP and non-Lite KSPI, so trying to run them together out of the box will lead to sadness. Fractal's development branch of KSPI seems to be pretty good with keeping all of the resources it uses configurable, so I doubt you would have to change the plugin if you wanted to take a stab at integration yourself. If you want the whole constellation to work out of the box, I'd still recommend sticking with KSPI Lite and CRP.

TreeLoader tries to present the pick-a-tree window if it doesn't find either a tree.cfg or notree.cfg in your save folder. If it finds a tree.cfg in the save, it loads it without trying to hit the online repository. The blank menu may be just a hosting problem with the online repository and nothing on your end. It presents the "update" dialog, as best I can tell, if the version of a tree on disk doesn't match what's online (subject to whatever's ailing the online functionality at the moment). If you manually copy tree.cfg from the Interstellar folder into your save folder, you'll be loading the right version of the tree and TreeLoader won't bug you for that save any more. I haven't found any way around the nag windows when starting a new save; that may have to wait for a more actively-maintained replacement to TreeLoader. I haven't found a good way to prevent TreeLoader from bothering you or installing (or trying to) the online version and then offering to update on a new save.

I can't find any of the contents of GameData/OpenResourceSystem in the github repository. Are there any changes I need to make to any of the texture or config files from 0.11?

EL's plugin doesn't link against Kethane's plugin. If it did, the Karbonite conversion would have been impossible. At most, the config files for scanners and converters may need to be updated. Once you have RocketParts, the EL-specific code that builds ships from RocketParts is unaffected.

Updated the OP with some notes on what I plan to do regarding Fractal_UK's new release.

Set up ModuleDeployableSolarPanel as a fixed panel with a raycast transform for the direction on the model that needs to be pointed at the sun. Then create a plugin that looks at the same raycast transform and autopilots the ship to point it at the sun.

warp_tweakscale.cfg is the file you just delete in its entirety. The values you're looking for are in ScaleExponents.cfg in the same folder.

Radiator breakage is based on dynamic pressure, similar to stock solar panels and RT2 antennas, but it looks like the maximum dynamic pressure of 0.0015 atm (about 150 Pa) is quite a bit more delicate than anything else that breaks at high dynamic pressure. Radiators are going to be extremely light for the amount of area they present to the airflow, so 150 Pa might be reasonable. I'll look at making max pressure adjustable in each part's config file so you can customize to taste or create an atmo-rated deployable radiator and send a pull request if I can get it working.

That is a stock bug that occurs when a part with three or more RESOURCE nodes has no PartModules. Many Interstellar parts have enough resources to trigger the bug if their modules fail to load for whatever reason. If you post a KSP log, we can probably figure out what PartModule isn't loading and why.

The thermal nozzles themselves still calculate thrust and Isp from heat source temperature, thermal power, and fuel multipliers the same way you're used to, with at most a couple of fuel-specific multipliers changing. But since the high-end reactors are not as powerful in Lite as they were in 0.11, you'll find some configurations producing lower thrust.

Spacecraft reactors are a lot lighter than terrestrial reactors of the same power level, and shorter life is part of how they pay for that. Fuel burn rate is calculated from the power output and the energy density of the fuel, so just like in real life there's only so long you can get a gigawatt of power out of a few tons of fuel. The most realistic solution is probably to have lower-power variants of the larger reactor sizes for applications where fuel capacity is more important than ease of moving.

If RealChutes is playing nice and running all of its patches in its own :FOR pass, running DRE's patches :AFTER[RealChutes] should be enough.

Wave plans to keep his pack available for download and import any improvements that Fractal releases. Whether any of Wave's work makes it back upstream will depend on who has how much time to port it. I'm confident that both authors would rather have two good branches available than worry about which flavour is more popular.

I'd have thought mods running patches in the :FINAL pass would be discouraged to keep a pass available at the end for local customizations. I'm curious what mod this is and why going :AFTER something specific doesn't work.

The dome-shaped refinery is out, but the inline refinery is still in KSPI Lite and can do all or nearly all of the modes that the other part could.

The important thing is what you don't have. Any part with ModuleCommand, regardless of its crew capacity, will give local control unless it also has ModuleSPU on the command part. A nonzero "minimum crew" setting in ModuleCommand will be honored for crewed pods, but ModuleCommand with a minimum crew of zero still counts as local control unless you also add ModuleSPU. The design is conservative to avoid making a manned ship "remote control only" unexpectedly. Antennas still require a connection to transmit science no matter how the command pod is configured as long as they are transmitting with ModuleRTAntenna instead of the stock ModuleDataTransmitter. So if you want to enforce RT2 for science transmission and not for control, just remove or edit RemoteTech_Squad_Probes.cfg so your preferred probe cores will still permit local control, but keep the antenna changes.

It will be a pretty quick fix if r4mon gets a chance to do it, but it requires a change in the plugin that the license doesn't allow anyone except r4mon to make. The best anyone else can do is contribute to the development of a freely modifiable replacement.

You need to compile ORS first, then make sure the ORS that you compiled is in a location where the compiler will find it when you're compiling the Interstellar plugin. You may need to edit some of the paths in the project file to point to where the dll is going to be on your setup.