Starman4308

There is a reason why this thread is stickied and noted as "READ FIRST". Read it. First. The only guess I can make from what information was provided is that Steam updated KSP to version 1.3, which breaks mods for version 1.2.2. Well, that and that you have an AMD graphics card (or APU) and 16 GB of RAM, but that doesn't really help debugging.

On top of there being no stock support for such a feature, or any mod that I know of... that could get to be an awful lot of debris for the game to track, which could start to really slow the game down.

The fins are also relatively small and mounted high up on the craft. You want a top-heavy, bottom-draggy rocket for stability, which means fins as low down as possible on the stack. There's also an excess of struts, though it's possible that that's because stock joints are much more wobbly than what I'm used to with KJR (Kerbal Joint Reinforcement). EDIT: To be clear: while fins that small might work (you can often get away with rockets that are aerodynamically unstable, so long as you can still use gimbal and reaction wheels to keep it on course), they should definitely be as low as you can possibly mount them.

So, quick question: should this be compatible (even with just generic messages) with planet packs not specifically listed, in my particular case Galileo's Planet Pack? This looks like a fun little mod to make the science system more interesting and elaborate than "land, press designated action group, have a Kerbal hop out and click a couple buttons, return, lift off before two minutes have passed".

Very little, at least directly. You've got maybe 250-300 m/sec of delta-V from the aircraft itself, the the energy boost from starting at 35,000 feet isn't very much. Where it helps the most is with small payload launches. By starting 35,000 feet up, you're in much thinner atmosphere (about 0.25 atmospheres pressure), which means less atmospheric drag losses, and your first-stage engine can be much closer to a vacuum-optimized engine instead of something designed to start at sea level. Where it makes things worse is that your rocket has to be braced to be carried laterally, fully fueled up into the air (adding mass), and you've got a big, expensive aircraft to maintain for the launches. That has to be weighed against the conventional wisdom of "just make the first stage a bit bigger".

They're just the radial chutes from RealChute, set to minimum size.

I did say it was needless drama, did I not? Also, the first version of this post got eaten. If anybody has suggestions on how to deal with that, I'm all ears. And a little bit of eyes, torso, toes, etc. Ceti: Year 305, Day 264, 09:58 Lifson 7 arrived in Ceti orbit twelve days after the Iota landing, and rendezvoused with Neil 3 the next day, targeting a landing on Ceti's lowlands. The landing site chosen was much closer to the equator than previously, requiring minimal inclination change. And is also the planned landing site, Jebediah. Powered descent began late on day 265, with touchdown at 10:49:40 At the landing site was placed a plaque, which reads: "Here landed four brave Kerbonauts, blazing a trail to the stars much as did our ancestors. We have come a long way since the Transplantation. While the journals and knowledge of our ancestors has carried us a long way, it is time to go beyond; much remains not just to be rediscovered, but also discovered for the first time. For the first time in centuries, we have walked upon new worlds, and should we meet again with the Kerbals of Kerbin, we should be glad to share with them the worlds we have found." At 11:06, the Lifson 7 crew took off from the surface, achieving an almost circular 18.5x3.9 km orbit with the initial ascent, for which we congratulate the crew of Lifson 7. By 00:20:34 the next day, Neil 3 had docked to Lifson 7, and the crew returned home ten days later, splashing down at sea. The Lifson 8 and 9 missions have had more thorough and technically challenging scientific goals, as the first mission was kept conservative in its goals. Notable achievements are samples which show that the Ciro system, unlike Kerbol, likely had a late heavy bombardment period, where the inner planets were subject to a great number of impacts. Jebediah, 70 degrees latitude is not an accidental deviation from a nice, safe, equatorial landing. Tellumo: Year 306: The First Interplanetary Probes Arrive Early in year 306, the Pioneer 1 and Tellukhod probes arrived in Tellumo. On the first pass around, Pioneer 1 confirmed the existence of van Allen belts, a faint ring system, and a strong magnetic field around Tellumo. Shortly thereafter, Tellukhod arrived and began its descent. While it was intended that the transfer stage separate from the lander and be used as a relay, the transfer stage's attitude control system was completely forgotten failed, and while Tellumo impact was prevented by throttling the two side engines, that only allowed control in one axis, and the transfer stage had to be abandoned to Cirocentric orbit. The probe itself, however, performed above expectations. An intentionally low periapsis was set, as Tellumo's atmosphere was not well characterized at the time, and with no engine aboard Tellukhod, the decision to enter at a low periapsis of 25 km, potentially risking a high-G aerocapture, but with more certainty of aerocapture period. What Tellukhod discovered was a relatively thin atmosphere, that only became significant at 63 km... but which very quickly gets denser at lower altitudes. Tellukhod peaked at 30.6 Gs of acceleration during descent, and the only major hardware malfunction was a failure to have the heatshield separate. About twenty days later, when Pioneer 1 circled around into communication range of Tellukhod, the probe returned data from all instruments, as well as images clearly showing the presence of trees. Later on, Pioneer 1 conducted three two-minute braking passes over Tellumo to bring itself down from a highly eccentric orbit to a circular, 800x800 km polar orbit and began mapping activities Preliminary mapping shows that there is just one major landmass on Tellumo; the smaller continent is connected to the larger by a small land bridge. Otherwise, Tellumo's ice caps are significantly larger than Gael's, not just in terms of extent, but also in how deep they are.

The only other piece of advice I could give is to build your mining and transport ships as big as you can without dropping framerate too badly. If the limiting factor is human-time, then it's an excellent idea to build big, even at the expense of some efficiency. Also, I think Hyperedit has some functionality to add resources to a vessel; I haven't used it, but it's there. EDIT: And I think stock has bigger fuel tanks than ore tanks, so you might want to have your miner also be a refiner, so you can fill up a smaller number of larger tanks on the transport vessel.

Now that I think about it more carefully, you could have the second LV-N angled through CoM. It'd be curious to see; dropping the second LV-N early would increase gravity losses landing on Eeloo, but takes a significant chunk out of your dry mass.

Did you ever consider something like having one of your two LV-Ns on a separate decoupler, so that you could remove that mass once you no longer needed the thrust? EDIT: Also, to elaborate a bit for some people: the reason why Tylo is harder than Eeloo is that you can use gravitational slingshots to enter an SOI with arbitrarily small relative velocity for free*, but once inside the SOI, there are hard limits on how much delta-V you have to spend to land and return. For Tylo, you're talking ~6 km/sec bare minimum to land and return, versus just 1.6 km/sec for Eeloo. So, with smart gravity assists, you can get to Tylo and Eeloo with similar amounts of delta-V, but orbit insertion, landing, and return is much more difficult for Tylo than Eeloo. *Assuming infinite patience and precision. In practice, you're going to be somewhere above this theoretical lower bound.

Well, take a look at the moment of capture into the Mun's SOI. You know the Mun's velocity vector, and can make a good estimate of your vessel's velocity vector: approximately parallel to the Mun's trajectory, at your apoapsis velocity. Thus, your Mun capture velocity is approximately the Mun's velocity, minus your transfer orbit's apoapsis velocity. In practice, it's probably going to be a bit more, because you're probably not going to be at exact apoapsis and you're probably not going to be exactly parallel to the Mun's orbit at the moment of capture. Thus, you now have a Mun-relative V, and you already know G*m for the Mun, and your altitude is the Mun's SOI (be sure you're using SOI radius from the exact center of the Mun, not from the Mun's surface). An example, assuming you started from 100 km periapsis of Kerbin, and will capture 20 km above the Mun: Note that the vis-viva equation simplifies to V^2 = mu/a when you are in a circular orbit (r == a) Vpark = sqrt(mu(Kerbin) / rpark) = 2246.139 m/sec at parking orbit Next, your transfer orbit apoapsis will be about at the Mun's SMA of 12,000,000m, so your transfer SMA will be 0.5*(700,000 + 12,000,000), or 6,350,000m. Vtrans = sqrt(mu(Kerbin) * ((2/rpark) - (1/atrans))) = 3,087.738 m/sec So, your Mun injection burn requires (3087-2246) = 841.6 m/sec Next up is calculating your Mun-relative velocity at capture. Vapokerbin = sqrt(mu(Kerbin) * ((2/apo) - (1/atrans))) = 180.1 m/sec We know the Mun's orbital velocity, 542.5 m/sec. So, at capture, your Mun-relative velocity will be approximately 362.4 m/sec. We can now plug this in to determine our Mun-capture SMA using the Mun's SOI radius as our altitude. V(mun)^2 = mu(Mun) * ((2/SOI) - (1/a)) Rearrange, and you get a = 1 / ( (2/SOI) - (V^2/mu(Mun))) We now have a semi-major axis of -838387 meters. Yes, I know a negative SMA seems nonsensical, but it's how SMA works for hyperbolic orbits. We can then plug that in to determine our velocity at peri-Mun of 220000 meters Vperi = sqrt(mu(Mun) * (2/220000 - 1/a)) = 818.45 m/sec We can then calculate the velocity of our destination, circular 20 km (220 km from the center) orbit Vdest = sqrt(mu(Mun)/220000) = 544.14 m/sec From that, we know the delta-V of our insertion burn: 818.45 - 544.14 m/sec = 274.315 m/sec

A crackpot theory from before we had images good enough to be sure that yes, Pluto actually was a planet. Also, while I'm not super-sure on how the frame dragging might influence pure slingshot maneuvers, one could at least exploit the Oberth effect quite magnificently at the bottom of a deep gravity well.

It is easiest (for me) to do with the vis-viva equation, which relies on conservation of orbital energy. You have a certain amount of relative velocity incoming to the Mun, plus gravitational potential energy. The vis-viva equation is: V^2=G*m*((2/r) - (1/a)), where: V is velocity, G is the gravitational constant, m is the mass of the Mun or whatever body you're transferring into, r is current altitude, and a is semi-major axis. You will often see the Greek letter mu substituted for G*m; that product is the body's standard gravitational parameter, and due to not having a very precise estimate of G, real world astronomers usually use mu directly. So, if you know what Mun-relative velocity you capture with, and the SOI radius, you can solve for a, and plug that back in with an r much closer to the surface, and now you know your velocity at periapsis. From there, calculate the velocity you will have in the target orbit, and subtract.

Another question to keep in mind here is how the commsats are powered. If you're using solar panels... no dice, they will get no significant power terameters away. If you're using reactors... those run out of fuel. If you're using RTGs, be sure not to have RTG decay configs. Anyways, I think I have a semi-answer based on a greedy algorithm: you will need 1610 satellites in 24 rings, assuming you let relays be a maximum of 990 Gm from each other (if you are using the root model with the JX2 antennae, that goes down to just 411 satellites in 12 rings with a maximum separation of 1980 Gm). Increased range of the antenna drops the number of satellites needed enormously; as distance needed becomes large, the number of satellites is proportional to the square of (distance/antenna range), so by doubling antenna range, you reduce the needed number of satellites by a factor of about 1/4. You might kinda want a JX2000 for this one. As usual for me: Java with the Apache FastMath package, which can be 1:1 substituted with just the regular Java Math class. public static void optNetworky(double target, double range) { List<Integer> circleSats = new ArrayList<>(); circleSats.add(3); double currSep = range; double halfR = 0.5 * range; double currAlt = halfR / FastMath.sin(FastMath.toRadians(60)); double r2 = range * range; double pi2 = 2.0 * Math.PI; /* * Algorithm: knowing the altitude of the current ring of satellites and the separation between them, figure * out the maximum altitude of a satellite that is exactly between and 1x range beyond them. Knowing that * altitude, figure out how many satellites must be in the next ring. */ while (currAlt < target) { double extraAlt = currSep * 0.5; extraAlt *= extraAlt; extraAlt = r2 - extraAlt; extraAlt = FastMath.sqrt(extraAlt); currAlt += extraAlt; double maxTheta = FastMath.asin(halfR / currAlt) * 2.0; int nSats = (int) FastMath.ceil(pi2 / maxTheta); double theAngle = pi2 / nSats; currSep = currAlt * FastMath.sin(theAngle); circleSats.add(nSats); System.out.println(String.format(" New ring with %d sats, altitude of %9.4g, and separation of %9.4g", nSats, currAlt, currSep)); } int totalSats = circleSats.stream().mapToInt(Integer::intValue).sum(); int numRings = circleSats.size(); System.out.println(String.format(" Total: %d rings with %d satellites", numRings, totalSats)); } EDIT: Short version, do what Bewing and Snark suggested.

Well, my entire save folder is 849 MB, with each recent .sfs hitting 16 MB. What's probably inflating things are the sheer number of mods that are adding modules and resources to my craft. TAC life support? Food, water, and oxygen for each command pod, plus however it tracks how long it's been since the vessel was updated. FAR? Adds an aero module to each part (though that's possibly regenerated in flight). RealFuels? The tanks get more complicated, the engines need to keep track of remaining ignitions and what configuration they're using. There's also a bunch of KAC backup saves, so there's a lot of 16 MB .sfs files hanging around. At least they compress really well, being particularly repetitive text files.

There are also some tricks for how to do the transfer. Split up long transfer burns into a set of periapsis kicks, use a Tylo slingshot to capture into Jool orbit followed by some more gravity pingpong to adjust your Jool orbit, etc. Without a screenshot or craft file, it's hard to be certain, but my initial suspicion is too much payload and engine, not enough fuel (and remember that the nukes use only fuel, no oxidizer).

There has been an entire challenge to that effect. Man, I loved that challenge. To the OP, may I suggest the following rules: No kOS, MechJeb autopilot/Smart A.S.S. (possibly no MechJeb period), no RemoteTech (which has a flight computer), etc. Ideally, submissions should require a significant degree of manual piloting; you may, for that matter, insist on some specific rocket (probably designed to not be too terribly stable). I'm probably not going to participate here (it's just not my cup of tea), but I thought it might help to close a couple loopholes before somebody tries to rules-lawyer it up.

First, is it possible that KSP got updated to 1.3 when you're still using 1.2.2 mods? Steam can and will silently update KSP behind your back, which is why many people (including myself) copy the KSP folder somewhere else, and leave the Steam installation as pure stock. Second, that's not really much info: please read this:

What I'm wondering is how I'm going to finish off my Space Race victory before Montezuma comes calling. More seriously, I'm cautiously optimistic about this, but if all else fails, well... I still have plenty of DRM-free versions of KSP stored locally.

I'm glad you guys enjoy the telescope pictures at least. If you have any advice or criticism, please pipe up: I full recognize it's been years since I last did any serious creative effort, and I'm bound to be making mistakes... to the point at which not even I'm sure what tone I'm trying to take with this story/report series. Year 305: The Lifson-Armstrong Project: Kerbals on the Moons The goal of the Lifson-Armstrong project was simple: to use the proven Lifson crew transfer vehicle design to rendezvous with expendable landers positioned around Iota and Ceti, and to take Kerbals to the surfaces of Iota and Ceti and return them home safely. Each 9.7 tonne "Neil" lander, named after Neil Armstrong, first Kerbal on Minmus, is lofted on an Oz booster, and is powered by a single Sparkler engine fed by MMH/NTO, with four radially mounted droptanks carrying the landing legs. Day 252, 05:37:22: Launch of Lifson 7 After endless testing and preparation, Lifson 7 launched into parking orbit prior to Iota injection. Mission policies called for a reserve Lifson vehicle to be ready, and two Neil landers ready to go in orbit around each moon. Thus, if any single component fails, rescue is still almost certainly possible. Four days later, Lifson 7 captures into Iota orbit, and rendezvous with Neil II at 07:35:09 Jebediah Kerman makes the command decision to alter the landing point; instead of landing at a well-established equatorial zone, with the large fuel reserves available, Jebediah makes a 415 m/sec inclination change to land on the polar Droops of Iota, landing at 08:50. You're lucky we don't have your head for this stunt, Jebediah! This mission cost GSC almost 300 grand! Shortly thereafter, Richemy Kerman becomes the first Kerbal to step foot on a world not Gael in the Ciro system, that the spirit of Kerbal-kind might endure far from our original home, to explore for the sake of all. The statement given by Gilinne Kerman as she debarked upon Iota was "Oh, and this time, we didn't flub our opening line." Shortly thereafter, the crew of Lifson 7 departed the surface of Iota; life support supplies are limited, and there was a transfer window to Iota to meet. I know this is kind of a half-chapter, but the hour grows late, and I have a lot of work to do tomorrow. Now, to needlessly drum up some drama, I shall leave you with the cliffhanger: does the Ceti landing go perfectly fine, or does it end in DISASTER AND FIRE?

Watch for the nearest approach marker, and use it to help tweak your Kerbin ejection and possible correction burn. Otherwise, I generally use MechJeb for precise transfers, less tedious than setting it up manually. Also, curses, I wanted to make the first angel/angle joke.

Had a busy Memorial Day weekend with family, and I wasn't really able to keep up too much with you guys. The highlights: Put Kerbals on Iota and Ceti Discovered a love for IVA docking (at least using some docking mod because I'm not that crazy) Put Pioneer into orbit of Tellumo Landed Tellukhod 1 on Tellumo And, despite intending to put the Tellukhod 1 transfer stage into some sort of orbit of Tellumo to act as a relay, well... I forgot to put a reaction wheel on the transfer stage. Antenna, check, solar panels, check, engines, check, any way to steer the thing... not check (not even engine gimbal). It's currently going out into heliocentric orbit thanks to being able to kinda-sorta steer in one axis by throttling the two outboard engines. I am, at the very least, happy I managed to hack together a kOS script to handle the descent: primarily, collecting temperature/pressure in low atmosphere, locking steering to surface retrograde, and a (not successful) attempt to stage off the heatshield after velocity dropped below 20 m/sec. I'll need to find a better Tellumo entry window, because aiming for 25 km periapsis, I hit 30.6 Gs of peak deeceleration.

A short note: sorry about the delay getting this out, but I had some real-world stuff going on, and now I'm behind again... as will become particularly evident at the Tellumo section. An Updated Planetary Catalog By: Prof. Winkel Vallten, Head of Planetary Astronomy, Lippershey Astronomical Society We at the Lippershey Astronomical Society would like to remind the public that yes, there are 10 planets and a smaller star orbiting Ciro, and our interns in particular that just because the orbital telescope program has not seen a planet does not mean it does not exist. In preparation for launch of the Augustus orbital telescope later this year, we're publishing our most up-to-date catalog of Ciro's planets. Icarus: Ciro's First World Not much is known about Icarus. Named after the myth of a boy who flew too close to the Sun, Icarus is known to orbit very close to Ciro, and is presumably very hot. Atmosphere is unlikely given its small size and extremely close proximity to Ciro. While my colleagues at GSC are reasonably confident about their ability to place satellites into orbit of most of the inner planets, a flyby may be called for with Icarus due to the difficulty of matching velocities with something that orbits so close to Ciro. Thalia: Ciro's Second World The deplorable state of our knowledge about Icarus is echoed with Thalia. Presumably hot, and orbits close to Ciro. Niven: Ciro's Third World Our knowledge of Niven is not quite as atrocious as that of Icarus and Thalia: we can say with reasonable confidence that it is rocky, and any atmosphere is at best tenuous. Plans for a survey of Niven are underway. Gael, Iota, and Ceti: Home While reasonably well covered by our prior publications, my colleagues at GSC are reveling in lunar samples obtained from the Lifson-Armstrong missions. Tellumo: A Strange Terrestrial World We are looking forwards to launch of the Armstrong telescope, which should occur before Tellumo is terribly out-of-sync with Gael. One thing that the Pioneer and Tellukhod missions have revealed is what appears to be a faint equatorial ring orbiting Tellumo, strange for an inner planet. Lili: Tellumo's Small Moon With Pioneer in orbit around Tellumo, we have now confirmed that Lili is the only significant object (except for the ring) orbiting Tellumo. An expedition is planned for the next Gael-Tellumo transfer window. Gratian: An Arid, Duna-Like Planet Not much has been discovered about Gratian itself, but orbital telescopy has helped to resolve its moon Geminus. Geminus: Gratian's Known Moon The sheer degree of similarity between the Gratian-Geminus system and the Duna-Ike system has prompted me to assign one of my students to devise models: perhaps the outermost of the inner planets is usually subject to bombardment by large planetoids diverted by the outer gas giants. It may be a coincidence, but truly a striking coincidence, possibly one that has led to life on Kerbin, Gael, and Tellumo by diverting early-solar-system impacts to itself. Otho: The First Gas Giant Improved telescopy has revealed the presence of a truly gigantic storm, larger than Ceti, moving through Otho's atmosphere. Augustus: Otho's First Moon Large. Brown. Presumably airless. Hephaestus: Otho's Second Moon Repeat observations from new-generation telescopes have revealed, shockingly, that Hephaestus continues to be gray, probably airless, and a moon of Otho. Jannah: Otho's Third Moon The smallest of Otho's observed moons, Jannah is once again presumably airless. Moon X: Otho's Fourth Moon My calculations show that Otho must have a fourth moon, but it has yet proven elusive to telescopes. I intend to name it "Don Quixote". Gauss: The Second Gas Giant While Gauss, Catullus, and Tarsiss have been adequately covered previously, we now have orbital telescopy of its second known moon, Loki. Loki: Gauss's Second Moon My students' jokes aside, Loki did not "trick" us into forgetting to take an image, it was simply forgetting to take an image with my first telescope technical difficulties. Nero: The Third Gas Giant Very distant from Ciro, Nero is the palest of our gas giants. By this point, our current telescopes do a very poor job of resolving anything. Minona: Nero's First Known Moon Minona is small and barely resolvable with current technology. Presumed airless. Hadrian: Nero's Second Moon Not much is known about Hadrian: its albedo is so low that it can be barely distinguished from the background. Hox: The First Dwarf Planet Hox is the first known dwarf planet orbiting Ciro. Due to orbiting over a billion kilometers from Ciro, it is presumed cold, and known to be very, very difficult to get good telescope images of. Argo: Hox's Moon Shown alongside Hox in the above image, Argo is difficult to resolve with current technology, and we know about as much about Argo as we do Hox: very, very little. Leto: The Second Dwarf Planet Barely visible on our scopes, Leto has no known moons. Grannus: The Other Sun Big. Red. Angry. No known planets despite a large amount of searching. This announcement was funded via GSF grant R03-481992, and the Minmus Ice Cream Corporation (TM).

It doesn't matter what the specific language was; none of the words used were particularly mean. The intent of your message, however, was "I don't think Starman4308 can hold a rational discussion because he's too much of a fanboy, as well as everybody else who's trying to argue the point of Squad's limited resources should inform limited expectations." It doesn't matter how you say it when what you say is an unfounded insult. Kindly refrain from insinuating that anybody who disagrees with you is a raging, unreasonable fanboy.

That is an extraordinarily rude accusation to hurl at somebody who simply disagrees with the assertion that they should have had everything in your specific wishlist taken care of in 1.3. I mean, I wish they'd added articulating parts similar to Infernal Robotics, made some rescaled heightmaps for upscaled systems, rationalized and rebalanced their parts, etc, but I can at least recognize what's never going to happen (rescaled heightmaps), what's probably economically infeasible (adding robotic parts), and what they might be able to get around to when Squad's tiny remaining staff has the time (rebalancing parts). There are a large number of things that the players want Squad to do. There are a smaller number of things Squad wants to do. There are even fewer things Squad can reasonably do. There are even fewer things that they can do that might also make Squad (a business) additional profit. From there, Squad must prioritize features based not only on how much players want them, but also whether they have any expertise in the matter, whether it will bring them additional money, and whether it will cause them headaches keeping it maintained down the line. Turns out, what they prioritized this time was localization to new languages (potentially bringing in many new customers) and squashing a number of bugs. Better luck next time, maybe they'll address things on your wishlist.