VaporTrail

The point in subdivision of antimatter containment is that you get the antimatter to react before it becomes a danger to planets. It's not to make it safer for the ship. Any significant uncontrolled antimatter reaction aboard ship and the ship is toast anyway. If you have a large amount of antimatter in one place as a solid chunk, there's a higher likelihood that that chunk is going to stay intact. A big enough chunk of antimatter is a possible planet-cracker if it got enough dV to deorbit. Honestly, once you get to the scale of "destroy the planet" the best thing you can do is keep them away from the planet. Antimatter at least has the scalability to be used at small craft sizes... instead of strictly for inter-planetary missions. A singularity drive is a bit further up on the "uh-oh" scale.

Um... You'd be hard pressed to build an antimatter storage that would have an appreciable effect on Earth from 1 AU. Keep in mind that 1 AU is the next best thing to eight and a half light minutes. Even from low orbit the danger of an exploding antimatter storage unit is pretty minimal, as long as you don't get large chunks of antimatter impacting the planet. That's a design issue. You can't subdivide a black hole to make it safer.

Vibration pauses, resumes from where it paused as soon as time warp is returned to 1x. Physical time warp, the vibration and amplification is still present, but presents differently (begins pitch spin much quicker, with much less oscillation of the arms). It may have something to do with the small "strut-truss" sections I have connecting the spreader arms to the main trunk arms. Taking those out and seeing if the problem still presents. Taking the spreader arms off does cause the problem to present differently. The phantom force is still present, but doesn't amplify as easily. The arms cause the vessel to tremble slightly... rather than enter the complete out of control condition shown earlier.

A Mechjeb maneuver planner option to reach (or at least get close to) a specific set of orbital parameters (SMA, Ecc, Inc, Lan, W, etc...) would be nice... but getting the fine control necessary to do that is the issue. Mechjeb is great for rougher orbits, but anything that requires extreme precision it tends to overcontrol. Something that puts a target up, allowing you to see where you need to burn with RCS (and how much dV is needed) would be nearly perfect. Once you get close enough to the desired orbit, drift is going to be a non-issue. I just want to get away from using Hyperedit to set orbits on my power or comm constellations.

Here's what I'm running into in video form. Vessel is trimmed down quite a bit to try and narrow exactly what is causing the problem. Problem persists regardless of deployment speed.

Must have been the old version... updating gutted the vessels I had up... though I swear I had the latest version. I'll try to reproduce. Er... I think it might have been the IR Rework parts, instead of IR proper. I'll see if I can get it to reproduce. I hope I can, cause if not, I gutted my sandbox game for nothing. Looks like I'm getting an anomalous force when the arms are fully extended, which results in a positive feedback cycle resulting in an out of control condition and rapid unplanned disassembly (with parts getting stellar escape velocities). Vessel Pic (kicking it to orbit with Hyperedit).

Hmm... After reading this, I would propose a different (probably bigger) version... This would be for interplanetary missions, where quick response to emergency situations is unlikely. Basically the same kind of setup, but a larger undeployed volume (expanded base height), sacrificing (most of the) deorbit capability for extended life support consumables. The rationale behind it is basically keeping the crew alive long term in orbit for rescue, rather than de-orbiting the crew. Also, one thing bothers me... how does this meet it's electrical power needs? One would assume there's at least an emergency beacon going when occupied... and various other electrical needs. Fuel cell might be a possibility, though a H2 + O2 fuel cell would allow for better duration on the water. Another random thought... does the same 'evac' button that dumps the crew to pods also top off any/all resources in the pods? Makes sense in that these pods should be the last to be used.

Actually that's kinda my point. A difference of 5psi is ~34,000 pascals. 20 Pa seems almost insignificant in comparison. That I'll believe. Wrapping my head around such a tiny pressure difference ripping apart a rocket (as a peak pressure difference... not as something causing a cascade failure) was kinda tough..

Is that measurement in Pa, kPa, or MPa? I can't see a measurement of 20 Pa being enough to break a rocket in half... (20 newtons per m^2, with a standard atmospheric pressure being 101,325 Pa). Just doesn't seem to jive to me... sounds like someone could sneeze on a rocket and bend it in half.

Well, short answer is yes... Longer answer is still yes, but you'll basically need to build a comm-net at your destination if you want anything like full-time comms with your probe. If you just want one long range transmitter, for a mission that you plan on having a lander, you might need up to eight sections to your mission, with a bare minimum of five. Bascially the long range transmitter, you're going to want to leave in a high orbit, with a decent inclination so you don't have very many dead zones during it's orbit. Then you need three to six low orbit relays for coverage of the surface and the lander itself. Bascially the incoming signal hits the long range transmitter in the high orbit relay, is shunted to an omni antenna and relayed to the low orbit net, which bounces it around the planet to the lander via omni's. When using RT comm restrictions, I generally break missions down into "establishing a comm-net" and "actual landing ops." That way I'm not sending huge amounts of mass in a single package. It might be more efficient to send a three package comm-net, each equipped with a long range transmitter, and an omni for comms to the surface, to the destination. That would allow full time comms (assuming no occlusion by moons) and surface coverage. A fourth package in a high polar orbit (or something close to perpindicular to the plane of the moons' orbits) should allow comms around any occluding moon, provided you've got the range for the comms there.

Having seen the F14 wing joint up close, that's essentially how it's done there... the wing root is bulked out and covers the hinge and hydraulics. PWings are really good at that kind of thing. Here's an illustration: Something I've noticed with that design and stock areo... you don't really need much of a control surface on the wings... Large elevators on the tail (which basically become elevons when the wing is swept) are plenty for pitch maneuverability. The small stock control surfaces are enough to get enough roll authority at low speeds... and at high speeds the elevons work well enough to keep the plane stable.

Cross post from the Infernal Robotics thread. Built this as a test for variable sweep wings... worked out great.

IIRC, the minimum number of relays and orbit is three at 600km. It's a pretty precision orbit (Hyperedit works wonders for making perfect orbits...), but it's doable. Four in a higher orbit is a lot more forgiving in terms of lacking perfect orbital stability. I generally have six relays in my basic power distribution system, three in an equilateral, equatorial, 600km orbit. Three more in an equilateral, equatorial, semisynchronous (1585.18km) orbit. That'll allow distribution anywhere in the Kerbin-Mun-Minmus system short of the back side of the moons. Another set of three around each of the sats in a high polar orbit (500km or more) will bounce power around the moons to the surface or beyond to the rest of the Kerbol system. A further set of relays around each planet will be necessary to distribute power to their surfaces and backsides... but it's fairly easy.

How about attached to a docking port as a range/alignment aid in a HUD-like display? Neat, simple, straightforward implementation, I like. I might not use it, as it's a pretty niche item... but for being a niche item it looks extremely well done.

Go ahead... I based the wing design heavily on what I remember of the design of the F-14. Have to say though, it was literally thrown together as a "lets see if this works."

If I was going to go into it heavily, I'd probably go in and set the rotation limits on the washer, so it doesn't overrotate. As it was, I just did it by eye.

I saw your request about variable geometry wings, and decided to build this as a test. Uses Spaceplane+ and Pwings [edit] and KAX wheels (oops)... flies pretty stable for something just thrown together. Here's some pics... The business end of the wing sweep: Just a docking washer attached parallel to the wing axis. Main wing attached to docking washer so that the washer will sweep the wing: Another Pwing attached forward of washer to hide the joint and gap when the wing sweeps: Flight Pics:

Had a "ah ha... HA ha..." sort of moment when reading the release thread. Failure event for Universal Storage bays: If open and failed, or failed and subsequently opened, Bay will not close without being fixed. Minor annoyance for anyone using standard aero... but I think it'd be a pretty big problem for anyone using FAR and DRE. As far as "fairing enclosed parts." I'd think that fuel leaks, and such shouldn't be considered... But perhaps things like Deployment Jams (landing gear, radio masts, and solar panels refusing to deploy...) might be good. Stuff you can EVA and fix after the fairing is removed... but that aren't going to be such a PITA that starting the flight over from scratch is the more attractive option. [edit] Big freaking lightbulb... Has anyone suggested this before? Might want to hook up with whoever's got control of Chatterer and see if there's any way you can set a trigger for Chatterer to play some of their excited Kerbalish whenever DangIt fires. Would be an awesome complement to DangIt's functionality.

The problem I was running into was that one TJet (running off a MWThRec) would lag on throttleup by quite a bit. To get something with multiple TJets off the pad (or heaven forbid, runway) I'd have to have it held by launch clamps until the thrusts were balanced... and when you've got one TJet running wide open at 235kN and another climbing up from 170ish... well, a mistimed release makes cartwheel lovers happy. Might look into using smaller reactors and building Tjet craft if I can't figure out what (or if) I'm doing wrong with them on MWThRecs.

How do you find the thermal turbojets handle with dual reactors?... I've only used them with microwave receivers and have had boatloads of problems with thrust balance.

You might look into RLA Stockalike http://forum.kerbalspaceprogram.com/threads/24593-WIP-RLA-Stockalike-0-9-4-released-27th-November?highlight=RLA+stockalike for 2.5 axis RCS. They've got (two different) 5 port RCS parts, as well as 45 degree RCS ports. They've also got a bunch of different engines, both LFO and monoprop and some other stuff...

The thing is, there's nothing in the stock game that requires 250 Ec/sec, and the majority of mods that add exceptionally high power requirement parts also add the methods to generate that power (KSPI and NFP as examples). Reactors from KSPI and NFP really are in a class by themselves. If you're not using KSPI or NFP power consuming parts, anything that produces large amounts of electricity is going to be hugely overpowered, because there isn't much that will draw enough Ec. Consider: From the Kethane mod: 250 Ec/sec will power 8 heavy drills and 4 heavy converter units, simultaneously with plenty EC left over to do pretty much anything else you want (10 Ec/sec). To do this with stock parts would require the aforementioned 333 RTGs, 320 Ox-Stat panels, 120 small tracking solar arrays, or 14 Gigantor solar arrays. KSPI or NFP reactors cover that with one of the smallest reactors. KSPI SAFE-1500, which is the smallest KSPI fission reactor, punches out 2MW unupgraded, with about 1.5MW usable Ec. That is six times the power... But KSPI also brings in parts that require so much power input (Alcubierre drive, for example) that they have a purpose. For a stand alone part, 250 Ec/sec and surface to orbit levels of thrust is pretty OP. Now if it's being designed to be used with the KSPI or NFP packs then it gets better... but still on the high side for a part that performs multiple functions IMO. [Edit] just saw the last reply. Edit for a link to the Dev thread and I'll drop in there.

Passing thought... are all those experiencing blacklisted resource leaks (spare parts, etc) getting them from "self inflicted" failures done by the mod test feature? It just sounds to me like the debug option to generate a failure on a specific part might be ignoring the blacklist somehow. I see it's fixed... never mind.

Had to build an Infernal Robotics powered ball kicker... Figured out something though... anything >350m from the command part is going to "splat" rather than bounce... basically 'stays intact, but all vectors die on contact with surface.'

Thing is, with KSPI, you're using the reactor for thermal power, which either goes to an engine for thrust generation, or to a generator for electrical generation, with the side effect of waste heat generated. And KSPI reactors can produce literally hundreds of times the Ec your engine/generator does (again, with the side effect of waste heat, which can literally melt your ship if you don't include enough radiative capability). Without KSPI installed 250 Ec/Sec is incredibly powerful, compared to the available stock parts. Like I said, twenty six tons of RTGs... That's three-hundred-and-thirty-three RTGs. Without some form of downside (like waste heat) it's a bit more powerful than is truly necessary for a stand-alone part.