undercoveryankee

The mods don't really pay attention to each other. You can't control a ship through Interstellar beamed-power relays, and you can't power it through RT2 communication relays, but there is nothing preventing you from having both types of networks up, either on the same satellites or on separate satellites. Because they don't interact or both modify the same stock parts, any bugs that occur are unlikely to be specific to the combination. Interstellar's seismic-impactor experiment generates huge Mit sizes that are an excellent torture test for any mods that affect science transmission, but that's the closest they come to a direct interaction.

I noticed the git commit saying that 1 EC/S=1 MW is the convention in Karbonite. Interstellar goes with 1 EC/s = 1 KW. It would be easier to use both mods together if they had a common convention. Were there specific reasons for choosing the 1 EC/s = 1 MW factor?

The in-game time display goes negative at a time that indicates a signed 32-bit number of seconds. Since the number in the persistence file is floating-point and vessels and bodies on rails don't teleport when the time rolls over, I'm pretty sure that the floating-point value is the master, with the 32-bit value just being an intermediate step before breaking out years, days, hours, and minutes.

That message "joint between x and y failed due to aerodynamic forces" is generated by FAR's aerodynamic failure calculations. If it's happening when the DP-10 is shielded by a fairing, that would be worth bringing up on the FAR thread. "Fairing support" in RT2 is looking more at allowing retractable antennas to be extended inside a fairing.

KSP generates an output log even if it doesn't crash. On OS X, the detailed log is ~/Library/Logs/Unity/Player.log. If you're on Windows or Linux, do some searching or wait for someone to chime in with those paths. Any weird behavior that you can reproduce, you start KSP, go directly to the behavior, quit right after you've reproduced the behavior, and share the log and a detailed description of what you did.

I'm not sure if anyone has balanced the antenna costs yet, but the pre-release builds have been decently stable for me on 0.24 (32-bit, OS X). Some people report builds as far back as the 1.4.0 release doing all right, but the ones I've personally tried were prereleases 32 and 41.

The download link in the first post still points to 7.0rc2.5, even though 7.0rc4 is current. That could be how you ended up with an older version than you thought you had.

TreeLoader may not offer the "pick a tree" window on a save that already has some progress. If it doesn't give you the option, manually copy tree.cfg from GameData/WarpPlugin to your save folder.

MKS and Karbonite run fine with the ORS from WaveFunctionP's build of Interstellar, as far as I've ever heard.

First thing to try is to turn off any attitude control (SAS, SmartASS) on both ships. Sometimes that's enough to let the ports figure it out.

Here's the deal: There are SLS configurations planned with payload to orbit slightly larger than the Saturn V. Stacking a 1- or 2-seat lunar lander behind the Orion capsule is realistic in a technical sense if NASA's decision makers decided to fund such a lander. Since right now it looks like the only thing anyone can agree on is that NASA should develop the capability to eventually do Mars, I expect any lunar landing that gets funded to be a multi-launch mission with 6-8 astronauts on the surface, so the technology that gets developed will be more applicable to Mars.

With the atmosphere-only setting, you take a really steep penalty at sea level, recovering to normal performance by zero pressure. The more fuel you can get to high altitude, the better you'll do. A more stock-like ascent profile (long vertical ascent before turning, TWR a little over 2) may do better under those conditions than a normal FAR ascent profile.

Sarbian has you covered on making the researching faster, too: http://forum.kerbalspaceprogram.com/threads/78067

Would have to be more recent than this response that says the opposite: http://forum.kerbalspaceprogram.com/threads/83305-Development-Resumed-RemoteTech-2?p=1220163&viewfull=1#post1220163

For me, the button shows up in blizzy's toolbar. If you're running the toolbar and don't see the TAC button (icon of a green knife and fork), you may need to "Configure visible buttons" in the toolbar's menu.

I'm familiar with what Atomic Rockets has on stealth. It's written mostly to rebut claims that stealth will ever be good enough to guarantee total surprise up to the moment of firing weapons. There are probably still tactically useful tricks that are possible, especially if you have an idea of where the sensors are located and what their capabilities are. You can probably arrange that if a known sensor picks you out of the background it will have no way to tell that you're not an inert asteroid until it's too late. Planning the times and paths of any necessary radio communication and using the least detectable beam shape at your disposal are part of that.

Sounds like missing or inaccessible image files. Make sure that all of the contents of GameData/RemoteTech2/Textures are present and at that exact path, and that any texture manager you're using (e.g. ATM, TextureReplacer) is keeping anything that looks like a button readable.

1) Once communication delay gets beyond a couple of seconds, any powered landing is going to have to be automated. If you can do it on Ike, you can do it on Moho. With precisely timed flight computer commands and RoverDude's airbags, you might be able to pull it off without kOS, but kOS is the best-supported way to do a local autopilot. 2) Yes, a ship with a crew of at least six (across all parts that hold crew) can act as a command center as long as the ship also has a probe core with "IsRTCommandStation = true" set. In stock RT2, that's the 2.5m stack probe core (called the RC-L01?).

Any chemical propellant has a theoretical Isp limit based on the energy produced and the molecular masses of the combustion products. http://astronautix.com/props/h2oazine.htm gives the vacuum limit for hydrazine/HTP as 327 s, with the best chemical reactions that have been discovered (hydrogen/fluorine) capable of 470. Anything above the upper 400s has to be obtained by supplying additional energy from outside the propellant. Nuclear engines use heat from a nuclear reactor, and ion engines use electricity.

I thought Shuttle SRBs were reloaded after water landings.

I know representing hydrogen as LiquidFuel isn't perfectly realistic - LF is closer in density to RP-1, and the LF/O mixture ratio is closer to RP-1/N204 or UDMH/N204 - but I haven't found an alternative that I like better, mainly because there are a lot of engines in stock and other mods that are based on or similar in performance to hydrogen-burning engines. If you leave those burning LF, you're left with the incongruity of hydrogen being used for everything except chemical rockets. If you try to convert them, that's a pretty big zoo of configs to maintain if you're not otherwise interested in RealFuels.

Kerbal ISP Difficulty Scaler, by ferram4. Primary function is to scale rocket performance so you need a large rocket to reach orbit even though the planet is tiny. I use it for the thrust corrector option to vary thrust instead of fuel flow as Isp varies with atmospheric pressure.

Just upgraded to build 282. Delta-V stats aren't displaying, with the log message [MechJeb2] Exception on MechJebModuleStageStats.RunSimulation(): FuelFlowSimulation.SimulateStage reached max step count of 100 Edit: further testing. Downgraded to 280. No change. Removed KIDS. 282 displayed delta-v stats. Reinstalled KIDS and tried different KIDS settings. Turns out delta-v calculation breaks only if my KIDS settings have "Extend curve to zero ISP" active.

Accidentally clicked "Reload Database" while in R&D. Backed out to space center, then clicked back in to R&D, and all of the parts now showed as unresearched. Is that something that could be caused by the database reload, or do I need to look for some other mod conflict? Edit: Further information. The parts remained unresearched after quitting and restarting KSP. I haven't seen any adverse effects yet from just using Research Them All.

It's possible to get crew reports from multiple biomes into a command pod, but there's a trick to it. Freshly generated reports don't stack, because the code that handles running experiments assumes that the part that you use to run the experiment won't also have storage. But reports that are moved to the capsule by a kerbal do allow you to store one per biome, just like moving any other experiment to the capsule. If you EVA, take the data from the command pod, and then store all of the data back in the same pod, that will be enough to move the crew report to the part of the capsule that can hold one per biome and allow you to take another.