steve_v

Gah, this again. I really wish this "cellphones cause cancer" BS would die already, it's been tested enough to say "no link found". Not to mention the whole getting a bigger dose from pretty much everything else. The only people who believe this junk are those who have no idea what they're on about, or how radio works. I've recently seen (local paper no less): WIFI causes ADD, and a whole host of other things, and should be banned in schools. (guess I should move that 6' antenna out of my house then ) A big (and largely successful) campaign against a cell tower (main argument: dangerous radio waves) in a real coverage black spot. I really hope the pitchfork wielding mobs come for these fools when someone dies in a boating accident because no cell coverage.

Lame. Extremely lame. Not even worth a *facepalm*.

Not really: Wait and see what improvements v1.1 brings, ruthlessly prune part count on your designs, OC your CPU, or try a welding mod. The physics engine KSP uses is old, slow, single-threaded and CPU only. As such, it'll only ever utilise one core, and lag increases almost exponentially with part count. If you haven't already, reducing the physics delta T slider in the settings to minimum might help a little - it'll make the physics run slower than realtime, but may help framerate. I've said it before, and I'll say it once again: This games performance is abysmal, even on high-end hardware. I've long since given up on building anything >500 parts, 800+ is slideshow territory on my machine (I7 @4.3GHz), entirely due to the shoddy CPU-bound physics engine. Unfortunately, Squad seems utterly uninterested in using anything but the physics engine built into Unity, and any performance concerns become "Unity issue, can't fix". The upcoming (1.1) port to Unity 5 may improve this, but I'm pretty sceptical. It's supposedly faster, but AFAIK rigid-body physics is still single-threaded and CPU only.

20Km is indeed about the limit for the Whiplash, and more intakes won't help. The rapier should make 25-27Km, but after that you'll need to light the rockets. I immediately see a couple of "old" design features there: Intake spam - no longer needed, counterproductive due to drag. Biplane wings - again counterproductive, due to drag. (though I run FAR, so maybe not) I can't see your engine layout clearly - I see 2 turboramjets and 1 nerva. If that's correct it's probably going to be easier with higher TWR rocketry or rapiers. Nerv powered SSTOs are hard. For inspiration, check out the Kerbodyne SSTO Division, again, they're set up for FAR but any rated for 1.0.5 should work fine in stock too.

Agreed, best space combat game(s) ever IMO and I still play them... As for mods, I think my FS install is somewhere around 21GB The fs2_open engine is sweet too.

Yup, MechJeb has "smart RCS translation". If it's shifting fuel load that disturbs your calm (and you have several tanks), there's also PWB Fuel Balancer to even it out again.

Why Am I (Still) Playing Kerbal Space Program? It's Fun. I like building stuff. It's got a ton of awesome mods. It's got stable 64bit, for the running of said mods. It has a GNU/Linux native build (I'd boot Windows to play it, but hassle outweighs Fun eventually). ...Was some time ago. That said, currently taking time out of KSP to play some (also GNU/Linux native) old-school RPG ATM... But I'll be back.

IIRC, my second point of confusion when I first started playing was: "What's going on with aerodynamics? Pancakes shouldn't fly this well." (old aero model), right after "What's up with physics? Real rockets aren't this bendy." Ferram4 to the rescue in both cases. So no, I don't think we should bring back the old it's-not-air but stuff mysteriously slows down in atmosphere model. The key word being "mysteriously", if you're learning it you're learning arbitrary game rules, not real-world physics, and it's only "easier" if it's what you're used to. The new stock aero model is fairly intuitive, for anyone who has ever made a paper plane or thrown a dart - it's easier to learn by researching how real rockets work too. I'd love to see more realism (and hence teaching potential) in the game, but IMO the current aero strikes a reasonable balance between "game" and "physics simulator".

If you have windows you can move about the screen, you're running a Window Manager - I assume the one that comes with whatever Desktop Environment you're using. (Which is?) Most of the time (again dependent on what DE you're running), installing a new WM will give you the option to use it at the login screen. I'm tempted to suggest trying openbox, it's not to weird, but there are far too many options to cover them all. That said, I see absolutely no performance difference running in KDE/KWin with full shiny vs. bare X with nothing but an xterm. PSA: glxgears is not a benchmark. It's an old GLX demo, and it'll give you some indication that GL is working, nothing more. That it is a benchmark is a persistent myth. It doesn't monitor desktop framerate, and you can't get it to monitor ingame framerate either - the only thing it "monitors" is itself. To see KSP framerates: Ingame: GCMonitor, ksp-devtools or the built-in debug menu. Overlay: voglperf or GLXOSD. If you want some kind of general GPU benchmark using modern features, you could try one of the Unigine demos. 'glxinfo' will always dump a huge wall of text, even if you're stuck with software rendering. Filter it to the relevant bits with grep: glxinfo | egrep 'direct | vendor' If you get "direct rendering: Yes" and the vendor strings all match, you've got GPU GL acceleration. For GPU recommendations, I haven't bought a new card in some time but my GTX680 still handles KSP without issue. In fact I'm pretty sure it's overkill. I haven't had any problems with Nvidias Linux driver in some time (years). AFAICT, my performance issues (it runs ok, but it could be far better) are all CPU/physics engine. And barring any huge flaws in AMDs driver (not at all unheard of mid you) I suspect yours are too.

"it's a Unity issue, cant/wont fix"... after the Unity update.

Heh, this kind of mistake (upside-down docking port) is both very common and very kerbal... and that's what preflight / kerbin orbit testing is for no? 'Tis kinda like installing the ion engine upside-down, putting the parachutes in the wrong stage or forgetting the solar panels - I'm sure we've all done it once, learn from the experience and move on. It'd be a boring game if you couldn't make mistakes. Of course one could put a big "this way up" on the parts... NASA does You have of course realised that you need a docking port on both vessels if you intend to re-dock, right?

It's a bit of a long shot, but installing KJR might help here. To quote the feature list: Physics Easing Slowly dials up external forces (gravity, centrifugal, coriolis) when on the surface of a planet, reducing the initial stress during loading

If you insist I'm expecting it to fall on deaf ears, but as far as I can tell this is exactly the kind of fallout and ongoing corner cases I predicted from the removal of same-craft collisions and the over-simplified drag / occlusion model.

Every one of those examples comes right back to the extremely janky (or, in most cases, entirely missing) same-craft collisions. Poorly braced payloads clipping through fairing walls and cargo bays are another obvious example, and one not solved by the "stowed" mechanic. All this serves to further reinforce my suspicions that this was added as a lazy way to avoid dealing with the real issue - fairings are, for all intents and purposes, not solid objects, at least not when interacting with parts on the same craft. The lack of collisions what is "unrealistic" (and allows things to poke through fairings), not the lack of a (working) contrived gameplay limitation to work around it. Who else has had a fairing get stuck on a craft because it clipped into some other part while attached, and can't clip back out again after magically becoming solid when jettisoned? As I mentioned earlier, fix the underlying physics issues and the problem this dirty hack attempts to address goes away, taking all its bugs with it. Again, dirty hack for lack of collisions. Antennas should hit the fairing, not pass through it. If we're stuck with the "no same craft collisions" thing, at least calculate whether a part is obstructed / occluded / shielded from the actual shape of the craft - something like the voxel approach FAR uses would (and does, for aero) work rather well. All the bugs related to the "stowed" mechanic stem from trying to work out what is shielded and what is not using some magical, spheroid "zone of occlusion" emanating from root of the shielding part. - It's far too easy to a: miss the removal of the shielding part (particularly when it's more than one section) or b: have something that is placed just-so and is shielded when it shouldn't be - i.e. placing something too close to the outside of a service bay.

The released versions can be found under the "41 releases" link on that page, "master" is the current unreleased/WIP code, aka. the dev version. The readme etc. generally get updated when a new release is made.

Indeed, and herein lies the problem.

Looks like KSPI to me, but I haven't used it since ~0.25. Try the thread for the current incarnation.

Having used mod fairings (with FAR) long before this mechanic was introduced, I can confidently say: I can't think of any at all. To add yet another fairing related bug to the pile, I just had a craft die because my solar panels were "Occluded by aerodynamic shielding"... in orbit of Minimus, with no fairings in sight. Sure, this system would not be such a big deal if it worked properly, but it doesn't. Considering the oversimplified way fairings and cargo bays calculate occlusion I have my doubts that it will ever work without introducing such issues. It's both broken and unnecessary, so the logical course of action is to get rid of it. As of right now, in my copy of the game anyway, correct. Mono is a craft-wide resource and pulls from all tanks, "stowed" or not.

False as in not where the dev build can be found, or false as in NOT SHOUTING ENOUGH? It's some kind of secret then? Not very well hidden if that's the case. Besides, I wasn't suggesting that one should use the dev build, simply that testing the dev build first is better than reporting (possibly already fixed) bugs repeatedly.

There's a long and gory history behind this, best to let sleeping dogs lie. If you want to use the unsupported Win64 hack, go nuts. Just don't ask for support, particularly from those modders that have clearly stated they want nothing to do with it.

Hit the The source at GitHub link in the OP, You should see a "Download zip" button on the right just above the file listing, this is what you want - specifically the "GameData" subdirectory in that zip. It's always worth giving the dev build a go before reporting bugs, your issues might already be fixed.

Hmm, this will either be a perfect example of why this thing should die, or a broken image, but as there's no preview and this editor is a load of manure I guess I'll just try it and see... Nope, guess not. Of course, normally I'd just delete this now pointless post... but that's broken too. I'm over fighting this steaming pile. Nevermind.

Ya know, I was going to to cross-link this to the "Remove the terrible cannot activate while stowed" thread, as it's a perfect example of why this should die in fire... but it's become increasingly clear that nobody is actually listening to such things, so why continue to spit into the wind? Engines "cannot activate while stowed", parachutes "cannot activate while stowed", craft crashes and burns. Nothing was actually stowed at the time mind you, that fairing is long gone. Will anyone on Squad or forum staff admit this "stowed" mechanic was a dumb idea in the first place, and causes more problems than it solves?... not a chance.

If you look at the fine print in the upper-left, that's exactly what happened. This is why this idiotic mechanic should be removed. It's a real nice lander otherwise, and it looks like it would have plenty of thrust for that suicide burn... if the engines had fired as intended.

Why yes, yes it is. Indeed, so it should probably be: "Some Americans are ignorant." again, not a particularly good survey. Ahh, but here 'tis you bringing up political bias, nobody else has mentioned it. Would you like it more if it came from a right leaning paper? Sure is, and it's turtles all the way down. Then again, there are some people alive (how?) that believe the earth is hollow, or only 6000 years old, or flat... the list of stupid ideas is endless. Scientific discovery is supposed to correct these misguided ideas, yet some always resist, and yet more just don't care how wrong they are.