Jump to content

Tiron

Members
  • Posts

    939
  • Joined

  • Last visited

Posts posted by Tiron

  1. I haven't tested it, but does the KAS connector not attach to the kerbonaut's back at the kerbonaut's center of mass? If so, thrusting forwards would impart no rotation on the kerbonaut and be stable.

    It looks like it does, yes, although when the kerbal's walking around it does seem to shift around a bit as it doesn't follow the animations.

    Edit: Oh, I think I see what he's getting at. he's thinking of the inline winch that has the cable come out the side of it, which would do pretty much like he says. If you use the one with the cable mounted on the end, dead center, it wouldn't be a problem... I think.

  2. Can you reproduce a problem? If so, PM me a bug report. I've seen it screw up but not reproducibly: whenever I look carefully, it works flawlessly.

    Well, it's better than it was, last time I checked, but it still sometimes flames out if you're climbing too hard, particularly if you try to cut the safety margin to get more thrust out of it. After some goading in the K-Prize thread I've tried to find a way to use just the jets to go higher, and have consistentently failed, and usually end up in at least a partial spin at least once if I push it high enough, even on 5% margin (which seems to reduce the thrust too much to make it really work, or maybe I just don't have enough period, I don't know.)

  3. I built a space plane capable of getting to 80 km and circularized however in order for it to get off of the runway it requires a couple of SRBs. If the runway was about 50 ft longer or had a little ramp at the end i could get off no problem....

    However because i run our of runway i need a little more oomph to get off the ground.

    Problems getting off the runway are usually caused by the placement of your main landing gear. It's a leverage thing. In flight, the 'fulcrum' of your craft is the center of mass. But while you're on the runway trying to get the nose up, it's the rearmost set of landing gear that touch the ground while level (so tail bumper gear don't count.)

    So what happens is, if your rear landing gear are too close to the control surfaces, those control surfaces have very little ability to lift the craft because they've got almost no leverage.

    So what you want to do is move the rear landing gear forward. The further forward they are, the easier it'll be to get the nose up. But also the more likely you are to have a tailstrike. So you have to balance the two. The key thing is you don't want them inline with your control surfaces!

    If you're not opposed to mods, you can ease things a bit with TT's modular multiwheels pack, which has a whole bunch of very useful landing gear that are taller and tougher than the default ones, and have a suspension to boot (which helps a LOT landing on rough terrain). Some of them also have very weak built in motors. And there's even a cute little tailwheel which is just awesome for preventing tailstrike damage.

  4. I mostly use ions for precise orbital adjustments, normally only on geosynchronous flights where precision is key.

    I've done that too. I also used a pair on each of my station cores on my old refueling station (which never refueled anything, ironically) for the same purpose. It's the one case where their weakness is an advantage: A throttled-down Ion is less powerful than RCS, so you can execute fine orbital adjustments really, really well. To a precision greater than the physics system itself can handle, actually.

  5. Basically, what happens is this: Intakeair is (extremely unrealistically) automatically routed throughout the craft. So when one engine flames out, all the Intakeair that it was using automatically redirects to the remaining engines, keeping them alive.

    There's really only three ways to deal with it:

    1.) Have a Center Engine that flames out first.

    2.) Manually disable the engines before they flame out via Action Group

    3.) Cut the throttle to reduce the intakeair requirements to a level that prevents flameouts.

    The last is hard to do manually. Mechjeb 2 will do it automatically, although it's far from perfect at it.

  6. if memory serves - it might not - the brake button (up top) doesnt activate all brakes, unless you tweak it with action groups. have you tried a combination of that and pressing the button that does braking?

    actually, it just activates the 'brake' action group, which by default has everything with a brake in it. It's common for people to remove wheels from the brake action group though to prevent the brakes from flipping the rover.

  7. I think using landing legs for a claw would be your only real chance... I know EJ made something like that for getting rid of space debris, so it should be posssible in theory.

    Maybe if you used some kinda girder-claw-thing that used landing legs to lock onto the girders he's using to step off his landing legs(Which is clever, btw)?

  8. there's an abort button? What is it?

    I always wanted to be able to press eject and have my Kerbonaut pop out of the command pod and float down on a tiny parachute.

    Yes, there is, and by default, it's nothing. It activates the Abort Action Group, which by default has nothing in it. Its default hotkey is backspace, but there's also a button on the left side of the altitude indicator (which you have to hover over the edge of to get it to pop out before you can click it.)

    Technically you could use any action group for it, but backspace is a lot easier to hit in a hurry if something goes wrong.

    So for an 'escape tower' type setup, you'd set it to decouple the pod and activate the sepatrons on the tower. Press backspace and BWOOSH, the pod is gone.

    You'll find that method less effective if you have a structural failure somewhere and lose throttle control.

    It still KINDA works, because the parachutes will help pull the pod off with some rocking. Or violently rip it off if you hit 500m AGL (Or were already below that): as long as you're not going too fast the pod will probably survive.

    But as he kinda points out with his '(Not with Solids)', escape towers or similar are really only necessary if you're trying to get away from rogue solid boosters, but are also good for any failure below 500m (including pad failures, which was why Apollo's LES was so massive.)

  9. Never had much of a problem with that myself; when I use SRBs I try to make sure they're depleted well before it's time for the gravity turn, which is where the trouble usually begins in my experience.

    Unless you're building massive, superpowered monstrosities like I have in the past.

    Imagine a central orange tank double stack, six more orange double stacks radially attached to it, two single orange stacks attached to each of those six, mainsails on all of them, and then five large SRBs for every two outer tanks at the bottom. On top of that? Seven more Orange tanks, with Poodles. And then there was one more center-only stage on top of that, but I forget what I had in it.

    Completely asparagus'd, even to the point of inter-level asparagus: it was set up so that the poodles would fire as soon as they were exposed by parts of the lower inner ring dropping off, with fuel drawn from the lower tanks. Which is roughly equivalent to a pancake, efficiency wise, but actually looks like a ROCKET. And gives some really weird and cool looking firing patterns.

    Getting that monstrosity TO the gravity turn was an accomplishment. Getting past that was...something I never really managed.

  10. I don't know about that. The way i see it these packed vessels are described by a couple of kb, the majority of memory is in the models of the part which are loaded once irregardless whether they are used zero or a thousand time, but please correct me if I'm wrong.

    Actually it's more likely to be the textures hogging up memory than the models... but I digress. Yeah, individual instances of stuff won't take up that much memory... but it'll be highly variable depending on the number of parts involved. Trick being, each piece might be a minor hit, but if you just spam absurd amounts of junk floating around, I strongly suspect it'd hit the memory harder than the CPU. I could be wrong, though.

  11. There sure is.

    And Separatrons weigh so little that they're not really noticeable on a Mun or Minmus flight, as well as making useful emergency de-orbit motors. I'll keep that in mind for when I start planning manned missions beyond the moons, though.

    Yeah, the more Delta-V you're wrangling the more noticeable the extra weight gets. One particular sub-advantage is that because you're dumping it partway up, you can use more sepatrons on a tower than you would mount directly to the pod without affecting the performance much.

    Which is useful when you're trying to outrun your suddenly free-flying SRBs. Fekkers are FAST when they're not attached to a rocket, particularly the small ones. Their inward-curving tendencies are bad for survival too.

  12. Yep. Got into the habit before 0.21 was released, because I kind of got attached to Jeb. I don't use the escape tower, though; I find a brace of Separatrons are just as good and look a bit better.

    For spaceplanes, or rather vaguely aeroplane-shaped deathtraps that will someday become spaceplanes, I use the EVA parachutes mod and the eject module.

    There's an eject module? For spaceplanes I just mount a decoupler behind the cockpit and attach some parachutes. Works pretty well, so long as you don't hit it at high speed below 500m (which semi-frequently results in the parachutes being either ripped off or destroyed).

    The advantage to using a tower versus just putting sepatrons on the pod directly is...you can get rid of it. It weighs more at launch but you can dump it around 10km or so, and it's not weighing you down on your way to Jool.

  13. the problem with Escape pods is the problem with KSP in that parts aren't sucure so to add in an extra decoupler on the main stack means so much more chances of failing that I'd lose more Kerbals testing the abort than it could ever safe

    Well you should already have a decoupler on the bottom of the pod for parachute landings anyway. But there's a nice, dual use, minimalistic method to add an abort 'tower' on top of it.

    Put a clamp-o-tron on the top node of your pod (which is handy anyway). Attach a Modular Girder Adapter directly to the Clamp-O-Tron. Yes, directly. Add two or more Radial Mount Parachutes to the pod. Mount desired number of Sepatrons to the Modular Girder Adapter.

    Set action groups as follows:

    Abort: Rockomax Brand Decoupler under the Pod: Decouple. Sepatrons on Modular Girder Adapter on top of the Pod: Activate/Toggle (Doesn't matter which, since they can't be turned off anyway.)

    Desired Custom Action Group: Clamp-O-Tron On pod: Decouple (You heard me right). Sepatrons on Modular Girder Adapter: Activate/Toggle.

    Suggested:

    Desired Custom Action Group: Radial Parachutes on Pod: Deploy.

    With this setup, the abort action group will decouple the pod and fire the sepatrons, extracting the pod at a rate proportional to the number of sepatrons used. The first action group I suggest is the jettison button for the LET; press it and the escape sepatrons propel it extremely rapidly away from your rocket (Note: I suggest doing this after starting your gravity turn, or else it will come back down QUITE close to your rocket.) The second action group is...to deploy the parachutes. Because unfortunately, activating the abort is probably going to leave you with a bunch of empty stages sitting there which you may not have time to get cleared before crashing.

    These are the directions for the 3 man pod version but it's easily adaptable to the 1 man pod just by using smaller parts.

  14. I regularly launch rockets specifically designed for no other reason than to create debris mrgreen.gif

    I like to watch it drifting/screaming by as I go about my orbiting. Got a nice lil ring going at this point. Still no collisions yet but several sub 2.5k passes....that I'm aware of anyway.

    One thing that does bug me is those silly 60x35k orbits that don't decay. Will the romfarer setup cranked to 99kms "sweep" that stuff out if orbit as it passes below?

    The 60x35 orbits, well, expanding the physics range using the lazor plugin WOULD fix it. sort of. They'd still have to be within that range of whatever you were focused on. Keep in mind that 99km isn't that far: Kerbin has a radius of 600km, so even at 99km physics range you're only going to 'sweep' a relatively small portion of the orbital space, so it's going to take more orbits before they get down to despawn range.

    For non-mod method, you can use the 'debris' filter on the tracking station to 'fly' the relevant piece of debris. The 'simulation bubble' will thus stay centered on that piece of debris, and if it's really on a 60x35 orbit, it'll continuously decay until it crashes, which will probably only take one, incomplete, orbit.

    If you've got a cluster of things in the same, atmosphere-entering orbit, you could potentially combine the two: Use Lazor to expand physics range so that the 'bubble' encompasses all the pieces in the cluster while 'flying' one of them. This way, you can take out the entire cluster at once.

    The downside of focusing a piece of debris to make its orbit decay? You can't go back to the space center from it while it's in the atmosphere, so you basically have to ride it down. Unless you can somehow manage to switch to another craft after the PE gets below 20km (the point where on-rails stuff despawns). And this is a downside because...well, if you ride it down, and it hits land, there's a fair chance one or more pieces will successfully lithobrake, ending up lying there on the surface. If it hits the water though, they're all toast (unless it's a mod part that's completely invincible).

  15. It seems like this is the same mechanic as with the deployable panels, only that smashing the static one doesn't make it explode into a million pieces.

    In fact, the OX-STATs have isBreakable = false in their part.cfgs. It is perhaps a bug that they display as broken in the first place.

    I've wondered that, because they don't store their broken status in the save file, unlike every other breakable part. You just have to reload and bam, they work again.

    window movie maker...might be better

    Yeah, I think I might look at that. MSI Afterburner does a good job recording (even though I have a sapphire vidcard, snerk), but the compression options are...less than optimal.

  16. Mostly on untested designs. Much like on the Apollo missions, you really only need a dedicated escape system for a relatively short period near launch. And in my experience, even then mostly only on relatively untried designs.

    Apollo had five main abort modes:

    Mode 1: Launch Escape Tower. Used from the pad until about 30 seconds after second stage ignition (somewhere above 30km), at which point the LET is jettisoned. 3 Altitude Variations mostly having to do with getting the CM in the correct attitude.

    Mode 2: Service Module Escape. Used from when the LET is jettisoned until they get high enough for Mode 3. Uses the Service Module's engine to clear the rocket, then proceeds to splashdown.

    Mode 3: Contingency Orbit Insertion. Once high enough, the S-II is simply jettisoned early, the S-IVB and Service Module are used to place the Command Module in orbit, with no possibility of a Lunar Mission.

    S-IVB to Orbit: Mode 3 variation where only the S-IVB is needed to get the CSM to Orbit. Still no possibility of going to the Moon.

    Mode 4: CSM To Orbit: If the S-IVB fails, the CSM is used to place the Command Module in orbit, again with no possibility of going to the Moon.

    I've used variations on all of them at some point or another, although I consider Mode 3 and Mode 4 to be basically the same thing: Drop the damaged/malfunctioning stages and keep going.

    I generally find that an actual LET is only really neccessary during the relatively early phases of the launch, but even then mostly only if you have SRBs. A failure with the SRBs still firing is much more dangerous than any other type, because they have a disturbing habit of surviving the stack breakup and going flying all over the place (many of them into the stack, there's a marked tendency for them to curve inwards if they get loose.) They're REALLY fast when separated from the stack, so an EXTREMELY powerful LET is needed to have any chance of outrunning them (and even then it may not quite, but it still helps avoid them.) I made one design that used 16 sepatrons for a three man pod, and it STILL couldn't quite outrun the large SRBs (the small ones have a MUCH higher TWR and are EVEN FASTER!) Just make sure to set up a jettison action group for it. Helpful tip: Jettison the LET only after starting your gravity turn. I've yet to have one fired straight up come down on a rocket, but it's ALWAYS close, so it's just a matter of time.

    In the absence of SRBs, a failure is likely to only result in damage to part of the rocket, which makes simply jettisoning the damaged bits and using whatever's left to get to safety quite viable. The main thing you have to watch here is TWR: If the lower stages are still firing, and your upper stage's TWR is less than the lower stage is providing, the upper stage will be held in place by the greater acceleration from the lower stage. This means you need to cut throttle before jettisoning it, or if that's not possible...well, you're stuck for a bit, so watch that.

    Mechjeb's 'PANIC!' button on the translatron module (which I've yet to find another use for) is exceedingly excellent for pulling a Mode 2 style abort. When you hit it, it cuts throttle and nigh instantaneously stages to the last stage with an engine. FAR faster than it can be done by hand. (It somehow sequentially fires them all in a fraction of a second, without the normal wait time between stagings.) It then activates an Autopilot which aims straight upward at full throttle for some seconds, and then activates the landing autopilot in 'Land Wherever' mode. This entire sequence takes only a few seconds, and I cannot recall an instance where it failed to save the pod when it was actually able to function. Loose SRBs taking out the upper stage are pretty much the only reason it's ever failed, in my experience.

  17. Edit the save. I've done that once or twice when weird things happened and my solar panels broke for no apparent reason.

    As I've just personally confirmed, for OX-STATs this is unneccessary. OX-STAT solar panels do not appear to store their broken status in the save at all, so merely reloading repairs them without even exiting the game.

    I'm presently uploading a video demo of this to Youtube. Gonna be a bit, though. Stupid 1080p and stupid crappy 'compression' on MSI Afterburner...

×
×
  • Create New...