Jump to content

Zhetaan

Members
  • Posts

    1,005
  • Joined

  • Last visited

Reputation

981 Excellent

3 Followers

Recent Profile Visitors

5,117 profile views
  1. You can boost, though, right? If that's the case then it's a matter of one of two most likely causes: pilot error and rocket design. Pilot error is the easiest thing to correct, but it assumes that you are completely new to KSP and need help learning to fly. That's not a bad thing (we were all new at this once), but if you can get a rocket into orbit and fly to the Mun, then it suggests that rocket design is the most likely issue. Just the same, if you are completely new and need help learning to fly, then some basic instructions are in the spoiler. On the other hand, let me ask: are you simulating an Apollo-style mission? Do you have a separable lander of any configuration? Your problem may be that, assuming that they are docked nose-to-nose, your upside-down vessel is the control point for the whole assembly, and every time you orient retrograde to burn for capture, you're actually burning prograde to escape. If that's the case, then right-click on the pod correctly oriented, select 'Control from Here', and try again. Don't forget to tell us whether that worked (and if not, then please provide a screenshot of your rocket, preferably in flight, so we can try to diagnose the problem). Good luck!
  2. I see a whole-vessel delta-V of nearly 7,000 m/s and a thrust-to-weight ratio of 2.3. You're fine. Actually, at this point, I'll caution you that that is a very energetic lifter and you may find that, after launch, you have a hard time turning it in atmosphere without ripping pieces off if you're too aggressive with your pitch control. If that happens, then the solution is to use the thrust limiters on the SRBs. You should be able to turn down the thrust to, oh, 67% or so. That will drop your launchpad thrust-to-weight to a respectable 1.5-ish which will keep your rocket flying upward but with less unplanned disassembly. The other issue that might become a problem is staging away the SRBs when they burn out. They can have a tendency to strike your core after you detach them. I usually prefer pairs over quads for this reason, but don't be afraid to use Sepratrons if you need them.
  3. In Kerbin orbit? That will take you to Minmus and back several times. On the launchpad? Add a launch booster to get it into orbit.
  4. It's also possible to get back to Kerbin for under 1,000 m/s, provided that you go from Dres to Jool. There are flyby trajectories that have you using Jool for a braking gravity assist to drop you into the inner system for a Kerbin encounter; the best flybys that I've found so far can do it for between 950 and 980 m/s. These are obviously very time-dependent (transfers that coordinate three moving bodies--not including your vessel--are an order of magnitude more complex to plan than two-body transfers) but the window does reopen every few thousand days.
  5. Technically, that would be an asymptotic function, not an exponential. Anyway, according to this post, it's probably an algorithm, which is to say that the results change based on arbitrary rules that don't necessarily relate well to a mathematically-precise continuous function. I'm interested in finding out a bit more about it myself, so I think that I'll look into it a bit more deeply. I won't have much time to do so until the weekend, though, so don't expect an answer from me for at least two days.
  6. 200.25, in point of fact. @Nicias: Since you are a dedicated mathochist, at the least you'll need to get to eccentric anomaly so that you can figure your time-of-flight and ensure that you'll intersect Vall's orbit at a time that Vall is actually there. Which means that you'll need true anomaly, and well, it becomes an avalanche at that point. Do you use Kerbal Engineer? You'll need a way to get the true anomaly, which you cannot do with celestial observation in KSP (the skybox is just painted on; there's no First Point of Aries, and if there were, it wouldn't stay in the same place). Alternatively, if you're feeling extra insane, you can simply define a coordinate system and solve for it there. So long as you have the relative positions of your vessel, Vall, and their orbits correct, then you can solve for the burn in any convenient system without needing to use mod tools.
  7. I'll second @Streetwind's post, at least for planes. However, nothing in your post says specifically that you're flying a plane; just that you're flying in an atmosphere. Nevertheless, the logic holds. The only really good reason to take a tank full of LFO is if you intend to use it, and if you're using closed-cycle Rapiers when you have Nervs available ... well, why would you do that? Pushing through the upper atmosphere might be a good reason, but you don't need a big rocket tank of LFO for that. Depending on how much oxidiser you need, you may be best-positioned to use a Mark 3 liquid fuel fuselage with a Mk3 to 2.5m Adapter. It still has a lot of LFO--likely more than you'll want--but you'd need the adapter anyway for the cleaner look. Of course, you can always try a mod; there are plenty of rocket-profile LF tanks out there, since people correctly saw that it made no sense for the Nerv to be a fantastically-efficient LF-only space engine and not have any good rocket-profile LF-only tanks to go with it. Some of these are just fuel-switching mods that will make a stock LFO tank into an LF-only tank without the need to add extra parts. It's worth a look: without mod tanks, the result is often that you either get a Mark 3 fuselage assembly that adapts down to 1.25m for the Nervs (and the adapters almost all have LFO, so watch out), or else you get clusters of Mark 1 fuselages because they have the same 1.25m profile as the mid-diameter rocket parts (small in KSP would be the .625m parts, like the Oscar-B). In fairness to the developers, the Nerv originally was an LFO engine like the other rocket engines (it wasn't realistic in its function; it just had great efficiency), so when it was introduced, there was no need for new tanks. They corrected that later, but never added new tanks to go with it.
  8. Hmm. Well, it doesn't seem right that it would reference field work (as opposed to contracts) and then not convert field work. Perhaps 'field work' refers to things such as part tests and experimental surveys--these are things that generate science because of the contract, but are not counted as part of the science reward for completing the contract. To put it another way, if you have, for example, a contract to test some part on the pad, then the test itself will often generate science over and above the listed contract reward. I must offer my apologies because I did not test this myself. I'll take a closer look later today and report on what I find; I have a test install of KSP that I can use for this. In your mission summaries (these would be both the report after you recover a vessel, and the contract completion report that you access from the toolbar) does it show a number in parentheses next to the science total? That would document the effect of your strategy. I ask because it may be that the devs decided to leave actual experiments available as a source of science points if you needed them (this would be from before they made the changes to the mobile lab, mind), though it boggles the mind that they would not have been thinking of these experiments as field work. I'll look at the cfg files as well when I run the test rig. There are couple of other possibilities to consider, as well. How high is your reputation? One important difference between science and rep is that science is a running total that cannot go below zero, whereas reputation asymptotically approaches the endpoints on its -1000 to 1000 scale. If your reputation is sufficiently high, then you cannot gain more. (The same is true in the other direction: the general public becomes inured to your indiscriminate and reckless disregard for property and the lives of your Kerbals, and your reputation cannot go below -1000, either.) In other words, the more reputation you have, the harder it is to get even more. I think that the game would take the many disparate sources of science, add them up, and only then convert the total into reputation points, but if it does each conversion individually, you might be gaining thousandths of a point and thus seeing no practical change. What this means for your strategy is that if you already have a high reputation, converting science points into more rep may just be a way to get rid of excess science points. and nothing else. Another alternative is to ask whether you committed 100% to the strategy? You mentioned unlocking the entire tech tree, so I assumed that you also had a level 3 Administration Building, which you need for 100% commitment. I'll have an answer within twelve hours, I hope. Edit: Did it in eight! Anyway, the strategy configuration file is very clear: 'field work' consists of ScienceTransmission, VesselRecovery, and Progression. ScienceTransmission is straightforward. VesselRecovery covers, I think, both experiments recovered with the vessel and the vessel itself (for those times that you bring back the first vessel to fly by, orbit, or land on a body). Progression is the internal name for World's Firsts rewards. I also ran a short career save with the strategy turned up to 100% and with a number of experiments in different situations. The vessel recovery window showed the science value of each experiment, but the bottom of the window showed zero science gain. The notification window (the one with the green checkmarks for completed contracts and blue globes for World's Firsts--it's the first button on the toolbar) showed the correct subtractions of science and additions of reputation as I expected, and my actual science total did not change after the mission. Perhaps that was the problem?
  9. It just means science points from doing actual experiments, as opposed to the science points that you may receive from completing contracts.
  10. In that case, this is pretty much the definitive post on the subject. It's also the case that you'll be looking for something more nuanced than just passing in front of or behind celestial bodies, because the main trick to those multiple-assist trajectories is getting the timing right for the intermediate legs. For example, there's a multiple assist to get to Moho by way of Eve: you can get to Moho by way of Eve but the problem is that Eve cannot, on its own, slow you down enough on an infalling trajectory from Kerbin to both get you to Moho in one pass and save enough propellant to be more worthwhile than just flying there directly. So the way to do it is a K-E-E-M assist. For that middle leg from Eve to Eve again, the exact flyby orientation is less important than the timing of the interval, which needs to be exactly 65.5 days (one Eve year) or else you'll miss the Moho encounter (or make it very expensive, at least). But that means that you need to take the assist that will give you that interval, not the one that reduces your solar speed the most. It's not so bad as it sounds, because the assist that gives you the right interval will put you in the right place for the next assist, which is the point. But it means that you're not looking for the maximum possible effect on the flyby, either. That's okay, since multiple assists are really just chained transfer windows, and transfer windows are mainly about timing. Your mission may be about propellant efficiency and delta-V budgets, but the windows don't care one bit about that because the planets move and align regardless. Unlike, for example, a Tylo gravity brake to get into Jool orbit, where it's ideal to approach Tylo from directly behind (if possible), swing round at nearly ground level (if possible), and exit exactly in Tylo's retrograde (more or less required), you may find yourself exiting (or approaching) the intermediate celestial bodies at a weird angle, because that's the angle that gives you the right timing for the next encounter. Do not neglect your course correction budget, and remember that when you correct for an upcoming encounter, you should really be looking at the encounter after that. Well, maybe glance back to ensure that you're not getting that 'encounter' via a collision course with Kerbin or something. Otherwise, this encounter should be all about setting up the next encounter. Do that and you'll be fine.
  11. If you mean passing in front and passing behind, then ... roughly, yes. It would be more accurate to say that your exit speed relates to how close your exit direction is to the celestial body's prograde direction. If they are roughly parallel, then you speed up in the primary sphere of influence. If they are anti-parallel (meaning that you're aligned with the body's retrograde), then you slow down. B and D show the craft leaving the body in something like the body's own prograde direction (it isn't exactly parallel, but it's obviously more prograde than retrograde), so the craft speeds up. A and C show the craft leaving roughly retrograde, so it slows down. There's a whole list of caveats and addenda to that, mostly relating to your speed, angle of approach, and periapsis (and a lot of it deals with the fact that, being in three-dimensional space, you can do other things like change inclination with a gravity assist).
  12. Apsis is borrowed from ancient Greek. 'Apses' is an attempt to use a Latin pluralisation on a Greek root, which is not correct. The correct plural is apsides. Wall of explanatory text in the spoiler: In the end, though, languages--even dead ones--change over time, so eventually, apses is probably going to be accepted as a legitimate plural of apsis. However, if you do decide to use the correct Greek form, then please be aware that the pronunciation is ap-si-DEES, not ap-SIDES. It rhymes with keys or freeze, not rides or hides. In theory, they can be anywhere. Of course, an escaping comet or asteroid has no apoapsis because it is not on an elliptical orbit, but escape is not a function of position; it's a function of speed. There is no magic line where an object on one side is captured and an object on the other side is escaping. You see this on any interplanetary launch from low Kerbin orbit: with enough speed, you escape Kerbin from a, for example, 100 km orbit and go to Duna. Burn in the retrograde direction and your orbital speed drops to zero and you land (or 'land', in the sense that the char and ash will eventually hit the ground). Do nothing and you orbit until the hard drive fries. It has nothing to do with being in low Kerbin orbit: all three scenarios are possible. Another way to look at it is in terms of eccentricity. An elliptical orbit has an eccentricity strictly less than 1, but the problem is that the formula for eccentricity is this: e = √(1 - [b2 / a2]) Where e is the eccentricity, a is the semi-major axis, and b is the semi-minor axis. The problem with this is that eccentricities less than one are achievable for arbitrary values of a and b, because a can tend to infinity and b can tend to zero while keeping the b2 / a2 term nonzero. A parabola, which has an eccentricity of exactly one, can be seen as an orbit where a is exactly infinite. A radial orbit, which while not a parabola also has an eccentricity of one, is the case where b is exactly zero. Practically, comets are going to have some nonzero speed which will constrain the possibilities for apoapsis if they have an elliptical orbit, but I don't know the range of those possibilities.
  13. I agree, but I will also say for the sake of posterity that one of the drawbacks of KSP1's tutorials was that the tutorials were made while the game was still in alpha. Thus, a lot of the tutorials were incomplete because they didn't cover new features, or existing tutorials were broken when things were changed. For one example, the change to the atmospheric model between .90 and 1.0 completely ruined most stock aeroplanes. For another example, the updated engine models (and deprecation of the engines that they replaced) broke one of the rocket design tutorials--the tutorial looks for a part that no longer exists, and of course it won't complete until the user places that part on the rocket. KSPedia helped a lot, but it's not the same thing.
  14. 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.
  15. 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.
×
×
  • Create New...