• Content Count

  • Joined

  • Last visited

Everything posted by Laie

  1. It seems that I've unlearned how to offset parts... I can use B/N to offset the parts so it looks nice, but the moment I press "H" in order to attach, the offset is back at default. What am I doing wrong? I don't use KIS/KAS much, or often... but I know that I could offset parts the last time I tried.
  2. Oh boy, it's been long enough to carry a child to term... but I've got a few ideas abot my original problem. First off: if I want to decelerate at full thrust for a long time and eventually end up in one particular circular orbit, I also have to start from one particular, well-defined orbit, need to start the burn at just the right time, and have absolutely no steering errors along the way. I dare say that this is not practical. In order to actually do this, I need some parameters I can watch and control: as in, "if X gets too high, throttle down". This is a retrograde maneuver on a mildly eccentric orbit, just for illustrative purposes. decelerating before PE will move the PE away from me. There's a combination of thrust and distance from PE that will allow me to constantly burn retrograde while maintaining the same position relative to PE, somewhat similar to "maintain 1 minute to apoapsis" on ascent. If I have more thrust, I can maintain a position closer to PE. The above also requires some eccentricity. Burning closer to PE will reduce eccentricity, up to the point where it flips and eccentricity increases again. PE starts running away quickly, soon I will find myself near AP. Taken together, there's one combination of eccentricity and distance from PE (probably best expressed as an angle, Mean Anomaly), where I can keep decelerating at full throttle while both remain constant. Proto-Algorithm: throttle down whenever distance to PE or eccentricity gets too high. As those two are linked, it may turn out that only one of them really matters. I don't have the slightest idea how much will be "too high" for either, but guess that I can find out applicable values with some experimenting. *looks outside* Weather is overcast, drizzly, near-freezing. I don't think I have anything better to do today.
  3. It's because the "just keep flying" approach keeps you in the thicker atmosphere for longer. -> more drag. Pulling up first, then catching up on speed later, is more efficient... if you can pull it off. It comes at the risk of pulling up too hard at first, then failing to catch up, and ultimately dropping back.
  4. There's one thing I don't get about this challenge, and that's the whole premise of it. we're supposed to have backup systems & transport in Duna orbit so the station can be abandoned at the drop of a hat. scoring is by having the mostest people on Duna for the longest time. I've spent some time thinking up Kerbin-Duna shuttles, but at closer inspection it seems as if shuttling would be a bad idea. All transfer vehicles have to remain in Duna orbit for as long as the crew they brought is on the surface, in case the station needs to be abandoned. And as long as everybody's happy (that is, once you have the big four), there's no reason to send anyone back home -- except for the one guy carrying the First Soil Sample, and another for company. But everybody else should stick around until year ten, when they all have to return for the final tally.
  5. Yup, that's where I spent my weekend. I don't think KSP and kRPC differ very much in what information you can get out of the game. Yep, that's what I've been considering as well. Take starting position and vector, add thrust and gravity to vector, get new position from old position and new vector. Rinse repeat. I don't have any idea as to how accurate that would be, though, and found that it needs a lot of groundwork before I can even start to find out.
  6. Yep, that's the case I'm interested in. Alas, it turns out that this is much harder than anticipated. I've spent the better part of a day writing a (pos, vel)->(kepler) function that doesn't quite work. And that's not even half of it! At the very least I still need to compute ejection angle & and speed, kepler->(pos,vel), and possibly more. At my skill level, that would take me weeks. You know what? I guess I'll let the game do the maths, after all:
  7. Do you have testflight? Could it be an engine failure perhaps? (MJ used to catch the resulting changes in dV, but perhaps they've thought of some new way to leak propellant)
  8. The dV thingy in the staging list says you have 108m/s. The maneuver you're trying to do requires more than that. That's why the indicator is red: it thinks you cannot finish the maneuver you have planned.
  9. Short answer: You have to calculate the dV for every single stage, then add them all up. More comprehensive answer: deltaV = Vex * ln(full mass/dry mass) where "Vex" is the exhaust velocity, that is, (Engine Isp)*9.81. The dry mass changes every time when you throw away a spent stage, so you have to calculate the dV for every stage individually: If you use different engine types, you first have find the ISP of your rocket: For every engine, add ISP*Thrust, then divide by the total thrust of the whole vessel. Find the full and dry mass of your rocket stage. That is, "full mass" at the time the stage starts using it's fuel, then subtract the mass of however much fuel you're going to burn in that stage. calculate dV for this stage. An just by the way, here's my favorite "online" calculator.
  10. Blast. As mentioned in my previous post, that's a problem with the game giving you wrong directions. Small wonder that you're frustrated. The only stock workaround I can think of would be to "aim camera" at the docking port you're using, then rotate view and zoom in, so far that you're effectively looking out of the port. And then fly visually. Good luck. Other than that, try mods.
  11. I think I spent a whole sunday on failed attempts until it started to get better; after that, results improved quickly. In hindsight, it was fun; not sure if I'd have said the same then and there.
  12. Probably not. You can try to take off yourself, then activate the MJ steering after staging -- but knowing MJ a bit, I suspect it's first order of business upon taking command will be killing the throttle. There goes your one and only ignition. However, for manual launches, a) don't follow the gravity turn all the way to orbit. IIRC (it's been a while) an Atlas needs to start on a relatively shallow turn, but then has to pitch up for a while after booster separation. b) Quite generally, lacking a throttle, you can still control time-to-apoapsis by pitch -- try to make it so that it's close to zero towards the end of your fuel. It's pretty easy to launch into a near-circular orbit that way, the hard part is hitting a certain altitude. I was happy if I got altitude to within +-10km. c) remember the verniers (LV-101?) -- even the original plans for Atlas involved the sustainer being cut a few m/s before reaching the desired velocity, and finalizing it on the verniers. Which will provide perhaps 0.1g rather than the 3+g you get from the sustainer, so it's quite leisurely.
  13. What you are trying to do is very much like threading a needle, and once you've made sure that the ports will be about parallel to each other, I don't think it gets any easier than that. But, steering by Navball for the final few meters isn't that hard: just make sure that your prograde and target markers line up (picture stolen from the illustrated docking guide): There's a bit of experience involved... given a few tries, you'll figure out what kind of error has which results, and soon you will use that knowledge to your benefit. Oh, and have we already mentioned that there is such a thing as "fine controls" (CapsLock by default)? This makes it much easier to carefully nudge your vessel. -- Finally, one gotcha: when determining the direction to target, the game is looking at the docking port you're targeting, but it's looking from the center of mass of your vessel. When your docking port is attached somewhere at the side of the vessel, this can lead to serious parallax errors. In that case, by all means, resort to autopilots.
  14. Nothing inside a cargo bay (or fairing, for that matter) is supposed to generate any drag. This includes decouplers or docking ports that are attached to the inside nodes of a cargo bay. In reality, this doesn't always work. It's usually fine when you first roll out the vessel, but once a cargo bay has been opened and closed again, the parts inside may generate drag. This doesn't always happen, but to me it happens quite often. I'm not aware of any method to make the game reconsider.
  15. The (comparatively) easy solution: you've probably done a few launches from that site already, and know where your orbit will be relative to the Earth's surface. You now have to time your launch so that after launch, you a) end up with the smallest possible AN/DN with the Moon (this happens every day but the launch window only lasts a few minutes) , and b) you can do a lunar injection from near your AN/DN (this happens twice a month and lasts perhaps a day or so). Fix the inclination as part of your transfer burn. Put a marker satellite into a polar orbit. Plan a transfer to the Moon's orbit. Notice how far ahead or behind of the Moon you would be by the time you get there. Then use the cheat menu to adjust the LAN of the satellite's orbit, re-cast your maneuver, rinse repeat until you found a polar orbit from which you can get a nice encounter on your desired launch date. When the big day comes, launch your mighty N1 and try to match the orbit of your marker satellite.
  16. The stock solution is to have both aligned in the "normal" or "anti-normal" direction. That way, the ports will at least be parallel to each other. That, and locking the view "so that rcs pushes you in sensible directions compared to your view" (suggested above) will help a lot. Also, for the final few meters, don't even look at the vessels. Steer by navball.
  17. Well, I can think of two reasons: wobbly rockets / too much gimbal: Do the engine bells swivel from full left to full right, while the rocket swishes like a cow's tail? Then it may help if you tweak down the gimbal range on most or all of the engines. bad aerodynamics / too much drag in front: the way aerodynamics work in this game, you will have a surprising amount of drag from the parachutes. Also solar panels, airbrakes, radiators, but on this particular vessel the parachutes are the worst offenders, and also the most forward. It may be that you simply have not enough tailfins to make up for that. And once you jettison the boosters, you have no tailfins anymore. If your problem is aerodynamics, you will have to re-design your vessel. This sounds more like aerodynamics. Perhaps you can try which way the vessel will fall if you simply let it drop in the atmosphere? Either by using Hyperedit, or a combination of Cheat Orbit, (short) de-orbit-burn, and turning off heat effects so you can see aerodynamics play out without the vessel blowing up. If you vessel turns itself tail-first into the airflow, that's your problem right there.
  18. Does it? The whole point of the exercise is to get a workable solution for arbitrarily low TWRs. I don't think I'll ever get so low that I will actually spiral out over the course of several orbits, though: There's still the matter of patience and it's limits.
  19. Just had an idea that ought to make it much easier: The game already hands me my position and vector. I only need to apply thrust and gravity in order to arrive at position +1. No need to calculate a new set of keplerian parameters at every interval. Actually, I have an inkling that this could be integrated. However, at this point in life I'm happy enough if I can still solve a quadratic equation.
  20. Iirc it varies by engine. Try it with a stack of Ox-Stat panels in the exhaust: Those overheat and blow up quickly, until you get to one that doesnt even get warm. That is the distance where the plume no longer interacts with the vessel.
  21. For someone who can go interplanetary and land in a teacup, that's surprisingly basic questions. ISP denotes the efficiency of a rocket motor: a higher ISP means that you will get more impulse out of your propellant, someone once called it "more buck from your bang". In first approximation, a vessel with a more efficient motor will have more delta-V; however, delta-V also depends on your wet/dry mass ratio, and a efficient but heavy motor doesn't always pay off. TWR means "thrust to weight ratio". With a TWR < 1, you cannot even take off: engines running at full throttle, fire and smoke, but you're not going anywhere. With a TWR that's slighty greater than one, you can take off, but very very slowly. Things quickly get better with increasing TWR, 1.5 is usually sufficient. More doesn't hurt, though personally I find anything above TWR=2 to be rather excessive.
  22. Delta-V wise, you've got it right. 1450m/s for Duna is already generous, you probably won't need a 20% safety margin on top of that. I typically need 1300m/s -- with a high-twr, needle-shaped vessel, well under 1200m/s are possible. Duna is rather friendly, with an atmosphere that slows you down for landing, but is so thin that it's not much of a hassle on the way up. You can use parachutes to great effect: while a soft landing would require dozens (too heavy!), one or two chutes will slow you to well under 100m/s. Engine power can take care of the rest, and the landing will be a lot less frantic than on the airless Mun. Such a landing usually requires under 100m/s. Bring 200m/s and you're safe. However, you will need a drogue chute as well, or the main chutes cannot be deployed in time. You've got a wide choice of engines. The air is thin enough that most vacuum engines still perform well.
  23. Solved, kinda, sort of: problem occurs if kRPC was the last to touch the servos. The workaround is to adjust them myself (to anything) before saving the game.
  24. I can't say I enjoy low-thrust, long-duration transfer burns, but find myself in that situation pretty often and have learned to cope. Lately I familiarized myself with kRPC and now I wonder if I might be able to do it right: performing a single long burn, pointing prograde all the way while spiraling out of the system... and still getting where I want. I haven't done any orbital calculations yet. The maths doesn't look too hard, it's just that I don't have any first-hand experience. So I also don't quite know what to look out for. Advise would be welcome. I assume that I can use an ordinary, instant in-game maneuver as a template, and then somehow work out a power track that sends me on a similar trajectory. I'll have to calculate a series of tiny maneuvers in short intervals, right? Or is there a more elegant way to do this? how do I tell if I succeeded? The eventual trajectory cannot possibly be identical to the one I planned earlier (cf. example above). I presume what matters is the velocity relative to the sun right after SOI transition, is that right?
  25. For a VTOL vessel, I attached engines to servos. Worked well for landing, but on takeoff I find that engines remain fixed while the nacelle gets swiveled about. I don't think I can take off again. Short video of the problem (10sec, 870kB: that's less than many a screenshot these days. Now if our forum would embed these just es easily as pictures...) Full disclosure: The nacelle is a compound part, consisting of pre-cooler, end caps, and an integrated servo. So it's as if the servo had flipped sides, now moving the end that's supposed to remain fixed. Has anyone an idea why this happens, and if there is is a solution? ETA: saveloading doesn't work. Or rather, it seems to cause the problem. I can reproduce it thus: roll out vessel, use servos (work as intended), save. Load vessel, use servos: they swivel at the wrong end.