Starman4308

To clear up any confusion: for the purposes of this story, it now starts on Year 301, using Earth years (because that's what my game clock displays). Year 301 is still the "first year" from the OP. Contract Law, or "Check Contract Deadlines for Impossibilities" Year 301 Early in the year, we've invested in a more sophisticated mission control center to coordinate the plethora of commercial contracts coming our way. We now wish we'd invested in a lawyer, and more importantly, an intern to check the fine print. The contract parameters: send up a bulky, awkward 1-ton telescope to Gael orbit, before we've even launched an exploratory probe to orbit. Deadline: 50 days from realizing we needed to get cracking on it. The largest, most sophisticated booster yet was designed to load this awkward payload, scraping the 18-ton limit the engineers had established on the launchpad. Fueled primarily by kerosene and high-test peroxide, along with two SRBs, it had the theoretical delta-V to reach orbit. It failed, miserably. The technical team was still struggling to come up with an effective payload fairing, and without fairings, the telescope was just too big, too draggy, and caused far too much instability: the Range Safety Officer was forced to terminate the flight less than thirty seconds in. This has left us in a tight spot, with less than 50,000 roots worth of funds, and the primary assets being under-construction Kerbin-program vehicles slated for tourism missions. Back to the grind. Year 302: Orbital Infrastructure With the first year of the Gael Space Program behind us, it's time to take stock. We still haven't gotten to orbit. We finally have a little bit of cash from tourism missions. It's time for the GSC to go to space and stay there. Project Hermes: The Relays To establish a basic presence in space, one of the first steps was to establish basic relays to low Gael orbit. A series of four basic satellites equipped with the GSC's first space-rated PV arrays and lightweight omnidirectional antennae were sent into roughly geosynchronous orbits around Gael, one that still serves today, despite their basic construction. The orbits are not truly geostationary, possessing about 8.6 degrees of inclination; this was in part due to the Rearguard OMS engines, which could only be ignited four times. Project ROSO: Return of Science from Orbit To prove ablative heatshield technology, a simple orbital mission was devised, one that would achieve orbital velocity and immediately brake retrograde, as the batteries would last only a half-hour. It started well. It ended in fire and disaster, as it moved past line-of-sight from GSC ground antennae, and engineers overestimated the reach of the onboard low-gain antenna, which was incapable of reaching the Hermes relays. Without a control signal, propulsion was lost, and the commands to arm parachutes and separate from propulsion were never sent. ROSO II had a bigger antenna.

With great difficulty. I think there was a tool called KSP-TOT or something like that for detailed mission planning. It's a very non-trivial problem. For the case of a Mun flyby on the way to Duna, if you don't mind a distant flyby, you could delay your transfer for a few orbits until it grazes the Mun's SOI, though the closer the Mun is, the harder it'll be to fine tune the maneuver to stay on course to Duna.

I'm pretty sure Mono is the engine-over-the-engine on which Unity is running*. If mono.dll is crashing, it's probably either because you have a corrupted version of mono.dll (in which case you either use Steam to verify files, or re-install KSP), or that something is throwing an exception that is never caught, leaving mono.dll to say "okay, nothing caught this, time for me to shut everything down". In any event, standard debugging applies: upload the logs somewhere, and try to narrow it down to the minimal set of mods causing the error. *My understanding is that Mono is an implementation of the C# language, providing a VM for its execution.

Okay, that gave me a chuckle. I installed the Star Trek Kerbonaut uniform pack mostly out of boredom, though I rather like them. As to Klingons... maybe they're out by Grannus, the giant red maybe-a-gas-giant-maybe-a-red-dwarf? Speaking of, dangit contract system, don't give me contracts for Grannus. It's about 4 Tm away from Gael at closest approach, and my biggest dish has a whopping range of 288 Mm, barely enough for operations in the Gael system*. *Though I did substantially buff the ground antennae to 200 Mm, 20 Gm, and 960 Gm for level 1/2/3 tracking stations, and with the square-root rule, I can reach out to Ceti with even the wimpy little always-on ascent antennae. It just seems silly to me that ground stations could barely reach out to Gael's moons (as configured in default settings), when realistically, the Deep Space Network has the biggest, most ludicrously powerful radio antennae out there. After all, what's cheaper, putting a 30m dish here on Earth and hooking it up to your local power station, or putting a 30m dish onto the New Horizons probe?

First, I started a mission report thread: Second, landed on Iota and Ceti: the landers are relatively minimalistic, just lightweight science parts that can be used for transmission. Got three contracts in one with this probe: I finished a "satellite in specific orbit" contract, a "test radiator in suborbital fight over Iota" contract, and a "impact Iota with at least 265 MJ of energy" contract. I'm pretty sure I only built it for the "test radiator" contract, and the other two were just gravy. The Reentry Particle Effect can lead to pretty spectacular reentries, especially if you have a service module burning up in the background. Right now, I'm finishing up on putting polar communication networks over Iota and Ceti: the idea there is that by having them in relatively high polar orbits, I can cover the vast majority of the surface, with only small equatorial dead spots that A, move as the moons orbit under that network, and B, are sometimes covered by direct communications to Gael anyways. That, and endless "rescue Kerbal from Gael orbit" missions have taken up a fair amount of time, although I'll be getting back to exciting things soon.

Hello fellow KSPers. Inspired by @CatastrophicFailure's Alien Skies story, I'm running a career in Galileo's Planet Pack at 3.2x scale, deliberately not looking up anything about the planets. As a request: please don't spoil anything about Galileo's Planet Pack. I'm coming into this blind, using a combination of CactEye telescopes and probes to figure out what the system is like. Other key mods: FAR, Real Fuels-Stockalike, TAC Life Support, Kerbal Construction Time, Karbonite (with some custom Real Fuels configurations from some prior 6.4x stock system work), kOS, RemoteTech 2 (currently no communcations delay; that may change if I feel brave), and plenty of other mods. Funds rewards are set to 120%, science rewards to 40%. Note that the early posts are going to lack specific date information and even the year information will be outright guesses, but I'll try to keep better track in the future. Now, onto the good stuff The Astronomers of Gael The First Year: The Climb to Orbit Ciro shines upon us, as the Gael Space Center is finally established. It has been three centuries since the Transplantation, a mysterious event that brought our ancestors here from a world named Kerbin, a world much like our own. Fortunately, it also brought food, a library, many tools, and for some reason, the Kerbin Paper Airplane Museum. We now seek to go to the stars. Our ancestors suspected the Ciro system is in the same galaxy as the Kerbol system, and the answers of how we got here, whether there are still Kerbals on Kerbin, and why the food included RTG-powered freezers full of Minmus-themed mint ice cream await us in space. If the Transplantation was the work of a higher power, clearly, it has a sense of humor. Sounding Rockets to Space Before more complicated missions could be carried out, the Gael Space Agency was tasked with something quite simple: "how high is the atmosphere?" Our early missions peg this world's Karman line at about 98 km, as well as carrying out valuable experiments, such as exposing samples of several proposed propellants to vacuum (no surprise that the liquid oxygen boiled out). No van Allen belts were detected by this early effort, though they probably exist courtesy of Gael's magnetic field and the fact that we haven't all died of cancer. Program Kerbin: Suborbital Manned Flights The Kerballed project begins with relatively simple 1-Kerbal capsules mounted on 6-ton solid rocket boosters. Initial conclusions can be largely summed up as "yep, we can still go to space and zero-gravity, much like our ancestors did with their space program". However, the photographs delivered by Jebediah Kerman have been widely distributed, and the Gael Space Program has a line of tourists paying for suborbital hops... and the actual space program.

One possible minor issue is that it would change the layout of KSC, which is largely assumed fixed. For example, the default launchsite in Galileo's Planet Pack is on a fairly small island, so there may be some Fun (TM) to re-configure those launch sites if it changes the area of KSC. Granted, overall I'm in favor of the idea; while personally I'd probably have it as a static object next to the runway ("launch" rover from the runway, drive off it a short distance to the rover test range), it'd be nice to have something with a variety of slopes and grades close to KSC*. *And don't get me started on the "just drive to the grasslands" bit if you're playing on 6.4x.

Um, if it helps, this is what I'm running for visual mods, I'm running Scatterer with defaults (some GPP-specific stuff as described in the GPP manual), and Distant Object Enhancement with stock configuration. I haven't installed SVE or SVT for fear of clashing with GPP.

Sounds like maybe garbage collection? In that event, a possible fix (assuming you have the RAM to contemplate it*) is to use MemGraph to pad your heap, and force less frequent GC pauses. *8 GB or more. Generally: you won't get much improvement in KSP frame rates by reducing graphical settings. KSP is a lot more CPU-heavy than most games, so quite often, it's the physics calculations that are the bottleneck, not the GPU rendering frames as it is for other games. Your GPU can be entirely capable of rendering 200 FPS, but will sit idle most of the time if the CPU can only chug through the physics for 10 frames per second.

To go along with DOE (Distant Object Enhancement), you might want to pick up CactEye telescopes. Image of a couple moons from GPP (Galileo's Planet Pack: over-writes the stock system) Another note is that Texture Replacer can replace the stock skybox*; I'm using Pood's Milky Way Skybox. *The distant stars that are fixed in the background.

First off: CactEye is wonderful, and the people who've made and maintained it are wonderful. It fits in perfectly with my current GPP playthrough. Got my preliminary comm network up: with the primitive technology available (max of 4 restarts, no RCS), the best I could do was a geosynchronous network with about 8 degree inclinations, not particularly coordinated. At some point, I'll want to replace this preliminary network with something more substantial. Had my first orbital reentry fail on account of forgetting that no, the little antennas can't reach my geosynchronous network, something that will be rectified with the second flight (which will have more powerful directional antennas pointed at active vessel). A fixed-wing aircraft mission kinda-sorta worked, although I'm not going to try repeating it until I have a level 3 runway which is smooth enough to take off of. Valentina was the first Kerbal to orbit, returning a large number of EVA reports from space just over all of Gael's many biomes. I've offloaded some polar launches to a site near the poles: I think this was a mapping satellite. My first slingshot around Iota was a complete success, with low-orbit science collected via dint of mapping all the instruments to the lights action group, and writing a kOS script to hit that action group at periapsis. I've got to say: I like the look of this moon. The first telescope I launched has returned images from many of the celestial bodies, and I've got to say I love it. I'm going to have to figure out how to set the controls really fine, though, because these were all done via MechJeb pointing. I'm wondering if I should start a thread for this in Mission Reports: I'm not quite able to come up with a cohesive story that I like, but maybe just talking about how I'm going about things, and the process of discovering and understanding the Ciro/Gael system might be fun for people. EDIT: Also: all images taken at a max of 1024x zoom with the first-level wide-angle camera. Looking forwards to the higher-level cameras; some objects I outright couldn't see.

-1 and NaN are distinctly different things with distinctly different meanings. If you got one vs. the other for the result of a speed calculation, that means your code broke in different ways. A value of NaN is what should probably be outputted if there is clearly an invalid input/output*, but a programmer may not explicitly check for that, because there is no way that value can ever be achieved with valid inputs, and adding a check for -1 means A, a coder wasted his time checking for that, and B, your CPU is wasting time checking that if condition. *Though what I would actually probably do is throw a descriptive Exception. A computer doesn't think about its result, it cannot realize "oh, hey, -1 m/sec is clearly impossible, let me just change that to NaN or an exception-throw instead"; the coder has to check for that nonsensical condition and change the output accordingly.

It doesn't matter if -1 is nonsensical. If the calculation somehow comes up with -1 meter of distance, it will display -1. A NaN value has a specific meaning, that of "either you tried to convert the world salad into a number, or you are too large to hold in the chosen format, or the math is invalid, such as divide by zero."

I think (though am not sure) that sun-synchronous orbits are impossible even with Principia, since Principia's main thing is N-body gravitation, and precession is caused by non-uniform gravitational fields (mostly: planets bulging at their equators). You can do N-body gravitation with point masses without modeling precession and non-uniform gravitational fields, and I suspect you can do non-uniform gravitational fields (and thus precession) without N-body gravitation. As to how to cheaply get into a polar orbit: the best way is to set up your transfer (or set up a small correction burn while still far from the destination) to pass over the poles. If it's too late for that, usually your go-to methods for large inclination changes are either to use gravity assists from moons, or to use a bi-elliptic transfer (raise your apoapsis to near the edge of the SOI, adjust your inclination there, bring it back down at periapsis).

For you, 8 km/sec was the fastest, most hair-raising reentry you've ever performed. For me, it was Tuesday*. *8 km/sec is a bit less than lunar reentry speed at 6.4x scale, which is what I've mostly played at. For the RSS players, it's LEO reentry speed. I'm not sure I'll take this challenge on, but there are multiple ways to do it. #1: Bi-elliptic transfer. Eject straight from Kerbin orbit out to a very elliptical heliocentric orbit: then, at apohelion (Sun apoapsis), reverse your course, and you've done the plane change. Granted, you're going to have Fun (tm) at your new perihelion, bringing your apohelion down to something that you can reasonably use to rendezvous with Burbarry, and then Fun (tm) again going for another bi-elliptic back into prograde solar orbit. #2: Bi-elliptic transfer with gravity assists. Ignoring the fact that you're leaving poor Burbarry alone in a capsule for years, this would be how I'd approach the problem, probably trying something like Kerbin->Eve->Kerbin->Jool->apohelion reversal->Jool->Eve (with a braking maneuver at Eve) -> Burbarry -> Eve -> Kerbin -> Jool -> apohelion reversal -> Jool -> Kerbin/Eve braking -> Kerbin return. Doing the big burns in the SOIs of Eve and Kerbin gives you some benefit from Mr. Oberth, because X velocity added or removed inside their SOIs can translate to more than X added or removed once you escape their SOIs. Granted, that's a vastly more ambitious set of slingshots than I've ever actually pulled off. #3: Massively staged nuke/ion spam: a brute force approach. #4: Playing a fun game of gravitational ping-pong inside the bounds of the Kerbol system, which is most of Cpt Kerbalcrunch's strategy.

8-16 GB of RAM (mostly for mods), and either an overclocked Core i5 or Ryzen CPU. Graphics are minimal, it's mostly a single threaded CPU thing... and due to the nature of rigid body physics, there will be no panacea for slow framerates with many parts on your vessel. SSD might help loading up the game, particularly if you run many mods, but should have little impact on gameplay. In short: CPU single thread performance is key to KSP framerates with large vessels.

Kinetic energy that you have from going down. Down is the enemy, because up is the enemy. The ideal is a Hohmann transfer to 0 altitude circular orbit followed by instantaneous cancellation of surface velocity. Any thrust applied upwards is waste. Any downwards velocity you let accumulate requires upwards thrust. In a suicide burn, you're letting some downwards velocity accumulate early in the burn that you have to cancel later. I suppose you could think of it as this: in a suicide burn, you don't start pitching over until relatively late in the process, plus you have to start with a periapsis above the landing altitude, incurring gravity loss, whereas a constant-altitude descent, you start pitching over almost immediately, but you wind up not having to pitch as far up because you've never let downwards velocity accumulate. If you're burning pure retrograde, that is inherently the instantaneous local optimum for eliminating energy. It kind of builds suicide burns into being a greedy algorithm, because while there is no better way to shed your kinetic energy at that precise moment, you can cause yourself larger problems down the line.

Do note that I'm not the one who came up with the theory, but my guess: With infinite TWR, constant-altitude and suicide-burn descents are identical: a Hohmann transfer down to the desired altitude, followed by an instantaneous cancellation of horizontal velocity. That is the ideal, that you cancel out excess gravitational potential energy with Hohmann transfers preceding descent, and the "descent" is just about killing horizontal velocity. Granted, none of this quite works out when you start dealing with things like "terrain", but the theory has to make some simplifications. With finite TWR, you're always going to need to expend some extra delta-V perpendicular to the direction of travel to avoid smacking into the ground, although both do a good job of burying a lot of that via the magic of trigonometry. With a constant-altitude descent, this is pretty easy to see: as you start to pitch up to maintain altitude, your gravity losses are basically cosine losses from not burning directly retrograde. With a suicide burn, it's slightly subtler, as while you're always burning retrograde, effectively a local optimum* for eliminating unwanted kinetic energy, some of that unwanted kinetic energy is a side effect of earlier in the burn, as you were eliminating horizontal velocity without taking care of the vertical acceleration it would induce. *Which is why I suspect an idealized suicide burn boils down to being a greedy algorithm. Effectively, while constant-altitude is not eliminating your horizontal velocity with perfect efficiency, you avoid causing unwanted vertical velocity that you need to deal with later, and via the magic of math that presumably works*, it can be shown that the cosine losses of maintaining 0 vertical velocity is preferable to suicide burns, where you must start from a higher altitude, and generate some vertical velocity that you don't deal with until later. *Unfortunately, the linked post's proof is no longer available. I know I've seen at least one other forum topic about it: wish I'd kept the link to it. I think I vaguely understand the concepts, but otherwise I'd need to do that math myself.

This is not a helpful suggestion. The developers are already aware that people want performance, and have already done several code optimizations. Anything major from this point likely entails writing a custom physics engine, which is an extraordinarily expensive task. Now, if you had something specific, like "I found some API for a development version of Unity that will let you run much more in pure double precision without endless conversions back and forth", then you might have a point*. *Note: I do not know of such a feature, or if it was implemented already at some point.

Not yet sold on that mod; A, I already have enough mods with development-only releases, and B, I'm not sure it fits what I'm going for, which would be that, while it's trivial to find most of the planets with a bit of telescope work from Gael, it might not be easy to find details like "does this planet have an atmosphere, how does that atmosphere behave", etc, which I'm implementing via self-restraint and actual scientific missions, as in "actually look at it with a CactEye scope, watch the thermometer and barometer on descent, read the science messages for once, and when in doubt, chuck an expendable probe at it." To be fair to Near Future, the specific impulses on its ion drives are quite plausible. The thrust isn't, but unless you want to leave KSP running for weeks to complete a burn, that's something you'd just have to accept. Alternately, Starwaster's Heat Pumps mod will enable ZBO (Zero Boil-Off) missions with cryogenic propellants for nuclear thermal rockets.

Abandoned my new 1.2.2 6.4x scale playthrough, because @CatastrophicFailure just had to put the idea in my head of a Galileo's Planet Pack playthrough without looking up any of the planets, just a straight-up, blind exploration deal. Thanks Catastrophic, now there are a bunch of tourists who will never get their Moon flybys thanks to you. The new settings are: 3.2x scale with Real Fuels-Stockalike*, GPP (obvious), 40% science/120% funds, deliberately not looking very hard at the tracking station until I have telescopes up, RemoteTech instead of CommNet, TAC LS, FAR, and a whole mess of other mods. *Decided to drop down a bit from 6.4x; I wanted to spend a bit more time doing what I want, and less time figuring out how to deal with the relatively immense delta-V requirements. Some of the early flights determined that Gael's atmosphere was basically dead-on a match for Kerbin, and captured a beautiful shot of Ciro Aaand the first sounding rocket to breach the Karman line, well, it may have a liiiitle bit fallen onto the mountains just west of the GSC (Gael Space Center). Right now, I'm mostly just running suborbital tourism missions, which are basically "Mk. 1 capsule and a sounding rocket probe core on an RT-20 SRB*". *From Ven's Stock Part Revamp, basically an RT-10 Hammer stretched out an additional 50%. That is in no small part to recoup losses from this contract, which I foolishly accepted without taking a close enough look at the completion deadline... and with my KCT settings, there was no way to get a 1-tonne telescope up to orbit in time. I tried a last-minute Hail Mary with the biggest booster I could devise, but the aerodynamics simply didn't work out without having a fairing to put over that hideously asymmetrical telescope. I'll have to scrape up some science from somewhere; I need about 15 more to get basic fairings, after which point I can really start setting up some orbital infrastructure. Maybe I can send brave Valentina on a short suborbital hop westwards to obtain EVA/crew reports from west of the mountains...

It may also be a small sop to making aircraft lighter*. One thing KSP fails to model is the difference between a vacuum-proof crew cabin for use in space, and aircraft cabins, which are generally not airtight and sometimes not even pressurized. *This leads to "fun" like cockpits being heavier than many real-world aircraft. The capsules aren't too terribly bad mass-wise, but cockpits are made awkwardly heavy so that they aren't absurdly unbalanced against the capsules.

Nope. I'm pretty sure the theory boils down to kinetic energy and the Oberth effect, that by allowing negative vertical velocity to build up, you're going to need to deal with it later by spending excess delta-V. That said, for high TWR and small bodies, I'm pretty sure constant-altitude and perfect suicide burns come pretty close to each other.

That isn't strictly speaking 100% true; I'm pretty sure the maximally efficient descent profile is a constant-altitude descent, where you start pitching up to keep your vertical velocity at 0. Of course, this means you're skimming over the terrain at a scarily low altitude, and an ideal constant-altitude descent is outright impossible if there is any terrain higher than your landing site between said landing site and where you begin your burn, but the concept remains roughly the same: by keeping your vertical velocity under control, you can minimize gravity losses during descent, because you're not picking up large amounts of kinetic energy in the downwards direction*. What I usually wind up doing is a half-eyeballed sorta-constant-velocity descent where I try not to let my downwards velocity get too large; I generally also keep an eye on the MechJeb suicide burn indicator. If the MJ suicide burn indicator is negative, that means you're probably doing it right. If it's too negative, however, you may want to consider pointing your vehicle straight up before you slam into terrain. *Oberth, etc. @Ncog Nito Again, congratulations. Not unexpected that direct ascent winds up better at the stock scale. The theoretical basis for lunar-orbit-rendezvous missions is that you get to leave the propellant to return home in orbit, at the cost of having a separate landing vehicle (entailing some duplication of parts). The problem in stock is that it's much tinier than the real world, so delta-V requirements are much smaller, so direct ascent costs you much less, because you need so much less return-home propellant. If you ever get tired of that, try installing Sigma Dimensions and up-scaling the system a bit, possibly using either SMURFF or Real Fuels to bring fuel tanks and engines closer to reality as well*. *Stock engines have poor TWR, specific impulse consistent with very good kerolox/methalox engines, but throttle and restart perfectly. Stock tanks are ridiculously heavy relative to the contained propellant, but the fuel is absurdly dense and doesn't have issues like boiling off or any of the other 5,439 complications that come with real fuels.

So, you're running this career after deliberately not looking up anything about GPP, so that it's all exploration and discovery for you, a fresh start with no prior knowledge to contaminate the discovery process. PЦҬЇЍ. I'm not going to be able to read this story until I have that running too. See you once I've caught up!