Project

General

Profile

Bug #1978

Leaving Warp causes changes in Pe and Ap.

Added by JohnFX over 10 years ago. Updated over 8 years ago.

Status:
Closed
Severity:
Very Low
Assignee:
-
Category:
Physics
Target version:
-
Start date:
12/17/2013
% Done:

100%

Version:
Platform:
Win32
Expansion:
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

Install fresh KSP.
load Kerbal X craft.
Launch to a roughly 80km orbit (not circular).
warp until just after Periapsis.
Set warp to 1.
Set warp to 0.

Your Apoapsis will be reduced, your Periapsis will be raised.

Rinse, repeat. If you pass Ap warp to after Pe. Eventually you will have a perfectly circular orbit using nothing but warp.

If you warp until after Ap and before Pe the effect is reversed. Your Ap is raised, your Pe is lowered.

This effect is independent of craft orientation. Prograde or retrograde makes no difference.

Not tested with higher orbits or planets other than Kerbin.


Related issues

Related to Kerbal Space Program - Feedback #3568: Ship Vanished in Orbit Around GillyNeeds Clarification11/25/2014
Related to Kerbal Space Program - Bug #2055: Encounter change while under normal physics. Closed01/29/2014

History

#1 Updated by JohnFX over 10 years ago

Here is a video of the effect in Vanilla KSP with the Kerbal X craft using windows 7 64bit 32Gb ram GTX 570 I7

http://www.youtube.com/watch?v=Tt_Zr0es_7k

#2 Updated by JohnFX over 10 years ago

After more testing this effect is centered on the halfway points between orbital markers. At Ap and Pe the effect is reduced below resolution. On an 80km orbit the largest effect is about 45m change to the height of each marker.

It is possible to deorbit a craft from an 80Km orbit using only this effect. The eccentricity of the orbit seems not to be a factor.

#3 Updated by BloodyRain2k over 10 years ago

That comes from the craft being on rails at warp and entering physics (leaving warp) makes micro wobbling adjust the orbit on that scale.
I think it's not really a bug but rather a side effect and I don't think it's easy to avoid.

And 45m jumps are a joke, make a 20m/s orbit around Gilly, your AP / PE might circle all around it constantly, the more circular (less eccentrical) the worse it gets.

#4 Updated by JohnFX over 10 years ago

Thank you for restating my bug report but I cannot see how your post was helpful. I have deorbited a craft with this effect and only posted the bug here after being urged to do so by a Mod who finally realised it was not the issue you are talking about. The effect is not changed by whether the orbit is circular or not, it just becomes more noticable. I have stated a very easy fix to this issue in the thread I started in the bug reporting area on the forum.

I am FULLY aware of the problems of which you speak which is why I have noticed this bug.

You are misunderstanding this bug on the most basic level. This is not a bug caused by circular orbits. This is a bug that will change your orbit whether it is circular or not and by choice you can make it more eccentric or more circular in a reliably predictable and repeatable (read that as fixable) way.
This bug is fixable but the problems with circular orbits are not.
This is not caused by the `problems of going from rails to physics` as you and a lot of people seem to think, it is a bug in the implementation of that. If you cannot see that one is hard maths with all its problems and one is a bug then please do not post here.

"the craft being on rails at warp and entering physics (leaving warp) makes micro wobbling adjust the orbit on that scale." this would not cause this effect which is consistant in applying force in the same direction and at a force which can be calculated as a sin (possibly) of the percentage of the distance between Pe and Ap with one side of the orbit giving a circularising effect and the other half increasing eccentricity.

A calculation error caused by insufficient resolution would not produce such a consistent predictable effect. This is not the issue you are talking about.

This is a bug in the calculations at the point of going on rail to off. It can be fixed by looking at that code and seeing the mistake. The issue you describe cannot and I would not report that as a bug.

To pre-empt anybody else who wishes to waste my time as has been done far too much in the other thread. You may think this is not a bug but it has been established by more than one mod that this is a bug, it is serious enough to be reported here and that I should do that which I have.

PLEASE DO NOT REFER TO THE PROBLEMS OF AN ORBIT WHICH IS TOO CIRCULAR HERE OR CALCULATION RESOLUTION LIMITS AS THIS IS NOT THOSE ISSUES YOU ARE CONFUSED AND YOU WILL CONFUSE OTHERS PLEASE DO NOT THREADJACK

Could people please read the sentence above before posting. Sorry for shouting, I have tried many times without in the other thread and people just want to argue...

#5 Updated by Ruedii about 10 years ago

This is clearly a (very) consistant rounding error when going between the rails on warp and the real-time physics.

Yes, it is a rounding error, however consistant it may be.

#6 Updated by JohnFX about 10 years ago

To pre-empt anybody else who wishes to waste my time as has been done far too much in the other thread. You may think this is not a bug but it has been established by more than one mod that this is a bug, it is serious enough to be reported here and I was advised that I should do that which I have.

Could people please read the sentence above before posting.

#7 Updated by TruePikachu about 10 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

JohnFX:
You appear to have misunderstood the other messages in this bug report. BloodyRain2k was stating (correctly) that the adjustments in the Pe and Ap are a result of physics being applied. When switching out of warp, every single part of the ship inherits the momentum that the ship had when in warp. Coupling this with the structural integrity of the ship proper (the distances each part is from each other), possibly also a result of SAS being active, there are minute changes in the actual momentum of the ship, which results in the changes of the orbit. They then went on to state how changes of 45m aren't very significant to the orbit proper, and gave an example of how the indicated points can move all over the place.
You then went on to explain how BloodyRain2k was incorrect in the analyses, assuming that both statements made were relevant to the bug as they interpreted it. You are correct in stating that the bug with circular orbits is not fixable, and then seem to state that this bug (#1978) is not caused by going rails->physics, but rather caused by going rails->physics. You then state that the correct issue (physics being applied) can't result in the issue you have, which indicates that force keeps being applied in the same direction, etc. each time, where it can (see later). However, and I can state this from experience, fixing bugs isn't always as easy as just looking at the code where it seems to happen, especially if the problem is because of bits of code from all over the place. You then state again that the issue is caused by rails->physics, which is correct. You then mention another thread (bug report here?), which might be benificial to have a link to, then correctly state that the bug isn't from circular orbits, but incorrectly state that it isn't from calculation limits.
Ruedii then repeats the correct statement that the bug is because of a calculation limit, and you then discount that statement again, believing that they are incorrect.

In 0.17, the physics engine was changed to make it so that rather then moving your ship all around space, space rather moves all around your ship. This was done to avoid the Kraken, but also makes it so that positions on the ship (I'm assuming relative to the center of gravity) are much closer to zero then before. This means that a small movement (say from 1 to 2) is, with respect to the floating point implementation (I'm assuming IEEE754), could be a full magnitude of change, which would result in the lowermost position of accuracy to be dropped. Then, with the slightly reduced accuracies, calculations are done, which result in numbers further and further from what would ideally be the case. This noise would end up certainly changing the orbit of the ship at least somewhat, with a more pronounced effect on some point the further one is from said point (which explains why the effect is most pronounced on the Pe and Ap when halfway between the two).

In end, the bug which this entry was created for is caused by errors with respect to floating point numbers, which might be fixable eventually by applying a slight bit of dampening on changes to velocity caused by parts moving about on the craft. A workaround would be to increase the precision, but this is pretty much only practical if the numbers aren't already doubles.

I have noticed that this does happen in 0.23, and might be related to #1219 (due to the identical effect - note that loading applies physics from what is effectivly on-rails).

As a final note, please remember that bug trackers serve as a means to find, research, and fix bugs. One of the most important things when researching a bug is to listen to what other people state, because they might have an idea as to why the bug manifests, or might know of further problems caused by the bug; this is especially true with community-availible bug trackers, since a wide variety of people can try to figure out the underlying cause, which often results in a wide variety of different possibilities for the cause. Not everyone will always be correct in figuring the cause of the bug; I myself have been wrong on numerous occasions. (And as a slight aside, if you work with other bug trackers (I've seen Mantis, Flyspray, and Mojira), you'll notice they have the capabilities of linking multiple bugs together, since oftentimes multiple bugs can have the same cause. For example, the result of the circular orbit bug is the same as the result of this bug, just not as pronounced as you describe, so the two would be considered Related)

#8 Updated by JohnFX about 10 years ago

Thank you for your reply and for confirming the bug. It is very possible I did not react well as I only posted here to get away from the bug forum where I had been badgered by a particular user about this until I was told that I had found a novel bug (which had not been posted on the bugtracker) by a Mod who understood what I was trying to say. I decided this problem should have a post on the bugtracker so it could be dealt with by the correct people. This is what I have done. All I wanted was to post the information describing the bug so that the people who actually deal with these issues (yourself I assume) could look at the information and make a decision as to exactly what was going on and decide whether it was worth addressing. This I have done. I did not and still do not wish to be engaged in a big debate about this. I just wanted to report the bug, how it manifests and an idea for a possible solution in this particular case and then get on with my life.

As a slight aside, I know abut the calculation problems you refer to, why Ap and Pe `wobble` when your orbit is fairly circular, and the moving universe as opposed to the moving craft and the calculation problems connected with this (or at least to the level described in the article about that) and the precision issues connected with going on and off rails. Using KOS (for automation) and this effect, I have deorbited a craft which was at a circular 80km orbit around Kerbin. This is how I noticed the effect, my KOS program could not reach Pe (IIRC) as leaving warp moved it so much my program tried to warp to it again. I now use this effect to get circular orbits (within 1m) using KOS and warp. I now just run a program I made called bugcirc. (which just warps to makes sure it is on the right half of the orbit and goes in and out of warp until the orbit is circular) and I get a perfectly circular orbit using no fuel. To my mind a rounding error would not be quite so predictable.

Whatever the cause, a very simple solution would be to simply adjust the values by the amount they are in error. If it is a rounding error (and by implication unfixable) then it is one that introduces such a predictable change in the values that it could be calculated based on your orbital information and eliminated in the case I have described by adjusting the underlying calculations. If it can be predicted, it can be mitigated. There is no need to increase precision.

#9 Updated by JohnFX almost 10 years ago

Truepikachu, I did misunderstand bloodyrain2K`s post (sorry bloodyrain2K) but I disagree with the conclusion still. The bug I reported was not an inevitable result of the process but an error in the calculation code for that process. One is not fixable the other very much is.

I have done some research on rounding errors and looked at the cases of the circularising bug as a result of so many people contradicting things I thought to be fact. I can now be more definite about my statements.

"the bug which this entry was created for is caused by errors with respect to floating point numbers" is not accurate. Errors in floating point resolution would produce a random effect, not a predictable one. Looking at the way the bug manifests eliminates this as a possible cause.

I can now say for sure this bug is neither of those. Rounding errors do not produce predictable effects due to their nature and the effect happened with all orbits, not just circular ones. These two facts eliminate those two possible causes.

On a nice note, it seems this bug has been eliminated in 0.23.5, looks like it was very possible to fix and may have been so easy that it was fixed in the course of going over the code for ARM...

I apologise for my harsh reaction to the effect I noticed being called a joke and for people telling over and over the error in calculation code was a rounding error (which produces different effects) I can understand now this is part of the process but I still cannot see how it helps. In this case they were a distraction from the actual bug.

IMO this bug has now been fixed. I have tested the same conditions with 0.23.5 and the effect is gone or is below altimeter resolution

To me the very fact the bug has been eliminated says that it was not an inevitable result of the way physics is handled in KSP or a rounding error and it was, in fact, a bug of the type I described.

In the last 32 years that I have spent finding bugs, I have found that `known bugs` often hide other bugs which have similar but distinct effects and can only be distinguished by knowing what sort of code manifests which sort of behaviour and being able to eliminate causes based on this. Relating bugs based purely on their effects (like the circular bug/rounding error and this one) can lead to bugs not being fixed.

This appears to be a case in point.

#10 Updated by Squelch over 9 years ago

Giving this a bump for visibility due to it possibly causing the unexplained loss of craft.

#11 Updated by Squelch over 9 years ago

  • Category changed from Bug Tracker to Physics

#12 Updated by Squelch over 8 years ago

  • Platform Win32 added
  • Platform deleted (Windows)

#13 Updated by RexKramer over 8 years ago

  • Related to Bug #2055: Encounter change while under normal physics. added

#14 Updated by Endersmens over 8 years ago

  • Status changed from Confirmed to Closed
  • % Done changed from 10 to 100

Also available in: Atom PDF