• Content count

  • Joined

  • Last visited

Community Reputation

568 Excellent

About Zhetaan

  • Rank
    Curious George

Recent Profile Visitors

3,291 profile views
  1. Did you mean Moho or Minmus? Then visiting it anyway is the pinnacle achievement of the game. Anyway, in the interests of sincere advice, @Kerbal007, I will offer that your main concern is that you're not thinking about a big enough goal. You've decided to follow something that approximates actual history: I invite you to consider how, historically, these sorts of missions were planned. As a case in point, consider that President Kennedy committed the United States to landing a man on the Moon (and returning him safely to Earth) before the end of the decade. At the time he made the announcement, the only manned space mission that the country had completed was Alan Shepard's suborbital flight aboard Freedom 7. From that point on, everything--especially everything Gemini and Apollo--was directed to achieve that goal. There were unmanned test rockets. They learned how to rendezvous and dock in space. They figured out how EVAs work. They tested the manned modules in Earth orbit. They tested them again in lunar orbit. Then they finally landed on the Moon, and the landed missions grew more complex, as well. Take a look if you're interested in some of the different mission types. My point is to say that you can do things like this quite readily in KSP; you have an entire solar system to play with. Let's imagine, for example, that you want to fly a circumnavigating aeroplane around Duna. Call it a D-Prize if it strikes your fancy. Flight on Duna is possible but it's not at all like flight on Kerbin. To make that happen, you'll need to run an entire battery of tests, get the science needed to unlock the right plane parts, figure out your engines, fuel, and general mission parameters, design something that can fly in Duna's atmosphere--which may involve taking unmanned test gliders just to see which ones work--and let's not forget to provide means for those doing the piloting to return to Kerbin. And, of course, that's just from the one planet, and includes neither the design of the surface-to-orbit delivery rockets and interplanetary transfer rockets that you'll need, nor the skills to fly them correctly. Have fun.
  2. Zhetaan

    Most efficient way to turn back

    @laythe depression: To start, welcome to the forum! I think that the thing to remember is that Ike orbits Duna with a sphere of influence of only about one million metres. Duna's is nearly fifty times larger. Your Ike-centric inclination is extreme, but your Duna-centric inclination is going to be much less so. Add to that the fact that though Ike has somewhat low gravity, its small sphere of influence means that your orbit is always going to be very close and thus inclination changes will be expensive. There is probably a point where it's cheaper to make the change at Ike and then go to Duna's sphere, but if your intention is to make an interplanetary trip, then you'll probably want to transfer out to Duna high orbit and return from there, with or without a dive for Oberth effect assistance as you see fit. However, if you want the most efficient return, then that would entail using both your orbit around Ike and Ike's position to effect an Oberth dive nearly to Duna's atmosphere at the right time to get a Kerbin transfer. However, without a fuel depot to offset the cost of setting up the encounter in the first place, the savings probably aren't worth the trouble. Duna and Ike just don't have enough gravity.
  3. Zhetaan

    I need help...

    Others have addressed this, but yes, I expect it would. If you have to use the regular docking ports instead of the 2.5 m ones, then decide on a standard module length and only send one module at a time. That limits the wrong-size nodes to the ends of the module and eliminates the joint in the middle. Don't expect it to help much in space if your combined vessel is very many modules long, though. Also, while the outrigger engines are not automatically a deal-breaker, they are acting as fins at the top of your payload. That cannot be good for handling in flight. If you want to try the outrigger-based engine cluster approach, consider using decouplers with crossfeed enabled instead. You could try docking ports too, if you're inclined to do so, but that requires either precision (from a mod) or double docking to get the torque correct. Additionally, you may be over-thinking your Duna vessel. If you only want to go there for the initial science harvest, then you may not need very much more rocket than it takes to land on the Mun. Whatever it was that you could get into orbit, take the mass of that payload (minus the command equipment). That's how much mass in fuel and tanks that you can take to orbit with the same lifter. It helps for your fuel/tank payload to be roughly the same shape as your other parts for aerodynamics, but if you can get anything into orbit, then you can get that much fuel into orbit. I suspect that this issue is that your design is falling short of your ambition, which certainly happens often in early career before you have the better parts. You can't get a full orange tank to orbit? Take half a tank, instead. You can only take three-quarters of a tank? Empty a quarter of the fuel in the VAB and launch that--it's a little inefficient, but not so much as the rocket that doesn't get off the pad. You will lose the perfect balance of LF to Ox by doing it this way, but that won't matter once you get the Duna craft fully fuelled. Expect it to take some time, though.
  4. It's two groups of four. They ought to be working. @Heroshrine: I think it's a bug, but just to cover everything (that I can think of), did the upper thrusters sink into the tapered piece when you placed then in the VAB, such that you had to pull them out again with the offset tool? It's possible that placing them on the very edge caused them to think they are clipped into the part and thus occluded. I think that throws a message on the right-click menu, but I am not certain. Either way, if it's not a bug, and it's not a control issue, then a placement issue would affect all four thusters at the same time (but not also affect the other four lower down). Perhaps @bewing knows. He's far more knowledgeable about the inner workings of the code, and might be able to say whether this is an edge-case occlusion issue.
  5. @Heroshrine: I suspect that you're seeing the intersection of two separate problems: fine control and an imbalanced vessel. Bugs are always a possibility as well. It's not a lot to go on, but I notice that you have fine control turned on (the pointers for roll, yaw, and pitch in the lower left corner are blue instead of their normal orange: it's toggled with the Caps Lock key). With fine control on, the craft tries to counter any imbalances in the mass and placement of RCS thrusters, which can result in some thrusters appearing not to fire. In actuality, they are firing at extremely low throttle, but there's no easy way to see that. With a full fuel tank and presumably an occupied command pod at one end, and an almost-empty monopropellant tank and hollow structural piece at the other end, you're definitely imbalanced. Do the thrusters work when you roll? Your vessel should be balanced on the axis, so there would be no throttling for that. Alternatively, do they work after you press the Caps Lock key? Failing that, you might want to right-click on the thrusters themselves and check their context menus.
  6. @Kerbamesh: Welcome to the forum! The longitude of ascending node (LAN) is definitely the problem here. The general answer to changing the LAN is to pick one of the two points where your current orbit and target orbit cross (the higher point is best, if there is a difference) and create a manoeuvre node. Use the normal/antinormal handles (/) to adjust your orbit to match. As a caution, doing that will also change the periapsis/apoapsis, so you will need to add some prograde/retrograde (/) to the burn in order to fine-tune the adjustment. Alternatively, you can adjust the LAN with one burn and then fine-tune the periapsis and apoapsis with a second burn. The KSP answer is as @bewing said: Adjust the orbit so that the AN/DN markers you see reduce to zero. The thing to remember here is that the AN/DN markers show your ascending/descending node with respect to the target, but the contract, if it refers to your inclination, wants you to adjust your ascending node with respect to the planet. Ensure you are making the correct adjustment before you move forward. Unfortunately, however, I'm not certain that you can make that range of adjustments with only 308 m/s of delta-V. You'll have to test it for yourself.
  7. You need one, or perhaps two if you have a lot of mass outside the centre. KSP reaction wheels are insanely overpowered compared to real-life versions, and that's before considering that they run on alien spacemagic and create momentum from nothing. Part of it is also that while space stations do occasionally need to rotate, they usually only need to hold an orientation: they don't need to be quite so responsive as vessels under thrust. To put it into perspective, four large wheels give a total of 120 kN of torque. That's along the lines of a mid-sized rocket engine--not quite a first stage, but definitely more powerful than the vacuum engines--whose entire output is dedicated to twisting your station about. Also note that if you want to mirror the look of the ISS, there's nothing wrong with sending four reaction wheels and disabling three of them. Then you have extras on hand if it works out that you really do need more.
  8. Look at the misalignment at the connecting rings. The entire central module is rotated out of true with the rest of the station. Also look at the two arrows on the right side: they point to two radially attached batteries, and if you look closely, you can see that the lower battery has a gap such that it appears almost disconnected from the module, but the upper battery appears clipped into the module. There are other places, too, such as the constriction on the left side, where things are misaligned. This is a situation that practically begs for a rapid unplanned disassembly. ... Or did you mean to say that you were not experiencing the issues yourself beyond the wobble? If so, then you have my apologies for my misunderstanding. In that case, I have found that autostrut issues tend to appear most often with parts that change orientation or size, especially in multi-part stations and such. There are a lot of mod-derived inflatable parts that can trigger the problem, but in stock, I've found that anything with a collider that changes shape can do it. That means anything with doors, such as cargo and service bays, anything with an extendable collider such as solar and radiator panels or landing gear--though landing gear are rarely a problem because the landing gear are rarely in the way of an autostrut--and airbrakes. Drills don't usually do it for me because the drill head is cosmetic only; the physical mesh doesn't contact the ground. Another possibility, since you did say that it occurred after rotating the station, is that the wobble occurs because your station's flexibility is throwing it out of alignment with your target orientation and your reactions wheels or RCS are too powerful for the station joints. The torque shakes the station, it comes out of alignment with your chosen orientation, SAS comes on to re-orient it, it over-corrects, so it comes on to back-correct, and it creates positive feedback that eventually destroys the station. In that case, turn off SAS, let the station settle, and press Caps Lock to activate fine control mode before re-orienting again. Also consider disabling extra reaction wheels.
  9. That's a fair point. Conceded. I'm not certain I understand you here. I never implied that this was something new: my assertion is that the experience system has interfered with the spirit of the game since its inception back in 0.90. Rather, the addition of personal parachutes in March only highlights the existing two issues as I described them: 1) the rewards offered do not logically follow from the tasks one must complete to earn them, and 2) the nature of the task encourages grinding. The difference, on the other hand, is that the experience system can be modded if one prefers something different, but the parachute cannot. Also, in reference to the spirit of the game, I ask, not as an accusation but as a preventive, please do not confuse my emphatic delivery with some sort of moral outrage: KSP goes farther than any other game I've owned in that it--for the most part--lets me change the features I don't like into features that I do, or else shut them off. I have nothing but appreciation for that ... but I would appreciate it more if that aspect was delivered consistently--hence, the parachute thing. I'm actually not opposed to the idea in principle, so long as it is executed well. That is to say, as before, the items and attributes offered in reward ought to make sense in the context of the task. Otherwise, I can see such an effort resulting in nothing more than the big passenger buses swinging out to Jool or another appropriate body after visiting Minmus. If the only goal is to encourage people to leave Kerbin, then I'll grant that is a success. However, if the true purpose was something subtler, such as encouraging people to explore the solar system that all that effort went into coding, then--and perhaps we're of completely different temperaments in this regard--I think having such a thing as a 'token Jool XP run', or anything that caused people to see part of that solar system as a mere waypoint rather than a destination, would be disappointing. But I digress. I'm not the one who makes those decisions, and I'm not going to dictate to people how they should play their single-player sandbox game. I suppose, in like fashion, that I should avoid being too emphatic about telling the devs how to program it. Thanks for the discussion; your points are well-made and well-received.
  10. This reply ran a bit long, so I decided to put my answers in spoiler tags.
  11. I'm aware of that. My point is that it's tedious, and made even more so because you have to do it again for every Kerbal that you want to have the parachute. I appreciate that it doesn't take much effort beyond landing on the Mun and Minmus to make it happen ... but landing on the Mun and Minmus takes a lot of effort! Most people who play KSP never leave Kerbin's sphere of influence, after all. We're also talking about putting together gigantic tour buses that double as moon multilanders, and all for the sake of having what by rights ought to be standard equipment. Granted, this only highlights the problems with the experience system. However, there's a mod for that, among many others. Kerbal experience is exposed to the modding community and there are a few different takes on it that work to make it a) less tedious and b) more relevant to the tasks that the Kerbals are expected to do. So long as EVA parachutes remain hardcoded, they have no similar option. It might be possible to make a mod that records a Kerbal's experience, temporarily gives that Kerbal level 3 if it's in the air without a vessel, and then restores the original experience once that Kerbal lands, but that seems unreasonably cumbersome--especially since at that point, you may as well install the EVA parachutes mod and avoid the issue completely.
  12. @eatU4myT: You've got the right idea, but the wrong parameter. Inclination and apoapsis don't have a mathematical relationship. What you need to use is the argument of periapsis. There are other ways to derive a more exact position from Keplerian elements, but I'm going to assume that you want a quick-and-dirty approximation, so ArgPe it is! I'm also going to assume that you have the means to obtain the argument of periapsis, because you need the means to obtain the ground latitude and most things that give you one can also give you the other. Anyway, the argument of periapsis is the angle measured from the ascending node to the periapsis in the plane of the orbit and along the direction of motion. Since the ascending node is always at zero latitude, that gives a convenient point of reference. Also, the periapsis and the apoapsis will have the same absolute latitude, so there's no need to add extra steps for conversion--if it's important, then just remember to change the sign. Unless I am completely missing the mark (I'm making up maths as I go here), for a given inclination, the periapsis varies in its latitude according to the inclination multiplied by the sine of the argument of periapsis. What this means is that, for example, if the inclination is zero, then the latitude is zero--which we expect. If the inclination is ninety but the argument of periapsis is zero, then it means that the periapsis is co-located with the ascending node, i.e., at the equator, so the latitude is also zero. If the inclination is ten degrees and the argument of periapsis is ninety degrees, then the sine is equal to one and the latitude will equal the inclination, i.e. be at ten degrees. If you have a Molniya orbit with an inclination if 63.4 degrees and an argument of periapsis of 270 degrees, then the latitude of periapsis will be -63.4 degrees, and that gives a latitude of apoapsis of +63.4 degrees. Edited to Add: And if I am completely missing the mark, then someone will be along shortly to correct my egregious errors. Either way, you'll have a good answer soon.
  13. Sorry. I've got an issue on the bug tracker about it but so far, I've seen no motion on it. Personally, I think it's better to tie the parachute to a building upgrade that theoretically improves suit technology--the obvious choices are either the Astronaut Complex or Research & Development (or both). To put it in perspective, imagine if Grissom and White, owing to their time in Gemini, got wrenches and cutting tools for escaping the command pod in an emergency but Chaffee didn't get them because he was the rookie. 'Hey, New Guy: if there's a problem, you're the designated victim.' It's completely nonsensical. Add in the fact that you can't get to level three without going interplanetary, and the whole affair ends up with a large question mark next to it as if to ask, 'What's the point?' As it stands, personal parachutes are more of a sandbox toy: I like to take my time in career and don't get to interplanetary space for a long while after I've done most of the cross-Kerbin science trekking with unstable aeroplanes. When I do get to interplanetary space, I usually also have the good plane parts and don't really need parachutes. I suppose paragliders are cute but they're really not my cup of tea, and I'm definitely not making a sandbox save for the sake of one feature--except for testing, in which case I figure out how it works, delete the save, and then probably never use the feature again because it doesn't support anything else I want to do. I like the idea and think it has a lot of potential, but the cost to unlock that potential is too high and in the wrong direction.
  14. Zhetaan

    Best time to rendezvous?

    Anyway, to seriously answer this part of the question: The main help is that if you time it correctly, then you can launch directly to rendezvous and save yourself both time and the little bit of fuel you'd need to use for matching orbits. It also looks well cool when you make it work. The drawback is that if you get it only close but not close enough, it usually takes a lot longer to achieve rendezvous: near-identical orbits take a long time to match. Usually, you end up boosting to a different orbit in order to match quickly, which of course uses fuel. My usual approach is to put most things in either a 125 km or a 245 km circular orbit. I chose 245 km because it's low enough to count as low orbit for science (the altitude for high orbit is 250 km) but high enough to get good time warp (the altitude for that is 240 km). I chose 125 km because it gets the almost-good time warp (that altitude is 120 km) but is close enough to Kerbin that it gets short orbital periods and is easy to reach from the ground. I chose circular orbit because it avoids the problem mentioned earlier about one vessel going up while the other is going down. If there is no apoapsis or periapsis, then all transfers are equally ideal: I can rendezvous anywhere. 125 km is the temporary parking orbit for most things; 245 km is the orbit for everything permanent that I want to visit repeatedly. The best part of this system is that I can still time it so that I have a quick transfer immediately after I reach orbit, but I don't need to do so; I have lots of room under 245 km to catch up if I fall behind. I almost never launch directly to rendezvous, but that is merely a matter of preference.
  15. @Tacombel: The Triple-Z Radio Astronomy Telescope is its own mod, so that, at least, makes this part easy. As I look through the configuration file, it appears that the contract is satisfied by any orbit up to 249,000 metres. Technically, anything with a periapsis under 70,000 metres is suborbital rather than orbital, so those are your parameters: have a periapsis above 70 km and an apoapsis under 249 km. Therefore, both 75 km and 100 km should have worked, so if they did not, then something else is wrong. So far as I can tell, this mod is a parts pack, contract pack, and science experiment that interfaces with a lot of other mods but does not have any of its own plugin code, so it ought to be compatible with a large number of KSP versions. That means that the problem is probably not a bug in the mod itself: the most likely culprits are that you either have a dependency that's out of date or malfunctioning, or that you have not yet included everything that you need to satisfy the contract because it's waiting for a different mod part. The radio telescope part is obvious, and the contract will accept anything with a docking node as a docking port. It also only specifies a minimum number, so if you included two or more, it's not a problem. It goes out of its way to allow a number of different power sources, including Kopernicus solar panel modules and nuclear reactors--it even has a line for those fancy curved solar panels from Near Future Solar. For the science lab, there are different parameters depending on whether you have Station Science installed. Both cases require a part with ModuleScienceLab, such as the stock MPL lab. If you have Station Science installed, then it appears that you additionally need to have a part with StationScienceModule, which includes any of the main lab parts in that mod (such as the TH-NKR and D-ZZY research modules--look for parts with a similar naming scheme in the Science Tab in the VAB if you don't know whether you have Station Science installed). If none of that works, then I think you have a bad installation.