Tiron

Well they already said awhile ago they were going to do updates that way, push compatibility breaking stuff back and then do it all at once in a single patch. It's just bloody depressing to have to redo the same things over and over and over...it takes longer to get it done each time because you're less interested in doing it, and thus avoid it. I'm already at the point where I'm so tired of remapping kerbin, the mun, and minmus that I've barely gotten anything done at all this time around. In 0.19 I'd mapped Duna, Ika, and Eve for the first time ever, and had a Duna mission in progress that I unexpectedly lost when 0.20 unexpectedly broke my save, so I started over. Again. I've never been in the SoIs of Jool, Dres, Eeloo, or Gilly, because I end up stuck back in the Kerbin SoI mapping again every time compatibility breaks. For a completionist like me, having to start over, and over, and over, and over is just depressing and makes me not want to play the game. So I've gotten far less done in 0.20 than I have in any other version since I bought the game...and I'm not going to be doing any more in it at least until more info comes out. If I can salvage my maps I've JUST made, it won't be so bad, because I don't really have any missions in progress I care about all that much. If I can't, I'll probably stop playing KSP for some time to come out of the desire to not get stuck remapping again for the umpteenth time. Edit: But what do you suppose the odds are that they're not gonna mess with any of the terrain or anomalies on a compatibility breaking save? I don't WANT to map the mun again! I just finished it yesterday! AGAIN! I was in the middle of finishing up Minmus when I read this post and closed the game.

...Well poo. I'm tired of remapping everything...I've mapped kerbin like six times and the mun like five, and if I lose those too, I may just quit bothering with KSP for quite some time. Having to redo the same things over and over and over is frustrating enough... As long as Kethane compatibility survives it won't be AS bad... ISA mapping takes long enough, but at least you can use higher orbits to speed it up. Kethane...even with the hexes you still have to use a low tight one that takes forever, even time accelerated. I'm never gonna get to Jool at this rate.

It can help drive home just how badly you've failed. Although if you're like me and actually include ways for your semi-brave almost-astronauts to survive failures...It's somewhat annoying when they don't work.

There's also the question of where all that free oxygen came from. Oxygen's so reactive that it's generally locked up in oxides. On Earth, it was freed and released into the atmosphere by...Plants. It caused a hell of a problem for awhile, because Oxygen is quite corrosive and somewhat toxic (Which is one of the reasons you can't use normal air to dive past a certain depth in the ocean.) The presence of oxygen in the atmosphere suggests some form of life that's releasing it as a metabolic byproduct. Something like algae in the oceans, most likely, given there's nothing visible on the surface (and it'd get killed by the radiation most likely anyway). But either way, there's probably SOMETHING in the water...

They're listed in order by which seat they're in, yes, and empty seats get no portrait. Neither do Kerbals on EVA. At this point it's pretty much literally just a camera pointed at the Kerbonaut sitting in their chair in whatever Pod/Cockpit they're in. Hitchhikers don't currently have ports OR IVAs, but I gather it's being worked on.

That's coming. Lack of Oxygen and Too Many G-Forces deaths are planned, for a start. It's based on the Crew Member's statistics. There are, at present, three relevant statistics. Dumb, Brave, and the BadS flag. Dumb is how smart they are, oddly enough, which affects how well they're able to tell when they SHOULD be worried about something or not. Brave is their level of courage, which is pretty obvious. BadS is an on-or-off flag that squad calls 'pilot training', which causes them to have said (@%-eating grin almost any time they're in flight, with the sole exception of when the ship starts breaking. Right now, only Jeb has the BadS flag set. For an illustration of what the various statistics do, Bill and Bob are pretty good examples. Bill has a low Brave value, but a high Dumb value. He's pretty aware of what's dangerous and what's not, but has almost no tolerance for anything that's even slightly in the 'not' category, and thus freaks out anytime it's the least bit dangerous. Bob, on the other hand, has a midlevel brave value, but a very low dumb value. The latter tends to override the former, because he's so unaware of what's going on and what he SHOULD be afraid of that he interprets almost everything as a life-threatening emergency, unless it's blatantly obvious that it's not. If you get one with high brave AND high dumb, they react quite appropriately. When things are going normally, they're not quite so grinny as Jeb, but close. Unlike Jeb they still react to goings-on that don't involve explosions.

Not when it's true, it's not. See, you can't just slap a bunch of content together and have it be a game. There has to be a code framework holding the content together that makes everything work. This framework is called an 'engine'. When making a game you have basically two options: Make a new engine from scratch, or use an existing one. The second option means either having already made one or getting one from someone else. KSP uses the Unity3D engine (there's also a 2D version, which Rovio is rather fond of). Basically the entire core functioning of the game relies on Unity and its features in order to work. Especially Unity's built-in physics engine, an older version of nVidia's PhysX that only supports running physics calcs on a single core and can't use GPU acceleration. Unity's old version of PhysX is one of the primary things holding performance back, as the inability to use more than one CPU core means that ships with large partcounts use all the available processing power on a single core. Most modern systems have at LEAST two cores (Mine has Six!), but KSP can only make use of one. A different physics engine that could make use of multiple cores(Including later versions of PhysX) would allow for much larger ships before physics lag became a problem. Though as I explained above, Unity has no particular reason to bother updating this. Which means there are only a few options available to Squad in this area: Throw out almost everything that's been created and start from scratch on a new engine. Do all that, only trying to create the engine themselves too. Tinker with the engine itself, modifying it to do what they need. Pray someone else does the latter which they can then use. Changing engines would require YEARS, even if NOT creating a new one, and would require most content to be recreated. Changing to a different physics engine (Bullet, say), would take some months of refactoring to get everything to work with it. Performance optimizations generally come very late, and there's a reason for it: It's rather hard to do them when some of the things you need to optimize are being reworked by someone else at the same time you're trying to optimize them. And it wouldn't help anything that got added in later, either. Ah, that must be the one I've heard of. Unfinished, unreleased, being worked on by a single guy, who hasn't posted to the thread in nearly seven months. If it ever got finished and released it could potentially help KSP enormously. If. It looks pretty abandoned.

Because there's no substantial economic incentive for them to do so. Let's face it, for most purposes, especially the kinds of games that are usually made with Unity, old, single-threaded PhysX 2 is plenty adequate. Unity is designed primarily for accessibility and cross-platform capability. It isn't really intended for large, system-intensive games made by major developers (who generally make their own engines). It's intended for small developers to be able to pump out games on a lot of platforms, without spending years developing a framework. These kinds of people are usually okay with the features the old PhysX 2 has. Why spend lots of time and money integrating something most of your customers don't need or care about? KSP is ONE game, with unusual requirements. Unity aren't going to spend a lot of money implementing a feature for one game. And let's be clear, more than anything, it's the physics engine holding KSP back, not Unity itself. It was Unity's choice to use PhysX 2 instead of a better, more modern engine, but it's still the PhysX 2 that's the main problem. Yes, it would take quite some work to switch to a new physics engine. But the change being to the game engine itself rather than a plugin probably wouldn't make it any easier. Even then, it'd be as a new version of the Unity Engine, and we've already gone through THAT once (Remember when they upgraded it to Unity 4?) It'd still be easier than changing to a different game engine. That's part of why I suggested PhysX 3. We're already using PhysX 2, and it'd probably be easier to update the current physics calls to work with PhysX 3 than to modify them for an entirely different physics engine. But so far as I can tell, there ARE no Physics Engine plugins for Unity, of any sort whatsoever, so until that changes, that part of the discussion is moot anyway.

Venus is worse. It may not have the higher gravity, but it DOES have the thicker atmosphere. It's also EXTREMELY hot(Runaway greenhouse effect). And has clouds...of Sulfuric Acid. Which leads to quite literal Acid Rain. Eve's hard to get off of. Venus is hard to SURVIVE on, even for probes.

Depends. If you take one of them to a lower orbit, it'll orbit faster and catch up to the other. Or you can take one to a higher orbit. It'll go slower, and the other will catch up to it. When they get close enough you can synch the orbits and start using more direct methods. There's some good rendezvous tutorial vids out there...I just don't happen to have any links to hand. :X

Because a lot of them started off making mods for KSP, as I recall...

Because it's easy. Jool, Dres, Eeloo, and Moho are all hard to get to, either because of the delta-V requirements (Moho, Jool, Eeloo), or because of irregular orbits (Dres, Eeloo), or both. Vall, Tylo, Bop, Pol, Eeloo, Dres, Ike, Gilly and Moho all lack atmospheres, which makes them much harder to land on. Some of them also have severe surface irregularities which makes it even harder. Gilly has the lowest gravity of anything, which makes it hard to land on at all. This leaves Eve and Duna as the easiest planets to reach and land on. Eve has the third highest gravity (after Kerbol and Jool) and second thickest atmosphere (after Jool) of any body in the Kerbol system, making it extremely easy to land on, but extremely hard to take back off from. You'd have to land something with substantially more delta-V than is required to escape kerbin, and you can't use jets because there's no oxygen. This leaves Duna. It has around twice the gravity of the Mun, but also has a (very thin) atmosphere. With good use of aerobraking, it can actually be easier to reach and land on Duna than to land on the Mun. And because of the low gravity and thin atmosphere, it's relatively easy to get off of: Duna's atmosphere at Datum is about as thick as Kerbin's at 8000 meters...and Duna's covered in highlands that are several KM above Datum, so you're fairly likely to end up with a surface pressure MUCH lower than that. Duna's downside? The thin atmosphere makes parachutes hardly work, so successful touchdown is a bit harder (in terms of both difficulty and frequently, in actual impact, which is why there's been so many weird landing methods for Mars probes) than on Laythe, Kerbin, or Eve. Edit: As for Laythe, it has a fairly thick, oxygenated (!) atmosphere, but a surface almost entirely covered in oceans. This makes finding a landing spot harder...but as there's oxygen in the air, you can actually use jet engines there. It's fairly hard to get there, and once you get there, it's a PILOTING challenge to actually get to a landing spot and land there. And a lot more fun of a challenge than trying to vacuum land on irregular terrain.

Actually, technically they broke the mods, and the broken mods broke the saves. I lost two flights in progress when 0.20 came out because they were using parts from a mod, and the parts wouldn't load in. The way it happened really whizzed me off and put me off KSP for awhile. I sent a new craft to the launch pad, and it informs me, on the pad, that it's unloaded two craft for missing parts. No prompt, no warning, nothing. Getting the parts to load in was an easy .cfg hack (it didn't make the mod work but it would've prevented the ships getting unloaded, and they could've sat until KAS was fixed), but it auto-saved AFTER unloading the craft. I *still* haven't gotten back to the point I was at when it happened, because I'm getting tired of redoing the same few things over and over.

Back in the days of yore, when we had KIA Portraits, there were only three Kerbals. Every flight, you got Jeb, Bill, and Bob. Even if they'd been killed on the previous flight. Also, how are you going to put a new kerbal in the pod when the pod was destroyed? The only way to kill a kerbal while having a portrait for them is to destroy the pod they're in. They don't get a portrait while EVA, not even when docked to a command seat.

Well, if I Recall something about there being Moholes as well...

From: http://docs.unity3d.com/Documentation/Manual/Plugins.html Suppose someone set up, say, PhysX version 3 (Which has multi-core physics support among other features we presently lack) so that it could be used as a Unity Plugin. Now instead of redoing everything from scratch, you only have to change the calls to the physics system.

Eyup. It's a very weird bug.

Test Rig 1+2: The hubmax parts have a weird issue where they'll only work properly if one particular node is used as the parent node. The rest of them result in it sitting there greyed out like that. Test Rig 3: You can't do this. The ships are built as a tree structure, each part can only have one parent. You can't make circular or square structures in the VAB, only Linear, branching ones. You can get around it by using the multi-docking feature, but only if you use actual docking PORTS. Docking ports are separate parts that have to be added on. They're called 'Clamp-o-Tron's, and come in three sizes. If you use pairs of ports, you can create the kind of structure you're going for. It'll still only actually be connected in the VAB on one side, but the other side will form a physical connection when it finishes loading. You could achieve the same effect in a non-removable form by using a strut to connect the unconnected joint.

Guys, it's an ancient thread some guy necro'd. Everything prior to Stupid Industries is out of date and inaccurate. Just ignore it.

Well there's already a table with all the relevant statistics... http://wiki.kerbalspaceprogram.com/wiki/Parts#Liquid_Fuel_Engines

I only worry about stuff in Kerbin orbit, particularly LKO, because I know with my luck, I'd beat the odds and get hit by something.

Watch someone do this and have their station just flat-out disappear because it somehow got within the despawn-unfocused-objects threshold of a planet (20km on Kerbin, I don't know if it varies).

For the benefit of anyone coming upon this evil necro thread: Unity DOES currently support 64 bit executables...poorly(in the case of windows at least, I gather there's 64 bit versions of KSP for Linux already). There's apparently severe stability problems at present when KSP is compiled as a 64 bit program, which is apparently the only thing preventing a 64 bit release. Performance wise, it *might* run better as a 64 bit program, but mostly it'd have access to more RAM. At present it's limited to 4GB by its 32-bit-ness. My KSP generally floats around 2.4GB, but I don't have many mods installed. The primary performance issue at the moment is Unity's old version of PhysX, which can only run calculations on a single CPU core. 32 bit or 64 bit isn't going to make a lick of difference there. Mostly, it'd just make it easier to have more mods installed, especially super memory hogging ones. The issues with PNG textures in mods massively exacerbate the scope of the problem, and when they're fixed it probably won't be nearly as bad.

You forgot about Bobak Kerman.

As people have said, the real problem is Unity. Specifically that they're still using ancient PhysX version 2. Plenty for most games, but not for one so physics heavy as this. I've heard stuff indicating that someone was working on a different physics engine for Unity, to be released as a plugin for the engine. Which could be fantastic for us, because it could potentially fix so many basic problems with KSP. Framerates with large ships (if it can use multiple cores and/or GPU acceleration) and the instability in orbital parameters (caused largely by Unity's old PhysX being unable to use floating point numbers and consequently introducing rounding error, or so I gather) for a start. Unfortunately, I also gather that development on said physics plugin has basically ceased, as it was one guy doing it and it sounds as if he's basically abandoned it. If some wonderful person were to make or port an alternate, better physics engine in a way that would allow the KSP team to easily integrate it into the game (PhysX 3, perhaps?), it would do so much to help the game in general it's not even funny. Double unfortunately I'm a hardware geek with only very minor experience in programming, or I'd just try and do it myself...