Zhetaan

Members
  • Content count

    467
  • Joined

  • Last visited

Community Reputation

529 Excellent

About Zhetaan

  • Rank
    Curious George

Recent Profile Visitors

3,148 profile views
  1. I believe the Krakens said that they came from outside the system. My suspicions are cast at Slate and Tylo: both of them should have atmospheres, but don't.
  2. And now I have a mental image of a paperclip in a cavalry hat rolling out to give advice on my letter-writing. Well done.
  3. If I'm not hearing phantoms, it's Collision FX from @pizzaoverhead. You're hearing the sound of metal scraping against metal. It works better when it's a plane sliding down the runway on its belly after a bad landing (it throws sparks, too!) but I don't know which part is causing it in this case.
  4. I think we need to wait another ten years before @Kuzzter can release the remastered version. Since it's already digital and everything shown here is technically CGI, I suppose it'll have to be a retro-remaster with hand-coloured laser beams, puppets, and practical effects (the battle for Kerbin will look very different).
  5. Zhetaan

    Brachistochrone trajectory planning?

    Here's the Scott Manley video:
  6. @Mrcarrot and @roboslacker: Nice rings. @Just Jim: Nice shirt. Also flute, but I couldn't help but notice the very sneaky means by which you ensured that your video was on-topic.
  7. I'm fairly certain that mention of other star-bound games is heresy. At the risk of breaking that rule by oblique mention of another such game, that's heresy, not HERESY.
  8. @putnamto: The immediate answer is that you can put RCS anywhere, because without monopropellant, they won't work and thus will contribute no torque ... but I'll assume that that's not the issue. Since it appears that you already have RCS Build Aid installed (I believe it is the icon at the leftmost point on your toolbar), I'm going to assume that your issue is one of actual placement rather than one of finding the centre of mass, which is good, because that makes this a lot easier. Since the 4-way RCS block's thrusters all lie in a plane, you need at least two to guarantee three dimensions of motion but you need three to get the counterbalance you need to prevent torquing. Four would be better, but because that will force issues with placement and available space, start with three and work from there. It is certainly possible to position thrusters three-dimensionally about an asymmetric, irregular mass such that you get zero torque, but the solution space for that is ... not fun, to say the least, and can result in solutions that have you thrusting in odd directions--a problem, definitely, if those landing legs are not purely decorative. By far, the ideal approach is to find a solution in which the thrusters all lie in a plane and are aligned with the axis of the vessel. I do not presently have access to KSP or a good modelling program, I'm going to rely on a Mk. I eyeball and guess at the placement. I believe that the mobile lab has the greatest share of mass, so I will consider that the primary part--meaning that the best solution places most of the thrusters on the lab. Practically, one thruster will be on the longer radial part; the way this works is to imagine a circle drawn about the centre of mass in the plane horizontal to the ground and to place thrusters at the points where that circle intersects the skin of the vessel. The centre of mass for the whole structure is below the centre of the lab, naturally, and pulled somewhat towards the radially-attached parts, so that circle (its size is adjustable so long as it intersects the skin of the craft in three places) will erupt and submerge at two places on the far side of the lab and a third somewhere on the larger radial part (and possibly a fourth and fifth on the shorter parts). So long as the thrusters are correctly spaced on that circle (and the circle is on a horizontal plane), they are all equally spaced from the centre of mass, the torques cancel out, and you won't have to concern yourself about torque from up-and-down translation. The centre of mass is easily determined, so I won't go into further detail about that, but the remaining issue is lateral translation; your solution needs to be rather precise. To solve it, figure out a circle that has the thrusters closest to equally-spaced around it. In other words, the three (or four) intersections need to be at as close to one hundred and twenty degrees (or ninety degrees) as you can make them. You are stuck with the one on the radial part; the most you'll be able to do is move it in or out from the centre of mass unless you add a cubic octagonal strut or the like--but it should be on the inside of the right angle. The finesse comes from placement of the thrusters on the far side of the lab from the long radial tube, since those thrusters can be moved from side to side. For thruster placement, forget symmetry; you have to place them one at a time. That ought to make sense: symmetry is only effective on symmetrical craft. If the craft lacks symmetry, so does your propulsion solution. The trick is that the solution you want is symmetrical about the centre of mass, even though the vessel is not. Ideally, you would be able to calculate the correct thrust and limit the thruster nozzles accordingly, but there is no way to throttle individual nozzles. Single-direction RCS ports provide more flexibility but also potentially more headache. When you move this vessel, don't forget to activate caps lock while translating, assuming you're going to do it in space--on the ground presents different challenges. That puts the thrusters into precision mode, which works to throttle asymmetric output a bit to correct for minor deficiencies in placement and further reduces or eliminates problems with torque. After all that, note that there probably is no in-game way to totally eliminate torque on that vessel while constraining the major translation directions to coincide with the principal axes of the craft, meaning parallel to the axes of the lab (for the landing legs) and the radial tubes (for the docking ports), but it likely is quite possible to reduce it to something manageable. To conclude, I would place my ports slightly higher than the axis on the long radial tube, between the blue line and the hatch on the lab (at about the bottom of the door seam), and on the other side of the hatch a bit farther away from it than the second thruster is. Then I'd work from there. If need be, you can put one thruster on each of the three radial tubes and a fourth on the lab; however, the increased radius both allows you greater precision to reduce torque in placement and extracts greater punishment in the form of a longer lever arm if you err in that placement. You may be best served by using advanced tweakables to shut off thrusters for rotational adjustments (use reaction wheels for that) and keeping RCS solely for translation, in which case you would want your thrusters as close to the centre of mass as you can get them.
  9. Zhetaan

    Wondering Out Loud: Seven questions

    @Bakkerbaard: This has been covered; I don't have any more to add. My usual rule is to begin pitching to the east at 100 m/s or at 1000 m altitude, whichever is first, but to design the rocket in a way that they both happen at about the same time. I try to be at about 45 degrees at 10 km and just about flat at 30 km, but I generally get smoother turns if I focus on keeping my time-to-apoapsis (it's in map view) at about one minute. I prefer to adjust that time by pitching rather than throttling, but it can work either way. 2a. It's not called fuel because fuel is a chemistry term. The term's technical meaning is used in rocket science, as well, so there is a reason why the preferred term for the 'stuff that makes the rocket go' is propellant. In short, a fuel is a substance that holds a great deal of bound energy (chemical fuels have chemical energy, nuclear fuels have nuclear energy, and so on) and which releases that energy in a reaction. For rockets, the release comes when the fuel is combined with an oxidiser (such as oxygen, naturally, but other oxidisers exist), but because the released energy works on everything in the engine to force all of the reaction mass (meaning the products that contain mass from both fuel and oxidiser) out of the nozzle, it is appropriate to call the combined mass of both the fuel and the oxidiser the propellant. Jets and trains and garden tractors that have airbreathing engines don't need to carry oxidiser, so in common usage, the terms fuel and propellant are treated as interchangeable. Here's the Kerbin atmospheric pressure curve. Your vacuum engines will have enough effective Isp to outperform the atmospheric engines at between 10 and 20 km. Thrust is another matter; you need to either have enough thrust or enough speed that you don't re-enter before you can use that vacuum efficiency to complete your orbital insertion. My rockets usually break into three stages: the initial or 'kick' stage gets everything out of the thicker lower atmosphere, the middle stage uses an efficient-but-high-thrust engine to push the rocket to orbital velocity where the air is thin, and the final stage is for everything vacuum, including orbital insertion, manoeuvring, and braking for re-entry. As others have pointed out, you can save on stages by putting decouplers into the same stage as the next stage's engines. I try to get my ascent stages to burn for about two minutes each (the vacuum stage may need more depending on whether you intend to go anywhere once in space). Any more results in carrying too much wasted mass in propellant (propellant isn't often wasted mass, but in early stages it absolutely can be), and any less results in too much wasted engine mass (aside from being necessary to move the rocket, the engine is dead weight). Yes, with the caveat that it's the easiest and simplest, but not the best way. Don't forget that you can use radial decouplers to attach fuel tanks to the sides of the rocket; you are not required to jettison an engine along with the tank. If you're going to Duna, for example, then it makes a lot of sense to use one engine (or one cluster; maybe you like big rockets) for Kerbin orbit insertion, Kerbin-Duna transfer, Duna orbit insertion, and possibly Duna-Kerbin transfer if it's coming back. Having fuel tanks that you can jettison when they empty is a great advantage to your manoeuvring budget. This has been covered, so I won't revisit it. If I understand your question correctly, you don't need to use the science instruments to learn the characteristics of a planet or moon as you visit it. They can be helpful, but (perhaps surprisingly) their primary function is the acquisition of Science points: the data readouts are secondary to that purpose. Since you want to know the gravity and atmospheric characteristics of these places before you find out (too late!) that you ought to have brought a bigger engine and a heat shield, you can get some information from the Tracking Station. Here: The two buttons halfway down the screen at the right edge (one appears as a lowercase i and the other is a stylised planet with something in orbit) give you the useful information about whichever planet is in focus in the station.
  10. Zhetaan

    How do you pronounce “Mun?”

    I don't think so. They had to update the display font before they could localise, which ended up being part of the UI upgrade back in ... 1.1, was it? Of course, if you're talking about pre-0.18, then I'm not certain at all. Anyway, I pronounce it mun, but only while I'm taking off from there. When I'm landing, it's important for me to use the shorter mun because I usually have a lot going on and do not wish to crash. If I'm planning on orbiting, I'll call it a cismunar injection if I'm going to a prograde orbit, but I'll change it a bit and call it a transmunar injection if I'm going to a retrograde orbit. The difference is subtle, but then again, so it is with the injection. Once I'm in orbit and want to describe the parameters, I choose instead to go for maximum snobbishness and say pericynthion and apocynthion, even though those terms are so old that no one recognises them anymore--that's part of the appeal. Truly, it does not matter. Use what you like; if you wish, download Kopernicus and rename the Mun to Billy Bob's Cajun Spice Shack in the Sky--with apologies to @Cydonian Monk, of course--and spend the rest of the game crashing rockets into it because you're giggling at yourself too much to be able to land.
  11. Zhetaan

    SpacePlane Reentry?

    The choice is a bit more complicated than that. Steep descents minimise total heat exposure but have a high thermal spike. They can work if your parts have high skin temperature limits. Shallow descents have lower instantaneous temperatures, but because you spend much longer in the fall, you generally get more total heat input. That works best if you have low skin temperature tolerance but high internal temperature tolerance. In actual use, most parts have the same skin and internal values, but since skin heats up quickly and the internals heat up slowly, shallow is usually the better choice. If that isn't working for you, then you have at least four other options: Use different parts, or change the way you use existing parts. There isn't much to be done for fins--by their nature, they have to be exposed to the air stream--but you can put the parachutes in a service or cargo bay. If fuel tanks are blowing up, you should consider changing the fuel flow rules so that the tanks most exposed to the heat have fuel in them while you descend. Fuel can take some--some--heat, as well. Fixing the balance is something you'll need to figure out. Leave a lot of fuel in the tanks and try a powered descent. This is wasteful and requires either forward-facing engines (seriously?) or descending backwards. Use radiators. Obviously, they cannot be deployable, but remember that they need to be in the air, not a cargo bay. This is something that can bite you--radiators, assuming I understand the behaviour, will take on heat as well as dispose of it. Try tumbling. This does two things: it increases drag, which slows you, and it spreads the heat around every part of the plane. The drawbacks are the complete loss of control and attendant general concern over whether you'll get it back and the need to ensure that every part on the exterior of the plane has high enough heat tolerance. After all, rapid deceleration due to drag is exactly what makes steep re-entries spike in temperature, so it will be hotter. But no single part will take the full brunt of it.
  12. Zhetaan

    Permanently Parking a Lander in Orbit

    I agree; that's about as modular as it is possible to be with just the stock parts. It's not at all how I play, and for my trouble, I'd prefer to have a solar panel or six on the can, but otherwise I can see the appeal. On the other hand, mission planning also means shipping the various modules that you might need and supplying storage for the modules you're not using right now, so I can see how this solution can balloon quickly into a logistical nightmare--but since you're in the habit of building stations around everything, I suppose that's not so much a problem for you. Monopropellant is not so efficient as LFO. The Twitch and Spark are the nearest comparable LFO engines (they have roughly the same thrust, mass, and size), and the comparison breaks down as follows: Puff Spark Twitch Thrust 20.0 kN 20.0 kN 16.0 kN Isp (vexh ) 250 s (2451.7 m/s) 320 s (3138.1 m/s) 290 s (2843.9 m/s) Fuel Flow 8.16 kg/s 6.37 kg/s 5.63 kg/s Isp is specific impulse, the measure of engine efficiency available in the game (it's given in seconds), and vexh is exhaust velocity, a different measure of engine efficiency (given in metres per second) that is more directly useful to the comparison. For double-checking purposes, vexh is calculated by multiplying Isp by g0 (one standard gravity, set in-game and real-life as 9.80665 m/s2), though in reality, Isp is calculated from vexh and not the other way round. Thrust is measured in kilonewtons, a measure of force (one newton is equal to 1 kg*m/s2), and is equal to exhaust velocity times fuel flow. For the most part, the differences are in the engine design (one could, for example, configure a monopropellant engine that uses .00001 kg/s of fuel--it's just a number in a computer file) but it is meant to reflect reality: monopropellant, in general, cannot effectively store or release so much energy as a bipropellant system. The chief advantages of monopropellant are in the simplicity of the fuel delivery system (no mixing ratios), reliability of the engine (run it over a catalyst and it blows up; there are no ignition problems), and stability of the fuel (most bipropellants have at least one cryogenic component; most monopropropellants are stable at high temperature). In-game, monopropellant is less effective because it is less dense: LFO (LF and O have the same density) is 5 kg/L; monopropellant is 4 kg/L. Therefore, in addition to the mass of fuel being dribbled out of the engine at lower velocity (which reduces efficiency), it takes more units of that fuel to reach that mass. Translating to units of fuel consumed per second (which is what you see on the resource tab), the Twitch takes 1.13 units/s (.51 LF and .62 O), the Spark takes 1.27 units/s (.57 LF and .70 O), and the Puff takes 2.04 units/s (all 2.04 Mono). Part of what you see is an illusion; the LFO engines consume fuel from two bars on the resource tab, so each bar drops at approximately half the total rate (45% LF and 55% O), but the monopropellant engine still takes almost twice as much fuel after accounting for that. If we were to create an LFO engine with the exact same efficiency as the Puff, it would also have a fuel flow of 8.16 kg/s, but that would translate to 1.63 units/s (.73 LF and .90 O) solely because of the 25% greater fuel density than monopropellant. All taken together, this means that to get the same effect from monopropellant, you need to take more of it. The main advantages to using monopropellant are that you don't need to be concerned with tank arrangement, placement, and plumbing, that the tanks available (especially the radial tanks) can be fit into many small or otherwise wasted spaces on a vessel, and that (especially if you already need it for docking) you can save on complexity by using only one fuel for everything. The main disadvantages are that it is less effective, more expensive (.3 Funds/kg versus .2 Funds/kg for LFO), and lacks good high-volume tankage solutions. At least at first, I tend to take a lander to the Mun or Minmus (or both), leave it in orbit, and then bring the station later. Of course, that's usually because I need to go to the Mun and Minmus to get both the science and the money to afford decent station parts--my original forays into reusable landers came of the need to leave off mass in order to have a cheaper ride home. Since it was already there, the next mission was made cheaper by my only needing to take extra fuel rather than an extra lander, but I freely admit that that had more to do with my hard-mode game settings than it did any especial advantage of the method.
  13. Zhetaan

    Location for Kerbal Penal Colony

    I'm surprised that no one has suggested Bop. If they worship the Kraken, then they won't want to leave Bop. Additionally, Bop's orbital characteristics make it (surprisingly) one of the more difficult places in the system to reach. Many a would-be Jool-V expedition ended up as a Jool-IV because the planner failed to account for Bop's inclination. Also, you can solve the jetpack problem by making a base that has only command chairs and no capsules. Then there's no source of EVA fuel. An asteroid on a solar escape trajectory is an interesting idea, but it leaves the problem of subsequent transportees.
  14. Of course. They can't reincarnate as a lower form of life; they have to keep coming back as bugs.
  15. Zhetaan

    Permanently Parking a Lander in Orbit

    I do not wish to impugn @Greenfire32's experience, but I think compounding the lander into a self-sufficient flying base to stave off fuel shortages is evidence of a solution in search of a problem--by that I mean to say that if the original issue is bad piloting which dips too far into the lander fuel reserves, then isn't it a lot cheaper to learn better piloting skills? In fairness, I make use of the permanent on-station lander method, but I also use reduced science gains in a modded tech tree to make it a lot more difficult to acquire science in the first place. I also use LS, and the advantage of needing to take only small amounts of LS supplies to the surface while the transfer vehicle carries the supplies needed to keep everyone fed for a few weeks is a worthy one. Therefore, I'll say that it is useful, but that it is perhaps more a novelty in stock. It definitely has a place when exploring the Mun (it is a cousin to the popular 'biome-hopper' styles of landers) because of the Mun's variety of biomes, but for explorations of the polar regions where you need a polar orbit, it's both cheaper and easier to get a polar orbit on transfer rather than after arrival--but a polar orbit can interfere with your mission planning in a number of ways, not the least of which is that it compounds the transfer window problem. Of course, if you want to visit a number of places on multiple trips, a different-but-equally-viable method is to take a rover, land it once, and then ensure that it is parked somewhere relatively flat. Then you can take your lander to it, rove wherever you wish to go, and return. If you want to be really creative, you can land on the rover and take your lander with you, or attach wheels to the lander and let it be a rover as well. Unless you're using fuel cells (which is a valid method) or an engine alternator (which is also a valid method, but it's expensive), it doesn't cost delta-V to run electric rover wheels. To more properly address fuel shortage concerns--as I said, I have no desire to insult @Greenfire32--if running out of transfer fuel is a possibility and piloting skills are not up to the task of cheap and efficient rendezvous, you can always calculate the amount of fuel that will be required to return to Kerbin, load that amount, and then lock the tank until you are ready to return. Then there will never be a need to dip into the lander's reserves unless you make a deliberate choice to do so, and in that case, on thine own head be it. With that said, there are distinct disadvantages to having a permanent lander on station. @RizzoTheRat as much as said that designs iterate over time: the lander with weak engines and fixed solar panels that you could afford as soon as you had the parts to build it was probably only just good enough for the job, but once you unlock good vacuum engines, better electrics, and decent landing legs, you may feel the need to upgrade. Modular building mitigates that a bit but eventually you'll feel a need to actually use some of the parts that you're spending all this time getting the Science to unlock. Unlocking new science experiments poses a problem if you don't have a means to attach them to the lander. I took a single-seat lander with a docking port on top and added a two-seat can on top of it (it was a modded part, not the ungodly heavy Lander Can Mk. II) that had docking ports on either end and my new science experiments attached to the sides. It's ugly, but I designed the lander to handle the mass (I had the future in mind when I made it--it now serves for crew transfer as well). Once you unlock the tech tree, however, the acquisition of Science becomes academic (apologies for that) and since most base and station contracts require new vessels, the only continuing use of such landers is for flag-planting missions and communications relays--though a couple of mine do see service as station tugs and crew transfer vehicles when I'm somewhere far enough away (Jool or farther) that sending a dedicated crew tug is far more prohibitive than the parasitic mass of the never-to-be-used-again landing legs on the vehicle that is there right now.