Starman4308

First off, it may help to upload the craft to KerbalX so that it can be exactly reproduced. Second, while I'll forgo giving specific advice on the craft (not much recent experience in stock), I do have a recommendation. Send several landers (probably separately), as well as experiment storage units, either directly on your manned vehicle or separately. That'll allow redundancy and potentially science from multiple biomes. There may have to be some manual experiment shuffling, but it can give nice return on investment to have a manned vehicle rendezvous with unmanned landers; I did a very similar thing a while back (the Ariadne-Theseus project). EDIT: But do bring some experiments directly onboard your manned vehicle. You can use a scientist to reset a materials bay and goo pod to harvest loads of science from Duna and possibly Kerbolar orbit.

EDIT 2: Thanks to the mods for moving this to the correct thread! Landed an unmanned rover on Iota, complete with BonVoyage module. The landing itself was uneventful Then, I decided "I'm going to manually rove up that mountain". Gravity was so low that, when catching some vacuum, I could collect magnetometer data and retract the boom before landing. And it wasn't very close, either. This image shows me near a boulder. What it does not adequately show is what direction I was moving. I had one bounce to not crash my expensive rover straight into a boulder. Fortunately, I span out and narrowly avoided landing on the back of the rover, filled with instruments and solar panels. I should do reckless things like this more often.

First, I'd like to apologize. It was pretty badly uncalled for, and I was vastly more venomous and unpleasant than was ever called for. Second, a couple recommendations: Deep Freeze, which keeps your Kerbals in cryogenic stasis. Time Control, which lets you increase time warp beyond what stock allows. There are also probably some ways to set up closed-loop life support; you might try looking at how TAC Life Support handles its recyclers, and configure something to recycle the extra waste into those life support supplies that can't ordinarily be recycled.

Okay, I'll be good. For those who wish to go interstellar at relativistic velocities: You would probably want to set up a mod as a library into which other plugins could query its API. Presumably, instead of their default behavior, when loading a vessel, the life support mod in question would ask your mod "How much time has elapsed for this vessel?" Your mod, in turn, would check to see what the vessel's velocity is. Below a certain threshold, you probably would just want to return actual time elapsed. If, however, it's above a threshold, then you could use relativistic equations to determine how much relative time had elapsed for that vessel. While theoretically you'd want to evaluate speed over the entire path to take into account what gravity does to your velocity... gravity isn't doing anything significant to your velocity at relativistic speeds. Jool's enormous gravity well? In and out in a minute. There would be no real need to try to look back into the past.

A, you would probably need to have the various mods insert hooks into their code for time dilation, code that might get kinda fragile. You really don't want to mess with the overall game time clock, so they would need separate code to figure out how much relative time had elapsed. B, in a game about semi-realistic space travel, dealing with relativistic effects becomes a theater of the absurd. For those like me, it wouldn't be an enhancement, it would just throw me for a loop what with the absurdity of it all. C, you're still badly underestimating how far we need to scale back c. For reference, the velocity attainable via a 1:1000 ratio with the Dawn ion engine is about 284 km/sec, a piddling one-millionth of the speed of light. EDIT: By the time you scale it back far enough to be attainable, it bears no real resemblance to the speed of light, and while I can't speak for other people, it would just really make me wonder what was going on.

So still mind-bogglingly fast, impossible to achieve without either the debug menu or particularly overpowered mods. Let's take the highest specific-impulse engine in the Near Future mod, the FI-2154 Jewel-4. It produces 5.6 kN at 19,300 sec of Isp, at the cost of something like 400 electric charge per second. Some would call this engine overpowered. Now, let's plug in 0.05c into the rocket equation; 1/2 of your scaled-back speed of light. 3E8 m/sec * 0.05 = 15,000,000 m/sec dV = Isp*Gm*ln(mw/md) mw/md = e^(dV/Isp*Gm) = e^(15000000/9.8063*19300) mw/md = e^79.25 power mw/md = 2.63*10^34 Kerbol, the sun, masses a mere 1.8*10^28 kg. The real-world sun masses a mere 2*10^30 kg. Short version: please stop underestimating the speed of light. No, you can't reach it. No, you can't reach a tiny fraction of it. It is simply too fast for humans to easily grasp what it means.

So, hopefully I actually remember what I did in the past couple weeks. Year 306, Day 125: Launch of the Augustus Telescope To improve reliability and serviceability, the newest telescope under GSC jurisdiction, the Augustus orbital telescope was launched to an equatorial 500x500 km orbit over Gael, with a full service bay, and a most wonderous invention by Prof. Vallten's group, a lens cap. We can now have much less fear of optics getting destroyed by Ciro's light, as the sensitive optics can be shuttered away as day breaks. While the optics are not overwhelmingly superior to prior telescopes, Augustus can be much more easily serviced than previously possible. Some of its early images include a shot of Jannah. Project Mercury: Interplanetary Communication Networks To assist in interplanetary missions, a standard set of relays was designed for Thalia, Niven, and Tellumo. Three relays are stacked onto a single Laythe booster, with the upper two having PPT Teflon RCS thrusters. Project CLOSE: Ciro LOcal Satellite Exploration Project CLOSE is the codename for the first series of probes sent to the inner planets. While Pioneer 1 was not under the auspices of CLOSE, probes have been sent to Thalia, Niven, and Gratian, with plans to send additional CLOSE probes to Thalia's newly discovered moon Eta, and a probe for an Icarus flyby. CLOSE-N: Niven: Launch, Year 306, Day 252 Status: Primary Mission Complete, Standby Despite CLOSE-N being theoretically our pioneering mission to Niven, it was preceded by a radio/telescope surveillance platform built on contract with the Luxtine government. This satellite entered Niven orbit on Year 7, day 49, at 11:25. Surprisingly, Niven appears to have an atmosphere, although its thickness is yet to be determined. Niven Surveyor completed entry into the requested orbit on day 65 at 11:39, with just 346 m/sec of delta-V remaining. CLOSE-N itself arrived on day 68 at 01:35:00, and inserted into its final orbit on day 81, 06:43:15. A very final orbit. There's not a drop of fuel left. The southern hemisphere is not quite as well-observed as a result. Scientists are still unsure of what caused the enormous Nivenean Trenches, although some suspect a volcanic origin. CLOSE-G: Gratian: Launch: Year 306, Day 342 Status: still in-transit to Gratian CLOSE-T: Thalia: Launch: Year 307, Day 153 Status: Initial high-orbit mapping in-progress CLOSE-T is noted for a relatively unusual shape, with an upper, tapered cylindrical tank above a narrower cylindrical tank. This was to allow the enormous radiator panels to fit inside the fairing, while still shortening the overall propellant tank. Due to the strict delta-V requirements of transit to Thalia, the probe itself had to complete the final 125 m/sec of the Thalia transfer burn, rather than the upper stage of the booster. On Year 7, Day 319, CLOSE-T approached Thalia, and the wide-field camera discovered an unknown moon, Eta. Unfortunately, the mission did not budget enough delta-V for an extensive survey of Eta, and remains focused on its primary mission of surveying Thalia. The capture burn was immense, a 2617 m/sec burn that took fourteen minutes to complete. Thalia itself is a blasted landscape with no apparent atmosphere. More will be known in the coming weeks, as data continues to come in from CLOSE-T, which is currently in a 400x1500 km mapping orbit. A relay vehicle was sent; however, one of the three relays had to be jettisoned as mission planners realized they would not have enough delta-V to capture into Thalia orbit. This will help ensure constant communications back to Gael, and mission planners are pondering whether to send a third relay to complete a polar constellation. Project ISRO: In Situ Resource Operations To test the concept of ISRU, the ISRO satellite was launched towards Iota on Year 7, Day 285. The mission objectives: land upon Iota, drill for hydrated minerals such as epsomite, retrieve the water contained within them, electolytically crack the water for hydrogen and oxygen, use that fuel to launch back to orbit, land again, and fill up a second time. The first landing, at an equatorial midlands location, succeeded on day 288, 09:34. ISRU operations proceeded apace, filling up both the water tank and topping off the fuel. Each of the four lightweight drills provided about 55 grams of hydrated minerals per second, from which about 15.5 grams of water could be extracted. By day 295, almost half a lunar day later, ISRO was ready for launch. By 11:28:39 on day 295, ISRO landed much closer to the poles. ISRU operations did not immediately commence, however, as night was about to fall. About five days later, Ciro rose over the hills west of ISRO. Mission planners scribbled in their notes, "do not land on the leeward side of a hill". Unlike the equatorial landing, this time, ISRO landed with the solar panels on an east-west axis instead of north-south. As a result, it took nearly twelve hours to bring ISRO fully online, as Ciro painfully slowly rose over the horizon to give the solar panels a better angle for light collection. Because of this, and the much more depleted tanks from the round-trip landing, it took two Iota days (each 5 Gael days, with a 5-day night) to refill the tanks. Finally, the GSC continues to insist that images such as these are not black magic, and are simply caused by the Sigma Dimensional KSCS optical illusion. EDIT: Next time, on Dragonball Z Astronomers of Gael: Rovers, Extended Surface Experiments, and Even Bigger Boosters! I am really liking my new Ike series, which uses the same upper stage for: 25 ton payloads to Gael escape, 32 ton payloads with a bigger first stage engine, 40 ton payloads with a pair of Kickbacks, and 55 ton payloads with a pair of 70-ton KW Rocketry SRBs. The really fun thing is that I can take that same upper stage, replace the central Poodle with a Penguin and give it more propellant, and probably get even more payload capacity. I've overhauled all payload categories now that I have tech-level 7 boosters, but the big one is the one I like the most.

I think "escape trajectory out of the sun" can mean "will capture into another planet's SOI". The patched conics are a much better guide: just see if your orbital track continues to show an Eve intercept. Also, Kerbal Alarm Clock is an outright godsend, as you can make alarms for SOI transitions, manuever nodes, raw time alarms, ascending/descending nodes, you name it. It's not stock, but it's one of the most widely used utility mods; I use it religiously. Standard mod things apply: you should probably install mods into a copy of your KSP game folder (for Steam, this will usually be C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program), so you always have a pristine installation untouched by mods, Steam doesn't update KSP behind your back, etc.

What I'll sometimes do for heavier 1.25m stacks is have a central Reliant and two Swivels on the side. The Swivel loses a fair chunk of TWR in exchange for a little Isp and gimbal. You probably don't need three stages to get to LKO, so it seems quite possible to me that you're over staging and should use bigger, longer burning stages. It's been forever since I last played stock, but I'm pretty sure three stages to orbit is overkill unless you're doing something fancy like asparagus staging.

What other mods do you have going? Usually, RSS players have some of these mods. Ferram Aerospace Research: Makes aerodynamics more realistic, and in particular gives reentry vehicles more drag. MechJeb or Kerbal Engineer Redux to help design vehicles Procedural Parts and Procedural Fairings: helps make very large, very small, and oddly shaped parts. One of these three: SMURFF: Brings stock propellant tanks and engines more in line with reality, but without all the complexity of Real Fuels Realism Overhaul: Includes Real Fuels and a wide variety of real-world engines, along with a truckload of other tweaks Real Fuels-Stockalike: Brings stock parts into line with reality, using Real Fuels, and all the complexity that comes with (ullage, cryogenic boiloff, etc). The reason for the last three is simple. Because Kerbin is so much smaller than reality, Squad balanced things by making fuel tanks extremely heavy (9:1 full:empty, versus real-world tanks that can exceed 30:1), and by making engines very heavy relative to their thrust output. They also pegged engine specific impulse at approximately the level of the common hypergolic propellants (hydrazine/MMH/UDMH as fuel, NTO as oxidizer), whereas you can get slightly better performance with cryogenics like kerosene-oxygen, and much better performance with hydrogen-oxygen. All three of these correct these much closer to real-world values, which helps partially with getting to orbit. In particular, you'll generally find real-fuels stages will often have more delta-V and burn longer, because with lighter-weight tanks and engines, there's less incentive to stage off fuel tanks and engines. Also because the delta-V requirements are so much greater, but that's what you're trying to address.

Pretty sure. The first image can easily be explained by low-quality imagery: the fact that the satellite has been confirmed as reaching its target orbit cannot be explained away, not with the published specs of the Proton launcher and its payload. If you need to lie about what they lied about... it's time to stand back, think about what you're doing, and in the case of Russia, instead look at the things they very, very clearly lied about. There's no shortage of those; we don't need to make up something like this.

Largely irrelevant to the discussion. While it becomes more complicated when you factor in finite accelerations, the overall conclusions are largely the same: mainly, that in some edge cases, a bi-elliptic transfer is more efficient than a Hohmann transfer (particularly if you need to do a very large inclination change; I think at about 80-ish degrees, it's always more efficient to do it with a bi-elliptic). Granted, I feel this point is kind of lacking in K^2's analysis: the cheapest thing in most scenarios is not to perform a bi-elliptic, it's to not have to do that bi-elliptic in the first place; for example, to get to a low retrograde orbit over Kerbin, the most efficient method is not a bi-elliptic... it's to launch retrograde in the first place. I'm pretty sure that's not actually what "suicide burn", "gravity turn", and "constant descent trajectory" mean to most people. To me, a suicide burn is: you burn retrograde in orbit to set periapsis beneath the surface, then hold your vessel to the surface retrograde vector, and kick on the engines at the absolute last second, perfectly coming to a stop as you touch the ground. Key to this are that you're pointed exactly dead-retrograde the entire way, and light up the engines at the last possible second. A gravity turn is mostly just something for ascent from atmospheric bodies, where you start by going straight up, induce a small tilt (usually eastwards), and then go get a coffee, letting aerodynamic stability keep you on track. It's not a good idea for airless worlds; you waste far too much dV going straight up, whereas the ideal for airless worlds is to go as horizontal as you possibly can without lithobreaking events the instant you take off. A constant descent trajectory is something entirely different; you get to a circular orbit just above the surface, and then, instead of locking purely surface-retrograde, you start pitching up to maintain a constant-ish descent velocity, which is ideally 0.

Because sane people like margins for error. For my own spreadsheet, I peg lowest possible orbit as 15 km above an atmosphere or 25 km above the surface. In case anybody could use mine, it's uploaded here, though it's not as compact as Ed's. A lot of the fields are done as equations, so if you wanted to add fields for, say, OPM, or replace the values with a rescaled system, you don't need to re-enter or re-calculate everything, just enter in some of the fields. I don't mean to steal Ed's thunder here, I just assumed everybody who'd been playing KSP long enough had spreadsheets full of the information they most commonly need to plan missions.

The difference between circularizing into a low parking orbit and direct-to-landing is very minimal; the only real difference is that you can be slightly more aggressive with the altitude of your capture burn. Given that putting yourself into a parking orbit first makes it much easier to hit a given target, and gives you the chance to re-evaluate things*, I find no convincing reason to go direct to landing. *For example: "do I have enough dV left for the landing, or should I scrub this one and just return home?"

On that last bit: I suppose I should clarify that sometimes practical concerns can outweigh the theoretical. For example, your descent trajectory to Gilly should be less concerned with optimizing gravity losses vs. engine mass, and more concerned with not embarassing yourself by crashing into Gilly.

Aim for a very low periapsis, as low as you can get it without smacking into terrain. This conclusion comes from two things: the Oberth effect, and conservation of orbital energy. The Oberth effect says "the faster you're going, the more energy you gain or lose by accelerating", and conservation of orbital energy says "unless you make a maneuver, the sum of your kinetic energy and gravitational potential energy is constant". The energy of a nice circular orbit around Minmus is much less than the energy of the capture, where by definition you have at least enough energy to escape Minmus orbit. So, you want to shed that energy. Where's the best place to do that? At periapsis, where Minmus's gravity has accelerated you to the greatest extent possible, so your velocity at the capture burn is maximal, so you can shed more kinetic energy per m/sec of delta-V. Where's the best place to have your periapsis? Scarily low, where Minmus's gravity will have accelerated you as much as it can without experiencing a lithobreaking event. The length of the burn should simultaneously be very short (Oberth effect) and very long (engine mass is dead mass for the Tsiolkovsky rocket equation). It's a complicated optimization problem; I took a stab at the landing part of it a while ago and I think my conclusion was that the optimum was to have enough engine for about 2-2.5 m/sec^2 of acceleration (4-5 TWR for Minmus, ~0.2-0.25 TWR on Kerbin). Landing should begin at as low of an altitude as you dare, managing vertical velocity to avoid a RUD event while shedding as much horizontal velocity as quickly as possible. Again, the Oberth effect comes into play here, and is a balance against adding too much dead-weight in the form of rocket engines. The ideal rocket, after all, is a giant, infinitesimally lightweight balloon full of propellant being fed through an infinitesimally lightweight (but still high specific-impulse, can't forget that) rocket engine*. *And if you want to go real-world about it, that engine has an infinitely long de Laval nozzle... that again is infinitesimally lightweight.

In terms of features, my understanding is "not much". There have been bug fixes, though. Here's the wiki page and the official announcement for the changes in 1.3. My own opinion can be summed up as "nice, but not worth risking my teetering pile of mods crashing, exploding, and burning if I try to update, even if the mods are updated for 1.3". Were I pure-stock, though, 1.3 ahoy.

I don't mind huge posts. I dislike it when people quote huge posts in their entirety to comment on a small section. Thus why I snipped out the vast majority of your post. You can also put some images in spoiler tags to reduce page load shenanigans.

The problem did get solved; it was a syntax thing as mentioned in the edit: I forgot a leading # in front of a variable.

Alrighty, thanks for that; I'll probably try installing it in the next few days. I know to some extent there's "test it yourself", but with my save games being a gigantic, fragile, teetering pile of mods, I try to be careful about things.

First class piloting there. Second-class engineering, but first-class piloting. Played almost no KSP today, most of it spent making my Real Fuels-Karbonite patch more elegant. The converters now produce heat (drills not yet, dangit I'll have to do that tomorrow now that I actually understand most of it), and everything is properly normalized to part mass. Otherwise, in the past about-a-week, I've: Landed Kerbals on Iota and Ceti Landed a probe on Tellumo after a harrowing, 30.6G, "I did not know the slightest thing about its atmosphere" descent More scope pics, some from the new Augustus telescope (yes, named after the poster who's making his own 6" telescope)

EDIT: Nevermind, I am an idiot. An idiotic idiot who did once idiot to idiotically idiot onto the Internet. I forgot to put a # before "$../../mass$". So, quick question: I'm trying to programmatically multiply an array of keys*, and despite this seeming like the correct syntax, Module Manager reports six exceptions (which at least corresponds to six keys...). *Trying to improve my Karbonite-Real Fuels patch by adding heat production and making stuff far more programmatic. @PART(stuff) { MODULE { name = ModuleResourceConverter <... other stuff> TemperatureModifier { key = 0 50000 key = 750 25000 key = 1000 5000 key = 1250 250 key = 2000 25 key = 4000 0 } @TemperatureModifier { @key,*[1, ] *= $../../mass$ // My understanding is this would read "for all variables "key", modify the second (0-indexed 1), space-separated value by the value mass that is two nodes below the TemperatureModifier node. Ideally, this is the part mass, though I might be messing that one up. } } }

I'll point out that @Cunjo Carl's strategy wastes a fair chunk of delta-V by splitting the Duna transfer into two burns, one outside Kerbin's SOI. The Oberth effect is your friend, which means you can get that Duna transfer energy for less delta-V if you do it in LKO. It's probably a bit simpler for finding the appropriate transfer window, but there are mods (and tools) for that. To transfer to Duna, you need enough orbital energy to kick yourself out of Kerbin orbit and raise your apoapsis to Duna intercept. By doing it all at once, you're starting the Duna intercept "burn" with the velocity of Kerbin around Kerbol, plus the velocity of your LKO parking orbit, plus the velocity of Kerbin ejection. By splitting it up, you lose all the velocity you had in LKO, plus the velocity of Kerbin ejection.

Personally, I think the grace period should extend to... <checks email> August 3, 2014, 6:23:36 PM CST. In terms of my actual opinion: I think what Squad is doing is quite reasonable, extending free DLCs to those who purchased under the understanding that they would get free DLC. It's a relatively small fraction of the userbase that purchased the game by that point, before it had really gotten hammered out into a truly enjoyable, full-fledged video game. I doubt Take Two would be stupid enough to renege on that promise; the PR disaster that would result would almost certainly cost them more than just giving out a few free DLC copies. Granted, one should never bet too heavily against human stupidity and short-sighted corporate greed.

Do CommNet antennae need to be activated to work? I know with Remote Tech that would be one of my guesses.