Jump to content

Streetwind

Members
  • Posts

    5,912
  • Joined

  • Last visited

Everything posted by Streetwind

  1. It sounds like rocket construction is an area in which you can improve further. You'd be surprised just how much proper construction matters. A launch vehicle of five hundred tons in mass should get you really, really far if you built it well. I bet I could get a direct Hohmann transfer to a low solar periapsis in less mass than that, no need for a bi-elliptic one. If you're encountering a case where adding more fuel to your rocket is no longer improving its dV, you are most likely adding that fuel to an already overloaded stage, thereby causing other stages to get choked by the added mass. The way rockets work is that everything you add on top affects everything that exists below. This may sound daunting - that's like, an unlimited number of variables to take into account! Good news though - it's much easier than it sounds. Because the way the math works out, there's only one single number that matters for each individual stage, and you can in fact eyeball it most of the time and it'll be fine, so long as you avoid going really far off track. Doing the math just helps you learn how to eyeball it. I've written about it here before. Apologies, it's kind of a wall of text. I have a regrettable tendency towards those. Trust me though, it'll be worth your time Note that this is very inefficient, due to something called the Oberth effect. It's a particularly arcane bit of orbital mechanics, and you had no way of knowing this beyond figuring it out through trial and error, so don't be hard on yourself over it This is what the forum is for. The way it works, in simplified terms, is that spending fuel is more efficient the deeper down you are in a gravity well. It's not exactly that, but that's what it boils down to in practice in KSP. What you have been doing is spending a small amount of fuel to get out of Kerbin's gravity well, then spending a lot of fuel to aim at your actual destination while you are not anywhere near a gravity well. Thus you spent more fuel than you needed to. What you should have been doing instead is spending all your fuel deep in Kerbin's gravity well - in other words, making the full transfer burn in low Kerbin orbit. Counterintuitively, the same amount of fuel - indeed, the same amount of dV - would give you a noticeably deeper Sun periapsis then. Or, well, you can follow Zheetan's suggestion and do a bi-elliptic transfer. But even then, you'd ideally do the full transfer burn to your high solar apoapsis directly from low Kerbin orbit. Escaping Kerbin before even plotting your transfer is always the least efficient method. But how do you get from this tiny circle around Kerbin to your destination in solar orbit? Well, imagine Kerbin wasn't there. Imagine if it was just your spacecraft in a solar orbit that happens to be identical to Kerbin's solar orbit. What would you do to lower your periapsis towards the sun? Burn retrograde to your solar orbit, of course. And if you wanted to get out to Eeloo? Burn prograde, of course. So that's what you do, except that you must do it while circling Kerbin. You are in a low orbit around the planet, but your goal is still to make a burn in the correct direction relative to Kerbin's solar orbit. For example, if you want to go closer to the sun, you want to make a burn on Kerbin's sunlit side, so you are ejected from Kerbin's SOI "backwards". In other words, you make a prograde burn (relative to your low Kerbin orbit) that ejects you retrograde (relative to Kerbin's solar orbit). And going out to Eeloo is the same, just on Kerbin's night side. You make a prograde burn (relative to your low Kerbin orbit) that ejects you prograde (relative to Kerbin's solar orbit). In this way, the burn to escape Kerbin's sphere of influence is at the same time a burn in the right direction relative to solar orbit, so you can just keep burning in the same direction to lower your solar periapsis (or raise your solar apoapsis) despite still being just a few kilometers above Kerbin's atmosphere. Of course, depending on the amount of dV you must spend and the acceleration your engines provide, making a very large burn in low Kerbin orbit can be very tricky. Because the orbit is so strongly curved, and you traverse a significant portion of the circle in just a few minutes, burns you make there grow less and less efficient the longer they get. If you burn at the maneuver node, you'll burn off-prograde for most of the time, whereas if you follow the prograde marker, you'll not burn in the right direction for most of the time. Rule of the thumb is that if your burn is longer than six minutes (three before the node and three after), you're starting to get inefficient. You can get around this by splitting the burn. For example, make one burn that raises your Kerbin apoapsis to around where the orbit of the Mun is. (Take care not to actually encounter the Mun, you don't want that here.) Loop around once, and as you come back towards your Kerbin periapsis, make a new maneuver node there and start a new burn in the same direction as the first one - basically continuing what you started. Once you have an escape trajectory out of Kerbin's SOI, you can keep burning until you have achieved your desired solar orbit destination.
  2. Does it specifically say the word "dock" anywhere in the contract? If not, then all you need to do is get them within physics load distance of each other - in other words, within roughly two kilometers. Note that the two spacecraft performing the rendezvous must be from different launches. You cannot put two probes on the same rocket, throw them at the Mun with slightly different trajectories to separate them, and later have them meet up again once there. That won't complete the contract. Also check the contract (and the app in the toolbar) carefully for mentions of requiring newly-launched spacecraft. This clause is common in satellite contracts, for example, and I'm not sure if it also exists for the rendezvous contract. If you also happen to have a "build a space station in orbit of the Mun" contract, you can do both at the same time. One launch to put the station there, and another launch to either just visit it, or to add whichever missing parts didn't fit on the first launch due to bulk or weight issues. The visiting spacecraft can also be a lander looking to touch down on the surface (or coming back from it).
  3. Try upgrading your tracking station. It improves the display of orbit lines, and additionally, unlocks extra data displays in one of the menus on the bottom left in flight mode.
  4. Nah, it's working fine. It is, in fact, working perfectly fine. Too perfectly, one might say. I've previously written about this here:
  5. First thing to check: that node towards Duna, does it ask you to burn right now? Or in XYZ days? Due to Kerbin's circular orbit around the sun, the direction the node sends you in changes as time passes. The direction doesn't need to be correct hundreds of days ahead of the transfer window; it only needs to be correct at the time you need to execute the transfer burn. The tool should place your node in the correct position for the alignment to match properly at the time of the burn. Second thing to check: are you playing via Steam? If so, let it do a file verification on the game. If not, completely uninstall everything, download the game fresh, and reinstall in a clean folder. Then, see if your alarm clock issue perists. If yes, please give us a number of steps which for you lead to to this issue reoccuring every time, which anyone can do for themselves. As in: start new sandbox save, spawn Kerbal X, launch into orbit, etc, etc. If it only happens in one specific savegame, provide that savegame for download, and explain whether it is a new save you started in 1.12, or an older save you've carried forward.
  6. I have never seen anything like it. Can you take a screenshot or video of the effect?
  7. For the limitations of the current implementation, see the link below. Meanwhile, if you can actually produce a situation in which the transfer tool creates a node that literally does not work (like not even leaving the SOI), then please try and see if you can find a way to consistently reproduce it. Like, a series of steps going "load this save file, go fly craft XYZ, use tool to create node to destination ABC". If you can find such a reliable reproduction method in a save completely without mods, please create a bug report with it at https://bugs.kerbalspaceprogram.com and then link to it here. I'll make sure it gets seen. Provide all the information you can, such as a save file for download, and precise instructions on what to do with it.
  8. See here: Same effect causes the transfer tool to tell you to wait multiple days for a simple Mun transfer.
  9. The Advanced Grabbing Unit (also called "the klaw") is a part that can latch onto another ship and establish a docking connection without the need for a docking port on the target ship. Though, note, I'm not sure if certain difficulty settings might not interfere with fuel transfer across the klaw. Even in that case, though, you can still use the engines on the ship with the klaw to pull your Eve return craft's orbit down to intersect with the atmosphere. After that, it's just a question of aerobraking until you reenter.
  10. @Termopsis Is that in an existing save, or did you start a new one? Also, did you mean update 1.12? You wrote 1.11, but that was the previous one. The one that just launched (on PC, anyway) is 1.12.
  11. The alarm clock app gives you the time of the start of the transfer window. Not sure how the size of the window is defined, but it's a period of multiple days. The best possible second to launch will be different than the time the alarm gives you, because the alarm only tells you when the window starts, and the best possible time is somewhere in that window. In practical application, for all bodies other than Moho it doesn't really matter if you're a day or two off of 'perfect'. You'll still get an encounter just fine. The transfer app, meanwhile, searches for the mathematically perfect solution to create a maneuver node. This means that it often decides to give you a node for a transfer window far into the future, because that future transfer would be mathematically better than the best the current window has to give you. This obviously doesn't help if you want a transfer for this window. This has already been raised as feedback during prerelease testing and acknowledged; but sometimes, a week or two before release is just not enough time to research and implement a fix and then run it through the entire proper test-QA-release process. The tool will likely be improved in a future patch. Probably. I'm not a dev, I'm just a volunteer
  12. The transfer app requires building upgrades. After all, you already need to upgrade a building to even make a maneuver node by hand. It would be silly to give you a tool that would make nodes for you even before that, right? The fireworks launchers are parts, and like all parts in career mode, are somewhere in the tech tree. If they are not in the tech tree, that would be a bug.
  13. No, that's not quite it. You wait until you see the Mun rise, and then you burn straight prograde. Not at the horizon/the Mun. In general, never burn directly at the destination you want to go - that's not how orbital mechanics works Only when you're trying to meet up with another spacecraft and have managed to get within 10 kilometers of it. Then, and only then, you can go straight towards it. When you look for the Mun rising, feel free to start burning immediately as soon as you see it. The perfect moment would actually be slightly before it becomes visible, but of course you can't see that moment. So you simply wait for it to peek over. EDIT: And if you still want to practice with maneuver nodes as well - here's a post I once made with a step-by-step guide about how to get a good Mun maneuver node. Not sure if it's what you're looking for, but I did include a video that shows the process in practice.
  14. I don't know. Can you? In all seriousness, the answer is "yes, if you have a docking port, and the skill to perform a rendezvous and docking". It's a perfectly valid strategy, and people have built entire motherships out of 10+ individual launches in orbit. The main difficulty is the inherent wobbliness of docking connections. If you want to move a 700 ton vessel, you have to bring either a lot of thrust or a lot of patience, and if you pick the thrust option, that poor docking port is going to struggle. So my recommendation is: bring an engineer and an inventory full of struts. Once docked, the two vessels are considered a single spacecraft, which means you can strut from one to the other in EVA Construction Mode to stiffen it up. The struts will later automatically disconnect upon undocking.
  15. So long as it flies as a rocket (as in, thrust dominates all other forces), a vessel shouldn't care much about where its center of lift is. It's the center of aerodynamic pressure that must be behind the center of mass for the vessel to be stable. CoP and CoL are not the same thing, and the little blue ball in the editor only ever shows CoL. You can pretty much ignore it 100% of the time in the VAB, unless you're specifically designing something that is meant to do aerodynamic flying at some point. In which case you only pay attention to it for that specific stage. As there's no way to see CoP in the editor, you have to eyeball the stability of your rocket. OP's rocket did not strike me as overly unstable from the image, and since both he and others have successfully flown it into orbit, that first impression appears to hold out.
  16. Hmmm. 3453 m/s total - that should make it to orbit. My rockets generally tend to make it in 3300-3400 m/s. Of course, you're carrying a winged orbiter, so you're going to have more drag than a typical pencil-shaped rocket. But drag is only a very minor factor in dV cost to orbit, in the end. The key to spending as little dV to orbit as possible is, counterintuitively enough, ignoring aerodynamic drag entirely and being super aggressive with your TWR and your ascent profile. So I would actually go against other people's suggestion here. Stick with your high TWR, and pitch over right the moment you leave the pad. A good rule of the thumb, for sane TWR values, is to aim to be at 45° pitch angle by the time you cross the 10km mark. But in this case, I want you to try to be at 45° pitch by 5 km. And just be full throttle all the time until you get an apoapsis outside the atmosphere. At that point, just coast, and maintain your apoapsis at your desired altitude by gently nudging it upwards every so often after drag has pulled it down. Finally, circularize at AP. If 5km ends up being so flat that you can't get your apoapsis outside the atmosphere at all, try 6km - meaning, don't sweat the exact number, just be as aggressive as your TWR possibly lets you be. Your first stage unfortunately burns out very early, so you'll have to experiment with what your second stage can manage. I hope you put all your exterior greebling on the inside, because you're going to be on fire nearly all the way to space EDIT: actually, since you have lift, a very flat, aggressive trajectory might suit this vehicle even more than a normal rocket. never tried anything like that myself. But is certainly shouldn't hurt you.
  17. Whether or not the object is a comet depends primarily on its orbit, not on its size. If its orbit closely matches that of a celestial body, it is an asteroid. For example, the kind of asteroids that the level 3 tracking station discovers. They all hug Kerbin's orbit around the sun very closely. If, by contrast, it has an orbit that swings up past Jool and dips down past Eve? That is a comet. Once you are sure that you are tracking a comet, note that the tail depends on how close it is to the sun. In the upper part of its orbit, closer to apoapsis, it will not show a tail. When it swings around to approach the sun again, it will eventually start showing one.
  18. Welcome to the forums! Unfortunately, you're very unlikely to get the help you seek in this way. At first glance, it may seem like providing the craft file is a good idea, because then people can see exactly what you see. But in practice, you are asking that people stop whatever they're doing, create a file and copy it around, and launch their KSP client just to see what you are talking about. This may well take 5-10 minutes, depending on how fast the person and the person's computer are. And then you've provided a modded craft file. That means that in order to help you, people now need to clone their KSP installation to a new folder, browse a mod repository, download and install those mods, then create and integrate your craft file, and launch the client. Even the most helpful-minded person is not going to do that. Instead, try providing a screenshot or two. Host them on imgur.com or a similar site, and link to the gallery (don't embed, that tends to break). You'd be surprised how much a veteran player can tell at a glance when presented with the image of a rocket. For example, a single glance would be enough to determine whether or not you have room to tape two basic SRBs to the sides of your launch stage. If the mass of some solar panels is enough to make the difference between getting to orbit or falling short, then you need only a small amount of extra dV to compensate. And that, in turn, means you can most likely eschew all complicated analysis, and just fall back on the most famous of all rules of the thumb in KSP: moar boosters. It may be a band-aid fix, but if you just want to get to orbit... If you're interested in improving your rocket construction and flying skills in general, let me link you to a few walls of text I've written in the past: On common best practices for building rockets On learning to consistently launch well
  19. Oh, there's still more to come Multiple weeks worth, even. Not out of my mouth, though...
  20. Not really, no. I raised this as a feedback item back when commnet was first introduced with (I think it was ) version 1.3. And I've brought it back up two or three times since then. I've gotten no reaction at all to my inquiries. Basically: it makes no sense, and it is here to stay until the end of time
  21. By default, it shows Kerbin-relative TWR. There is a dropdown menu where you can choose other celestial bodies. If you want to figure out if it can land on Gilly, you must select Gilly. Spoiler alert: you can land there on ion drives, even
  22. https://bugs.kerbalspaceprogram.com is the official way. Unfortunately, too many people post random requests for tech support or feature suggestions in new threads there, which really clogs up the place. Please do your part to keep the bugtracker clean, and search for existing issues on that topic first, which you can upvote and reply to in order to add extra info if you have any. If no existing issue exists, please post a qualified bug report, which includes things like screenshots, logs and save files attached, a detailed description of what happened in which order, reliable reproduction steps, information about your KSP install (version, source, mods present, integrity verified yes/no), and so on and so forth. Anything that helps the developers reconstruct your particular moment of gameplay.
  23. If you use the maneuver node UI element at the bottom left to set up the node instead of dragging on the handles in the middle of the screen, does it work? If not: if you press Alt+F12, go to input locks, and press the clear button, does that help?
  24. Can have many different reasons. The most likely one is that you're stalling. That is, you are going so slow, or the air is so thin, or your angle of attack (how far away you are from your prograde marker on the navball) is so high, that your wings lose lift. Then your plane will start falling out of the sky, tumbling and turning uncontrollably. Solutions: 1.) Go faster; 2.) Fly lower down where the air is thicker; 3.) Bring more wing area and control surfaces; 4.) Steer less abruptly; 5.) Bring thrust vectoring engines. But as mentioned, there are other possible reasons as well. Until you tell us more details, we can't be sure of what's happening.
  25. @MrWookie2U If you're fine with having a traditional launcher to place the thing into orbit, ion drive spacecraft are not that hard; the only part that requires real design thought is the power delivery. It basically goes like this: Build the science probe you want to use: probe core, antenna, instruments, batteries. It should be in the 0.625m form factor. Larger ion probes are perfectly possible, but let's keep it simple for now. Make sure you have control authority (the OKTO-2 for example doesn't have reaction wheels). Attach a single inline xenon tank and a single 'Dawn' ion engine. Check the dV reading in vacuum. If it's way more than you'll ever need, axe the inline tank and use two radial xenon tanks instead. But keep a healthy amount of excess dV, because you still have to: Add power production. One Dawn engine consumes roughly 8.75 Ec/s. You have two options for the general power architecture, and each of them has three possible variants in terms of part choices. Option 1: full power delivery. Use this if you're not sure how long your burns are going to be, or if you simply don't want to be limited by your power production. As such, you need to provide a solution that produces the required 8.75 Ec/s at all times, even when the engine is off. That means it's potentially going to be pretty large and heavy, and sitting unused most of the time. But it's worry-free. Option 2: buffer with recharge. In this scenario you would provide only a part of the required 8.75 Ec/s in power production, and additional battery buffer to get you through your burns. Because batteries effectively weigh less than power production equipment, this makes the spacecraft lighter, which increases your TWR and your dV, and makes the required launcher smaller. And since the power production equipment is going to do work even when the engine is off, to refill the batteries, you're getting more value out of your investment. However, this places a hard limit on how long you can run your engine at full power. If you produce 4 Ec/s and have 1000 Ec energy storage, then the engine (plus probe core) will be able to run for 200 seconds. Any burn longer than that will require you to throttle down to less than half thrust - and the ion engine already has anemic thrust to begin with. As mentioned, you have two options for how you want to produce your power. The first option are radioisotope thermoelectric generators (RTGs). They have a big upside in that they just work everywhere. Daylight, nighttime, at Moho, at Eeloo, you're going to get exactly the amount of power you designed for, at all times, forever. They also have a big downside in that they are absurdly heavy for each Ec/s you want to produce. A 0.625m sized probe might weigh around 600 kg with the Dawn engine and fuel included; but enough RTGs to actually run the engine at full power would add another 960 kg - increasing the mass of your probe by over 150%. For this reason, RTGs are typically only used with the buffer-and-recharge option. The mass efficiency gap between them and batteries is just so large, it really begs to be used. The second option are fuel cells. They, too, give you all the power you need, whenever you need it, regardless of location and time. And they are a lot more mass efficient than RTGs. But as a trade-off, they require you to bring liquid fuel and oxidizer along, which they will consume - and once you have consumed it all, you'll be out of power. Additionally, for some unexplained reason, Squad decided to make the small single fuel cell a huge amount worse in both mass and fuel efficiency than the big fuel cell cluster, to the point where it is practically always better to just make your probe a whole lot larger and run multiple ion engines on the much better cell cluster. Which leads to another downside: you really cannot build something small and light that uses fuel cells well. The tank and cell array are going to completely dominate your design. You're almost automatically going to end up with a 1.25m form factor, and can easily go larger. Which is fine if you're trying for some cool crewed space cruiser. But for a quick and efficient science probe, it's utter overkill. The third option are solar panels. They seemingly have all the upsides: small when folded up, attachable anywhere, mass efficient, good power delivery. Ideal in every way. However, if you're in the shadow of a planet, they're going to be useless. And the way orbital mechanics works, you'll always be in Kerbin's shadow for the majority of a burn that's going to the outer planets (Duna, Dres, Jool, Eeloo). Which means an ion engine spacecraft without sufficient battery buffer is going to struggle to even get on its way. And then there's that thing called the 'inverse square law'. The intensity of sunlight is inversely proportional to the square of the distance from the Sun. So as you're moving away from the Sun, going to the outer planets, your solar panels are going to get weaker and weaker. At Duna, you might still be getting roughly 40%-45% of their rated power; at Jool, you'll barely be getting 4%. Trying to power the hungry electric engine with that is going to be a real challenge. But, do note that this works in reverse, too. Going closer to the Sun, down to Eve, for example, almost doubles the power output, and at Moho your panels are going to be at over six and a half times rated power. Plus, when performing a burn towards the inner planets from Kerbin orbit, you'll always be in daylight. In summary: RTGs are always going to be using the buffer-and-recharge strategy. Fuel cells are almost always going to end up doing full power delivery. Solar can go either way, depending on the use case. If you're going to the inner planets, always go solar. You can either go for full power delivery here, or deliberately undersize your panels at Kerbin so that they'll be delivering full power for less mass once you're closer to the sun. This works especially well if you can get a bit of an initial push from leftover fuel of your launcher's upper stage. If you're going to Duna, solar is still fine. You can go for full power delivery at Kerbin and bring some extra batteries so you can run buffer-and-recharge at Duna, or deliberately bring twice as much solar power so that you'll still be at full power at Duna. It'll carry a mass penalty, but it's not that bad. Most of the time you're still going to need plenty of batteries anyway, though, because your transfer burn is on Kerbin's night side. If you're going to Dres, full solar power delivery is an exercise in futility. Either go solar buffer-and-recharge, or choose one of the non-solar options. If you're going to Jool or Eeloo, pick a non-solar option. Remember: RTGs are going to be really heavy but compact and endless, while fuel cells are much more mass efficient but physically huge and have limited fuel.
×
×
  • Create New...