Think I have the fluctuating orbits thing figured out

[MaxPeck]

Not the solution, but I think I see WHY it's happening.  @NathanKell I think you were working this, so maybe this will help you.

So I had a station in a circular equatorial orbit at 350km.  I docked a module with it at a right angle to the station, and presto... madness ensued.  Just for fun though, I decided to crank that puppy up to 4X physics warp and watch what happened.  Here's what I observed:

The orbit isn't changing.  It is, but actually it's not.  I zoomed out and watched for a while and what I realized is that the apoapsis had actually become fixed in space, and the planet was pulling away from it.  This accounts for the fluxuations, on one side of the sun, the planet will pull away from the apoapsis, on the other side, it's going to move back towards it.  The orbit isn't changing, just the opposite.  The apoapsis is almost acting like it's disconnected from the body it's orbiting, and the body is pulling away from it and moving back towards it depending on where you are its solar orbit, and the apoapsis is acting like it's tidally locked to the sun.  So if I'm looking at the orbit of Kerbin from the top-down, and Kerbin is at the 3 o'clock position in relation to the sun, and my apoapsis is at the 3 o'clock position in relation to Kerin, then in half of an orbit, Kerbin will pull away from my apoapsis and my periapsis will be in the center of the planet, but it will appear in the micro scale that my craft has wandered several hundred kilometers off course by the time Kerbin gets to the 9 o'clock position in relation to the sun.  As it continues to the rest of its orbit, Kerbin settles back into it's original position in relation to the apoapsis, and everything looks normal again.  Well, except for the times the station re-entered before that happened, but it was all in the name of science, so Kerbal losses were expected.  If you start at the 6 o'clock position, you have a much better chance of completing an orbit.

Just to see if that was the case, I did the exact same experiment using RSS in sandbox, so that I'd have everything in a larger scale, and I observed the same phenomenon with a station orbiting Earth at 360 km in the same orientations (3 o'clock/ 3 o'clock), but much more pronounced due to the larger bodies involved.  And more re-entries because the station had no hope of completing an orbit.

So, hope that helps.

EDIT: I'm not usually a fan of hyperedit, but I downloaded it to try it out.  If I used HE from the tracking station to force the station back to it's normal orbit, then all of the weirdness went away. The station would stay in orbit, the ap and pe would behave as expected, and no phantom forces seemed to come into play - no random tumbling or other bizarre behavior.  Is it possible that the act of docking in orbit somehow breaks the link between the station's orbit and the body it's orbiting?

Edited May 26, 2016 by JJE64

[NathanKell]

Thanks, that's very interesting! I think, though, that that might be an artifact of other weird stuff. What's happening under the hood is that KSP uses Unity PhysX with a timestep of 20ms, and that's really bad for orbits. Prior to 1.1.1, (i.e. 1.1, 1.0.5, etc) KSP just applied the force of gravity (as calculated at the vessel's CoM) over that entire timestep (i.e. told PhysX that for that timestep there was a force of x m/s gravity * craftmass in the direction of planet's-core) To lower the error from that, I implemented a naive version of RK2 where the final force applied was the average of that force, and the force of gravity you'd have after that frame (i.e. after the gravitic acceleration was accounted for in velocity, velocity * 20ms was applied to position, and grav force recalculated for new position).

However, over break (I am bad at vacations) I was talking with ferram, and he poked me into looking at it again saying "no, obviously that will lead to continual decay". And it does. Because (if you, dear readers, haven't already seen this) the force of gravity at the end of the frame will always be stronger, so we're averaging a correct-at-that-point grav force with one that is stronger. (That's for reasonably circular orbits; highly elliptical ones can get weird, AIUI).

So there's three takeaways here:

1. Euler sucks.

2. Floats suck (We do all rails orbital calcs in doubles, and we calc the force of gravity using all doubles, but the force applied is a float because PhysX)

3. Badly implemented smarter integrators are not necessarily helpful.

I have already fixed the decay in git, although that does just put things back to dealing with points 1 and 2 (i.e. Ap and Pe fluctuate over time, but more cyclically and less constant downward trend). That is to say it is exactly like 1.0.5 and 1.1, except the Ap and Pe no longer flicker madly because the proper CoM is used.

I am also, with @taniwha, looking into further things we can do to stabilize orbits. I can make no promises as to whether the further stuff will make 1.1.3 or whether it will be delayed (or, heck, prove unworkable in our current codebase), but we have some good ideas, and ferram and eggrobin helped with said ideas as well--mostly around either harvesting (partial) data from rails-estimated position and velocity or by reworking how floating origins work.

[KerikBalm]

So are you saying that this affects eliptical orbits more than circular ones? In a perfectly circular one, would not the force of gravity be constant, so you'd just average two identical values?

If the force of gravity is calculated as higher than average, couldn't this just result in higher orbital velocities rather than decaying orbits? I still don't quite understand the problem.

[MaxPeck]

@NathanKell thanks for the feedback and the explanation. I wonder what the heck I had going on, if that's the case. 

[Majorjim!]

So it's possible there is no fix for decaying orbits?? Isn't that kind of a game killer?

[iffy]

So hang on a minute, an update was made to the system-

a) That was untested.

b) Just before vacation.

c) 'obviously wrong' as soon as someone else saw it, and borderline gamebreaking.

d) worked ok before.

Maybe a lesson to be learned somewhere?

In the meantime how about releasing your fix on githib as a patch/module/mod whatever until 1.1.3 arrives in few weeks?

cheers

 

[steuben]

Dang. I haven't seen Runge-Kutta invoked since second year diff-eqs. You may have to investigate higher order invocations of the RK mathamagics. Though as always you end up trading computation time for accuracy. I think it is fairly linear as you go up the scale, but folks more familiarity with O notation will be able to say yay or nay.

Now for the Monday morning quarterback, the armchair general, the high school philosopher... it is time for the forumite dev! <insert flashy graphic using 80's community access VTR equipment>

Using a simple case structure you can separate the analysis of the forces based on the eccentricity of the orbit. As it increases you increase the order of the RK calculations. At a certain point the eccentricity is nearly linear so the error in those cases is small when using the basic approximations, and can be considered both the trivial and degenerate case. An analysis can be done that will determine the best breakdown of order of RK versus eccentricity versus error size versus calculation time.  Given this I can project that it will take on---

<insert video and audio of analog transmission static>

Sorry, that fellow slips out every once in a while. It's especially bad since I have panicked and crashed compilers in 6 languages, not counting major dialects, on 7 systems, with the classic "Hello world" code. I never really got beyond that in terms of practical coding.

Most of what I just outlined was probably considered at some point in the process. As I sometimes say to the people I work with, "simplicity of the solution is always inversely proportional to the knowledge of the problem".

Good luck with the solution, I know it will arrive when it arrives and not before that.

 

 

[steve_v]

22 minutes ago, iffy said:

Maybe a lesson to be learned somewhere?

Yup, don't make changes like this just before going on holiday.

Nice to see some progress getting to the bottom of it though.

[monophonic]

1 hour ago, iffy said:

So hang on a minute, an update was made to the system-

a) That was untested.

b) Just before vacation.

c) 'obviously wrong' as soon as someone else saw it, and borderline gamebreaking.

d) worked ok before.

Maybe a lesson to be learned somewhere?

In the meantime how about releasing your fix on githib as a patch/module/mod whatever until 1.1.3 arrives in few weeks?

cheers

 

Yup, and not just one change either:

As someone who has been there and done that I feel really sorry for @NathanKell; Any half-decent QA process should have stopped these on their tracks before they reached a release. Any fully decent process would have stopped them before reaching the master branch. But we know how rare a fully decent QA process is on the enterprise software side of the business, and we're swimming in budget compared to game industry.

[Fearless Son]

On 5/26/2016 at 11:51 PM, NathanKell said:

2. Floats suck (We do all rails orbital calcs in doubles, and we calc the force of gravity using all doubles, but the force applied is a float because PhysX)

Reminds me of an asteroids clone I made in college.  The asteroids were rendered as semi-circular vectors, with each vertex offset by a slight amount of randomness to give them a jagged "rocky" look.  They would then rotate around at a random rate and drift at a random velocity.  

I left the application running (minus player collision) one Friday, and came back to my work station the next Monday, to find that some of the asteroids had gotten huge, while others had shrunk.  Turns out that the calculations I was doing to rotate them were introducing tiny rounding errors in the float values of the positions of their vertexes, and those errors added up over the two days it was left running, either pulling it into a wider state or pushing it into a shrunken one.  

[The_Rocketeer]

@NathanKell I appreciate the honesty of your reply to this thread. Some elements of this community have made it clear that they're feeling pretty hostile about the effect the recent update has had on their precious leisure time, so I can see that it takes a little grit to lay it out straight and admit to oversights or mistakes. While I have no personal experience of videogame development, I can sense from various posts how complicated the Unity upgrade must have been and how frustrated you must now be considering many problems it has caused/revealed. I also really appreciate that you took time out of your vacation to look into this one - that's above and beyond in my book.

If I understand you correctly, this particular issue right now is marginally improved since 1.0.5 (flickering apo/periapsis solved)? If so, would I be right in thinking that, at least in a minor sense, orbit instability was an issue that was bound to rear it's ugly head sooner or later, but that the 1.1 upgrade has simply cast a light on it now? That being the case, I for one am glad the problem has now become clear and you will be able to try and do something about it.

[Gaarst]

5 hours ago, Majorjim said:

So it's possible there is no fix for decaying orbits?? Isn't that kind of a game killer?

When you have a bug you can't fix, make it a feature: time to add orbital decay to KSP !

[Majorjim!]

Just now, Gaarst said:

When you have a bug you can't fix, make it a feature: time to add orbital decay to KSP !

Even on airless bodies? NO thanks.

 

On 05/26/2016 at 8:51 AM, NathanKell said:

or, heck, prove unworkable in our current codebase

This concerns me greatly. Is that true that it might not be possible to fix?

[Gaarst]

5 minutes ago, Majorjim said:

Even on airless bodies? NO thanks.

Time to add an atmosphere to Moho, Gilly, the Mun, Minmus, Ike, Vall, Tylo, Bop, Pol and Eeloo

[adsii1970]

It's bad enough having the issue with wheels and the landing gear.  Now this? I look forward to a KSP without these kinds of bugs...

 

[Fearless Son]

26 minutes ago, Majorjim said:

Even on airless bodies? NO thanks.

This concerns me greatly. Is that true that it might not be possible to fix?

The implication I got from @NathanKell's response is that he has already implemented a partial fix in their development build which, if not eliminating the fluctuations that lead to decay, at least even those fluctuations out so that on average they stay the same.  He is currently looking into more robust methods to correct the issue, but if those do not pan out he might need to do a fix that requires more radical code restructuring, which can take a lot of time and potential introduce other issues which might be even less desirable.  

[tseitsei89]

On 26.5.2016 at 10:42 AM, KerikBalm said:

 

If the force of gravity is calculated as higher than average, couldn't this just result in higher orbital velocities rather than decaying orbits? I still don't quite understand the problem.

It could. There are two possibilities however. Because circular motion is described by the equation F=mv²/R or in this cas G=m(v_orb)²/R 

Where G is gravitational force affecting your ship, v_orb is current orbital velocity and R is the radius of your orbit

Now your vessel mass will remain constant. If G is calculated to be higher than it should be then you must either increase v_orb OR decrease R in order to balance the equation.

But in the simulation you probably take G and orbital velocity and calculate new location (R)  after the time step using those and that is why R is decreasing instead of v_orb increasing.

 

At least that's how I think it works...

[Kerbonaut257]

So are we discussing the bug of orbital decay happening? It's freakin annoying I must say :/

 

 

[NathanKell]

Let me try to clear some things up, since it looks like I stepped in it.

1. The reason I told people to try a single-part craft in prior versions, in the dev notes, is because this is not a new issue.

2. It was masked, for multipart vessels, by an even bigger bug: the wrong position was used for orbital calculations, and therefore rotating your vessel could drastically change the (stated) orbit, despite your velocity not really changing.

3. I fixed that bug for 1.1.1, over a week before vacation.

4. That unmasked bug 1.

5. I then, same day, implemented the RK2 bit to try to lower the drift observed. It did lower the drift observed, by over an order of magnitude.

6. I therefore pushed the changes.

7. Throughout the following week, QA and exp did indeed flag there was drift and decay, but see 1: that was not a new issue, and I knew I had lowered its magnitude, and therefore felt comfortable with keeping the change.

8. However, over vacation, it was conclusively demonstrated that unlike bug 1, the drift was no longer cyclical, it tended more towards decay than simple cycling drift. Please see towards the end of last week's dev notes for some good folks digging into detail on that, which was very helpful.

9. On return, I therefore reverted 5, leaving us back at 2.

 

Is that clearer? As of now (and thus for 1.1.3) the magnitude of the drift is the same as it was in 1.0.5 and prior versions of KSP, i.e. worse than 1.1.2, but it does not lead to steady decay over time, merely cycling. As I said taniwha and I are looking into how to decrease it without making the drift unidirectional, but again as I said I make no promises as to how long that might take.

 

Once again I reiterate that the drift, per se, is NOT A NEW BUG. And if you take a minute to check with a single-part craft in 1.0.5, you will see that. If you have survived that issue for literally three years of KSP, I dare say you can survive it a bit more.

 

And, also tl;dr: don't blame QA. They certainly noticed it. But see #7 above.

[Greenfire32]

8 hours ago, Majorjim said:

So it's possible there is no fix for decaying orbits?? Isn't that kind of a game killer?

 

5 hours ago, iffy said:

So hang on a minute, an update was made to the system-

a) That was untested.

b) Just before vacation.

c) 'obviously wrong' as soon as someone else saw it, and borderline gamebreaking.

d) worked ok before.

Maybe a lesson to be learned somewhere?

In the meantime how about releasing your fix on githib as a patch/module/mod whatever until 1.1.3 arrives in few weeks?

cheers

 

 

2 hours ago, adsii1970 said:

It's bad enough having the issue with wheels and the landing gear.  Now this? I look forward to a KSP without these kinds of bugs...

 

 

17 minutes ago, Kerbonaut257 said:

So are we discussing the bug of orbital decay happening? It's freakin annoying I must say :/

 

 

Le sigh...How I long for the days when KSP simply delayed broken updates instead of pushing them out anyway...

 

12 minutes ago, NathanKell said:

Once again I reiterate that the drift, per se, is NOT A NEW BUG. And if you take a minute to check with a single-part craft in 1.0.5, you will see that.

Yeah...technically it might have been there, but we certainly didn't notice it until now so. So now our orbits are decaying at rapid pace without reason, and now our wheels don't work, and there's a 50/50 chance your landing legs will work. And has the Klaw been fixed yet? Never really heard a solid answer on that, IIRC. Slowly but surely aspects that make the game work are dying. No doubt you guys all deserve a vacation, but in it's current state, this last update to KSP should NEVER have been released. It's embarrassing enough as a player, I can't even imagine how it is as a developer.

And if this new version of Unity makes it impossible to fix certain new bugs, then I HAVE to ask WHY the decision was made to go ahead with it. A lot of people won't "upgrade" to Win10 (myself included) because it breaks more than it fixes. Was 64-bit support worth breaking the game?

I cant imagine it would be.

13 minutes ago, NathanKell said:

If you have survived that issue for literally three years of KSP, I dare say you can survive it a bit more.

Again, first time we're noticing it in any real capacity (the problem is real enough that it now has a thread dedicated to it)....and talking down to your customer base is super cool too. We'll all love you for that.

[The_Rocketeer]

22 minutes ago, Greenfire32 said:

Again, first time we're noticing it in any real capacity (the problem is real enough that it now has a thread dedicated to it)....and talking down to your customer base is super cool too. We'll all love you for that.

So @NathanKell, a dev, comes on the forum and tells us:

• they've identified 2 separate bugs
• they know the causes of the bugs
• they already have a partial fix
• it is already in next patch
• the problem has been around for years and nobody ever really noticed it
• they have ideas to pursue for how to reduce it further
• that he, personally, took time out of his vacation to look into this

and your response is basically to say how little you appreciate being patronised?

I think some people round here could probably use a break from KSP - they take this stuff way, way too seriously.

[Kerbonaut257]

I'm not here to complain directly to squad staff. 

But this is a literally gameplay breaking bug. Many of us expect our orbits to, ya know, remain stable. Especially for things like remote-tech. I literally have to resort to cheating the orbital periods to equal because as soon as I focus the craft, it begins getting a shorter orbital period. Then, if I want to re-aim the dishes on said satellites, then I have to go back in and cheat the orbit back again. This is ridiculous.

 

I can't imagine the fix is THAT difficult. And would have been done in mere days if the patch hadn't been released before vacation. I doubt that was squads idea. But seriously. Who posts a big patch RIGHT before vacation without time to QA & bugfix? I am here to complain directly to whoever made that decision.

[radonek]

So decay bug happened because wobbly orbits issue is being worked on? Thats actually good news in my book.
 

[Majorjim!]

1 hour ago, NathanKell said:

Once again I reiterate that the drift, per se, is NOT A NEW BUG. And if you take a minute to check with a single-part craft in 1.0.5,

How and why would I have a single part craft in orbit? I guess that is why I never noticed it. So it happens now under a different guise for multi-part craft now am I right?

 

 

Edited May 27, 2016 by Majorjim

[MaxPeck]

Jesus Smoking Christmas, guys.  I made a simple observation.  @NathanKell was good enough to come on here and address it specifically and in great detail (thank you, Nathan!), without making excuses or obfuscating.  Can we possibly have one thread that doesn't involve us collectively keel-hauling the devs over everything?  I'm the last person to defend Squad's business practices, and I've been very vocal in my opinions about them, but even I have to admit the rancor is reaching the point of ridiculousness.  

If you continue to chastise these guys every time they speak, even when they're giving answers that they don't have to give, in levels of detail that they're not obliged to provide, eventually they're going to stop communicating with the community.  He could have just given a simple, "gee, thanks, that's interesting" and let it go, but he didn't he tried to be forthright with us, but we just can't resist the urge to punch down at every opportunity.  Give the guys a break, already.

Thank you, @NathanKell for addressing my OP.  I appreciate it.