Search the Community

Showing results for tags 'staging'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website
  • KSP Pre-release
    • 1.2.9 Pre-release Branch
    • 1.2.9 Pre-release Modding Discussions
    • 1.2.9 Pre-release Bug Tracker


  • Developer Articles

Found 16 results

  1. Hi devs! Thanks once again for the wondrous never-ending time-sink that is KSP. =;o} I build a lot of VERY asparagated ships. My current one has 26 stages, and the bottom stage has all 25 pairs of engines, plus the one in the central core, *PLUS* the additional radial-mounted engines on many of those stages, all firing at launch (This is because I'm trying to achieve orbit from a launch at the KSC with the gravity hacked to 10G... Good game, good game. =:o} ) This means that stage 26 shows up in the staging UI as a stack of 30 or 40 engine icons, each of which represents a single pair of engines. If I want to scroll up and check whether any pairs of engines have been accidentally added to the wrong stage, I first have to scroll through all of those icons, which - with so many parts of the ship making the game very laggy (especially after an hour of playing), is a *slow process*! (I'm on a modest 4GB machine, not able to upgrade any time soon.) I'd like to be able to right click on the orange icon with the stage number, and click "collapse stage", so that stages I don't need to see in detail get shrunk to a reduced, sub-grouped description with a single icon for each *type* of part present, and a number alongside showing how many are there. I.e., instead of: [ENGINE ICON] [ENGINE ICON] [ENGINE ICON] [ENGINE ICON] [LAUNCH STABILISER ICON] [LAUNCH STABILISER ICON] [ENGINE ICON] [LAUNCH STABILISER ICON] [ENGINE ICON] just show me: [ENGINE ICON] " x 6" [LAUNCH STABILISER ICON] " x 3" This should make checking the staging of large, complex ships much quicker and easier. It would also make moving parts from (say) stage 5 down to stage 26 much easier, since the intervening stages won't take up quite so much screen space (though obviously any stage with just a pair of speratrors/decouplers in is going to take up just as much space as before, the ones with several pairs of sepatrons in will shrink a bit.) At present, I have to scroll the source stage right to the top of my screen; grab the engine to be moved; drag it to whichever stage is at the bottom of the screen (there seems to be no auto-scrolling... or if there is, it fails!); then scroll *that* stage up to the top; locate the icon for the engine I'm trying to move; then drag it down... and repeat as many times as necessary! =:o\ Of course, we would also need to be able to re-expand selected stages (same method: Right-click and select "expand") once the time comes to drill down into what a particular stage has in it. An alternative (and possibly simpler to implement) option would be to collapse the selected stage to just the orange stage-icon, nothing else (i.e. forget about me "reduced description" idea. Then all stages (however simple) could be reduced in screen height, which would again help a lot with moving parts up and down a long staging list... Although I'd then have to expand particular stages one by one to hunt for the stray engines, so on balance I prefer my first version of the idea. Thanks for your attention.
  2. You know how engines have nodes on top for attaching to fuel tanks, and nodes on the bottom with shrouds for attaching decouplers? I think we need that for parachutes but the node on top has the shroud instead of the bottom! Also, there's probably a mod for this, but it should be stock
  3. Hello KSP Community! So in the course of a science game of mine, I've become really, really tired of playing around in my own little corner of the solar system. I've built a Mun orbiting space station, landed a couple of times on the Mun, and flown more refueling probes to the Mun than I care to count. I want to go to Duna. The question is, what does it take to get there? Manned or unmanned, I'm interested in both types of mission... but what does a typical Duna mission look like, and is it complicated? Thanks in advance, I know y'all are an awesome community who'll respond in a helpful way. Grafdog
  4. I've made plenty of stable and meta-stable rockets with stock fuel flow in my time, but while attempting a fully reusable career play-through I decided that this particular mechanic had to go. I'm aware of the workarounds using fuel pumps, tank locking, and even the TankLock mod being maintained by the illustrious linuxgurugamer: However, what I would really like is for rocket engines to just behave like jet engines, having the "resourceFlowMode = STAGE_STACK_FLOW_BALANCE" property which causes fuel to drain evenly from all of the tanks in the current stage. To that end I made a Module Manager patch with the following text: This should change the resource flow mode to the desired mode in all engines which use ModuleEngines or ModuleEnginesFX (every rocket and jet engine I've inspected the .cfg of), but it had no effect for me. I've only ever seen resourceFlowMode defined for jet engines (ModuleEnginesFX), and it's always defined as "STAGE_STACK_FLOW_BALANCE". Is this node simply not implemented for ModuleEngines, or have I made a silly mistake in my Module Manager syntax? Thank you.
  5. Challenge: Design and model a fully-reusable PSTO (parallel stage to orbit) shuttle, suitable for taking a crew to orbit and returning them safely to Earth. People get excited about SSTOs (both of the VTVL and winged varieties), but for Earth, using multiple stages is almost always more cost-effective. However, we've never once flown a fully-reusable human-rated shuttle, and there's no obvious configuration for a fully-reusable shuttle that uses staging. In particular, I like the idea of a parallel-stage-to-orbit design, where all the launch engines fire on the pad together, with the orbiter engines continuing to fire through stage separation (think Space Shuttle). This introduces additional complications, particularly with respect to configuration. Some considerations: 0/0 LAS. Being able to escape in the event of a booster RUD is ridiculously important, from pad to separation. The orbiter either needs to have sufficient thrust to push itself free of an exploding booster, or it needs auxiliary solids for LAS, or it needs full cabin ejection with chute recovery. COM/COT. Centers of mass and thrust in a vertically-stacked launch vehicle are simple, but for a parallel-staged launch vehicle, it's a little more difficult. The SSMEs had ridiculously high gimbal ranges to help with this, but with a fully-reusable launch stack things may be more or less complicated. Engines and crossfeed. Using the same engines and fuel on the orbiter and the booster simplifies operations and can also allow for fuel crossfeed, but that does introduce some additional complications. If the launch engines are used for orbiter LAS, then they will be large enough to take full advantage of propellant crossfeed. Booster recovery. A liquid fly-back booster is one option; a RTLS tail-sitting booster with landing legs a la Falcon 9 is probably better. No splashdowns for this. Asymmetric thrust and COM may be a consideration depending on how the launch configuration looks. Orbiter recovery. Again, no splashdowns. The orbiter can have wings and landing gear, or it can come back and land vertically with landing legs. However, if it is going to land on its tail, then the crew cabin probably needs to be ejectable using landing-abort solids and chutes, since a tail-first vertical landing is a high-risk maneuver. The ideal solution is to have landing engines which (somehow) can vector or change orientation to allow a vertical landing in horizontal attitude, like sci-fi spaceships. This allows minimal-risk landing and immediate egress. Lifeboat. If the cabin is ejectable, then it makes sense to allow it to act as an orbital lifeboat in the case of orbiter damage a la Columbia. However, this means it either needs its own RCS and TPS. It may be possible to integrate its RCS and TPS for use within the orbiter. Airbreathing. Should you use a rocket-combined-cycle airbreathing engine on either stage? It's a good question. On the one hand, having airbreathing engines on the booster reduces the weight penalty (since they don't have to go to orbit) and can assist in recovery. Having an airbreathing engine on the orbiter increases weight penalty, but could be helpful for landing since airbreathing engines are more readily vectorable than rocket engines, which must be gimballed. It's also possible to conceive a partial airbreathing engine, like an air augmentation shroud on the booster which wraps around the orbiter's launch engine. Altitude compensation. If the orbiter engine doesn't have altitude compensation, it will incur a specific impulse penalty. However, aerospike engines are heavy. An SSME pressure-compensated engine is one possibility. Another possibility is to have the orbiter engine interface with the booster body in such a way as to allow a higher expansion ratio after separation. Keep in mind, however, that you may be using the launch engine for recovery as well. Cargo. A cargo bay is not necessarily a requirement, but it definitely adds versatility. A cargo bay can also be used to add an auxiliary fuel tank for extended on-orbit operations or BLEO missions. Consider orbital refueling as well. I have a few ideas for how to pull this off, but I'm really interested to see the kinds of things the forum can come up with. There are a lot of options here, and none of them are automatically ideal. Design, describe, and model your submission! You don't necessarily have to fly it; it will probably be ridiculously overpowered for stock KSP. Excited to see what everyone comes up with.
  6. Ok, this is a really complicated question, but I'll do my best to make it clear. I've built myself a plane with a downward facing cargo bay (called henceforth carrier). It's purpose is to carry a few probe cores, outfitted with parachutes, a small battery, and some science gear, and drop them into different biomes for data collection (called henceforth pods). The idea being I can record data and collect science from many biomes with fewer missions launched, and also very quickly, since the carrier pushes right up to the edge of mach 1, fully loaded. So far so good. I fly off with one pod in the carriers belly, and an action group to detach the pod, deploy its chute, and turn off its hibernation all at once. I let it go at about 3,000m, everything looks peachy. I can't switch to the probe, since I'm flying in atmosphere, so I watch its altitude and speed from map view. It holds at about 175m/s all the way into the ground. After much tinkering with drogue chutes, differing altitudes and states of probe hibernation, I decide that what needs to happen is I need my control to follow the pod when it detaches instead of the plane. That way I can see what's really happening with the parachutes, and once its landed I can switch back to the plane and keep flying. I had toyed a little with the Stratolauncher (stock), so I figured this would work well. I converted all my action groups into a staging setup, since that's how the Stratolauncher (stock), is set up, and I thought it would work. Same deal as before. How do I get this to work? How can I designate to the editor that I'd like the staging to follow the probe pod out the belly, instead of the plane all the way? Or is there another solution I'm not seeing? I'd include the .craft file of the carrier as it stands right now, but I'm not sure how to attach a .craft. I'd appreciate a concise explanation of that as well if you feel the need to see the plane. Thank you!
  7. Hey guys, just had a quick question. Why do all probes/satellites (particularly early ones) seperate from the final stage of their carrier rocket once they reach the proper trajectory/orbit? And, is do any of those reasons matter in KSP? I've always done it, but I have no idea why. I guess just because that's what I've always seen them do. In early career though, when trying to save every buck per launch, why ever bother? Those TR-18A stack decouplers are $400 each, which I could spend on another RT-10 instead = more dV/$. Does everybody do integrated upper stages and I'm just late to the party? I'm also talking about stock here, but what about RSS/RO? Does that change the equation a lot? Thanks!
  8. I'm aware that this has been suggested a number of times before. However, I have never observed much follow up to the topic. I think it would be a very welcome feature to be able to toggle parachutes out of staging entirely, like you can with decouplers (as of a few patches ago, anyways). The first and perhaps most significant advantage to this is that it would allow the user a lot more freedom in designing emergency systems for their rocket. At the moment, I find it very frustrating that although the game includes both an emergency escape tower as well as a dedicated "abort" action group assignment, it's kind of inconvenient and annoying to actually utilize them. The primary reason for this is that they just add additional components to wrangle in staging. The interface could be exactly the same as the staging toggle for decouplers. Just right click the parachute, then click the option to disable it in staging. Another use of such a feature would be more precise control of parachutes for specific situations. Slowing a landing space-plane, for example. You could have parachutes be in their own separate stage, but then you have to worry constantly about accidentally triggering them at a bad time. With them toggled out of staging entirely, you can decide exactly if and when the parachutes are deployed. On a personal note, my neigh-pathological fear of messing up chute staging is why I've never tried making a space-plane styled after the space shuttle. A secondary suggestion, for the same reason, is to make it possible to toggle engines out of staging as well.
  9. Hello all, Could someone please advise me or point me to a post / document where I might learn when to fire the main engine? Presently I use boosters first then fire the main and I am undecided if this is best practice. Kind regards, Kerbal007
  10. I have a modding request, seems like it would be relatively simple, I would create it myself but I have not found any information on how I would go about doing this. The idea is simple, to have an option in the right click menu to simply remove any part from the staging list. Seems like this should already be a stock feature. There are times when you don't necesarilly want a part to stage and want to keep it as an option during flight. For example I may have a radial decoupler with a probe on it, I would at some point in my flight want to decouple this and leave it in orbit somewhere but want to decide that in flight. So I would simply right click on the part in the VAB and click "disable staging" and it would remove it from the staging list. Then I would have to right click and manually decouple the part in flight. Anyone know where I could get information on how to do this myself. I'm no coder but I am a tech guy so if given the information I could potentially do this myself.
  11. Another irritation, game keeps forgetting the staging info. E.g. lift off from mun, swap to the map view, swap back and now the engine, parachutes decouplers etc are all now in the same stage. E.g. #2, build a rocket, sort the stage order out, move to the pad, staging order has changed E.g. #3, build a rocket, save it, load it later, different staging order, again. Have also had one where the order looked fine, but staging triggered the bug, combined all stages, then activated them all... Would make sense of s sort if 'reliability' was something you researched to improve, but as it is this is a royal pain
  12. So working on the XenonStorm Mk3's fuel pod design has once again lead me to an old question: "Given a bunch of drop tanks of equal mass and a certain overhead per stage in the form of decouplers (whose presence in upper stages negatively affect all stages below), how many stages before decoupler mass starts really getting in the way, and how many tanks should be in each stage?" Absent decoupler mass, the clear answer is purge dry mass at every opportunity, staging early and often, however, decouplers do have mass, and in the case of my fuel pod, over 1/10 the mass of an empty tank. Also, if later stages are too large, the dry mass can damage the mass ratio more than it would on an earlier stage. To explore the problem further, I built a silly spreadsheet, here dealing with 100 tanks across 10 stages: I put a few important quantities here and there, notably the full and empty numbers for my fuel tanks, decoupler mass (stack decoupler), thrust, Isp, g, and the mass of the ship itself as the ultimate payload. "excess ratio" comes about because when the same engines are used all the way, it's the ln(wet/dry) part of things that makes the delta-v happen, so I took the mass ratio of each stage and subtracted 1 to make them more easy to compare, and allow them to be summed in a way that wouldn't be affected by the number of stages. The fuel pod's actually 7 stacks of tanks stuck on the back of a 1.25-2.5m adapter plate, but for simplicity I've chosen to study the case of 1 long string of xenon tanks with decouplers in experimental locations. A bit of experimentation bore some odd results -- running with the 100 tank concept, I first tried to keep all stages about equal in mass ratio and thus delta-v, winding up with 3/4/5/6/9/11/14/17/23 yielding a sum exccess ratio of 1.1623 and a delta-v of 45.3km/s, as seen above. Reversing this pattern (on the stage early and often concept) gave 1.1612 and 42km/s, supporting the too much dry mass in a late stage argument. Trying something odd, I tested 10/10/10/10/10/10/10/10/10/10, getting 1.1726 and 44.78km/s. I was expecting that to be worse, but very confusingly, the mass ratio sum is better than the even dv split distribution while the delta-v is worse. I'm no longer sure that the sum of the mass ratios really means that much...that or I messed up a formula. I then tried messing around with less stages, trying 12/15/19/23/31 for 1.1784 and 43km/s and 7/11/17/26/39 for 1.1788 and 43.6km/s All of this is of course just half-blind experimentation, though. I get the sense that there's something I picked up in algebra 2 or possibly differential equations that'd lead to a far better solution, as well as answer related questions like whether the fundamental results change noticably with different fuel tanks for decoupler masses. @GoSlash27's stuff on the reverse rocket equation is excellent, but doesn't answer weirder questions like "how much delta-v can I get out of a set number of identical fuel tanks by varying the staging?" What blade made of math might provide a more general solution? Edit: wow, that table looked like a toilet happened. Have a screenshot instead, or a copy of the spreadsheet itself: Theory.xlsx
  13. I've an issue with the advanced construction training scenario. In the "fix staging" part, I'm stucked because they tell me to put the Swivel in the same stage as the SRB, but I do so and I cannot advance. Can you help me guys with the correct order of the staging part?
  14. One of the ways that SpaceX keeps costs down is using the same fuel and engine on the second stage that it uses on the first stage. Only having a single engine design for the entire launch vehicle is a really good idea. I was wondering, though: how close to optimal is the 9:1 configuration? SpaceX started development of a 5:1 configuration so there is obviously some room for variance. I don't know what other TSTO launchers use matching engines so I'm not sure there is anything else to compare it to. The second stage engine has a higher specific impulse and thrust due to the extended nozzle, but that extended nozzle also weighs more, so that may or may not have an impact. I assume the primary driver here is the relative masses of the two stages: you want your launch vehicle to have a T/W ratio of nearly 2:1 at launch, but you want your second stage to be roughly one fifth the mass of your first stage and have closer to a 1:1 T/W ratio at separation, suggesting a nearly 10:1 thrust ratio...pretty close to Falcon 9. Any other considerations? What about altitude-compensating nozzles?
  15. My suggestion is to have the staging icons in flight across the top of the screen (or the bottom), with the fuel gauges hanging off the icons (or sitting above them), rather than vertical on the left hand side as it has always been (since I started playing). I would like to suggest a toggle in the UI options to return the toolbar to be horizontal at the top. I envisage that the staging could end up between the timer and the altimeter (as the toolbar might get returned) Ideally it would leave the centre of the screen free for cinematic recorders :). Thanks again for the awesome game. Peace.
  16. Hello, I am encountering crashes when using the 3.75m decoupler (Ven's Stock Revamp is installed), and it only occurs when using that one. No matter the altitude or time, it just causes a game crash. I have a .zip folder with my log file and some screenshots of my GameData folder. Thanks