soulsource

Although converting to dds is meanwhile as simple as running `convert inputfile.something -flip outputfile.dds` on the command line (given that imagemagick is installed, which is a part of most Linux default installations), I wouldn't drop support for png and tga. If I'm not mistaken, S3TC is lossy, so directly editing the .dds files is a bad idea. For modders, and also users who want to mess with textures it's therefore much more convenient to have the option to directly load lossless textures into the game, even if they are only used for testing before converting them to dds in the end.

Honestly, I wouldn't look for an Apple PC for playing games. Their specifications make it rather clear that the main priority during development was performance in CPU demanding applications (image and video editing for instance, but also numerics), while gaming performance obviously was much less of a concern. That being said, KSP is one of the few games that can actually benefit from such a design, as it's mainly CPU limited. So, when the question comes to MacBook vs. iMac, I'd focus on iMac, as from my experience a bigger screen always improves gaming experience. Also, as cool as a thin keyboard might be for portability, for gaming it's (again: in my opinion) preferable to have a decent lift of keys. So, even if you're planning to get a MacBook, consider buying an external screen, keyboard and mouse (and while you're at it, get a gamepad as well, as the new aero model feels much better with analogue sticks). That being said, the bottleneck for KSP is usually single thread CPU performance. I'm playing on an FX-6350 (3.9 GHz), what can approximately be compared to an i5 or i7 clocked at 2.5 GHz, and I must say that it's barely fast enough. With bigger ships the ingame clock often turns yellow, meaning insufficient CPU power for realtime simulation. Now, let's have a look at the iMac models. The cheapest one, for USD 1099, has an i5 clocked at 1.4 GHz (dual core, but that's nearly irrelevant for KSP). If it reliably would clock at its highest turbo boost frequency (2.7 GHz), it'd in principle be fast enough, but afair the turbo boost clock rate depends not only on CPU load, but also on temperature, and it's very hard to predict that beforehand. The integrated GPU should in principle be enough to run KSP at low graphics settings, but I'm not sure if it can deliver the game without stuttering in the screen's native resolution of 1080p. I personally wouldn't consider this model for playing KSP. The second cheapest model, USD 1299, has an i5 quad core clocked at 2.7 GHz, with turbo boost at 3.2 GHz. This CPU is definitely fast enough for KSP. The only thing I'm sceptical about is the lack of a dedicated GPU. I'm rather confident that this integrated GPU can display KSP at the screen's native resolution, but again I wouldn't bet on it being able to render high terrain details, or to allow using visual enhancement mods without occasional stuttering. Now the last of the 21.5 inch models (USD 1499) of course has a fast enough CPU (i5 quad core, 2.9 Ghz with 3.6 GHz turbo). I wouldn't bother about the possible i7 upgrade, as the main difference between i5 and i7 is in multithread performance. This is the first (and only) 21.5 inch model with dedicated graphics card. The nVidia GTX 750M is actually on the border between entry-level and middle class graphics cards, but as KSP is not very GPU demanding, it probably will allow running the game at highest settings (except maybe for anti aliasing), and will very likely have enough reserves left for using graphics enhancing mods. It's definitely the most gaming friendly iMac of that size. Regarding the 13 inch MacBook Pro: They all have a fast enough CPU, but all use the integrated Intel graphics processor, so what I've been writing about the USD 1299 iMac applies here as well. Now, the question which one to buy is also a question of finances. If you have enough money and are really determined to buy Apple, I'd recommend you to get the USD 1499 iMac, with the USD 1299 iMac as second best option. I personally would still build my own gaming PC from selected components. It's cheaper, and assembling a computer is fun. Also, as the 64bit version of KSP is (currently) only available for Linux, you might end up installing Linux on the Mac anyhow, and then there's the question, if the higher price really pays off, as the only thing that makes an Apple PC different from any other x86 based PC is the operating system. I don't know about the legal situation, but there's of course also the option of building a Hackintosh.

I think I found the offsets for the memory addressing issue in 1.0.2 64bit, but as I haven't tested them thoroughly, they could in principle ... Please be aware, that I won't take responsibility for any damage done by relying on these values. As said, I'm not absolutely certain that they are correct. 008ab803 008ab808

I've been doing a systematic study of the munar surface back in 0.23.5. It consisted of an orbital station with lots of xenon, and an ion powered lander. I'll just post the last imgur album now, you can read the full story here, here, here, and here. As you can see: 6428 science points.

Shouldn't it be LD_LIBRARY_PATH=/opt/lib? Anyhow, if that doesn't work, you might have luck using LD_PRELOAD.

I just rescued Martrix Kerman from munar orbit.

While the transparent navball has obviously lower contrast and distinguishing the markers is therefore harder than before, I wouldn't call it hard. Of course it depends on the brightness/contrast of your screen, the ambient light, and last but not least your own ability to distinguish colours (there's a thread started by a colorblind person who hardly is able to see the markers...).

Don't get me wrong, I fully agree with you. All I wanted to say is that mounting the landing legs on the surface without shielding probably wouldn't be a catastrophe, not that it wouldn't be better to properly shield them.

The math showing that for a vertical ascent going at terminal velocity is optimal at any given point is sound and still applies. In my opinion there is nothing wrong with a hypersonic ascent. Nevertheless, I've got the impression that one often reaches limits in stability and controllability before terminal velocity, so I've basically given up chasing for it, and just set my initial TWR of the first stage to about 1.5...

I wouldn't worry too much if you cannot meet the ideal shape with rockets. As long as the drag is not too one-sided you should be fine, since rockets reach high altitude, where drag becomes negligible, rather quick. If your TWR is reasonable (I'd say about 1.5 during launch, and quite a bit less than 5 when dropping the first stage), the aerodynamic forces should hopefully never get strong enough to damage anything. With surface attached stuff it might in principle be more difficult to get the rocket stable, so adding fins/control surfaces at the bottom might be a good idea.

Why not? Finally we get to do gravity turns instead of yanking an impossible and completely ridiculous 40 degree turn at 10 km, finally our planes break if we try to fly maneuvers that look like they should break them, finally aerodynamic forces keep our craft stable and we don't need to use SAS for everything, finally building a rocket that looks like a rocket pays off. Furthermore, finally our tanks don't change their aerodynamic drag when we use fuel, cargo bays finally have a purpose, and last but not least, finally it's reasonably easy to build planes. I managed to build (space-)planes in broth-o-sphere non-aero, but it was always a huge pain. Now, with the improved dependence of lift on angle of attack, it's much, much easier to get planes into the air, and piloting finally doesn't feel like sitting on a cactus. Of course this means one needs some time to learn how to build rockets and planes that actually look like they would fly in real life (as opposed to 0.90 and before, where even a hot dog with wings would fly), and one cannot use wings as hull parts any more (as SQUAD decided to use a different aero model for wings), but look on the bright side: Now we have engines that are actually balanced for realistic aerodynamics FAR is no longer the "I win" mod it was before, where it greatly reduced the dV requirements compared to stock broth-o-sphere. To be fair, stock aero isn't perfect, but for those who aren't satisfied with it, there are a lot of settings available either by tweaking the config files, or via the debug menu. It's possible to control how deadly a reentry is by using the difficulty settings (and don't complain that reentry is too easy, unless you have set this slider to maximum). Anyhow, if all of this still isn't good enough, there'll be a FAR release for 1.0.2 soon, and DRE should be updated for 1.0.2 at some point as well (and will be quite a bit more deadly than stock). Long story short: A really, really big thank you to the team at SQUAD for implementing an aerodynamic model that deserves the name. Please, please, please keep up the new system. Tweak it here and there, but, by the love of Jool, don't bring back the broth-o-sphere.

I'd say: Best atmosphere is FAR, especially combined with the tweaked engine Isp values from 1.0.2. I've been playing 0.90 stock and honestly it has not even the worst aerodynamics model one can think of, it simply has no aerodynamics model at all. Building a plane in 0.90 feels like sticking a spoon in a cauldron filled with broth and trying to stir. 1.0 was nice, and 1.0.2 is still quite good (although, honestly, I didn't play it much), but both loose compared to FAR (development builds for 1.0.2). I'm not trying to judge realism, as my knowledge of hydrodynamics is limited, I'm just talking about how "right" playing with each model feels.

I'm now nearly exclusively using rockets. Why? Because my planes usually tend to explode. Either they veer off the runway, or they get ripped to shreds by aerodynamic forces. Even if they survive these two things, I more often than not crash instead of doing a proper landing. While it isn't a problem to find enough brave/stupid test pilots, sadly on hard difficulty funds are limited, and my space program simply cannot afford loosing expensive crafts...

This has been answered I don't know how often in the last few days, for instance here. You'll also need Module Manager. As I'm running development builds: Yes. FAR works with fairings. There are as far as I can tell no issues with stock fairings, but, as with other procedural parts mods, procedural fairings would need to inform FAR about shape changes, what they don't do (yet). So, to be sure that your FAR data is correct, attach the fairings so they get the correct shape, remove (but don't delete) them, and re-add them again. Then, check the debug voxel display in the FAR window.

I've got the same issue as wal310. In space there is no reflection of the skybox, but a blue background instead. The craft, and nearby celestial bodies are reflected fine. To illustrate, here's a screenshot. Edit: While I don't think it makes a difference, maybe I should state here, that I'm using 64bit KSP on Linux, and that I tried skybox textures in .png and .dds format. Edit 2: Also, I've been using Texture Replacer with 0.90, also using the same dds skybox (with the ddsloader mod) and reflections were working back then. Edit 3: Just tried with a fresh install of 1.0.2 without a custom skybox. Same issue, both with 32 and 64bit Linux clients.

Ok, thanks a lot. That's all I wanted to know.

I just remembered, that at some point there was this. Now, as 1.0 is here, I can't seem to find it mentioned in the changelog. I'm wondering, is this feature in the game? If yes: where? If not, has there been any official statement from SQUAD why? (Please note: I don't want this thread to veer off into a discussion if it is/would be a nice feature. We've had that already...)

Stock Bugfix Modules Ferram Aerospace Research (not yet ready for 1.0, but will be within a couple of days) Kerbal Alarm Clock Edit: If you want dV readout, check out Vessel Orbital Information Display, it has an awesome HUD.

Edit: Nevermind, I misunderstood your issue. I've done a lot of successful flights in 1.0. Getting to orbit is much easier now than it was in 0.90, you just have to build an aerodynamically stable rocket, and keep your heading close to prograde during ascent. In other words: do a gravity turn instead of trying to tilt the rocket instantly at 10 km. The unstable pods are a bug, but one can either do shallow reentries, so that reaction wheels can counteract aerodynamic forces, or install the Stock Bugfix Modules (as you probably also did with 0.90). Anyhow, I'm looking forward to 1.0.1 as well.

The video wasn't as bad as what I expected. At least he shows how *not* to play, by completely ignoring the data displayed when hovering the mouse over the different parts, and that just slamming together cool looking things will not get you very far. ;-)

For my old save she was the first Kerbal in space. Also the first Kerbal whose capsule flipped and vaporized during reentry. Well, technically it wasn't me who killed her, but bug 4790...

My experience up to now is limited, but from what I've seen, it depends a lot on how shallow your reentry is. While with steep reentries the pod inevitably flips, with shallow reentries (perihelum above 20 km) it seems to be possible to slow the pod down already at high altitude, before aerodynamic forces get stronger than the reaction wheels. By this one is not only able to keep the heat shield oriented forward, but due to the lowered velocity maintains control even down to the lower atmosphere (last time I opened the parachutes at about 10 km).

I said goodbye to 0.90 with my first Jool-4. I didn't have time for a proper Jool-5, as I wanted to finish before 1.0 gets released - as you see, I nearly managed... It was sandbox though, as my first two attempts to put this monstrosity on the launch pad failed and left my career save nearly bankrupt. Also, I used quickload at Laythe, as I missed my desired landing spot twice, and in both cases ended up with a tipped over lander.

For me the worst FPS hog is Aero effects. You can try switching them off.