Search the Community

Showing results for tags 'staging'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • The Daily Kerbal
  • Kerbal Space Program 2
    • KSP 2 Discussion
  • 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
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • Breaking Ground Expansion
    • Breaking Ground Discussion
    • Breaking Ground Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


Location


Interests

Found 30 results

  1. I've managed to land on Eve using Matt lownes recent eve tutorial as a guide. My lander has a 2 stage core along with 6 external tanks designed to drain sequentially, jettisoning in pairs from the central core, each feeding into the next tank and then to the core. However, for some reason once the 1st pair have drained it skips to the core tank whilst all the other tanks remain full. I've reloaded the save several times and the only way I can get it to drain in sequence is by shutting off the core whilst enabling crossfeed on the decouplers. Fuel flow priority has no effect Any ideas?
  2. I built a massive lander for the moon which was attacked by a kraken while landing. While landing, I deployed the bottom stage (14 Jumbo-64s and 7 mainsails) to eject the lander (2 X200-32s, mainsail, hitchiker, Mk1-3pod, and landing gear). What I expected was that the stage would disconnect and the lander would fire the mainsail and land some distance away. What happened was that the lander sank rapidly into the bottom stage, and when it was almost all the way in it registered that there was a collision. My kerbal in the hitchiker went splat and the two in the command pod got launched at half the speed of light out into the outer void. Is there a known solution to this bug? I really want to land on the Mun with this lander, but if I have to eject the bottom stage early, I won't have enough fuel on reentry.
  3. I've occasionally used fairings when the stuff I was putting on the top half of the rocket got too blatantly unaerodynamic (or had gained a forest of doohickeys), but I've never really been confident of when the "best" time to get rid of it is. I mean, I guess I'm working on the underlying assumption that fairings are not always counterproductive. But if that's true, then presumably at some point the equation changes to where future delta-v savings of being aerodynamic are outweighed by the future delta-v losses of the mass of the fairing. Obviously this happens before you get to space, but is there a rule of thumb to follow here? 40km, lower, higher? How much do variations in speed matter compared to altitude thresholds if you are more or less following the usual type of ascent path for a large rocket? P.S. Do fairings help at all in reducing bending? I've always sort of imagined that they do, but without concrete reason or evidence.
  4. Recently, I have been experiencing an issue within the Space Plane Hangar concerning staging. Whenever I add a jet or turbofan engine to my craft, the stage for the engine does not appear. This occurs in the VAB and SPH, but is usually not a problem in the VAB as I do not use aircraft engines much there. This problem started after I installed the B9 Aerospace mod, which I think I have properly installed but I may not have. Here is my list of mods: X Science AJE (?) B9 Aerospace (B9 Animation Modules, B9 Part Switch, Firespitter, JSI, SmokeScreen) ChopShop Destruction Effects Kerbal Engineer (It's outdated, but still works fine) Kerbal Konstucts Kerballoons KWRocketry Procedural Fairings RealPlume (?) SETIrebalenceReactionWheels (?) SmartStage Smokescreen (?) Solver Engines (?) Squad (Stock Parts) I have added a question mark to the mods whose functions I've forgotten. Hopefully you can help with my problem. Thanks!
  5. KSP 1.4.0 x64 I was in map view, waiting for the SOI change (Kerbin -> Mun). As soon as it happened, a staging occured "by itself". I did not press the space bar, for sure. My finger was idling on top of the "M" key. And normally, when accidentaly pressing "Space bar" in map view, nothing happens. I had no planned maneuver in queue. This is of course a bummer, now I have debris to play with. The only thing that really changed was a test run of "Too Many Orbits", but I already checked the log and the mod is just not loaded at all. I will remove it for the next session, of course. Log: https://www.dropbox.com/s/ucdu6elg0mfdfje/2018-03-13_2 KSP.log.7z?dl=1 Edit: I loaded the backup persistent file and this time i warped upon 1 minute prior SOI change and did not switch to map view. All the time within flight mode, the same issue occured - no finger near the keyboard at all. Edit: It also happens without "Too Many Orbits". I will load a backup before launch, load the vessel to VAB and disable autostruts-grandparent which I set up with EEX... perhaps this is the issue, because I found a few "A joint can't connect the body to itself." inside the log. Of course the log does not tell me which parts are the culprit... Edit: Yeah, removing the autostruts (but left two manually, only the two biggest tanks alone) helped. It seems like the abrupt change of the camera view on SOI change kraken-destoys the whole vessel somehow when the "wrong" parts have autostruts set. But still no clue which parts are wrong... Perhaps radially attached ones?
  6. I have played KSP for quite a while now (and love it), but only recently have started using docking ports. for a minmus mission I decided to go with a lander vessel on top of a large carrier vessel joined by two docking ports. I tested it in orbit over kerbin, and it I could undock and dock it with no problems, except that after docking again the stages of the lander vessel are merged with the stages of the carrier vessel. Is there a way to prevent this from happening? Or should I build the craft differently (Now I have built both in one go, no subassemblies)? What I would like is the staging sequences of the two vessels to be kept separate. I don't even need to see the stages of vessel2 when controlling vessel1 (and vice versa). Hope someone can advice.
  7. When I make engine clusters for the sake of a higher TWR, I usually don't use the built-in adapters. Usually, I will take a radially-attachable nosecone and put it on 3-4x symmetry, then put the engines on the bottom. I then use the displacement tool to push them together in the center to look like and engine cluster. I do this for three reasons: 1) I think the partially visible nosecone looks better than the adapters 2) the nosecones don't make it less aerodynamic (as far as I know) and 3) I can't figure out a way to attach anything below the adapters (like if it were an upper stage and I need a decoupler below, I would have to now have several stacks of fuel tanks because of the inability to put a decoupler in the middle), and the above mentioned method leaves the node on the bottom of the fuel tank stack open. I usually place a girder or two on this node until they just stick out below my engines, then put a decoupler on the end of that. This way I can have a central stack below this for a lower stage. The issue with this is that it is unshrouded and the two sections of rocket are joined by a thin girder. Does anyone have a more effective way of doing this that still looks okay, or is this the best possible solution? Thanks for any input.
  8. For some reason, I don't know why. No-one seems to have these problems except for me. Whenever I make a rocket and move it over to the launch pad, The staging doesn't want to set off the rockets. The parachutes will deploy, The rocket will decouple, and still the rocket will not fire. The rocket will fire when I select it and tell it to fire but using two solid rocket boosters makes this impossible. I have checked and yes there is a green light at the bottom left corner. Has there been anyone with these same issues? Does anyone know how to fix it? Thanks in advance.
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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.
  14. 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.
  15. 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!
  16. I've posted a challenge over in the gameplay challenges forum but I thought it could use a discussion thread. Here's the link: This thread is for discussion of different launch configurations to achieve a fully-reusable orbital shuttle with parallel staging. Lots of pros and cons to different configurations and engine types and recovery options, so I'm interested to see where the discussion goes.
  17. 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!
  18. Basically I keep each stage of my rockets as separate vessels so that I can use switch and swap them around, and they tend to be pretty complex. So I have a rocket to get into orbit and a payload each with their own staging, all set up. Merge the rocket onto the payload and BAM. Not only are the rockets stages messed up, but it's changed all the stages for my payload too (usually into one giant jumbled mess with no rhyme or reason at all). if you can't figure out the stages, don't mess with them lol EDIT: The best solution? EDIT2: (why does tab submit on this forum) Make a type of ship design that doesn't contain parts but other ship designs and the stages are the designs in order. I don't actually expect though.
  19. 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
  20. Building an Eve landed I have come across two minor changes that I feel would be helpful to many. 1: Make stages collapsible, similar to sets of decouples and engines, but add it to the entire stage. I have lots of parachutes on two separate stages and lots of engines on other stages, construction would be much easier if I could collapse stages that I am not working on. 2: Adjust explosions to be somewhat more realistic. Empty fuel tanks should not explode when they hit the ground.
  21. 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.
  22. 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
  23. 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: https://dl.dropboxusercontent.com/u/59091477/Monstrosities/Staging Theory.xlsx
  24. I have a problem with the game crashing when I try and launch a certain craft. (Pictures and link to craft file below.) The radial boosters stage just fine. But when I go to do the first stage on the central stack, the game “quits unexpectedly”. The problem seems center around the stage with the orange tank. But this is the fuel transport vehicle that I’m trying to get to my surface base on the moon. If I remove the orange tank (and thus anything attached to it) the problem doesn’t occur. I normally run modded, but I've verified that the problem persists when I run unmodded. The craft file and pictures... https://www.dropbox.com/s/jzlulk3zgq1e46x/Fuel Carrier for Lauch.craft?dl=0
  25. 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?