ArcFurnace

I believe it's been stated by the developers that they don't see life support as part of their vision of the game (in short, they feel it restricts what you can do without adding much fun in exchange). Will edit in a reference for this if I can find one. On the other hand, I'm sure they're fully aware that more than a few people enjoy the added realism or added challenge (including me), and aren't going to complain about anyone modding it in. EDIT: Couldn't find support for my first statement, but I did find this Reddit post, stating that if they ever do include life support it will be a difficulty option that can be disabled.

If it's a probe and you're out of electric charge, you have no control, so you can't extend the panels because you can't make the ship do anything. There's a way to get around this- a Kerbal on EVA should be able to right-click the closed panels (so long as they're close enough to them) and manually pull the panels open. Then once you get a little power into the probe you'll have control again.

The current release of Interstellar uses TreeLoader for its tech tree editing. TreeLoader is broken, and has been since 0.25 came out. A "clean" install of KSPI 0.13 will not have the tech tree functioning properly. There are also several other things not quite working properly in 0.13. Deleting the TreeLoader folder from GameData and replacing it with TechManager will allow you to fix the tech tree problem. Alternately, you can wait until Fractal releases the next version with fixes, which should be fairly soon now, as he posted recently saying so.

In the past, I was usually able to attach radial chutes to the sides of the 1.25m capsule without them burning up, so long as I made sure they were near the top where the capsule narrows so they're "inside" the shielding cylinder provided by the heat shield on the bottom. Alternately, for really big radial stuff sometimes you can use an oversized bottom-shield (e.g. the 4m heat shield). Is something similar not working for you? Make sure you've got your heat shield pointed prograde, of course.

Such a good idea that someone already did it. Can display any image in-game, so long as you put the file in the correct directory first. Enjoy!

Seems to be working just fine. Thanks for the quick fix! I don't quite feel up to fixing these sorts of things myself, so the least I can do is make your life as easy as possible

1 EC/s = 1 kW = 1,000 J/s. 1,000 EC = 1 Megajoule.

Bug report: MechJeb is reading incorrect values for thrust from engines that have <100% values for the throttle limiter tweakable and a non-zero minThrust value in their engine config. This doesn't matter in many cases, as almost all engines have minThrust = 0, and the throttle limiter tweakable isn't used all that often. However, KW Rocketry solid boosters are an easy way to experience this bug- they have a minThrust of half of their maxThrust, and tweaking the throttle limiter lets you adjust the thrust of otherwise uncontrollable SRBs. This Globe X-10L "Thor II" SRB from KW Rocketry had the throttle limiter tweaked to 15% (0.15). It has a maxThrust of 3015 kN and minThrust of 1507.5 kN. The thrust according to MechJeb is maxThrust*throttleLimiter = 3015*0.15 = 452 kN. The actual thrust is minThrust + (maxThrust - minThrust)*throttleLimiter = 1507.5 + (3015 - 1507.5)*0.15 = 1733.6 kN. If the throttle limiter is pulled all the way down to 0%, MechJeb will believe that this engine cannot produce thrust, despite it actually still producing 50% thrust at 0% throttle limiter. This testing was done with the latest dev build of MechJeb (#343).

Are you using an Interstellar part that consumes ElectricCharge? I've definitely experienced those causing weird shenanigans with wildly fluctuating ElectricCharge levels during higher time warp (I think it's because ElectricCharge still uses the stock resource manager system, which has some weirdnesses at high time warp). Antimatter containers and fusion reactors in particular can be unhelpful due to their power consumption and ability to consume ElectricCharge. Anything that consumes Megajoules is less volatile since those use Fractal's custom resource manager.

I think ideally, it would not trigger using staging (to prevent accidents), but you could trigger it from action groups (namely the Abort action group). I'm not sure if that's even possible, though.

This paper (found in the citations of the Wikipedia article about antimatter rockets) says that just under 40% of the initial rest mass of a proton-antiproton annihilation will be converted into kinetic energy of charged pions (the rest is either the rest mass of the charged and uncharged pions, or kinetic energy of the uncharged pions, which cannot be deflected and used for thrust). The kinetic energy is ~374 MeV/pion, compared to a rest mass of ~209 MeV/pion, so those particles are moving at a substantial fraction of lightspeed. Will edit in velocity calculations once I'm more certain I haven't totally messed them up. EDIT: The paper itself gives the figure of ISP = 10,000,000 s. The other problem is since a significant fraction of your propellant mass is being converted into energy, you have to use the relativistic rocket equation instead of the standard rocket equation (you wind up getting worse performance, since a substantial fraction of your propellant mass effectively vanishes without doing anything). Also, ~38% of the initial propellant rest mass is converted into energy of the neutral pions, which rapidly decay into high-energy gamma rays. This means that nearly as much energy is converted into deadly radiation spraying in all directions as is coming out of the exhaust jet as useful thrust. Not only will you need shielding to prevent this from killing your crew, you will need heat radiators to keep it from simply vaporizing the shielding. On top of that, the gamma rays are energetic enough to forcibly induce nuclear fission/transmutation, so the shield's going to wind up radioactive even after you turn the engine off. EDIT #2: You get 40% as useful kinetic energy. 22% turns into the rest mass of the charged pions, and the remaining 38% into the rest mass/kinetic energy of uncharged pions (which rapidly decay into gamma rays and start trying to kill things, including but not limited to the crew, the structure of the spacecraft, and the engine itself).

I think the antimatter reactors as-they-are-now represent antimatter thermal generators; you dump antimatter into a massive excess of normal matter, and all the crazy stuff it produces just gets absorbed and turned into heat (which can be used to run a thermal generator, or to heat propellant). Beam-core propulsion would be a secondary "fuel" mode, where the reactor contains much less regular matter to ensure the charged particles can escape. Alternately, you could instead adjust the magnetic nozzles to work with ThermalPower+propellant so long as the source temperature is high enough to ensure the propellant becomes a plasma. The VASIMR electric propulsion system has a magnetic nozzle that handles plasma at >1,000,000 K - the plasma is generated in a different way, but that shouldn't really matter as long as it's plasma, yes? That would give you antimatter-thermal (plasma core) rockets with magnetic nozzles. That might work better game-wise than beam-core antimatter rockets; a realistically represented beam-core rocket would have absurdly high ISP (~10,000,000 s) and pathetic thrust at the power levels we have available. The numbers from Project Rho have 10 MN of thrust ... at an utterly insane power level of 500 TW! The 405 GW antimatter reactor would have <10 kN of thrust at that ratio, like some kind of antimatter-guzzling ion engine. The excessively high ISP is actually the problem, since increasing ISP decreases how much thrust you get for a given power level.

That looks like it's transmitting just fine ... can we see a picture of your reception setup at ground level, that you said wasn't working?

Any problems with negative-value parts are due to a weirdness in the way KSP deals with resource-containing part costs that Fractal didn't know about when pushing out the previous quick update for 0.25. Basically, you set the part cost in the .cfg file. This defines the total cost of the part in the editor. This includes the cost of full tanks of any resources the part contains- the price set in the .cfg is the absolute maximum price the part will have, ever. This makes it easy to define how much a full fuel tank should cost, but does weird things when you try to define costs for tanks of expensive, gatherable resources that start empty. For, say, an antimatter containment unit, Fractal set a price in the .cfg that would be reasonable for an empty antimatter tank. The game looks at the part, sees that it could contain several thousand units of expensive antimatter but doesn't, and dials in a massive price reduction for "removing" the antimatter from the tank (when it actually starts empty). Given how much a full tank of antimatter is worth, this pushes the "cost" of the part well into the negative millions, which is obviously absurd. If you want correct prices, what you need to do is: decide how much you want the dry tank to cost (or reactor with internal storage, or whatever), calculate how much a full tank of each individual resource would cost (by multiplying capacity by the price per unit), adding those numbers together, and setting that value as the price in the part.cfg. Fractal should be able to fix this easily whenever he gets the next update out, and in the meantime it should be possible to compile a fix (manually or using ModuleManager to make it easily distributable).

Hmm, yes, a good point. The most obvious way of dealing with it is adding non-ablative heat shields and increased MaxTemp to all parts that need it and could reasonably be expected to have it, exempting them from the hard cutoff. For example, Small Gear Bays already have a 25% reflective heat shield and MaxTemp = 1800 °C in current Deadly Reentry; this could be kept in the new version, implying a protective insulating shell of RCC around the gear bays. Starwaster will have to decide on appropriate values for the various parts that are currently heat-shielded (Mk2 cockpits/fuselages, wings, and such), and whether shields need to be added to any other various bits and pieces. Fairings or nose cones might also turn out to be more important for rocket ascent, to protect delicate vacuum-rated equipment and such not designed to survive exposure to a hypersonic airstream. On the way down, of course, we already have heat shields.

Some information on various materials intended for use at high temperatures: Melting point information is easy to find. However, most metals fail quickly at temperatures well under their melting points due to reduction in strength and/or creep (typically becoming a problem above one-half their melting point, measured in Kelvin). The Space Shuttle Orbiter's aluminum structure had a maximum survivable temperature of only 175 °C; it dealt with reentry heating using various sorts of high-performance insulation that prevented the heat from reaching the structure (ref). Titanium alloys for high-temperature use are lightweight and strong. Up to ~800 °C is survivable but decreasing operating temperatures increases allowable stress and/or material lifetime (almost all high-temperature materials have this behavior) (ref). Density is 4.6 g/cc. Your choice of 700 °C as a maximum temperature for most parts is nicely consistent with titanium alloy as the default air-facing structural material. Steels (typically stainless steels due to the necessity of corrosion resistance at high temperatures) are denser than titanium and have equivalent or worse strength at 600 °C (ref). Nickel-based "superalloys" are expensive, complex to manufacture, and very dense, but produce impressive high-temperature performance. Modern superalloys can survive temperatures of up to 1200 °C (more than 80% of their melting temperatures) and still maintain some strength (ref). Density is ~9 g/cc, almost twice that of titanium. As mentioned before, reduction of required operating temperatures improves performance. Various sorts of ceramics can have higher operating temperatures, lower densities, or both, but have a nasty habit of being brittle and easy to damage. Reinforced carbon-carbon has sufficient strength for structural use and can survive temperatures of 1500 °C - 2000 °C (the RCC on the Space Shuttle Orbiter leading edges was rated for 1500 °C). Its density is ~2 g/cc. However, it is somewhat brittle and lacks impact resistance; Space Shuttle Columbia was destroyed after a chunk of foam insulation falling off of the external tank smashed a hole in one of its wing-edge RCC panels. If debris strikes can be avoided, it is a very effective (and very expensive) heat shielding material. The "high-temperature reusable surface insulation" tiles that covered the rest of the bottoms of the Space Shuttle Orbiters can survive temperatures of up to 1250 °C, have an impressively low density of only 0.14 g/cc, and are incredibly insulating. However, they pay for this by having essentially zero structural strength; the low density and insulating effect is achieved by being a "foam" of 94% air/6% silica fiber. They must be mounted onto some other structural material (although due to their insulation value, temperature resistance is no longer a concern for said structural material), and they must be mounted as small individual tiles to allow for flexure of the underlying structure without shattering (ref). The currently-under-development Skylon spaceplane is supposed to use carbon-fiber reinforced plastic structural members and aluminum propellant tankage, with a lightweight, insulating fiber-reinforced ceramic aeroshell to keep heat away from the very heat-sensitive internal structure. Details on the exact nature of the planned ceramic aeroshell are not present. -------------------------------------- Not sure what a reasonable MaxTemp is for engines. The combustion gases and rocket exhaust are extremely hot, but the combustion chamber and rocket nozzle are generally cooled by fuel flow (or some other cooling method) and never actually reach those temperatures. Also, if it's too high, rocket engines can be used as impromptu "heat shields", which may or may not be desirable from a gameplay standpoint. 1400 °C is probably a good starting point for now, just remember to adjust heat generation rates if necessary to ensure that certain engines don't become guaranteed explosions (I'm looking at you, Mainsail).

From the first post in the linked thread for TechManager: So yes, you will need to remove TreeLoader. The tree.cfg file from Interstellar (a copy should be present in GameData/WarpPlugin) needs to be added to your save folder, the file path should look like this: [main KSP folder]/saves/[your save name here]/tree.cfg

I'm pretty sure the answer is "yes", but not 100% sure. If you dig around in the GameData files you should be able to find the .cfg file with all the resource definitions. If the resource definition has a set price then I believe that is both the price you pay when creating a rocket with resources onboard, and how much you recover when recovering a rocket with resources onboard.

The TreeLoader plugin included with the current download in the first post is broken in 0.25, and will not add the extra nodes default KSPI requires. It can be replaced with TechManager. For now you can just do this manually, Fractal will update the download in the first post as soon as he gets enough time (along with fixing a few other known issues with the current version).

If you want to stick with the "no significant tailfin" design, the compressed-air RCS ports and/or Throttle Controlled Avionics with engines to either side of the center of mass will help give you the necessary active control to keep it stable in yaw.

It's a bug, he fixed it in a dev build after the official release, get the dev builds here. v341 does not have the bug.

That should be much easier. Just remove all the related part files. I don't THINK this will break anything ... ask again if something weird happens, the plugin code has enough interactions with the various parts that it's possible.

The arrow was deliberately removed by ferram because it didn't actually mean anything and was just confusing people. This seems have had the side effect of confusing people as to why the vector is no longer there. I'm assuming that image is meant to be an illustration of the lack of vector on the CoL marker, rather than an example of one of your planes not having much lift, given that it's a SRB with two tiny control surfaces on it, which would (realistically) have near-zero lift.

The first step is to provide more information. Here's an explanation of the sort of testing you should do, and the information you should provide, to make diagnosing the cause of the bug as easy and effective as possible.

Because no amount of warnings in the thread to not bother him with bug reports from the instability-riddled Win64 KSP worked. Personally I like ferram4's solution, which also works here (according to the license terms in the first post): if you are capable of downloading the source code, modifying it to remove the small code snippet that disables the mod if Win64 KSP is detected, and recompiling it for your own use, this proves that you know enough about computers to not end up harassing the mod author with bug reports that aren't his responsibility and may use the mod freely in Win64 KSP. No redistributing it, though.