Reminds me of a time when I landed on the mun, and my lander tipped over on its side and broke my RCS so I couldn't stand myself back up. I launched that thing balls to the wall off a hill to get back into space.

This isn't done. I still have a lot of work to do with it. But I think if squashed most of the (die horribly when landing) bugs.
I am well aware of these issues.

- The icon for the gear is missing
- The gear is a tangled mess in the Vab, but works in the flight scene.
- The wing versions are not done yet.
- There are no textures or uv's for the model I slapped together for testing
- The source code is a mess, but will be posted soon. So if you don't trust the dll. Don't use it.

That said. Download this at your own risk, I can't guarantee anything as I'm still in the process of testing things out thoroughly....

I've been doing a lot of testing today, and I think I've found the exact cause of the bug people are calling the 'Deep Space Kraken'.

This, as it turns out, is a bit of a misnomer, because the Kraken does not live in deep space, as legend goes. It actually affects objects that move too fast, regardless of where they are.

The reason this was mostly noticeable in deep space is because Kerbin is actually orbiting at 8km/s around the Sun, so whenever you left Kerbin SOI for a sun-centered orbit, your physical velocity would increase by that much.

Apparently, 9km/s is a little too much for PhysX to handle. It will usually tolerate it with a simple ship, but the effects are noticeable with a ship as small as a pod attached to a tank.

So, what this means is that the Kraken isn't actually a bug. Not as far as coding mistakes go anyway. The Kraken is yet another PhysX limitation, and fixing it means we will have to set up some sort of workaround.

Fortunately, this isn't new to us by now. We've already hit physx limitations with planetary movement, rotation, floating point issues, so velocity is just another one really. And it's one that already has a solution, in a way.

Let me explain. Why is this problem not noticeable when you're orbiting Kerbin, if Kerbin is moving at 8km/s itself? The reason is that PhysX doesn't know Kerbin is moving. While you're orbiting Kerbin, the Sun is the one that's actually moving around the planet. So as far as physx is concerned, Kerbin is stationary, and its own velocity is just a number.

This is what the concept of Reference Frames is all about. KSP already switches back and forth several different frames as you play, so we would only need to add yet another one to compensate for the velocity restriction.

The plan is to create a speed limit, and check the main vessel's velocity against that. If it exceeds it, we clamp it down to the limit, and add the excess to the floating origin itself. This effectively creates a moving reference frame for the vessel, regardless of its orbiting body, and as far as physx is concerned, you will never actually exceed that velocity. It will stop increasing the ship's velocity, and start increasing the velocity of the universe around it.

The concept might sound familiar to those who were around when we implemented planetary rotations. Stop moving the ship, start moving the universe around it. This time, we are doing it with velocity instead of position or rotations, but the concept is the same.

Now, unfortunately, even though we know the cause, and have a plan to kill the Kraken bug, it's extremely unlikely we will be able to do this for the 14.2 release. There is simply no time, and the Kraken is a mild issue when compared to the much more serious problems we still have to deal with for this update. I just wanted to let everyone know that we are onto it, and I plan on fixing this as soon as we get to the 0.15 features.

It will stop increasing the ship's velocity, and start increasing the velocity of the universe around it. The concept might sound familiar to those who were around when we implemented planetary rotations. Stop moving the ship, start moving the universe around it.

NovaSilisko: for the love of god, never touch the 3ds max auto unwrapper ever again
NovaSilisko just saw the kosmos textures
CardBoardBoxprocessor: huh?
NovaSilisko: http://i.imgur.com/q5hNJ.png
NovaSilisko: this
CardBoardBoxprocessor: and?
NovaSilisko: that is the, frankly horrible, results of the 3ds max autounwrapper
CardBoardBoxprocessor: and yet you see no porblem with it on the screen shots
NovaSilisko: it's really, REALLY unoptimized, and leads to difficulties texturing
NovaSilisko: well
CardBoardBoxprocessor: perosnally i wish i had the time to unwrpa them by hand
CardBoardBoxprocessor: but I don't
NovaSilisko: if you want to ever give them textures that are more realistic (like i was going to try to, as an experiment) then they need to be unwrapped by hand...
CardBoardBoxprocessor: lol
CardBoardBoxprocessor: another reaosn why I do it like that'
CardBoardBoxprocessor: no one can fuck with it
NovaSilisko: why does that matter?
CardBoardBoxprocessor: i knew this day would come
CardBoardBoxprocessor: so i have a pre prehapred responce
CardBoardBoxprocessor: http://kerbalspaceprogram.com/forum/...p?topic=3491.0
CardBoardBoxprocessor: thre it is :D
CardBoardBoxprocessor: that is the reason
NovaSilisko: if someone makes a reskin without asking then you get up at them and tell them not to, rather than making the textures indecipherable to anyone who is willing to ask for permission
CardBoardBoxprocessor: i will never have god damn pnoy reskins ever
CardBoardBoxprocessor: but the real trick is
CardBoardBoxprocessor: I can add textures of i want. and still ahve i jarbelled up haha
NovaSilisko: that's very selfish, hoenstly
CardBoardBoxprocessor: hardly
NovaSilisko: well i wanted to make a reskin of the parts, based on real mir photos just to see if it'd work
NovaSilisko: i'd ask you before releasing but it's clear i can't
CardBoardBoxprocessor: if i was selfish i woudl ahve done it on purpose with different UV channles for wrapping and export.
CardBoardBoxprocessor: but yeah
CardBoardBoxprocessor: a good secondary to saving time is no reskins