Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Zhetaan

  1. TAC Fuel Balancer The mod thread does say that it is available on CKAN and updated for KSP v1.12, so you should not have any trouble there. I did look through the history to see whether, in the chain of people who have maintained it, anyone changed the name from 'TAC Fuel Transfer' to 'TAC Fuel Balancer', but didn't find it. The mod does transfer fuel, so I think it's just a case where someone got the name wrong and the wrong name caught on. I'm not certain that it does precisely what you want it to do, but at least now you can try it and find out.
  2. 5% cosine losses would be the dividing line that I know. There's no physical threshold or change of state for this; it's a matter of convention, like the unwritten rule of thumb that says that launch stages should have a burn time of about two minutes each, or that a launch thrust-to-weight ratio of 1.3-1.7 is ideal. What are cosine losses, you ask? I'm assuming that you know that the best time to thrust for an escape burn is at the periapsis. There are a lot of reasons for this, but two of the factors involved in making an efficient escape burn are that it's better to adjust the apoapsis (because it's the part of the orbit that is closest to escaping in the first place), and that it's better to thrust prograde or retrograde to change the shape of your orbit (normal and radial do change the shape, but they primarily shift the orbit's orientation, which a prograde burn does not). The periapsis is the one point on the orbit where both of these factors work together at maximum potential effect. Cosine losses, then, are the inefficiencies that you get from burning anywhere but at the periapsis. That's a generalisation, but it captures the idea. For an easier-to-understand example, let's imagine that you have a rocket with two engines side-by-side. Ideally, both engines point straight back: you want the rocket to go forward, all of the available thrust is pushing you in that direction, and there is no loss. Now, let's rotate the engines so that they both point outward somewhat in a V, like a lot of cartoon rocket ships do. The combined thrust vector still points out the back, but it's smaller because some thrust goes out to the sides (and is counterbalanced by the side-thrust of the other engine). That side-thrust is useless, the propellant wasted, and is an example of cosine losses. In the extreme case, we rotate the engines by 90° to point directly sideways, which results in a full cancellation of thrust and the rocket going nowhere. That would be 100% cosine losses. This example has a caveat: you don't need two opposed engines to have cosine losses, because any thrust that is not in the direction that you want to go is lost thrust. One engine pointed sideways gives 100% cosine losses, and one rocket pointed sideways gives 100% cosine losses, too. This means that thrusting normal when you want to thrust prograde is also an example of 100% cosine losses, even though in such a case, your rocket does go somewhere. Thus, thrusting in a direction that is not prograde at the periapsis, even though it does something, and though that something may be mostly what you want it to do, is not 100% ideal. Since it isn't possible to have a 100% ideal burn, cosine losses can also be said to represent the unavoidable difference between the ideal and reality. You calculate cosine losses by taking the angle of interest (engine deflection in the previous example, and angle difference from periapsis in the orbital one) and taking the cosine of that angle. The difference between that cosine and 1 is the fraction of the burn lost (so cos 90° = 0, and 1 - 0 = 1, therefore 100% of the burn is lost when you thrust sideways). That said, some cosine losses are inevitable. The only burn that is perfectly efficient is instantaneous, which of course does not happen in reality. This is where burn time becomes important, especially for low-thrust rockets: you want the burn times to be long enough to actually do something with the orbit, but not so long that you're wasting the thrust on something that you'll need to correct later. 5% cosine losses correspond to a window of a little under 13° on either side of the periapsis (and around two minutes in low Kerbin orbit) Depending on what you're trying to do (and how tight your propellant reserve margin is), you can adjust that limit up or down. I prefer something a lot tighter (I try not to go over 6° unless I can't avoid it), but I'm willing to split a long burn up into more parts to make that happen. You may want a margin of 20° or more, but you should know that the loss goes up rapidly when you deviate from the periapsis. As far as planning a split-burn, that's a little more complicated, but the key is that you usually want your last burn to do the work of setting up your interplanetary transfer. This means that your next-to-last burn (and the others if you need more than two burns) works to set up your escape, and your very last burn must occur at the same time as you would have burned if you were doing it all in one big push. It's tricky in KSP to start with a later burn and work backwards (KSP is set up for planning multiple burns in succession going forwards in time, instead), but it can be done. Here's what to do: Note the transfer window time and location on the orbit. Also get the delta-V for the burn, and note your orbital altitude (the altitude is important; don't forget it). Set up a burn that is somewhat less than an escape burn. For a circular orbit, the delta-V needed to escape is a constant for a given orbital altitude. Let's say that you're in a 100 km orbit of Kerbin: to escape requires 3,176.5 m/s. You're already going at 2,246.1 m/s just being in orbit, so the escape burn requires 930.4 m/s. For the sake of easy numbers, let's go with a 900 m/s burn (to set up an orbit that almost escapes--and if that's too long of a burn, then yes, you can divide it into 3 burns of 300 m/s, or 9 burns of 100 m/s, or, if you're a dedicated masochist, 900 burns of 1 m/s). Note the amount of time that it takes to complete one orbit (you can do this from the map view). Whatever the orbital period is for that orbit, you simply go back that amount of time from the transfer manoeuvre and set up the burn. It likely won't be exact: you need the final manoeuvre node to coincide with your periapsis, so to make that work, you'll need room for corrections and adjustments. On the other hand, a close orbit of Kerbin takes about half an hour, so it's not like you're going to miss your window. Remember to take the 900 m/s off of the final burn. Well, yes. That's exactly how it works. A typical transfer to Duna (typical defined as: I used the alexmoon tool and took the first one it offered) costs 1,030 m/s of delta-V. 930 of that is spent just in escaping Kerbin's gravity. That does not mean that only the last 100 m/s can be said as being for going to Duna. That is exactly the wrong way to look at it: the transfer burn needs to be considered as a whole rather than as a sum of independently-movable parts. All of it is used in going to Duna, and all of it is spent in getting away from Kerbin to do so. The truth of this is seen in the execution: if you don't complete the burn, then you don't get the encounter. You can split a burn in two and do it in two distinct steps, provided that you don't change location (that being, in this case, the periapsis of your ejection/transfer orbit). You cannot split it into two pieces, do one in low Kerbin orbit and the second in solar orbit, and expect the burns to add the same way. The reasons for this take a while to explain but the short version is that the energy of the orbit is distributed differently, which for you means that the energy available to exploit for the transfer is also different. The same kind of thing applies to launching from the surface of Kerbin: at or near the equator, you save a few hundred m/s by launching to the east because the surface of the planet is rotating in that direction. If you launch from the north pole (putting aside for the moment that there is no east), it doesn't matter your direction because there, the surface of the planet is only rotating in place. Kerbin's rotation didn't change; you just put your rocket somewhere where you couldn't take advantage of it. Thus it is with your choice of interplanetary burn: you end up wasting a lot of the second one by burning somewhere other than at the periapsis. It's not cosine loss, per se, but it's a similar sort of problem.
  3. There is a difference, but not at a point that matters. Since you intend to orbit both, there is no gravity assist to help you. The only place to save delta-V, therefore, is in the braking burn on return to Kerbin. That makes the Kerbin-Mun-Minmus-Kerbin route the better choice, because you'll be coming in from Minmus slightly faster and can shed more velocity for 'free' by aerobraking ... at which point, the mission's over anyway.
  4. From what I can see, you should try adding engines (and propellant for those engines). I hope that does not come across as condescending, since it is a sincere reply to your question--but because I see no engines, what you have in orbit right now is what I would call the return capsule, or the very last part of the rocket that is left when the rest of the mission is done. If you took this to orbit, then the only thing that you can do with it is return to Kerbin ... but to do that, you need either an engine or else an orbit that hits the atmosphere. If you want to do other things, like go to other planets or moons, then you need more rocket. I can't be more specific about what to improve without knowing what you want to do with it, because those mission types, and the rockets needed to complete those missions, vary dramatically with the destination and intended goals. Given what you've shown so far, I'm going to guess that you're a new player (or else you're very dedicated to using the demo). That's great--we love introducing new players to the game!--but it also means that there are ideas at work here that you're probably unfamiliar with, and sometimes, we experienced players forget to explain them. Instead, let's talk about it from a different direction. There's no such thing as a 'best' rocket, because rockets are designed completely differently to carry out completely different missions. There may be a 'best' rocket for a specific mission, though, so let's talk about the mission. What do you want the rocket to do, which it is not currently doing?
  5. @HebaruSan is correct, so I'll give a bit more context and explanation. You can't stop it. This is an emergent property that arises because you're in a rotating frame of reference. Because your orbit is a curve, the direction of forward motion (what you and I know as prograde) changes with respect to any absolute frame of reference. Anything that moves to intercept is necessarily on a different curve, and so the different directions of prograde will result in relative drift. This is true even if you match orbits perfectly first, because moving to intercept necessarily changes the shape of your orbit. This is also the reason that all of the counter-intuitive manoeuvring (i.e., decrease altitude to increase speed, and so forth) works in orbital mechanics: you have to account for the rotating frame of reference. That's true on the surface, as well, but we can usually approximate things with straight lines and flat surfaces (though there are notable exceptions in navigation: following a great-circle course, with a few edge case exceptions, means constantly changing your heading). This rotation affects everything in any combination of prograde and radial directions. You may note, for example, that radial in at the periapsis points in the opposite direction of radial in at the apoapsis. Over the course of the orbit, the compass rose of prograde, retrograde, radial in, and radial out rotates around one time. This rotation is parallel to the axis of the orbit and perpendicular to the plane of rotation, i.e., about the normal direction. What this means is that normal does not change over the course of the orbit, and you can use this to your advantage when docking. Provided that you do not change inclination much, you can approach from normal or anti-normal and get a dock without the target vessel rotating away from you. This only works for small relative inclination differences because matching orbits in every way but inclination means setting yourself up for a collision later--either controlled docking, or the more explosive version. Other alternatives include docking in a high orbit (with its slow rotation) or simply docking quickly (this could mean rendezvousing, matching at a close distance, and waiting for a potion of the orbit for the target to point the docking face that you want towards you).
  6. I'm glad to see that you figured it out, but in the interests of education, you should know that there is an interaction range around the experiments, beyond which they are what I will call 'out of reach' of the Kerbal. This is something to remember if you're in the habit of putting science gadgetry in service bays. This range is called interactionRange in the .cfg files and it can be modded, but it's usually not necessary for stock science gear. For the Science Jr., the range is 1.85 metres. For the SENTINEL telescope, it's 1.2. It appears that for all of the others, it's 1.5 (I'm not certain about the magnetometer, but it is 1.5 for the rest).
  7. How many boosters? I try to avoid this when I can, but I have taken a rocket with a four-booster radial stack and thrust-limited two of them so that I could stage them in pairs. The trick, then, is to execute a roll program so that the pairs of boosters decouple to the sides, rather than above and below the main rocket body. If you're still having a problem getting the boosters away from the vessel, then you have a few possible solutions. One is to use a Seperatron. My preferred configuration is to use one on the outside side of the nose cone, upside down and essentially pointed so that it pushes the nose of the booster down and away relative to the rest of the rocket. I keep the decoupler near the nose, as well (fuel lines work a lot like struts and hold the bottom steady), but I don't know what the limitations are for a Kerpollo, so you'll need to see for yourself whether that fits in the rules. Another solution is a passive one; use aerodynamics to pull the spent booster away from the rocket. You can do this with nothing more than a basic fin on the outside of it; once you decouple, the drag from the fin will pull the booster away. You could possibly see a similar result by using a radial drogue parachute, but you'd need to be low and slow enough that it would at least semi-deploy. Another solution--admittedly, a bad one--is to carry the empty tank with you until you're far enough out of the atmosphere that you won't need to worry about collision when you do decouple it. If you run out of booster right before you start coasting to apoapsis (assuming that your program has you doing that), then you'll lose a bit to drag but otherwise won't spend too much in letting the tank ride until you're nearly ready to thrust again and put some distance between it and the main rocket.
  8. Aside from a general hope that they go with region over biome (which I think is rather a silly descriptor for a portion of a lifeless, airless moon), I do like @Tw1's general thinking that science should feel more like a process than a game of fetch. I can't speak to ease of implementation, but I think that there's something to be said for splitting out science from a general collection of points to something a bit more subject-based. I'm not looking for something so involved as to be confused for the real thing, but I don't see why taking the temperature of the ocean (or, for that matter, recovering a rocket for the first time) should help me build a more efficient rocket engine. Perhaps have a few broad categories, and having running experiments (or recording, in the case of sensors) in a given region will help to add to the collective body of knowledge in that subject. Linking the tech tree to interrelated fields of science, rather than an arbitrary point total, would probably help the thing feel a little less slap-dash, too. However, though I cannot speak to ease of implementation, I can say that this would probably become unwieldy in a hurry, which is unfortunate.
  9. Well, don't apologise for asking questions. That is the literal point of this forum, and besides, if you ask certain questions frequently enough then we can put it in a special place for questions that people ask frequently. We can call it 'Things People Ask About a Lot', or the TPAAL--something catchy like that. Anyway: For the Clamp-O-Tron Jr., you get two such to mate by having the shiny rings touch. This means that, assuming that you're going for an Apollo-style configuration, you will want the assembled Command-Service Module to have the shiny ring pointed up (assuming that the main engine is pointed down and for the Lunar (Munar?) Excursion Module's shiny ring to point down onto that of the CSM. However, I do feel compelled to point out that if you want authenticity, then you should have the LEM (MEM?) in a fairing under the CSM, which is at the tip of the rocket. Then, once you've achieved trans-Munar injection, you blow the fairing, release the CSM, and then turn around to dock with and extract the lander. For the other docking ports, the one that routinely gives people trouble is the Clamp-O-Tron Sr. The general rule is that you want to see a short slot on the docking face, and no plus sign. That's the mating face. Have a look at the part in the VAB (start a sandbox save or look at the wiki) and you'll see what I mean.
  10. @jimmymcgoochie has the essential limitation, so I'll merely flesh out that answer: In the stock game (meaning no DLC or mods), the total available science is indefinite. I won't say infinite, but it is unlimited. First, there is no limitation on the number of labs that you can have running at any time. You only need to supply them each with copies of the experiment data. Second, there is no limitation to the number of experiments that you can feed into a lab past the stipulation that each experiment be unique (so there are no repeat experiments in any given lab). The number of biomes (and biome-derived experiments) is finite ... but the number of asteroids and comets is not. The only real limitations on it are computer memory and, more likely, your patience.
  11. As others have said, loss of power is the likely culprit here. Assuming that that is the problem, here are some solutions: If you have solar panels, then turn the spacecraft to face the sun. This may require you to get out on an EVA and nudge the vessel with your suit jets. You don't need a lot; you just need to get it moving so that a panel eventually rotates to face the sun. Don't push the panels themselves; you'll break them. Just nudge the nose of the rocket a bit. This happens sometimes with the deployable panels when their rotational axis ends up pointing at the sun; they can't get power because that's the direction that they cannot turn to face. It's preventable by having panels that are not 180° from one another (I like to use either 3-symmetry, or if I don't need that much power, having two panels at 90° from one another). Be certain that nothing is on and drawing the power; you may want to use stability assist to keep your vessel facing the sun, but turn off any lights or other power-draining modules. If you are using the right rocket engine (a Swivel or Reliant, for example) then you have an 'alternator' installed that generates electricity while the engine is running. It would not take much, but of course you will need to make a course correction afterwards. The best part is that in the stock game, you don't need electricity to start the main engines. If you have the right trajectory, then you may need to do nothing at all. Once you are on a re-entry trajectory, you don't need to worry about power. You may need to use the engine to brake a bit, but you can do that once you're committed to the atmosphere. To get on that trajectory, you may need to get out and push (which is possible with your suit jets, albeit slow), but it is doable. Hopefully, you designed your rocket so that its aerodynamics orient you correctly on atmospheric insertion. If you need the electricity to keep your heat shield pointed in the right direction ... well, let's hope that you don't need that. Good luck!
  12. Here are the actual stats (from the wiki, so though not completely canon, they're probably accurate). Valentina: Courage = 55 Stupidity = 40 Jebediah: Courage = 50 Stupidity = 50 Valentina is slightly braver and moderately less stupid than Jebediah. However, it should be noted that both of them have 'BadS = Yes', which means that they ignore these stats and remain blissfully content even in the face of certain annihilation. 'BadS = Yes' has a way of equalising the attitudes of the Kerbals who have it to the point of making the actual stats completely irrelevant. It also should be noted that these traits only affect their facial expressions and even then are for aesthetic flavour only. A Kerbal pilot in the midst of a panic attack is still perfectly capable of controlling the rocket. Therefore, Jeb and Val are exactly equally capable, barring differences in experience--but that's a decision that you make by choosing to send one over the other on missions; it has nothing to do with raw, base talent or ability. Neither is more 'powerful' than the other. On an historical note, Bill and Bob were also equally capable back before KSP had specialisations (indeed, they were more equal to Jeb, because experience was not yet implemented, either). The only difference between them was the level of panic on display, and even that was something only seen on launch; reaching space gentled everyone very quickly.
  13. MechJeb just compares your orbital period to the time needed to reach the next transfer node. If it equals more than five orbits (though that is user-editable), then it adjusts the semimajor axis of your orbit by the ratio of (1 + (1.25 / PhasingOrbits))(2/3). If you go with the default number of five orbits, then it's just 1.25(2/3) or approximately 1.16--but the important part is that it adjusts the orbit by enough to guarantee that a transfer window will appear within the acceptable number of orbits in the new orbit, but does not adjust by so much as to be prohibitively expensive in propellant costs. It's not really trying for milligram efficiency or millimetre precision: it's like someone who is travelling through the woods and doesn't know exactly where the next town is, but knows that there's a long river leading to it, and so knows that finding the river--which is a lot easier to do, even though it will add time to the journey--will be good enough as a first step. It's done in terms of ratios, not kilometres, because distance in kilometres has varying importance relative to your altitude. If you're at Minmus's altitude, then orbiting 100 kilometres closer to Kerbin will make a negligible change to your orbital period. If you're orbiting at 75 km altitude, then going 100 km closer will be quite a dramatic change, indeed.
  14. Good catch. I don't have Breaking Ground, so I missed it.
  15. No. The power production falls off with the square of the distance, as it does in reality. Electric charge production is also affected by the panel's orientation, naturally, its temperature, and whether it is an atmosphere. This means that a solar panel that is close to the sun will produce less electricity than the inverse-square intensity calculation would predict because the increased temperature reduces its efficiency and partly offsets the increased insolation. It doesn't completely negate the effect of solar intensity--panels closer to the sun will still produce more EC--but it can be important to know if you want to have a solar-powered station or something operating in that volume of space. This also means that a panel on Kerbin's surface will produce less than one in space at Kerbin's orbit. Keep that in mind if you want to use solar at Eve.
  16. Assuming that your uncontrolled vessel is only drifting, but not spinning wildly, then you can dock with it provided that you can be both precise and fast. In the future, you should know that it helps to leave your target docking port in a normal orientation. You can see whether it is by using 'Control from Here' and watching the navball. As a vessel orbits, it remains in its orientation--it doesn't rotate to keep the same side facing the primary. Thus a vessel in orbit will appear to rotate as it revolves about the primary, but the normal direction is the axis of this rotation, so anything aligned that way won't rotate away from your approaching vessel. Obviously, adding control (even in the form of a cheap probe core) would help, but you should also know that docking to uncontrolled targets is exactly the intended use of the Advanced Grabbing Unit (the claw).
  17. I disagree with it being cheaty; if you're expanding the tech tree, then you need to expand the science pool, and that means re-balancing everything that goes into it. You may not be modelling the change in technological capability in your game, but it's not unreasonable to think that data storage and transmission can improve immensely in twenty years: twenty years ago, some digital cameras recorded images on floppy disks inserted into the camera, and streaming video was ... well, no, it wasn't. That's a big part of it. The RA-2 is literally the worst-transmitting antenna in the stock game. Switch to a Communotron 88-88 or HG-55 (the HG-55, not the HG-5). I don't think you can warp through transmission, but you can definitely make transmissions work better. Since you're comfortable with modding and writing patches, let me give you the essential idea behind data transmission, so that you'll then be able to decide whether to use a better stock antenna or else go in another direction. Science is transmitted in units called mits. It's like a bit, but mumbled. Individual experiments have fixed mit values. This is not automatically related to the science value of the experiment--that depends on whether you're recovered the experiment before, where you did the experiment, and so forth. For example, a temperature reading always has a value of 8 mits, but the science value changes if you take the reading in low orbit of Jool instead of Kerbin. Mobile Processing labs factor the science multipliers into the conversion to data, which is a trade-off: you transmit science from the lab at a transmission rate of one mit per science point, so you need more and longer transmissions for the same mit value of experiments as you collect them from higher-yield situations. Of course, the lab multiplies the data value, too, so it's a net positive, but you knew that already, I think. Antennas gather mits into bundles called packets, and different antennas have different packet sizes. The HG-55 has a packet size of 3 mits, the RA-2 has a packet size of 1 mit, and all other stock antennas have a packet size of 2 mits. Antennas also have a packet interval, which is the time taken per packet transmission. The reciprocal of this value is the number of packets per second, and taken with the packet size gives the transmission rate in terms of mits per second, or, if transmitting from a lab, science points per second. The HG-55 has an interval of .15 seconds with a packet size of 3, and the Communotron 88-88 has an interval of .10 seconds with a packet size of 2. This means that they both transmit science from a lab at a rate of 20 science per second. Lastly, antennas have packet resource cost, which is simply the EC used per packet. I get the impression that you don't have an electrical scarcity problem and are more interested in speed, but for your information, the HG-55 has a relatively low EC cost per mit but its high transmission rate means a high EC cost per second. The 88-88 is the worst in terms of electric use per second (but the RA-2 is the worst in terms of EC per mit). Anyway, if you're transmitting something of roughly 5,000 science points per transmission (though probably less given diminishing returns), then doing it through an RA-2 will take about half an hour. Using an HG-55 will do the same thing in four minutes and ten seconds, though at roughly double the electricity per second (but at one quarter the total electrical consumption). If you should decide to mod an antenna, then you will want to increase the packet size, decrease the packet interval, or do both in order to reduce the transmission time.
  18. Atmospheric attenuation. Here's a link to a relevant post. It's six years old but still accurate. The Gigantor solar panels are rated for 24.4 ec/s at Kerbin's orbit, as in at Kerbin's distance from the sun, absent any intervening obstacles. Intervening obstacles can include the Mun during eclipses, Kerbin itself (Kerbin tends to shade the panels a bit at night), and atmosphere. Because of this, the surfaces of the inner planets are actually some of the worst places in the solar system to use solar panels: solar panels at Eve sea level (with 5 atm of pressure) tend to be about two-thirds as efficient as panels at Kerbin orbit, and Moho's 61-day night (owing to its crazily-long rotation period with respect to its orbit about the sun) is something of an issue, as well. High temperatures affect panel efficiency, too. In the linked post, testing showed that near Kerbin sea level, Gigantors produce something in the neighbourhood of 21.5 ec/s at noon and get worse from there. Near sunrise and sunset, they make less than 1.5 ec/s. I don't know the decay curve, but there's no way that the average output is more than 90 ec/s over the course of the day. Another possibility is how many converters you are running on your converters. By that I mean to say that the Convert-O-Tron 250 has four converters on it: Monopropellant, LF, Ox, and LF+Ox. Each of those converters is a separate process, and so each will pull 30 ec/s to run. (They will also overheat the part if you try to run more than two, I think). Many players use fuel cell arrays rather than solar for their conversion processes, since the cells consume less than the converters produce, still generate respectable power, work at night, and don't break off in atmosphere. It chafes at my understanding of thermodynamics, but it's a valid gameplay strategy.
  19. Yes, yes it is. Near space over the sun is far enough away, in relative terms, that a typical Hohmann transfer orbit is no longer the most efficient way to do it, and you're better off using a bi-elliptic transfer, instead. That's similar to what you've been doing, but your problem right now is that you're burning at an apoapsis that is far too close to the sun to be efficient. You'll want to boost all the way out to Eeloo at the least. Farther is better and, counterintuitively, more efficient, but don't go so far as an escape orbit. You'll need to keep in mind the contract deadline, too. Once you're at your supra-Eeloo apoapsis, burn retrograde to bring your periapsis down from Kerbin to the sun as you have been. This has the additional advantage of making your periapsis transit faster, so perhaps you won't burn to death (or at least get by only slightly crispy about the edges). Remember that you're not near the sun for the purposes of science experiments until you're under one million metres in altitude, so I hope you brought thermal protection. Thankfully, you can take the measurements while flying by--you don't need to circularise. The other things that you can do are all the standard advice about designing your vessel properly for the mission, so picking the right engine (for a 500-tonne vessel, it won't be ion engines or Nervs), taking only what you need and nothing else, setting up clever staging, and so forth. On an unrelated note, welcome to the forum! As newer players go, you're certainly ambitious, but that's not a bad thing. Good luck, and if you have any other questions, then please feel free to ask.
  20. Unfortunately, it doesn't work that way. You're seriously overestimating the performance of this engine. I can show you why: we can work though the delta-V calculation backwards to get an idea of whether your guess is feasible for a vessel. Let's say that we want your guesstimated values, and since I like calculation, I'll cover both ends of your range. For 8,000 m/s of delta-V with a Nerv, we need a wet-to-dry mass ratio of 2.772. This requires a propellant mass that is 1.772 times that of the dry rocket, or a wet rocket that is 63.9% propellant. To have .5 thrust-to-weight, this rocket would need to push no more than 12.24 tonnes per engine. 3.00 of those tonnes are taken up by the engine itself, 7.82 tonnes are in the propellant, and the propellant tank takes up another .87 tonnes for a total of 11.69 tonnes. That leaves .55 tonnes, or 550 kg, for remaining payload, and of course does not account for the fact that there is no propellant tank that offers exactly 7.82 tonnes. One can string together multiple engine modules to keep the same overall performance and increase the payload, but that is the shape of the problem. For 10,000 m/s of delta-V, it works out that you need a wet-to-dry ratio of 3.58 and an attendant propellant mass of 2.58 times the dry rocket, or 72.1%. At .5 thrust-to-weight ratio, that means that you're still limited to 12.24 tonnes per engine, but now 8.83 tonnes are taken up by propellant, .98 tonnes are taken up by the tank for that propellant, and 3.00 tonnes are in the engine. That adds up to 12.81 tonnes, which is over-budget and leaves no room for payload. You may certainly choose to have a lower thrust-to-weight ratio, but it is not possible to combine the Nerv engine with a propellant load to have a .5 thrust-to-weight ratio and 10,000 m/s of delta-V.
  21. You actually do need to install the mod before you run the game. If you try to install the mod on the fly, then you'll be disappointed. That's because the game loads its assets (including mod stuff) at the beginning when it starts up. Other issues that crop up with this kind of thing include forgetting to unzip a compressed mod download, failing to install a dependency (that's when the mod that you want needs another supporting mod to function--usually, mod makers are pretty good about including them in the download), or installing the mod in the wrong folder. For example, a lot of mods come packed in a folder called GameData, and sometimes, people install them in such a way that they get a KSP\GameData\Gamedata (or more, I once saw someone who nested it five times). When a mod comes in a GameData folder, the intent is that whatever is in the mod's GameData is what goes into your GameData--you need to copy the contents, not the folder. Otherwise, @jimmymcgoochie's link is to an excellent tutorial, and if you can't get it to work after reviewing that, then I'd say you've got a bug and should re-install.
  22. I came along to make a similar point, so while @4x4cheesecake may be right in that most won't read the rules, I am evidence that others will and have noted the same problem. I think that there are enough detail-oriented people here that making the full rules visible in the 'Read Before Proceeding' page is worth consideration. Additionally, I'm not certain about how much flexibility the forum offers to put such things outside the wall and make them visible, but I think that there's merit in including some specific threads and posts out there, as well, such as the Good Conduct Guide and others. That said, I get the distinct impression that this was more of an administrator decision rather than a moderator one, so you have my apologies if I am directing this to the wrong people.
  23. Yes. However, the savings are modest enough that the choice between efficiency and rocket complexity is a serious one, and there are compelling arguments on both sides. Here's an example: Let's say that you have a 45-tonne rocket being pushed by one Nerv. That's a bit low on the TWR scale (it's only about .136) but that's fine. We're not looking for good burn times here. Let's say that our fictional rocket is bearing two Mk. 3 liquid fuel short fuselages. That's 14.29 tonnes per tank when full, of which 12.50 tonnes is propellant. Let's also assume that the rocket is built with reuse in mind--meaning docking ports rather than decouplers on the tanks--so that adds .2 tonnes (for a Clamp-O-Tron Sr.) to each tank. It also adds .2 tonnes to the main vessel, but we can ignore that because we're not staging away that port. A 45-tonne Nerv rocket with 25 tonnes of propellant when full, provided that you run it until it's empty as a single stage, has a mass ratio of 2.25 and a delta-V of 6,362 m/s. Let's say that, instead, we opt for a two-stage operating paradigm. The first stage is a 45-tonne Nerv rocket with 12.5 tonnes of propellant, a mass ratio of 1.38, and a delta-V of 2,553 m/s. Then we stage away the 1.99-tonne empty tank and docking port, leaving us with a 30.51-tonne Nerv rocket with another 12.5 tonnes of propellant. This rocket has a mass ratio of 1.69 and a delta-V of 4,135 m/s. Thus, the total for the two-stage design is 6,688 m/s. That's 326 m/s over the single-stage design (that's more than 5%), and all of it comes from not needing to push around an empty propellant tank. However, 5% may not be worth it to you, especially when you consider that replacement tanks need to be sent up from Kerbin (or recovered somehow--likely for a lot more than 326 m/s) and it means sacrificing your potential propellant load until you can get those replacements. For a one-off rocket, that makes a lot of sense. For a reusable rocket (that only operates in space--launch platforms are a different matter), it makes less sense. If you plan on ISRU, depots, or other tricks to resupply, then the tank is more valuable than the propellant savings. You ought to be familiar with that side of planning: you can save propellant by not sending Kerbals, too, but the capsule is more valuable than the propellant savings of not sending one, so it goes on the mission. In like fashion, when refuelling is a part of the mission, the empty tank technically becomes part of the mission payload rather than parasitic mass.
  24. OPM doesn't really directly affect the capability of vessels; it only extends the boundary for long-term missions. USI-LS does change the capability of vessels by increasing the necessary life support payload (and thus reducing the available payload for other things that you might have wanted to take). The amount that it affects depends on how many Kerbals you're taking, what kinds of amenities you have for them, and the difficulty settings for the mod. As others have said, there are no easy answers, but we might be able to rough out a solution space based on the kinds of things that you might want to do with such a vessel. First, I will assume that you will have enough Nerv engines to give a thrust-to-weight ratio of 0.2, and this is simply for the sake of your own sanity. The Nerv has a thrust of 60 kN, so 0.2 TWR means a maximum weight of 300 kN per engine. Take out the gravitational acceleration (TWR is a ratio of Kerbin weight unless specified otherwise) and that leaves 30 tonnes per engine (30.6 if you want to be more precise). Out of that 30 tonnes, 3 are the engine itself. Out of the remaining 27 tonnes, you can choose to use the Mk. 3 short fuselage, up to 12 Mk. 1 fuselages (though you won't actually want to use all 12), or you can add engines and divide a larger tank between them. Let's say that you use 10 Mk. 1 liquid fuel fuselages. That's 22.5 tonnes in tankage and propellant. 20 tonnes is in the propellant. Add 3 tonnes for the engine, and that leaves 4.5 tonnes for assorted other stuff. That's a payload fraction of 15%. That's a lot less than I'd like for a long-term mothership, but reusability eats into payload fraction with a certain ill-tempered voraciousness. If you need more payload, then add another 10-tank + Nerv engine module, and you'll have 9 tonnes of payload to use. The delta-V for such an arrangement (which is a wet/dry ratio of 3) will be 8,619 m/s. With no payload (or control, but this is just playing on paper), the wet/dry ratio is 4.636 and the available delta-V would be 12,034 m/s--but none of it would be useful. Therefore, you can go from 8,619 m/s for a fully-loaded rocket up to something approaching 12,000 m/s for an unloaded rocket. More payload than the maximum reduces the TWR to unacceptable levels, and less payload than just the propellant tanks and engine is not possible. Those are the boundary conditions for this design. Let's say, instead, that you want to use three Nervs and one Mk. 3 long fuselage. That tank is 57.14 tonnes (50 of which is propellant), and the engines add nine tonnes to that for a total of 66.14 tonnes out of a total target mass of 90 tonnes, thus leaving 23.86 tonnes for whatever else you want or need. That leaves a potential payload fraction (again, only on paper) of 26.5%. The total wet/dry ratio is 2.25. The delta-V of such a rocket works out to be 6,362 m/s. Unloaded, the delta-V is 11,066 m/s. Again, you can't actually achieve that, but it shows the maximum available range if you should choose to have a higher TWR with a partially-loaded rocket. Please note that I'm not certain that you can keep your Kerbals alive and sane with USI-LS for an OPM-scale trip with only 24 tonnes of available payload for life support. And, of course, using that much payload for life support leaves you with none for the actual mission. On the other hand, the propulsion module (1 tank + 3 engines) is a beautifully low part count, so you can multiply it easily. On the gripping hand, you could always send probes. Probes are cool. Remember, Mars is the only planet known to be inhabited entirely by robots.
  25. This comes off as cheeky, but ... ... cancel the mission. That's not to say that it can't be done--I'm a staunch completist, so I'd chafe immensely at the idea of quitting a mission in my own game--but one of the things that I've learned is that KSP often likes to throw improbable and impossible missions at you. The improbable ones serve to provide crowning moments of awesome in the event that you do actually manage it, and the impossible ones serve to provide experiential learning in how to cope with frustration. Also, you've probably got years in-game before the contract deadline, so you can afford to do some other missions, get some science points, and unlock technology that will let you do this mission ... provided that it is, in fact, possible. You may want to prioritise upgrading Mission Control for the sake of more contract slots, though.
  • Create New...