Interplanetary Craft Rendezvous

[Vostok]

Today I returned my first Kerbal to land on Bop, by a difficult, stock, road.

I'd sent him there to find the Kraken (which he found), with no way of return, so I built a ship to return him. (it had a seat on it, no command pod) Due to a large oversight that left me orbiting Jool retrograde to Bop's orbit, I burnt all my fuel just getting into a bop orbit, and by the time I'd gotten the astronaut on board the rescue ship and into a Jool escape trajectory, I had nowhere near enough fuel to transfer back to Kerbin.

So I sent up a duplicate rescue ship and opted to rendezvous with him in interplanetary space.

This is where things went a bit strange.

Long story short, the rendezvous was completed, and the guy returned safely home and re-entered kerbin's atmosphere vertically at 5km/s (which was fun).

About the rendezvous, however. Has anyone else experienced some glitchy craft positioning behaviour in interplanetary rendezvous scenarios? At one point I had a ship jumping 2km every few seconds, and 10km every time I engaged time warp. There were a whole ton of strange things happening, incorrect relative velocity readouts, distance readouts (with the target referance on, of course). I would expect that this is caused by the Krakensbane.

Has anyone else has attempted this and had similar experiences? Or is interplanetary rendezvous a bad idea?

[Xaiier]

It likely it a result of the floating point precision errors (the Kraken). In solar orbit, your velocity is quite high and so that is probably more prominent. I don't think people do solar rendezvous often so I'm not sure how much is known about it.

[Death Engineering]

I've seen some very unusual behavior of vessels jumping around when engaging/disengaging time warp while doing a rendezvous in deep space to rescue three kerbals who just completed their Moho landing but didn't quite have enough fuel to reach Kerbin. Several orbits around around Kerbin later (and about 750 days if I recall), the rescue ship finally got to them.

As I approached to dock and time accellerated to close the distance between the two, the distance would jump from ~1400m to over 3000m. Made for a very slow docking since it had to be done in real-time.

[Kimberly]

Heck, I've seen it happen while in orbit around Kerbin. Even within visual range, the target ship might move a bit when you engage warp.

[Vostok]

hmm, do we think this is a large enough bug to be a problem? Maybe I'll submit a bug report.

[strongest_2hu]

This ship jumping around is exactly the behavior described in all (very few) posts I've ever seen in regards to solar orbit rendezvous.

[Oggula]

Yeah, when Scott Manley was doing videos the asteroid he was landing on jumped by 2km every time he warped. You'll just have to not use time warp...

[Goldham]

Once I tried to dock with a Satellite in orbit around the sun to bring it back to Kerbin and It ended up sending me at about 4x the speed of light

[stupid_chris]

It'S not a bug, as someone said, it's floating calculation errors. You can make those more precise, but there will always be small errors, and with higher speed it's more likely to happen.

[Vostok]

It can be resolved, though, surely? I thought there was a system to move the universe around the ship, rather than the other way round, to allow the errors to be smaller.

[soranno]

It can be resolved, though, surely? I thought there was a system to move the universe around the ship, rather than the other way round, to allow the errors to be smaller.

There is something delightfully kerbal about this way of thinking.

Problem?? I know! We`ll move the universe!

[stupid_chris]

It can be resolved, though, surely? I thought there was a system to move the universe around the ship, rather than the other way round, to allow the errors to be smaller.

Krakensbane indeed moves the universe around the ship, this way the errors caused from being so far away from the center of the universe are mostly negated. But that doesn't remove all the errors. If you expect an errorless system, you're in for a hard time. Interplanetary space is more prone to those errors due to the high speeds.

The best way to help cure this will probably be when Unity finally gets it's crap together and adds multithreading support. That will allow your computer to make much more floating point operations per second and reduce those errors. Until then, just be careful with time warp when docking in interplanetary space.

[KerbMav]

There is something delightfully kerbal about this way of thinking.

Problem?? I know! We`ll move the universe!

10/charrrr

Lt. Cmdr. Data: Can you recommend a way to counter the effect?

Q: Simple. Change the gravitational constant of the universe.

[Khrissetti]

I experienced this building my manned Moho ship in kerbin orbit, fortunately, when I went to 2x physical warp, the ship only hiccupped by about 200m, so with a little correction, I was still able to dock.

[hugix]

It can be resolved, though, surely? I thought there was a system to move the universe around the ship, rather than the other way round, to allow the errors to be smaller.

did you found that out in a dream?

[Merinsan]

Happened exactly like that for me. It's the reason I swear I will never do it again!

It'S not a bug, as someone said, it's floating calculation errors. You can make those more precise, but there will always be small errors, and with higher speed it's more likely to happen.

Um, that is the definition of a bug. It's something that could be fixed. I doubt it will be though, because it's simply too expensive computationally to do so

[stupid_chris]

Um, that is the definition of a bug. It's something that could be fixed. I doubt it will be though, because it's simply too expensive computationally to do so

A software bug is an error, flaw, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, defect reports, fault reports, problem reports, trouble reports, change requests, and so forth.

Source

It's not a bug. The program is working just as intended, everything goes fine. What is causing the problem is your own CPU while executing exactly the commands ordered by the game. A floating point error could be compared to your calculator rounding pi to 3.142 because it can only show four digits at a time. It's not a bug, it's just a calculation error, and those happen because time compression accelerates the simulation speed at the cost of precision.

[Merinsan]

Source

It's not a bug. The program is working just as intended, everything goes fine. What is causing the problem is your own CPU while executing exactly the commands ordered by the game. A floating point error could be compared to your calculator rounding pi to 3.142 because it can only show four digits at a time. It's not a bug, it's just a calculation error, and those happen because time compression accelerates the simulation speed at the cost of precision.

I've been a software developer for over 20 years now, and this is a bug. The very first line in your source specifies it's a bug, since it produces an incorrect result.

All bugs are caused by the CPU executing exactly the commands ordered by the software. If my calculator is telling me PI is 3.142, it's not correct. It's an approximation, and I might accept it for somethings, but it's not correct.

There are ways to completely eliminate this problem, however they are terribly inefficient, so it's never done. For example, you could represent values as 128 bit floating point numbers (not sure if the current values are 48 or 64 bit). You could also represent them using fixed point numbers rather than floating point. If you are willing to use enough memory/computational power, this can be solved. The game wouldn't run well, but it is solvable.

[stupid_chris]

It's not a bug as it's intended. The "bug" is time compression speeding up simulation. In that case it's called a feature. Else, you could call the lack of precision in Universe Sandbox when speeding up time a bug. You should be aware when you time accelerate that you are trading off precision for time. In that case, the solution to solving the said bug is removing the feature it actually is. If you want to remove those errors completely, the solution is simple: remove time compression.

Edited July 18, 2013 by stupid_chris

[draeath]

Floating-point arithmetic is why we can't have nice things.

DAR (backup tool) has a custom datatype that allows the use of 64-bit integers even on platforms without 64-bit integer support. I wonder just how much of a performance impact that would have... because it seems to me avoiding floats would solve this problem. Such a solution should give you possible values between (−(2^63)) and (2^63 − 1) which is a metric crapload of domain.

Time acceleration "errors" could be mitigated by interpolating position updates over several samples. This might limit the maximum acceleration you can handle a bit, but I can't imagine it would do so by much.