undercoveryankee

Suggestion: add a way to generate ExoticMatter charge from karborundum. Since the other mod that uses karborundum is ESLD jump beacons, it feels like it ought to make other types of FTL travel more efficient. Less time to charge up than on EC alone, or the fitting-inside-the-bubble advantage of a karborundum tank that's smaller than what you'd use to generate that much EC, maybe.

There's a config file in the MKS package for that, but it's still looking for "RemoteTech2." Until I can get a fix to RoverDude, edit GameData/UmbraSpaceIndustries/MKS/MKS_OKS_RT2.cfg to change all of the :HAS[RemoteTech2] clauses to :HAS[RemoteTech].

Your problem may be that you're testing STAGE:SOLIDFUEL and STAGE:LIQUIDFUEL in separate WHEN triggers. Meaning that as soon as your last SRB burns out, SOLIDFUEL will remain zero and that trigger will keep triggering until you're out of stages. If you want ship-agnostic auto-staging code, testing for whether any engines are flamed out is probably the most general approach.

MKS/OKS has some processes that use ore. It's not in the basic life support loop that you'll set up first, but it comes in when you start manufacturing parts and machinery.

At 250 posts if I remember right.

The upgrade mechanic is designed so parts on already-launched vessels keep the performance they had when the vessel was launched. You should be able to right-click a part and retrofit it, either from controlling the ship you need to upgrade or from an EVA kerbal near the part. It may cost you a little bit of science. If ships launched after installing TechManager and acquiring the node aren't getting the upgrade, that would be a bug. It could be the already-reported bug where the VAB Thermal Helper shows unupgraded radiator performance even when the radiators do spawn as upgraded on launch, so make sure you're checking what the radiators are doing in flight and not just in the VAB.

As a design practice, CTT tells TechManager to create empty nodes, then allows anybody to create a ModuleManager config to put their parts in those nodes. Other tech trees that are available include the data on how to move parts in the tree config and let TechManager handle the reassignments, but the ModuleManager approach is easier for mod authors to participate in without taking up the CTT maintainers' time.

Depends on what KAS components you're talking about. Some KAS parts dock the two craft into one, some don't, and some give you the option when you're making the link.

The way the stock engine modules calculate their fuel flow rate from thrust and Isp requires every ModuleEngines or ModuleEnginesFX to have at least one fuel with mass to avoid a division by zero. If there's an upcoming part that runs ExoticMatter in a stock engine, that would require it to have a density.

If SCANsat is installed, the Karbonite Detection Array will have SCANsat functionality for detecting Karbonite. "Start resource scan" on the Karbonite sensor, then go into SCANsat settings and set the resource overlay to Karbonite.

It's a ModuleManager patch. Create a new .cfg anywhere under GameData, with any name that helps you remember what it does, or add it to any file you already use for local ModuleManager patches.

The point of moving that logic from MKS into the framework is so other mods that want to use it can depend on the framework and not on MKS. For instance, if you were converting EPL, you might want RocketParts production to vary with available labor similarly to your build rates. Or @spiritplumber might have a new application in mind entirely.

A lot of that logic already exists to control the efficiency mechanic in MKS. Bringing it over here would mostly be a matter of deciding whether any hard-coded constants need to become configurable.

I thought all of the sizes had name collisions; if you try the rigid drives in all of the sizes, you might find that some of them get replaced with folding units. Check all of the sizes while you're in the files. Meanwhile, I'll get started on that ready-to-use repack that I talked about a few weeks ago.

I want it to be installed by default like a regular recommendation if you install all of the packages that it bridges. That doesn't happen with a suggest.

Is there a way to "recommend" a package, but only if all of its dependencies are already present or being installed for another reason? For example, if I were packaging Interstellar, I would like to recommend my resource-sharing pack if Community Resource Pack and ORSX are installed, but without causing those dependencies to become recommended if they're not.

That happens when different parts have the same internal name. You'll need to edit the config files for the folding parts to give them a name that doesn't conflict with the standard parts, then rebuild any ships that are meant to use the folding parts.

It's a debugging message that seems to have been left in the code that controls radiator emissives. Unfortunately, it gets called per-frame if you happen to have one of those radiators present. There's no way to fix it without recompiling the plugin. For anyone interested in compiling locally, it's line 440 of FNRadiator.cs.

Here's a PowerPoint from 2010 that discusses some applications of large capacitor banks. The state of the art in capacitor banks as of writing was 50 KWh per cubic meter. Multiply by 3600 J per Wh, to get 180 MJ/m^3 = 0.18 MJ/liter. And here's a 1996 paper that uses 50 J/kg as the state of the art. Capacitor performance has been improving rapidly over the last few years, but from what I can tell their energy density still trails the best chemical batteries. Their advantages are in range of working voltages, time to charge and discharge, and number of charge/discharge cycles before degrading.

The name "kOS" appears in some of the code for the RT flight computer because of some historical efforts to get them to work together. All of the functions in that stack trace are part of RT.

The node locations are as intended. The models display smaller than they should because of the model-scaling fixes in 0.25; does anyone have a link to the post with the fix for that handy? As far as using fuel, two questions: Are they producing thrust? And what kind of reactor are you attaching them to? They are designed to require a direct connection to a reactor that produces ChargedParticles, LiquidFuel available in the stack, and Megajoules available. If any requirement is missing, the effect is zero thrust and zero fuel usage.

You need to modify the ATM config for the "WarpPlugin" folder so the textures used by the warp trail have scale=1 and are readable. I don't have their names in front of me, but they're hard to miss in the WarpPlugin folder. Refer to the ATM thread and documentation for details on editing its configs.

If you have a clean install of Interstellar 0.13, all of those issues with the deuterium rename have already been fixed, and all fusion reactors will run on LqdDeuterium. You may have stale or conflicting files somewhere, or you may have discovered the hard way that the 2.5m and 3.75m tokamak fusion reactors no longer store any fuel in the reactor itself. If you want to use those reactors, you'll have to have tankage for their fuels (the deuterium cryostat on the propulsion tab) somewhere they can draw from.

If Squad ever decided to add radial LFO tanks to stock, they would probably make the STACK_PRIORITY_SEARCH rules a little more radial-tank-friendly. Until then, all we can do is play the game we're given.

Some people prefer to leave the flow mode on Antimatter set to STACK_PRIORITY_SEARCH, the way it is in Fractal's package, so it flows the same as liquid fuel and oxidizer. If you're using STACK_PRIORITY_SEARCH, some configs will need fuel lines (from the tank to the collector, as if the collector were an engine; parts that produce resources do so by calling the "consume" function with a negative number), but erring on the side of "not connected" is sometimes what you want. There were some reports with Interstellar 0.10.3 and 0.11 that Antimatter with the stock STACK_PRIORITY_SEARCH flow mode wouldn't cross docking ports even when LFO would, so make sure you have a tank in the same module as the collector.