DMagic

Anyone know if the changes to resource flow had any effect on Kethane or the converters? I suspect not, but I want to make sure my tutorial is up-to-date as it still gets a steady stream of views.

This can be very tricky to do. Each part in the craft is numbered, so deleting one part will affect the numbers assigned to every part that comes after it. Unless you are deleting the last part (the one with the highest number) you will probably end up with lots of issues. I did this once with some decouplers that were put on backwards. I didn't want those parts sticking out of the end of my Mun base so I tried to delete them. I managed to do it, but I had to renumber about 50 or so parts, and fix all of the connection references (each part labels the number of the parts connected to it). It's not very fun. If you want to try it the parameters that need changing are all at the beginning of each part's entry in the quicksave file. To find what you need, first open the search box and type the name of your craft, that should bring you down to the right entry (it should say "vessel = *your name*", or something like that), though you sometimes end up with debris having similar names. Each part is then listed in order by name. It should be something like Part {*part name* then a bunch of stuff}. You can try just deleting the parts in question, but if that breaks things you'll have to deal with the part numbers. The entries for those are the "parent" entries, as well as the "node_stack" entries, struts and docking ports are more complicated still.

Thanks, it's been a while since I've looked at this thread. I think all of my Minmus landers had three ion engines, but two should be enough, it depends on how you are powering them. The big solar panels weigh a lot and are the least efficient in terms of electricity generated / mass. Using smaller ones, or a bunch of the OX-STAT always helps. As for landing, my strategy is always to start out in a relatively high orbit, maybe 25km over Minmus, and kill all horizontal velocity (you might also want to angle up a little to keep your vertical velocity from going too high). Then drop straight down while keeping your vertical velocity in check. This is really inefficient way of doing it, but it's the safest way.

My desktop looks a little better. I'm getting around 20-30% increases in FPS at a given part count, which is pretty good, maybe not the 50-100% improvement that some people might have liked, but that's still a big increase. It's about the equivalent of moving up to a CPU a few notches higher. And more subjectively, it seemed to me like things were smoother in 0.23. I don't know for sure, but it seemed better in ways that the fps data don't necessarily show. I'll have to run a frametime test sometime to see if that comes out any different. Edit: Yeah, that's what I saw too. I need to run a frametime test, those results in older versions were all over the place. Maybe some of that has been smoothed out now. I ran these tests more carefully and ran a new test on 0.22 (which I didn't do on the Surface). Yeah, it's an i5 4200U at 1.6GHz with turboboost up to 2.6GHz. It runs about the same as the i7-4650U in the Macbook Air I used to have (despite the much better GPU in that part).

So, anyone else getting better results? I tried this on a Surface Pro 2 and only got a very slight increase in performance. I'll see what I get on my desktop later today.

Mu was the one who mentioned that performance jump, the 700 part craft at 40fps, but he also said not to read too much into that, it's just one person's experience. And an i5 3570k is about as good as you can get in terms of CPUs for KSP. The higher end i7s and Xeon CPUs don't really make any difference because they are all about multiple cores and threads. Even at stock speeds that CPU will do better than all but a handful of other options.

Too many reaction wheels, or any type of control surface can cause shaking, but in my experience that is mostly harmless, just annoying. The death rattle, as I call it, is a different issue. I have no idea what causes it (parts clipping together might be an issue), but it doesn't seem to be related to how much or how little torque/control authority you have.

Steam only changes the files that have been updated. Things like saves, or craft files won't be affected. That said, you should still make backups of your save folder (which contains both save files and craft files) before every update. If you are really concerned you can backup the entire KSP folder.

In Linux you should be able to open a terminal and type "top". That will give you something similar to what task manager shows (though I think it gives memory usage as a percentage instead of an absolute number).

It’s time for one last 0.22 mission. Celebrating the awesomeness of KSP, the awesomeness of new planets, and the awesomeness of the Cassini mission to Saturn I made a tribute craft. I used Krag’s Planet Factory, rbray89’s cloud and city lights plugin, damny’s Scansat with some of Milkshakefiend’s parts, Engineer, and procedural fairings. Pretty much all of the parts used are either stock, or modified versions of stock parts. Now to get on with the mission. Here she is on the Launchpad (I love the light on the water tower), with the KSP version of the Titan IVB. I used some beefed up SRBs and a central liquid fueled engine with an upper stage for orbital insertion and ejection. It was smooth sailing all the way into orbit. After fairing separation and orbital insertion the hi-gain antenna and three radio/plasma wave antennas were extended. You can also see the undeployed magnetometer boom near the hi-gain. The second stage still has about 1200m/s of Delta-V remaining which should be enough for the first burn. Now the fun part begins. You can see below an overview of the mission plan; I’ll be relying heavily on gravity assists to push my orbit out to the distant planet Sentar. First off is the ejection to Eve orbit. A burn at an Eve periapsis of about 130km will provide a boost to reach Jool orbit. Another slingshot there will throw the craft out to Sentar’s orbit. The inclination is unfavorable at this point, so another large burn will be necessary to change that and set up an orbital rendezvous the next time around. After all of that one final burn is necessary for orbital insertion at Sentar. Here is a close up view of the first part of the journey. After an ejection burn from LKO of around 1100m/s and another 50m/s from correction burns (this transfer isn’t quite ideal because the positions of Eve and Jool need to lineup for these multiple gravity assists to work) the craft will approach Eve. A burn of about 800m/s will boost the craft into a Jool intercept. With the second stage spent, the transfer stage burns over Eve to boost Sentini out to Jool’s orbit. The red dashed line shows the path from Eve to Jool. Once there the craft will pass close to the orbits of Vall and Laythe. From there it will follow the yellow dashed line out to Sentar. Getting a close view of Jool’s swirling clouds the probe continues its long journey. No burns necessary here. The purple maneuver node below will expend about 1000m/s of Delta-V, match Sentar’s inclination, and put the craft on a path to rendezvous with the planet. After another six years in orbit, one final burn of about 500m/s will establish a stable orbit; no aerobraking is possible for the fragile Sentini probe. After its long journey the probe approaches Sentar, the blue, ringed planet never before explored by Kerbals. The transfer stage makes its last burn before separating and flying back out into solar orbit. The final few m/s are provided by the probes onboard engines. The Delta-V breakdown is as follows: - ~1200m/s for the Eve transfer and corrections - ~850m/s for the Jool transfer and corrections - ~1000m/s for the final inclination change - ~500m/s for the final insertion burn - A total of around 3600m/s. I have no idea what the Delta-V requirements are for a direct transfer to Sentar, but Eeloo requires around 4000m/s, so that number looks pretty good to me; the Eve to Jool slingshot didn’t really help me at all though. Our first objective is a close up trip around the outermost moon, Thud. The moon’s gravity assist and a small burn will then put the probe on a course for Erin. With all of its sensors extended the probe tests out all of its systems on this first flyby. Now Sentini approaches its primary target, the atmospheric moon Erin, which also appears to have stable liquid on its surface. An initial course is plotted for the probe to pass through the moon’s lower atmosphere. The unpowered Kuygens probe is released to follow this trajectory, while Sentini readjusts its orbit to pass safely over the atmosphere. Now is a good time to take a closer look at Sentini’s systems and sensors. In the first image you can see the probe’s main engines on the bottom. Around the bottom there are three RTGs to provide power, the three main reaction wheels are used to orient the craft, and four RCS thrusters provide power for orientation and minor course corrections. The primary sensor board contains several telescopes and scanners. These are used to image the planet and its moons in a variety of spectra. In the second image you can get a better look at the radio/plasma wave antenna (unfortunately I couldn’t think of a way to make a really long, narrow antenna like the real ones). The hi-gain antenna and magnetometer boom can be seen coming off of the left side of the image. There is another reaction wheel here, acting as a backup for the three primary wheels. The container on the right will be used to study the effects of Sentar's radiation and electromagnetic fields on the goo inside. Another set of sensors is visible on the right. These are used to study Sentar’s magnetosphere, its ionosphere, and to measure charged particles from the atmosphere of the planet and some of its moons. The mono-propellant tank for the RCS thrusters is visible here too. While Kuygens plummets through the atmosphere, Sentini conducts some mapping experiments. Many such close up flybys will be required to collect a more complete surface map for all of the moons. Kuygens’ heatshield protects the vulnerable probe during its fiery descent to the surface. The lakes visible on the surface are most likely liquid kethane, kept stable by the moon’s thick atmosphere and its low temperatures. This has interesting implications for future mining missions. Sentar hangs in the sky as the probe plunges further into Erin’s atmosphere. Once the probe has passed through the upper atmosphere and shed some of its excess velocity the heatshield can be released and the parachute deployed. Kuygens makes a soft landing, safely touching down on the surface. The ground appears to be made up of some loose, possibly viscous material, allowing the probe to sink slightly below the surface. With Kuygens released Sentini carries on with its mission to study all of Sentar’s moons. Its next target is the small, ringed planet Ringle. Flying within the rings Sentini gets a very close view of the surface, passing just 5km above the rocky ground. Next up is the moon Skelton. This moon circles Sentar in a highly inclined, retrograde orbit, indicating that it was most likely a rogue planet captured by Sentar’s high gravity. The moon’s most striking feature is an enormous mountain, most likely the result of volcanic activity. Sentini passes over this peak, but the moon’s dense atmosphere prevents the probe from getting a closer look. And finally, we take a closer look at Sentar itself. The blue-green gas giant has a dense ring system, warranting much further study. After visiting all of the objects in Sentar’s system Sentini still has around 500m/s of Delta-V remaining, plenty to make repeat visits in the months and years to come. Thanks for reading folks. Really though, everyone should at least read the Wikipedia article about Cassini linked to above. That thing is amazing. It was launched 16 years ago, it has been in orbit around Saturn since 2004 and it’s still going strong, and should continue to do so until at least 2017.

No, I think his GPU is far weaker than yours. It is an extremely low-end video card, the kind that has been pretty much replaced by recent integrated GPUs. The CPU could also be an issue, 2.7GHz dual core doesn't really mean much. There are huge differences between different families or generations of CPUs running at the same clockspeed. The next update might improve this issue, though I've yet to hear anyone directly say that the ocean terrain problem has been addressed. Maybe I just missed it, but all I've heard about has been CPU related performance. The ocean terrain fixed linked to above might help a little, but that really only provides a major improvement when you are at default or high terrain settings.

This sounds like it was a very recent change, so I would expect the whole command pod mono-propellant thing might change as well. Maybe they'll put EVA propellant in the command pod, or maybe not. In the videos I saw, the command pods did have a small amount of mono-propellant, the one-man cockpit had 7.5L I think.

You should be able to transfer Kethane by alt-clicking on both tanks. I think those KAS pipes have some options for how they connect though, you might want to check. The kethane converter is iffy though. I'm not sure if you'll be able to get fuel to flow from the converter to fuel tanks attached through those radial docking ports. Your best bet is to always stick a fuel tank directly onto the kethane converter.

It's possible to do maneuver nodes with the stylus, but it's really difficult, putting the staging in order is another problem. Most other aspects work ok with the touchscreen and type cover though. But if you really want to play you probably need a mouse to do it properly. It's a legitimately powerful computer in a really small form factor (it is and feels much smaller than my 11" macbook air). But it's the cost that's the problem, there's really no way around that. And I wouldn't go for the old Surface Pro just because the battery is so terrible there. I think it's pretty similar otherwise, the GPU is probably quite a bit better in the 2, but that low battery life kind of kills it.

That's interesting, these results look much more like what I would expect from your CPU, but they never reach the levels of the old results. I guess AMD's turbocore can do weird things to KSP performance. Actually, looking at this carefully, it seems like your old tests might have been done with the physics delta time set above 0.03 s/frame. Comparing the timing for stages and the way the simulation time compares between the two tests makes this seem likely.

I would say "big" in that in changes a lot of fundamental aspects of how rockets are build and flown. Mostly that's through tweakables, but the new engine and performance improvements could make a really big difference. It sounds like there are lots of changes to career mode too, but I think the next really big step there will be some kind of economy system.

Did they talk anymore about how thrust could be changed, or was is just the brief snippet from Yarg? My thinking is that this will be far more useful for SRBs than for liquid engines. No more worrying about blowing past terminal velocity. If we can tweak max thrust in flight I can see it being useful for liquid engines too, though. You could use it for offsetting a mass imbalance, or for making landing a bit easier (no more fiddling around with the throttle at 5% trying to come in for a soft landing).

Are you docking each segment together individually, or are you connecting multiple docking ports at the same time? Only the "primary" connection will transfer fuel in these multiple-port type of connections. The only realistic solution is to use TAC fuel balancer. It is perfect for this kind of complicated situation where the only alternative is to constantly balance the fuel by hand.

I've been playing around with wiggle gifs using regular screenshots. It's possible to do it manually, just take a screenshot, then move a little left or right and take another, but it's not very easy. Sometimes I can get it to work pretty well, and other times I get no depth at all. It has also required using a bunch of screenshots and then picking out the pairs or groups that work best, it obviously isn't a solution that's easy to scale up.

I managed to get some images with faster transition times, but apparently browsers are stupid and cut off the minimum transition time. They all do it differently, but on Chrome these work fine for me. It works a little better, but any faster than this and things start to look a little weird. I think to really get a really good effect I need a version with three or four frames set at a higher speed. I also found that the pictures of larger objects don't work so well, speeding up the transition time just makes the edges more noticeable. This one isn't too bad though, and the faster transition looks a little better.

The T100 is uses an intel Atom CPU. You probably won't really be able to KSP on that thing. It should technically work, but you'll have to accept really low performance. The price point is appealing, but you lose a lot to get it down that low (not just game related performance). I have a Surface Pro 2, it's not cheap but I think it's great, and it runs KSP pretty well, better than most full sized laptops that are more than a year or two old.

I think the idea with these kind of mods is that you have to start over again.

Thanks VirtualCLD, I added both sets of results. I see a little bit of improvement from the Q6600 to the 4670k. It's nice to see that your results match up well with Slugy and Nao's.

Supposedly that is for this update, 0.23. It was first mentioned a little while before the 0.22 update, and it has been brought up several times in the Tuesday Dailies. Though it won't be too surprising if they continue to optimize things for several updates, or again later on.

It's possible for one core to max out while the others remain idle or low, but that's not generally what happens. The processing load is spread out evenly across all cores, so most of the time when someone says that a thread is maxing out one core you will see all four cores running at around 25%. There are probably lots of reasons for this that I'm not aware of, but that is the way it works. Being single-threaded doesn't limit a process to running only on core, it just means that it can't be split up to run simultaneously on all cores.