undercoveryankee

For KSP purposes, my ideal would be one large "chemical processing" module that could be configured in the VAB with multiple converter modules if you need to do a multi-step process (e.g. water ice to hydrogen, then hydrogen+CO2 to methane) or separate pipelines for different resources you're using. Calculate a plausible conversion rate, and reliability/maintenance requirements if you're simulating those, based on how much smaller you've made the equipment than typical production scale.

When CRP transitions from PNG maps to Regolith resource definitions and SCANsat transitions to Regolith, the current release of the integration pack will become obsolete. With the PNGs that I'd been sharing with ORS going away, I think the only way I can keep resource sharing happening will be to convert the scanning and extraction bits of KSPI from ORS to Regolith, at least for the resources that it makes sense to share.

Whenever you have a connection or local control, Mechjeb will respond immediately (bypassing signal delay IIRC) to whatever you do in its windows. Loss of signal immediately disables all MJ control functions.

Barring unlikely serious bugs, they will be able to run side by side as well as ORSX and original ORS do. (With the exception that if you try to represent the same resource in both systems, there's no way to update ORSX's PNG maps to sync with the abundances that Regolith calculates). Once all of the USI mods and SCANsat have transitioned to Regolith, it should be safe to remove ORSX because nothing else uses it. But if you have something I haven't heard of that depends on ORSX, it won't hurt anything to keep it around.

Procedural shading can't deliver the same level of detail as hand-assembled textures without more code and GPU power than most games have to spare. And because the GPU often needs to access texels out of order depending on how the geometry is laid out in the scene, there's only so much you can do to compress the in-memory representation and still be efficient. Most compressed formats that you would use on disk get decompressed on load to the same few in-memory formats. Barring bugs in the texture loader (of which we have a few), MBM, TGA, and PNG should deliver the same result in memory. DDS uses the DXT family of compressed encodings, which can be used in-memory, so depending on details of the texture loader a DDS is more likely to get a DXT-compressed in-memory representation as opposed to an uncompressed one than a format that has to be converted. Most games that deal with this many textures are capable of loading and unloading on demand to stay within the memory limit. As long as the stock textures fit in 32 bits, though, Squad may continue to find that the stock game is more responsive with the current naive approach.

The comprehensive patch that I compiled to distribute with the Illustrated Guide includes a fix for the negative costs. The tanks in unmodified KSPI should start empty in the VAB and should cost 20,000, 40,000, and 60,000 empty, as measured in the cost of the rocket. The part's info window may display the cost of the tank and enough AM to fill it even though the tank defaults to empty, which is an astronomical number because AM costs more than 4500 funds a unit.

That contract looks like it has a hidden requirement to do it with a crewed vessel. In one of my test career saves where I added enough science to launch a stock comsat as my first launch, I accepted the initial four contracts before launching. "Altitude record" was the only one that didn't complete.

Do you get resources if you recycle a kerbal? If Kethane is installed, it would make sense to give the same amount of kethane as the KE-WAITNONOSTOP Unreconstitutionator.

It is possible to have a family of engines with common engineering that includes both cryo and hypergolic models, though. The Aerojet LR-87 (Titan first stage) was first developed as a kerolox engine, redesigned for storable hypergolics, and then a hydrolox version was prototyped but lost to the J-2. And even beyond the possibility of variants within a recognizable engine "family," you might use mode switching to represent similar-looking engines from different origins. The Titan core and Centaur upper stage are both 3.05m, so I might grab KW's Vesta VR9D to represent both the LR87 and the Centaur's dual RL-10 cluster.

Moving everything within the boundaries of the bubble and not just the ship the drive is attached to has a kind of intuitive cool factor to it. I suspect the kraken would have something to say if anyone tried to code it, though.

Right now, I have: One 0.23 Three 0.23.5 Three 0.24.2 Three 0.25 Plus master tarballs of 0.23.5, 0.24.2, and 0.25 in case I ever need a clean copy of a version that's no longer on Steam. It's no harder to copy an install from a Steam library to somewhere else than to do the same thing with the download from the store.

If you're using the stock tech tree, a few upgradeTechReq settings need to be switched to nodes that exist. If you're using TechManager to load the Interstellar tree, the upgrades should work the same way they did with TreeLoader. I'm still a few chapters of the Illustrated Guide away from unlocking any upgrades, but when I get there I'll be able to test upgrades in a TechManager/Unofficial KSPI tree career in detail. Speaking of the Guide, Chapter 1: Heat and Radiators is up if anyone wants to critique or revise.

I found code in the generator module that sets the generator's maxThermalPower to whatever the reactor can output when the generator is properly connected to a reactor. The value in the config file appears to be a placeholder to keep the generator module from crashing before a final value can be read from the reactor.

I don't think anything has changed that would cause the calculator.exe from the older versions to give you wrong answers. The in-game editor window is now powerful enough that you won't need it as much as you used to, though.

I've started a new project: The Illustrated Guide to Interstellar. I envision it as a series of tutorial articles covering every major system of KSPI in the order in which you'll encounter them playing career, with enough screenshots to show what all of the controls look like. I'll be testing each procedure while I get the screenshots for it, so I can provide the latest information on known bugs and workarounds. Chapter 0, covering installing and starting a career with TechManager, is up on the wiki at https://github.com/FractalUK/KSPInterstellar/wiki/Illustrated-Guide-Chapter-0:-Installing-and-Patching . During the testing and writing process, I collected the ModuleManager patches that I could find for Interstellar 0.13 on 0.25 and made a few updates myself.

I'm trying to do math on a part using values from a RESOURCE_DEFINITION: @PART[AntimatterTank*]:AFTER[WarpPlugin] { costOfResources = #$/RESOURCE[Antimatter]/maxAmount$ @costOfResources *= #$@RESOURCE_DEFINITION[Antimatter]/unitCost$ @cost += #$costOfResources$ !costOfResources = null } These parts have cost in the config files set to the intended empty cost. The patch is supposed to add the cost of the maximum amount of Antimatter. The log message is: [ModuleManager] Cannot parse variable search when editing key costOfResources = #$@RESOURCE_DEFINITION[Antimatter]/unitCost$ Is there some syntax error I'm missing, or are RESOURCE_DEFINITION nodes not accessible while patching a part?

MJ storage is on the generator because the reactor itself doesn't generate electricity without a generator. If you're using a big reactor without a generator to power a thermal rocket, there's no reason for that reactor to act as a battery. I haven't seen any serious exploit of the storage on the generator, because everything that draws MJ goes through the resource manager and is limited to the rate at which MJ are being generated. What we have works in practice without being unnecessarily complicated.

It's about what a 1.25m antimatter reactor can supply in a second. If you reduce the capacity much below that, then you may see power interruptions at high time acceleration.

That makes sense. If I'm understanding the code right, the first SPU found on walking the vessel tree becomes the master for that vessel. If the master SPU can't control the vessel (probe core out of power or capsule with no crew) when you hit the code that pulls commands from the queue and checks the SPU status, commands get dropped even if there's another SPU on the vessel that could have processed them.

There are several different fairing parts. The ones that decouple are in the "Aerodynamic" tab in the VAB. The "Fuselage Fairing" parts in the "Structural" tab don't. Double-check which ones you're using.

When you do EVA experiments at KSC, you're not really gaining any new information about the buildings and the grounds. You're testing sampling techniques and procedures for use in space. For which you need space suits. So it makes sense not to allow science until you have space suits. It would be nice to be able to EVA without a suit if you're in breathable atmosphere and just limit what science you can get in that state. For use by Vanguard or any succeeding crew eject/crew parachute systems. But that would be extra complexity in stock that would have no benefit without the mod, so just enforcing "you have to unlock space suits" everywhere is good enough for me.

Would it be rude to name an in-game AI core "Mariyate"?

My FAR launchers typically leave the launch pad with a TWR of 1.4 to 1.6 g. Much faster than that and they get hard to control. By watching what I was doing on successful launches, I found a rule of thumb of pitching over 5 degrees every 50 m/s (i.e. 85 degrees as you pass through 50 m/s, 80 degrees at 100 m/s, etc.). Depending on exactly how my TWR changes in flight, I usually pass through 45 degrees and 450 m/s at 10-12 km, at which point I follow the bottom half of the prograde marker down to the horizon. Try to set up your fin arrangements so FAR shows you moderately stable (I shoot for Cm between -0.5 and -2) out to +-8-10 degrees angle of attack through the full range of speeds and fuel conditions. If you go by the in-game center of mass and center of lift markers, look for the CL to be moderately behind the CM. Different rockets need different amounts of margin, so learning to use the FAR graphs will help you get the hang of it. Again, anything you learn with a Mainsail and stock tanks should carry straight over to the methalox launchers. Based on the flavor text and spindly appearance of the engine, I thought it was a lander/return vehicle engine at first too. The concept of in-situ methalox production will open up new possibilities like the flavor text says, but doing it in Interstellar will have to wait until someone contributes parts that aren't launch vehicle parts. Looking at the Firefly design, I'd suggest doing its plug aerospike as a 1.25m engine, fitting the role of "small launch vehicle," and then a smaller engine based on fitting one of its eight combustion chambers with a standard vacuum-optimized bell nozzle.

For the speeds at which sane parachute materials will work, the Cd is pretty uniform once the canopy is fully inflated and its shape is stable. Treating Cd as a constant for any given parachute shape and running the drag equation with good numbers for air density and area is a good enough model for most real-life purposes. You don't see major differences between FAR and non-FAR because the air densities coincide at typical parachute altitudes on Kerbin and the drag model RC uses isn't noticeably different from what FAR would calculate for the same shape.

The "[Flight Computer]" messages do come from RT. RT kills time acceleration if there's a command it's trying to execute or if another vessel comes into physics range. "Out of power" is issued if something has set isControlSource to false on the probe core whose ModuleSPU is currently being used (most often done by ModuleCommand when a probe core can't get EC, but can happen for other reasons). If that happens, any commands that come through the queue while the probe core is disabled are discarded. It looks like MechJeb is trying to target the Mun as part of the transfer program, but RT is eating the commands because it thinks they're coming from the ground and something has disabled the probe core. Are you using the AR202 MechJeb box, or have you added the MJ module to the manned capsule?