soulsource

I time warped until a transfer window to Jool opened, and sent off two probes and a crewed ship. The probes are for Tylo and Jool, the ship is going to Laythe. The probe for Jool is meant to dive into its atmosphere, send back some science data (not that I'd need it any more...), and then explode at some point. Maybe I'll even install some visuals mods especially for this occasion, although my PC has a hard time handling those... The probe for Tylo is my first attempt to land there. I was thinking about a crewed mission, but in the end I didn't want to risk my Kerbals' lifes in a mission with such uncertain outcome. Anyhow, it was really fun to design the Laythe mission. First, I realized that my calculation of the dV requirements for going directly into a moon's SOI without circularizing around its parent body first was quite a bit off, so I fixed the formulas, and now going to the Joolian moons doesn't look as frightening as it did before. The single-launch ship including lander became quite a behemoth still, so I (again) switched difficulty options to allow reverting. I needed it, as the craft had a horrible tendency to spontaneously disassemble when the physics engine kicks in, until I added more launch clamps, and took care to make my ship not only have a four-fold rotation symmetry, but also to have two mirror planes... Now all three crafts are on their way to Jool. Ah, and KSP nearly ruined my mission to Eeloo. After sending off my crafts to Jool I realized that there was a ship in Jool's SOI though the only craft I had sent there up to now was orbiting Pol. It turned out to be my crewed ship heading for Eeloo. KSP didn't show the Jool encounter on the map when I last had that vessel active, so obviously, now that it indeed did have an encounter, the unplanned "gravity assist" of Jool messed up my carefully planned trajectory... Good though, that a burn of just about 50 m/s will fix this again, but if I hadn't realized, the ship would have missed Eeloo by quite a bit...

Reputation determines how difficult and lucrative the contracts are that are offered to you. The wiki also states that it has an influence on the number of contracts that are being offered. http://wiki.kerbalspaceprogram.com/wiki/Reputation So, if you think that the contracts you get are too hard, better reduce reputation. If you only get contracts that aren't paid well, try to increase it.

For rendezvous, you're going to need Kepler's third law: All orbits that have the same semi-major axis have the same orbital period, and the square of this period is proportional to the cube of the semi-major axis. As an example: If the craft you'd like to meet is about ¼ of an orbit ahead of you at the intersect, you'll need to accelerate or decelerate at the intersect in such a way, that your final semi-major axis is times the semi-major axis of the other craft in order to catch it within one orbit. If you want to rendezvous after 2 orbits, it's of course not (1-¼), but (1-⅛) in the first bracket and so on and so forth. In order to get the required delta-V, have a look at Wikipedia's excellent article on Hohmann transfers, which not only gives you all the formulas, it also explains the derivation. Or, if you are in for a fun little exercise, derive it yourself. Here are some hints if you don't know where to start:

I know it's off topic, but for future reference: The log file is at a different location depending on operating system: On Linux it's in "~/.config/unity3d/Squad/Kerbal Space Program/Player.log", where the "~" character denotes the user's home folder. On OS X it's located in "/Users/$USER/Library/Logs/Unity/Player.log" . Last, but not least, on Windows it's being written to "KSP_Data\output_log.txt" in KSP's installation folder.

I'd never make low orbit, instead I'd go on a very excentric elliptic one. A bi-elliptic transfer, to be precise. I didn't run the maths (and am too lazy for such a crazy endeavour), but I'm quite optimistic that by this you might be able to get your PE inside the "atmosphere" of Kerbol without using infinite fuel. As heating will have to be disabled anyhow (at least I think there's no way to cool your craft sufficiently to survive being close to the sun...), you can just as well aerobrake.

That's to be expected, as all pointers (variables pointing to memory addresses) will take up - drum roll - 64 bits instead of 32. I've managed more than once to drive KSP to my physical memory limit on Linux, and although I have a whole partition dedicated to swap space, KSP didn't even dare to touch it. Of course a lot of other stuff that was running on my PC as well had been swapped out, but KSP itself remained completely in physical memory at all times.

I'm of course looking forward to 1.1, and of course I'd happily install the Beta version would it be available to me. As an engineer I see the advantages of using Steam's content delivery system (a well distributed network of servers all around the globe) over offering frequent updates from one's own website, so I'm not upset at all. Also, I agree with those who already mentioned that our experience with 1.1 will not be spoiled by the bugs that have been found and fixed during the beta.

Maybe Buzz Aldrin's Race into Space, or it's successor Buzz Aldrin's Space Program Manager?

Thanks for the confirmation!

Would someone be so nice as to explain how those numbers are being calculated? I tried to reproduce the table and got different results... My calculation yields an optimal orbital radius of 2*GM/dvH2, where GM is the standard gravitational parameter of the origin body, and dvH is the delta-v of the first burn of a Hohmann transfer (without taking into account Oberth effect) between the two bodies. With this formula I get for instance following optimal ejection altitude (meaning: radius of Kerbin already subtracted) for a trip starting from Kerbin (Unit: km): From/To Moho Eve Duna Dres Jool Eelo Kerbin 681 11043 7777 1021 360 209

I'll just quote a posting of myself, where I quote myself: Edit: What I didn't mention in the previous post was why one can sum energies but not velocities. That's because in a gravity field energy is a constant of motion, while the velocity obviously is not conserved. Sorry if this sounds confusing, but I'm trying to make clear that you cannot directly add a velocity change done far away from a planet to a velocity change close to the planet, as between the maneuvers your velocity will have changed due to the movement through the gravity field which requires a certain amount of work (in that case kinetic energy). The total energy - your kinetic plus your potential energy - is conserved though, as gravity is a conservative force, so you can indeed sum up energy changes done at different positions within a gravity field. Edit 3: If you just want to enter orbit around a planet and stay there forever or leave again towards the same planet you came from, there are optimal altitudes: Edit 5: I've been checking these numbers, and either the formula I derived in Edit 4 below isn't correct, or those numbers are outdated. I'd therefore recommend to recalculate them when you need them. If however you want to land, you're better off going directly to a very low parking orbit, as it's more efficient to do that than first going to the "optimal" orbit and then decreasing your orbit's radius. Edit 4: A few words on how those optimal altitudes are calculated: You can just take the formula from my post I've linked to above (m*(v0+dV0)2/2-GM*m/r=m*dVh2/2), and insert the orbital velocity v0 (which can be obtained by setting the force of gravity and centrifugal force equal) and then solve for the burn's dV0. The dVh value in this formula is the first burn of a Hohmann Transfer. What you get is dV0 as a function of orbital radius. All that's left to do is to find the minimum of said function, for instance by setting the first derivative zero. The result should be given by rideal=2*GM/dVh2 (where GM is the standard gravitational parameter of your origin body, typically Kerbin) - at least if I didn't make any typos while hacking this into my calculator...

If it's with the old, no longer maintained proprietary ATI drivers (fglrx aka. Catalyst, aka SirCrashAlot): I'd suggest not to worry too much about it. They are legacy drivers (I wrote ATI on purpose as they are their legacy...) after all, and will not be supported by future (and some current) Linux distributions anyhow (for instance Ubuntu 16.04, Debian Jessie with Gnome 3, Arch Linux and probably Linux Mint Sarah). There are currently two official AMD drivers available, both under active development: The currently recommended [1] drivers are the open source stack (radeon or amdgpu DRI module, combined with radeon or radeonsi OpenGL drivers). They are at the moment still a few extensions away from OpenGL 4.5 and have no Vulkan support as of yet, but support Direct3D 9. The other driver is the hybrid stack, using the amdgpu DRI module, and the closed source OpenGL driver known as AMD GPU Pro, which is currently in Beta testing, and also doesn't yet support hardware that's not at least GCN 1.1 (officially GCN 1.2, with GCN 1.1 being experimental), but GCN 1.0 support is planned eventually. Performance is slightly better than with the open source stack, and the hybrid stack has superior OpenCL functionality, supports OpenGL 4.5 and Vulkan, yet doesn't support Direct3D iirc. So, while currently about half of the Linux AMD gamers still run fglrx (I didn't expect that there are so many masochists [2]...), I'd predict this number to decrease dramatically within the next few weeks/months, when Ubuntu 16.04 and Linux Mint Sarah will be released. Due to this, I'd consider it acceptable if KSP works well with the open source drivers and AMD GPU Pro but not with fglrx. To only support AMD GPU Pro (and not support the open source drivers) would be a bad idea though, as AMD is still selling GCN 1.0 hardware as new (namely the R7 350, R7 370, and R9 370X). I'd really love to help test 1.1 on the radeonsi drivers, but sadly I bought KSP through the store, and am too parsimonious to buy it again on Steam just for testing a prerelease version... [1] If you are wondering why I'm linking to a forum post by "some random guy on the web" - that guy isn't random, it's John Bridgman from AMD, as one can rather well confirm by looking at other posts from the same account. [2] Or, maybe, there are so many people who require OpenCL image support or certain OpenGL extensions not available with the open source drivers on GCN 1.0 or Northern Islands hardware... That's pretty much the only sane reason I can think of to suffer the horrible mess fglrx is, especially now that the open source driver is nearly on par regarding performance...

Ok, so it's not me going crazy, but indeed it might be a bug. Thanks!

Hi everyone! I'm just wondering if anyone else has encountered this issue (I'm still playing 1.0.5): I had accepted two contracts of the grand tour type - one of them asking for the "Eve 3", the other for the "Ike 3" (if I remember correctly) challenge. The first contract asked for a flyby of Eve, Gilly, and Duna, and the second asked for a flyby of Mun, Duna, and Ike (again: iirc, I'm busy at work right now ). So, of course, I sent off an ultra-light probe to visit all of those destinations. Easy-peasy. The strange thing was, that although I still had plenty of time to finish the contracts, and although I'm absolutely certain that none of my craft did visit all the mentioned locations, both contracts suddenly moved from "Active" to the "Archive" and were marked as "completed" (as opposed to "failed" or "aborted"). At this point, the craft I wanted to use for the contracts had passed by Mun, and had reached an orbit around Gilly, from where it should have continued to Duna at the next transfer window. Even more funny: When looking at the "completed" contracts only the "Flyby the Mun", "Flyby Eve", and "Flyby Gilly" parts were marked as "complete", the other goals were still labeled as being "incomplete". Just before I noticed that said contracts had been marked as completed, I had landed another craft on Ike and then switched to the probe planned for said contracts in Gilly's orbit using Kerbal Alarm Clock. So, I could imagine KSP getting confused by my switch from a craft that had performed a flyby of Duna and Ike directly to a craft that had done all other flyby contract parameters (without going through the Space Center scene). As said, just asking if anyone else has seen this, as it was quite easy to mark the contract as active again by editing the save file.

If I'm seeing the screenshot right, you're using a pair of Tri-couplers. Probably it has become obvious to you meanwhile, but in such a case only one of the three connections will be linked by the editor. To be more precise: The editor will always just make one connection when placing a new part. That makes certain constructions (rings, pairs of Tri-couplers,...) impossible without using struts as reinforcements or without using docking ports that make a connection after putting the craft on the launch pad.

It's also possible to install Linux to an external HDD or USB drive, so you don't need to touch your internal HDD at all. I don't know how well this works when using (U)EFI (as all my computers are so old, they still use BIOS based firmware), but with BIOS (or BIOS compatibility mode in (U)EFI, often called "legacy mode" or "CSM") you can simply install the Linux bootloader to the external disk's MBR, and tell BIOS to boot from it (but beware: the ubiquity installer used by Ubuntu and I think also Mint will only ask you where to install the bootloader if you use manual partitioning).

It doesn't matter which guest operating system you are using, gaming inside a VM will always yield terrible performance, mainly due to partially emulated graphics. The only way around would be to pass through the PCIE GPU to the guest OS, and as I don't use Windows, I have no idea if this is even possible there.

You can just right click the tanks of the stage in question and remove the fuel to get the dry mass of said stage. Still, that's rather inconvenient and gets annoying as soon as you deal with a bigger multi-stage craft. Also, it's pretty easy to forget to refill a tank before launch... And no, Delta-v and acceleration are two very different beasts. Delta-v is what you get when you accelerate for a certain time, or mathematically written: , where a(t) is acceleration at time t, t0 is the time when you start to accelerate, and t1 denotes the end of acceleration. For a constant acceleration a=const, this formula simplifies to . And since nobody cared to write the Rocket equation down yet, here it is, in all its gory glory: Or rewritten, to give Delta-v: The derivation is actually pretty straightforward, and follows directly from the conservation of (linear) momentum. During the burn, the rocket expels mass at a given rate, and at a given exhaust velocity. Observed from an inertial frame of reference (a frame of reference that itself isn't subject to any acceleration - this makes calculations a lot easier, as accelerated frames of reference would require us to take into account fictitious forces), the momentum carried away by this expelled material is given by where vrocket is the rocket's velocity at time t, vexhaust is the velocity relative to the rocket at which the propellant is expelled (assumed to be constant), and dm/dt is the mass flow rate (in mass units per time, for instance in kg/s if one is using the international system). This means that the rocket's momentum has to change by the same amount: Now using the product rule of calculus, we get: Of course the change of mass of the rocket is just the negative value of the mass flow: This gives: what can be factorized to yield This can now easily be integrated, as on the left hand side we just have the rate of change of v(t) divided by a constant, and on the right hand side we have the rate of change of m(t) divided by m(t), what is, as one learns in basic calculus, just the rate of change of ln(m(t)). What is now missing to get the form of the Rocket Equation given above, is that the specific impulse is just a way to measure exhaust velocity in a unit that is part of both, the international unit system (as used by NASA) and the old unit system (used by some of NASA's component suppliers). It's related to the exhaust velocity simply by , where g is the gravitational acceleration at sea level of earth (measured in whatever fancy units one uses). Edit: On the use of Delta-v in spaceflight: One cool thing about gravity is that it's proportional to mass (F=G*M*m/r²), the same mass that's responsible for inertia. This means that in Newton's equation of motion (F=m*a) the mass of the craft cancels out. A consequence of this is, that no matter how your craft looks like and how heavy it is, if it has a certain velocity and position (both as vectors, meaning magnitude + direction) within a gravitational field, its path is defined. Therefore, the flight path of a craft can be perfectly reproduced with any other craft by changing the velocity in exactly the same manner (magnitude+direction) at exactly the same points. So, when planning a mission, one first sums up (the magnitude of) all velocity changes (Delta-v) required for the trip. Once one knows this sum and has the desired payload, one can start dimensioning the required fuel tanks using the Rocket Equation. As Delta-v is such a useful quantity, certain diagrams, known as Delta-v subway maps, have been drawn: Delta-V map for the Kerbin System Delta-V map for the real solar system The values for transfers between planets/moons are more or less exact, the values for landing/launching are based on experience, as the actual numbers depend on your craft design (TWR on non-atomspheric bodies, while on bodies with an atmosphere atmospheric drag will also play a role). It's also not too hard to calculate those numbers yourself. The transfers themselves are calculated as Hohmann transfers, and one also has to take into account Oberth Effect. Edit 2: I just realized that the terms of use of the service I'm using to render the equations require a link back, so, if anyone else would like to write LaTeX equations online, have a look at their website: http://www.codecogs.com

I'd say: Wait until you have a transfer window, and then, at the right time of day (¼ of a day - 1.5 hours - after or before midnight, depending on your target) launch and burn until you get in intercept. I'd still try to go to orbit first, for efficiency reasons, but well, if you have enough dV or high enough TWR, there should nothing stop you from going directly.

If I may add some trivia to Crown's excellent explanation: The natural logarithm is called natural, because its base, Euler's constant, has some very interesting mathematical properties. First and foremost, the exponential function f(x)=ex is its own rate of change (mathematically speaking: its own derivative: ). This furthermore means, that the area under the curve ex (its integral) is given by ex + a constant as well. Exponential functions of any other base get additional factors when calculating the rate of change or the area below. The general formula for the rate of change of an exponential function to arbitrary base a is given by , with ln(a) being the natural logarithm of a. Another remarkable property of the function ex is that it's related to the trigonometric functions sin(x) and cos(x). To fully understand this, you'd need to know about complex numbers, which are a 2D generalization of the real numbers, and still form a field. They have, as a basis, the real unit (1), and the imaginary unit (typically called i, but sometimes also j), which is given by . You can imagine them as being a 2D plane, where the real-axis is horizontal, and the imaginary axis vertical. So, any point in this plane is a complex number. These numbers can (obviously) be rewritten with their magnitude (distance from the 0-point), and the angle with respect to the real axis. And this is, where ex becomes interesting again. Euler showed that . By this, complex numbers, typically written as (where a and b are real numbers) can just as well be written as . So, although we are talking about an exponential function here, which basically boils down to how often one has to multiply a number by itself, we can do trigonometry with it. Isn't that amazing? It's also a "trick" commonly found in science, to use complex numbers to be able to combine these two remarkable properties, so that one can use the simple rule that the derivative of ex is ex again to calculate the derivative of a more complicated formula containing trigonometric functions, or to combine two coupled differential equations in one single equation (for instance the Schrödinger equation).

It's hard to name "the best" mods, as it's a matter of taste. Some people like mods that enhance realism, some people prefer mods that reduce realism, some like parts packs, others don't care about them... There is one mod though, on which's usefulness I'd expect most players to agree: Stock Bugfix Modules. Another mod that's widely regarded as essential is Ferram Aerospace Research, and as of 1.X it doesn't feel like cheating any more to use it, as the dV numbers required to reach orbit are now pretty similar in stock KSP and FAR. If you think KSP is too easy, you can try Realism Overhaul, which makes the game much more rewarding, as even "simple" tasks as reaching orbit will be a lot more challenging given a realistic scale for the planets and real-life engines. It's a quite heavy mod-collection though, meaning that you'll need a pretty fast computer, and the suggested part packs will easily drive the 32bit KSP build to the memory limits (I'm playing on Linux, and even there I had issues with Realims Overhaul, as KSP was happily asking for more than the 8 GB of RAM I have installed in my PC...).

I've finally started to use ISRU, by launching an empty ship to LKO a few days ago. Today I started the first fuel transport from my Minmus refinery to LKO, and also hauled some ore from the mining base to the refinery. While I appreciate the fund savings one can get through ISRU, it's quite boring to do the same ore-hauling mission over and over again... Anyhow, I thought this would be a nice opportunity to show the construction of my mining station:

Again I've been playing other games (dwarf fortress, mostly) for some days, but today I returned to KSP and did a lot. Usually I tend to do as much as possible in the least in-game time, but whenever a new KSP release is imminent, I get the urge to achieve as much as possible in the current save before abandoning it for a fresh career in the new version. So, finally I've decided to use time warp more generously and finally got some stuff done. I've adjusted the orbit of my SCANsat around Moho from 750 km to 250 km and switched from SAR to narrow band scanning. I sent of a base for its trip to Gilly. It is vastly overengineered, as the contract was just asking for place for 5 Kerbals, a docking port, an antenna, and solar panels, yet I chose to send along a science lab, and some gigantors to supply it, so that in the future I might eventually use this base. Given that I don't need much science any more, probably it'll just lie dormant on Gilly, with no crew... Using the same transfer window I launched a probe for flybys of the Mun, Eve, Gilly, and Duna, which will then go to Ike and fulfill a satellite contract. If one doesn't send any scientific payload this stuff is pretty cheap, and the "do several flybys with a single craft" contracts are quite profitable. I did a course correction for my SCANsat for Dres. Most important: The Kerbals gathered in the last three rescue missions around Duna have now been sent to Kerbin. I've deserted Duna Station, my orbital complex. The science lab is far from done with all the data gathered, but I've nearly finished the tech tree, and all the science stored in the transfer ships capsule should easily suffice to unlock the last few nodes. Ah, and I finished two satellite contracts around Kerbin, but those are hardly worth mentioning

There is little difference between Intel and AMD on Linux - both have excellent open source drivers. The troubles start if one is masochist enough to install the AMD proprietary drivers, which sadly are still required for some games (as the AMD open source drivers currently only support OpenGL 4.1, and Intel only supports OpenGL 3.3 - source -, yet the AMD proprietary drivers support OpenGL 4.5, but they tend to crash, and crash, and, did I mention that they tend to crash?), but luckily KSP is running perfectly fine with the open source drivers. By the way, most games that don't run with AMD open source drivers will not run on Intel at all, given that they have a very similar feature set, with some OpenGL extensions available only on Intel, and some only on AMD, but both open source drivers are under heavy development, and new OpenGL extensions get added every few weeks. Also, there is Direct3D 9 on Linux, but only for the AMD and nVidia open source drivers by using the Gallium3D Nine state tracker. It's far from perfect though (graphics glitches...), and also afaik there are no native Linux games using it. Windows games can use it when being run through WINE. Regarding Live-USB: I'm pretty certain that for most Linux distributions it's not directly possible to install proprietary nVidia graphics drivers on the Live-USBs, as they typically write their system partition as a CDROM compressed read-only filesystem on the USB-drive, so said system partition is write protected... There definitely are exceptions to this, I think Linux Mint might eventually be one (I never bothered with Live-USB for anything but installation...). Anyhow, it's not too difficult to install Linux from a USB drive to another USB drive, and also Dual Boot is rather easy to set up. *buntu and Mint are indeed pretty easy to set up with very beginner friendly installer programs, but if you feel more confident with a well written handbook that actually explains what the different steps of the installation are doing, you might want to have a look at the Debian handbook which is excellently written, and targets an audience that doesn't have too much computer knowledge (but beware: Debian und Ubuntu, as similar as they may be, use different installers).

While I haven't tried myself, I've seen people use kOS to read out a craft's sensor data and store it on the craft's kOS volume. From there one should then be able to copy the data to the kOS main computer, what means that the data will be copied to an actual text file on your HDD.