softweir

There are two types of fairing: one type is in the Structural Tab and can't be released - they are for building custom fuselages, and you don't want bits of fuselage dropping off mid-flight! The other type is in the Decouplers tab and can be released as you would expect.

There is a complex chemical process used to generate hydrogen peroxide. You can read about it On Wikipedia. Hydrogen peroxide (H2O2) is highly unstable: that extra oxygen atom is not a stable addition to a water molecule! For instance, when it comes in contact with copper and some other metals it spontaneously decomposes into oxygen and water, releasing so much energy that the water is converted to superheated steam. (This is used by some of those "rocket jetpacks" that you can find details about online - H2O2 is pumped through a copper mesh, and the resulting steam and oxygen can be used as a propellant. This can, of course, be very dangerous.) Also, when it comes in contact with some hydrocarbons (such as vehicle fuels) then it will spontaneously catch fire; that is, there doesn't need to be any spark to set the mixture alight. If there is enough fuel and H2O2 then the fire can be extremely hot: this is because the H2O2 generates heat as it decomposes, and more heat is generated when the fuel burns. Even when there is no fire or other emergency, H2O2 will slowly decompose, releasing oxygen. It can release enough oxygen that this can be hazardous to health, if it is in an enclose area. Not only that, but the buildup of oxygen in the air can make normally stable materials burn readily, so the tiniest spark can trigger a fire or explosion. In addition, when H2O2 comes in contact with living tissue it releases the excess oxygen, creating highly reactive free radicals that can damage and destroy the living tissue. The effect on fish and other waterborne organisms can be devastating: it kills them all! So: if H2O2 gets spilled on a road then there is a very serious risk of poisoning waterborne life or a major fire starting. It is imperative that Action is taken to prevent fuel coming into contact with the H2O2 spill Action is taken to prevent people touching the spill, as it can damage skin Barriers are set up to prevent it flowing into drains that lead to waterways It is neutralised using a suitable material. There are dry powders which safely absorb the H2O2, allowing it to be swept up. If there is no danger to waterways, then it can be washed into a drain using a very large volume of water to dilute it to safe concentrations Action is taken to repair the roadway, as H2O2 corrodes the tar used in many road surfaces (The exact order of actions depends on risks at a given spill site. For instance, if there is already a fuel spill when firefighters reach the scene then the first priority is to cover the spill with a suitable foam or dry powder.) Very dilute H2O2 is sometimes used in very small quantities as an antiseptic on minor cuts and abrasions. It is sufficiently oxidising that it kills almost all bacteria, while at the same time there are enzymes in the blood that can neutralise small amounts, preventing it causing deep damage to the wound. However, this practice is now frowned upon in much of America and Europe, as it does damage superficial tissues, which in turn can seriously slow down the healing process - and the damaged tissues can act as food for any bacteria that get into the wound later on. Instead of using H2O2, it is much better to use a sterile gauze to clean a wound and then dress it with a sterile bandage. If there is some special need to use antisepsis (such as the wound being open, the patient having some illness which predisposes them to infection, or the agent causing the wound being thought to be contaminated) then iodine is preferred: it damages tissues much less readily than hydrogen peroxide does, while being a very effective bactericide.

Depends. A candle, yes, that is true - the wax has such low melting & vapourisation points that the plasma loses heat very rapidly. The candle also conducts away a lot of heat. You end up with a spherical puffball of vapourised wax! A match, however, acts differently. If there are no air currents to mess things up and the match is held perfectly still, then the plasma can't lose heat except by radiation, and plasma is not a very efficient black-body radiator! The wood is not a good conductor of heat, so the combustion doesn't lose heat that way. The centre of the sphere of plasma is almost perfectly insulated by layers of decreasingly hot air that can't conduct the heat away. However, combustion continues: oxygen molecules diffuse in to the plasma, and combustion products diffuse out, exchanging heat with the oxygen molecules as they go so the zone of combustion barely loses any. As the gasses diffuse, so the oxygen mixes with superheated combustants and reacts with them, generating more heat. You end up with a concentration gradient of superheated combustants at the centre and cold air outside. The "fire" is perfectly spherical, intensely hot, emits no visible light, and slowly consumes the entire match. If disturbed by an air current then there is a very sharp "pop" as the plasma mixes with fresh air and combusts, and then the fire goes out as heat is carried away by the moving air. Such fires are hard to detect. No smoke is generated, as any particulates formed would diffuse more slowly than the gasses, and so would stay in the hottest zone until they evaporated and combusted. Though IR is emitted, it is at a shorter wavelength than is normal for gravity-sourced fires, so beyond the range of most IR detectors. Combustants are perfectly oxidised, so CO monitors would fail to pick them up. This would be a serious danger on on any space station that is less than perfectly-maintained. A short-circuit could create combustion that would be almost undetectable. The danger is that the sphere of combustion would grow large enough that it could become supercritical, expanding rapidly until it turned into an explosion, or at least caused critical equipment failure. (Sorry, very off-topic!)

You are assuming these people will be working on KSP. However, though Squad makes KSP, Squad <> KSP. There is nothing preventing them from making other games. An alternative is that they have an Acting Lead Developer, but that person doesn't have experience outside of Squad in that field and is making it up as they go along learning on the job. This is very common in Startup companies in game development, but it isn't a long-term sustainable situation in a growing company: it is too easy for an inexperienced person to set up faulty development models that then need to be reworked. We've seen some comments in The Daily Kerbal over the years which suggest they have had to rework their development paths repeatedly. It is common practice for one of the more experienced developers to fill the lead developer role in an informal capacity, and then for a more experienced lead developer to come in to streamline the production of more complex games. One important skill for a Lead Developer worth their pay is to make good guesstimates of how long it will take to do any given job, and decide who is best suited for that job. This enables them to dovetail work more efficiently than a less experienced person can, thus making sure everything ends up being done on time and with nobody hanging around for somebody else to finish their job. The more games a person has worked on, the better the guesstimates! At some point, the Acting Lead Developer will use the experience he gained in that role plus the experience he gained under a professional Lead Developer to get a job elsewhere as Assistant Lead Developer, and if s/he has the chops will go on to be Lead Developer for somebody, somewhere.

Do you launch / revert / re-launch? Any launch to rendezvous algorithm can only guess at your rocket's characteristics and how it will launch, and therefore can only guess at what time to launch. In order to deal with this, a full simulation has to be performed: NASA and co use powerful computers to do this, we have to use a trick to get the right "guess": Launch the rocket using Launch to Rendezvous/Plane. Mechjeb will make its best guess and will probably get it wrong, but it will save data on the characteristics of the rocket that will allow it to do a better job next time. This step is the "simulated" launch. Revert to launch. Repeat the launch without changing any launch profile settings or rocket loadout. (This is essential. The characteristics Mechjeb saved will only be valid if the launch profile and loadout are identical. If you change anything then you must go back to Step 1.) Mechjeb will use the saved rocket characteristics to get a very-nearly spot-on rendezvous or launch-to-plane. I hope this helps!

Agreed. Getting started would be a huge effort, and a lot of machines and essential components would need to be sent to whichever body one is talking about. One might be able to build some simple machines on the moon by sending the electronics and other precision components, along with a small robot to assemble them and a small oven to construct larger components by fusing regolith. The fused regolith wouldn't be very strong, but in that low gravity strength is much less of an issue than on Earth so it might be sufficient. Building a rocket... Nope. Not without many, many billions of dollars and many, many decades, even centuries of effort. We would have to start by sending a huge amount of startup infrastructure, and it would take a lot of trial and error to build new machines from scratch using the materials available. It is quite likely that a rocket manufactury on the moon would never be completely self-sufficient, and would depend on some refined materials being sent from Earth: the infrastructure needed for producing the dopes used in semiconductor manufacture (for instance) is huge! Considering the very unlikely hypothesis that we could do it, then there would be advantages. There is no ecology on the moon to destroy, so we could mine and plunder what we needed without any concerns for the morality of wiping out species or fears for poisoning ourselves. Without a rain cycle, waste would stay where it was dumped. Solar power would be available in huge amounts, just by laying out large arrays of solar panels. And the products of a moon-based infrastructure would be in an ideal gravitational situation to be sent to much of the rest of the solar system, helping to start infrastructures elsewhere.

It is rather counterintuitive!

What are you trying to achieve? Wheels that lock a craft down while landed?

The advantage of using a mini-cfg is that it will stay even if a new version of RealChute is downloaded, saving effort repeatedly! A neat trick is to put any such cfg's in a separate folder within gamedata, where it is easier to keep track of them.

Since it has to be robust enough to provide more acceleration during an emergency than it carries during launch, then it would inevitably be at least robust enough to survive. But why put it in the first stage interstage? Why try to save the second stage? The second stage has no facilities that would be useful during a launch emergency, and during an emergency is just dead weight, making a ring LES needlessly heavy to launch every time. Why not have it as part of the second stage interstage, just below the capsule?

NASA are concerned about hypergolics - the safety procedures surrounding them are complex, detailed, and rigorously documented and adhered to. But there are no reliable alternatives.

(My emphasis.) Unfortunately, the problem with the idea lies right there in the bolded phrase. If the nozzle extension improves ISP, then the upward acceleration it experiences due to the pressure of gasses inside it will prevent it dropping - would have to be forced down. If it is inert enough to drop, then it "weighs" more than the extra force it returns from the gas stream. I like the idea of a "collapsible cup", but some other mechanism would be needed to extend the nozzle! I have no idea if there are any mechanisms that could do that and deal with the extremes of heat, vibration and pressure experienced by rocket nozzles.

I watched it, a few hours after the launch. Have another look?

IIRC, HarvesteR once mentioned that "Kerman" is an honorific, like "mister" or "san".

It's a ring of stiffening material that keeps the second-stage engine bell in shape during launch. The engine bell is made of very thin, high-temperature alloy that could fold up under launch accelerations. Once the S2 engine is lit the pressure of expanding gasses holds it in shape, while it is coasting there are no vibrations or acceleration to damage the bell. Fun fact: they glue the stiffener on with a material that melts when the engine bell heats up, releasing the stiffener.

No, the legs lock once the pneumatics have extended them. This is because the pneumatics have only just enough pressure to extend the legs and no more (because high-pressure pneumatics are too heavy), so they don't have the force to keep them extended during touchdown. It was failure of one of the leg-locks which caused one booster to fall over after landing. I am sure somebody will remind me which one!

The MechJeb pod has been deprecated. The collision mesh needs updating to reflect changes to KSP: if you use it in flight then it will cause severe internal forces within your vessel leading to its destruction. Its creator is no longer active, and the original files used in its creation are no longer available, so it can't be fixed! The MechJeb pod still exists within the MechJeb files so old vessels can be loaded into the VAB in order that the pod can be removed (which is why it appears in the tech tree), but the pod itself has been removed from the parts list so it can't be used by mistake. The proper solution would be for some fine modeller to create a new one!

Exactly so. Think of it as running a simulation before the launch. Very rarely, a third launch attempt will get it even closer - though I am not sure why! It helps to make sure the target is in as near an exactly circular orbit as possible - it's no good aiming for a 100km orbit if the target has periapsis of 98 and apoapsis of 115.

This mod has not been updated for 1.3 yet! e-dog hasn't been active for a while, and he hasn't even visited the forums this year. However, if you read the dozen posts above yours you will see that @rsparkyc is discussing updating it and perhaps taking over maintenance. I suggest you follow him for updates!

That is a two-year-old comment, and MechJeb 2 is now no longer needed, nor has been for... a year or more?

*pats pats* That's KSP for you. It's been this way for a long time now!

Eventually Squad will stop working on KSP, and will start on KSP 2 or something. AT that point, all the modders can finally catch up and we won't be bothered by update-mod-lag. In the meantime, if you are using Steam you can Copy your KSP folder out of the Steam folders and into some other place; most players who do this use something like C:\KSP\KSP <version number> The copied version won't update, and so will continue to work with mods. You can use the copy of KSP still in Steam to test mods for compatibility. When they are all working, you can copy the updated version and retire your old version.

The thrill may be gone, but there is still something very satisfying about a clean, successful job done in what is a very difficult and treacherous field of endeavour. I watch quite a lot of launches (rarely live, given limited times of day I can do so) for the success - not the excitement of thinking "will it succeed - or fail?!"

Up to a point. However, the CPU has to squirt the drawing data across to the GPU, and is normally responsible for optimisations such as hidden-object culling (ie, half the Kerbals are out of frame so no need to render them). In addition, when algorithmic scenery is being generated (most scenery is KSP is generated by algorithms) then the CPU has to run those algorithms. What the GPU does is actually draw everything thrown at it by the CPU - which is a huge job, and the reason GPUs now have many more transistors than CPUs! In theory, it would be possible for a GPU to algorithmically generate a lot of scenery. However in practice we come up against the huge divide between Nvidia, Intel and AMD hardware. The different manufacturers use different systems for getting "code" across to the GPUs, and there are huge differences in numerical precision, rounding and other details that can cause bizarre differences in the final output. While there are reasonably consistent standards for rendering graphics across platforms, non-graphic calculations like algorithmic scenery generation are excessively non-standard. In order to get that to work, developers would have to write a complete new rendering system for each GPU line as well as a fallback CPU-based scenery rendering system to cope with all the cards that are from other manufacturers or are too old to do the job. This is beyond almost every developer, and certainly beyond Squad!

Um. Eeek? The range on those things is not too large, and with that engine it could go out of range in seconds - far too quickly for a pilot still learning the ropes to be able to turn it round and keep it in range. You will need a high-end RC controller to improve range, and be sure there is a safety cutout so the damn thing shuts off quickly in the event of signal loss. I assume you thought about this, but still, I felt the need to express my concern! Another point is that the relevant laws tend to use phrasing like "recklessly endanger persons or property". In the event of somebody not liking what you are doing, it could be argued in a court of law that flying an RC vehicle with that sort of engine is reckless endangerment, wherever you fly it and no matter how good your control. Beating a rap like that would be time consuming and expensive, and not in any way certain. Frankly, there are no places in the UK where you are sufficiently far from "property" (which includes livestock, crops, etc) that somebody won't consider flying that thing to be "reckless endangerment". How are you planning to land it? Normal RC aircraft engines don't get hot enough to start fires, but this one will. It's going to be pretty limiting waiting until you actually get a soaking-wet weekend, the way the weather has been the last few years!