[1.8.x, 1.9.x, 1.10.x] Orbital Decay Updated

[linuxgurugamer]

Originally written by @Whitecat106, this mod introduces the idea of decaying orbits.  Original thread here: https://forum.kerbalspaceprogram.com/index.php?/topic/116818-1

Adopted by @Papa_Joe, he compiled it for a later version of KSP (1.4), thread is here:  https://forum.kerbalspaceprogram.com/index.php?/topic/175618-1

I've adopted it, fixed a lot of bugs (see list below), and am continuing it now.

What does it do?

• On rails and off rails orbital decay for any vessel around any celestial body, this decay is determined by various factors, such as atmospheric drag, radiation pressure drag and more!
• Estimated impact times are given for each vessel.
• Station Keeping for active and non active vessels. Supports all KSP Resources.
• UI interface for predicted decay times and vessel information.
• The above work during time-warp!

 

Known Incompatibilities: (Major, Minor)

- RSS Extrasolar - Sagitarius A* causes problems with the coding of the mod, use at your own risk. Similarly other 'galactic core mods' may cause problems - To be fixed in 1.6.0

- Mechjeb autopilot can fail when nearly reaching a set altitude due to drag reducing the actual altitude - Fix in 1.6.0, other autopilot mods may be effected.

Note:  This mod now has dependencies:

• Click Through Blocker
• ToolbarController
• SpaceTuxLibrary
• Solar Cycle Simulator

 

 

Current in BETA, availability:

• Source:  https://github.com/linuxgurugamer/OrbitalDecay
• Download: https://github.com/linuxgurugamer/OrbitalDecay/releases/tag/1.7.0.3
• License: CC-BY-NC-SA 3.0

Will be available in CKAN when full release

Edited August 26, 2020 by linuxgurugamer

[Daniel Prates]

This  being in open beta, let me share my findings insofar.

My observations:

I launched a test vehicle to the lowest altitude I can reach with alt+12, which is  86.750m. is that the threshold where decaying starts?  It appeared to happen very slowly, then increasing in decay speed (as it should, btw, in real life, as you plunge deeper inside thicker atmosphere). I then alt+12 another craft to way higher, 6267km (whit is 3/5 of the way to the mun), and watched it from the tracking station. There it stayed with no decay whatsoever even after 50, 60 days.

Is decay only happening up to a certain altitude, or anywhere within the SoI? I mean, after a hundred days there was not even a meter of decay for that very high orbit test craft. It only appears to happen in much lower orbit.

There is certainly some bugginess. I was not able to reproduce both of those consistently, but will report anyway: 

a) in a certain flight, it appeared as if the decay happened, but didn't compute on the orbit or spacecraft view. Orbit of 86km would never fall, but I switched to the tracking station, and there it was much lower. Another time I also say no decay for several hours in very LKO, but changed to tracking station, and the craft was instantly gone (presumed crashed). What appears to be happening is that the dacay is being computed all the time, but does not register in all relevant displays (in this case, it did show in the tracking station but not when I was staring directly at the craft's altitude meter). 

b) trying to reproduce the above on one ocasion, i set a 100k orbit. No change whatsoever, it seemed above the decay threshold. When however I went to the tracking station to see what happenned .... BOOM, it was inexplicably higher than Minmus's orbit. The bug simply shot it waaaaay higher into orbit.

I am not sure how to get the proper logs, please guide me to that effect. 

[linuxgurugamer]

Useful info here from the older thread (which I'll need when I have a bit more time to dig into the issues)

and here:

and here: 

and: 

 

[linuxgurugamer]

In addition to the information found in the other thread, test cases are needed.  Specifically, make it fail or error in a repeatable manner, and let me know about how to reproduce it

[FreeThinker]

@linuxgurugamer I m currious how do you calculate vessel drag? Does facing have any effect?

[linuxgurugamer]

14 minutes ago, FreeThinker said:

@linuxgurugamer I m currious how do you calculate vessel drag? Does facing have any effect?

Keeping in mind that I haven't done a deep dive into this code yet, what I've seen is that it's doing a generic calculation based on some stats.  

Actually, it does appear that it gets the mass of the vehicle, see the VesselData.cs, line 355: 

 https://github.com/linuxgurugamer/OrbitalDecay/blob/e0d4a511aeaf66c88e94bfa128e9009771d345de/OrbitalDecay/VesselData.cs#L355-L376

It also calculates the vessel area, see, same file, line 261-295

https://github.com/linuxgurugamer/OrbitalDecay/blob/e0d4a511aeaf66c88e94bfa128e9009771d345de/OrbitalDecay/VesselData.cs#L261-L295

 

and I can't see any reason to do anything deeper.  This is meant to be an approximation, no way it can be totally accurate

Edited August 2, 2020 by linuxgurugamer

[FreeThinker]

4 hours ago, linuxgurugamer said:

Keeping in mind that I haven't done a deep dive into this code yet, what I've seen is that it's doing a generic calculation based on some stats.  

Actually, it does appear that it gets the mass of the vehicle, see the VesselData.cs, line 355: 

 https://github.com/linuxgurugamer/OrbitalDecay/blob/e0d4a511aeaf66c88e94bfa128e9009771d345de/OrbitalDecay/VesselData.cs#L355-L376

It also calculates the vessel area, see, same file, line 261-295

https://github.com/linuxgurugamer/OrbitalDecay/blob/e0d4a511aeaf66c88e94bfa128e9009771d345de/OrbitalDecay/VesselData.cs#L261-L295

 

and I can't see any reason to do anything deeper.  This is meant to be an approximation, no way it can be totally accurate

That might have worked in the past but a vessel no longer have the property "Mass" and "Area", so it no longer works as it once did. When it fails it assumes an value of 1, meaning all vessels have a mass of 1 and a surface area of 1

Also notice its using GetTotalMass() , which will not work for offloaded vessels. To get the total mass, you need to calculate it manualy from adding all parts masses

Looking at it more closely, I found there is a method public static void UpdateActiveVesselData(Vessel vessel) which saves Mass and Area in the vessel config node whenever the vessel is active. This means orbital decay will only work after switching to a vessel after you install this mod

Edit: VesselData.FixedUpdate and  Decaymanager.FixedUpdate  need a serious rewrite as it contains a lot of code code which causes n^n permuttons for the number of vessels. It also assumes that method like vessel.GetTotalMass() work correctly all times but they don't, which will lead to large vessels decaying much faster than they should

Lol, found the following text in the file "READ BEFORE UPLOADING":

Quote

-- I am currenly working on a new confignode system basically rewriting the VesselData.cs file,
please only submit pull requests for the DecayManager.cs at the moment!

That sentence is 4 years old. So at least one of the programmer who worked on it was aware of the code problems

Edited August 2, 2020 by FreeThinker

[Daniel Prates]

I did another round of testing. Can confirm that my spacecraft does not decay when I follow it loaded and in craft view, but when I switch to the tracking station, there it decays normally. If I return to  craft view and back to the tracking station and so on,  the problem will persist: no decay when vessel is loaded, decay when in tracking station.

[linuxgurugamer]

I hope to be able to get back to this soon.  I currently have 6 mods in beta, as soon as I can move some to a release state, I should be able to take a look at this again.

Given the state of the code, not sure yet what I'm going to do with it.

On 8/2/2020 at 2:14 PM, FreeThinker said:

vessel.GetTotalMass()

So if this isn't valid, what is?  and, would you know what situations it is and is not valid?

Edit:  Did a little research before bed, I didn't find anything recent mentioning that GetTotalMass is inaccurate.

I suppose I could just write my own for both loaded and unloaded, it's just looping through all the parts, adding the mass of the part and the mass of all the resources (Parts for loaded vessels, and the protovessel equivalents).  But I would like some clarification on this, if you can provide any.

Edited August 12, 2020 by linuxgurugamer

[FreeThinker]

3 hours ago, linuxgurugamer said:

So if this isn't valid, what is?  and, would you know what situations it is and is not valid?

When vessel.loaded = false you need Something like this

            // calculate vessel mass
            TotalVesselMassInTon = 0;
            foreach (ProtoPartSnapshot protoPartSnapshot in Vessel.protoVessel.protoPartSnapshots)
            {
                TotalVesselMassInTon += protoPartSnapshot.mass;
                foreach (ProtoPartResourceSnapshot protoPartResourceSnapshot in protoPartSnapshot.resources)
                {
                    TotalVesselMassInTon += protoPartResourceSnapshot.amount * protoPartResourceSnapshot.definition.density;
                }
            }
            TotalVesselMassInKg = TotalVesselMassInTon * 1000;

Edited August 12, 2020 by FreeThinker

[linuxgurugamer]

4 hours ago, FreeThinker said:

When vessel.loaded = false you need Something like this

            // calculate vessel mass
            TotalVesselMassInTon = 0;
            foreach (ProtoPartSnapshot protoPartSnapshot in Vessel.protoVessel.protoPartSnapshots)
            {
                TotalVesselMassInTon += protoPartSnapshot.mass;
                foreach (ProtoPartResourceSnapshot protoPartResourceSnapshot in protoPartSnapshot.resources)
                {
                    TotalVesselMassInTon += protoPartResourceSnapshot.amount * protoPartResourceSnapshot.definition.density;
                }
            }
            TotalVesselMassInKg = TotalVesselMassInTon * 1000;

Isn't that exactly what I wrote:

 

8 hours ago, linuxgurugamer said:

I suppose I could just write my own for both loaded and unloaded, it's just looping through all the parts, adding the mass of the part and the mass of all the resources (Parts for loaded vessels, and the protovessel equivalents).  But I would like some clarification on this, if you can provide any.

But asking again, what circumstances does the original GetTotalMass() fail?  I've observed in the times I've used it (>1.4.5, I believe) that it's always been accurate.

What I may do to answer this question is to write a little mod which will show all vessels's mass both ways, and dump that to a file along with whether the vessel is loaded or not.

8 hours ago, linuxgurugamer said:

looping through all the parts, adding the mass of the part and the mass of all the resources (Parts for loaded vessels, and the protovessel equivalents). 

I'm pretty sure that, at least recently, the GetTotalMass does it correctly, but my minimod which I'll write will show that or not.

[FreeThinker]

On 8/12/2020 at 2:03 PM, linuxgurugamer said:

Isn't that exactly what I wrote:

 

But asking again, what circumstances does the original GetTotalMass() fail?  I've observed in the times I've used it (>1.4.5, I believe) that it's always been accurate.

What I may do to answer this question is to write a little mod which will show all vessels's mass both ways, and dump that to a file along with whether the vessel is loaded or not.

I'm pretty sure that, at least recently, the GetTotalMass does it correctly, but my minimod which I'll write will show that or not.

Well in my test, (it might be related to KSP version) when a vessel was unloaded, GetTotalMass  only gave back the mass of a root part. We (me and @Standecco) had to add additional logic to ensure it we get total vessel mass

Edited August 14, 2020 by FreeThinker

[linuxgurugamer]

4 hours ago, FreeThinker said:

Well in my test, (it might be related to KSP version) when a vessel was unloaded, GetTotalMass  only gave back the mass of a root part. We (me and @Standecco) had to add additional logic to ensure it we get total vessel mass

When was the last time you did that test?  I do remember a problem like that back in the day, but I think they fixed that

[FreeThinker]

5 hours ago, linuxgurugamer said:

When was the last time you did that test?  I do remember a problem like that back in the day, but I think they fixed that

About a month ago. There has also been a discussion on the kerbalism discord about it. We originally calculated the drymass durring a vessel was loaded and added the resource mass to get to the total mass

 

Edited August 14, 2020 by FreeThinker

[linuxgurugamer]

21 hours ago, FreeThinker said:

About a month ago. There has also been a discussion on the kerbalism discord about it. We originally calculated the drymass durring a vessel was loaded and added the resource mass to get to the total mass

 

And I just confirmed it's still a problem in 1.9.1 :-(

 

Ok, thank you for bringing this to my attention.  Now I need to figure out how to get it properly.

 

Edit:  I now have a working method to return the total mass of an unloaded vessel, will be included in next beta of this mod

Edited August 15, 2020 by linuxgurugamer

[linuxgurugamer]

@FreeThinker

I've opened a bug ticket here:  https://bugs.kerbalspaceprogram.com/issues/25964

Could you take a look and confirm it?

[Standecco]

Can confirm the issue: as @FreeThinker said, we've encountered it while updating PersistentThrust to work in background. I've upvoted the bug report and looked a bit into why it happens.

It looks like they are ignoring all parts with no resources - that is, they are only counting the mass of the parts that contain at least one resource. The reported mass is therefore actual mass - base mass of parts with no resources.

 

@linuxgurugamer your code will work, but I think you forgot a + in the 7th line: it should be 

num += (double)protoPartSnapshot.mass;

rather than 

num = (double)protoPartSnapshot.mass;

 

[FreeThinker]

3 hours ago, linuxgurugamer said:

@FreeThinker

I've opened a bug ticket here:  https://bugs.kerbalspaceprogram.com/issues/25964

Could you take a look and confirm it?

Confirmed and upvoted

Edited August 15, 2020 by FreeThinker

[linuxgurugamer]

4 hours ago, Standecco said:

@linuxgurugamer your code will work, but I think you forgot a + in the 7th line: it should be 

num += (double)protoPartSnapshot.mass;

rather than 

num = (double)protoPartSnapshot.mass;

 

Notice the underlines? That's the += being misinterpreted by the web software.

I've posted a correction, the following is what I originally pasted:

        private static  double GetUnloadedVesselMass(string name, ProtoVessel protoVessel)
        {
            double num = 0.0;
            for (int i = 0; i < protoVessel.protoPartSnapshots.Count; i++)
            {
                ProtoPartSnapshot protoPartSnapshot = protoVessel.protoPartSnapshots[i];
                num += (double)protoPartSnapshot.mass;
                for (int j = 0; j < protoPartSnapshot.resources.Count; j++)
                {
                    ProtoPartResourceSnapshot protoPartResourceSnapshot = protoPartSnapshot.resources[j];
                    if (protoPartResourceSnapshot != null)
                    {
                        if (protoPartResourceSnapshot.definition != null)
                        {
                            num += protoPartResourceSnapshot.amount * (double)protoPartResourceSnapshot.definition.density;
                        }
                        //else
                        //    Debug.Log("Vessel: " + name + ", resource: " + protoPartResourceSnapshot.resourceName + ", no definition");
                    }
                }
            }
            return num;
        }

 

Edited August 15, 2020 by linuxgurugamer

[linuxgurugamer]

New beta, 1.7.0.1

• Fixed vessel mass calculation for unloaded vessels
• Rewrote the VesselData.cs to use internal class instead of confignodes
• Replaced ConfigNode structure with Dictionary using vessel id (GUID), huge speedup
• Fixed bug in DecayManager, which in CheckVesselProximity was comparing the vessel to itself and getting 0, this was preventing any decay from happening during timewarp Misc. cleanup in DecayManager

On 8/3/2020 at 1:00 PM, Daniel Prates said:

I did another round of testing. Can confirm that my spacecraft does not decay when I follow it loaded and in craft view, but when I switch to the tracking station, there it decays normally. If I return to  craft view and back to the tracking station and so on,  the problem will persist: no decay when vessel is loaded, decay when in tracking station.

Please try with the new beta, I found the problem and craft will decay.  If timewarping, the screen may not be updated, but will be once you leave timewarp.

[Starseeker]

What versions should this beta be compatible with?

Edit: didn't read title before I posted, whoops

Gonna grab this and try it out, see how well it works on scaled-up systems like JNSQ!

Oh, a question: are there any known incompatibilities between Solar Cycle Simulator and Kerbalism?

Edited August 18, 2020 by Starseeker

[linuxgurugamer]

On 8/2/2020 at 2:14 PM, FreeThinker said:

Edit: VesselData.FixedUpdate and  Decaymanager.FixedUpdate  need a serious rewrite as it contains a lot of code code which causes n^n permuttons for the number of vessels. It also assumes that method like vessel.GetTotalMass() work correctly all times but they don't, which will lead to large vessels decaying much faster than they should

I've rewritten the VesselData.cs, uses a dictionary now, no more permutations n^n.  Also, GetTotalMass has been replaced with my new method

[Daniel Prates]

Hmmm ... decay is fixed but it is now doing the weirdest of oddities: the game seems to 'stutter', I can see Kerbin 'rewinding' a few kilometres backwards every few seconds in a stutter-like fashion. Using alt12 to set different orbits sometimes work, but sometimes you do in during a 'stutter' and the craft reverts back to the previous altitude .... It is like the stutter is the game rewinding a little bit back in time every few seconds. 

Cool huh? Maybe Lois Lane just died and SuperKerbal is flying at full speed around Kerbin to reverse time and bring her back to life. 

Anyway, I am using a fresh install,  but with the versions of toolbar, solar cycle etc. that were valid a few weeks ago,  I will try reinstalling the whole thing anew and see what happens. But before I do @linuxgurugamer, one thing. The zip of the new version has a lot of stuff in there. Do in need to use everything, an 'xxxx' file included, or only the orbital decay folder?

Edited August 18, 2020 by Daniel Prates

[linuxgurugamer]

1 hour ago, Daniel Prates said:

Hmmm ... decay is fixed but it is now doing the weirdest of oddities: the game seems to 'stutter', I can see Kerbin 'rewinding' a few kilometres backwards every few seconds in a stutter-like fashion. Using alt12 to set different orbits sometimes work, but sometimes you do in during a 'stutter' and the craft reverts back to the previous altitude .... It is like the stutter is the game rewinding a little bit back in time every few seconds. 

Cool huh? Maybe Lois Lane just died and SuperKerbal is flying at full speed around Kerbin to reverse time and bring her back to life. 

Anyway, I am using a fresh install,  but with the versions of toolbar, solar cycle etc. that were valid a few weeks ago,  I will try reinstalling the whole thing anew and see what happens. But before I do @linuxgurugamer, one thing. The zip of the new version has a lot of stuff in there. Do in need to use everything, an 'xxxx' file included, or only the orbital decay folder?

Hmm. 

Any chance you have two copies installed?

Which file did you download?  you should have downloaded this:  https://github.com/linuxgurugamer/OrbitalDecay/releases/download/1.7.0.1/OrbitalDecay-1.8.0-1.7.0.1.zip

A complete view of the directory with files is this, if you have anything else, then something's wrong:

[Starseeker]

7 hours ago, linuxgurugamer said:

Hmm. 

Any chance you have two copies installed?

Which file did you download?  you should have downloaded this:  https://github.com/linuxgurugamer/OrbitalDecay/releases/download/1.7.0.1/OrbitalDecay-1.8.0-1.7.0.1.zip

A complete view of the directory with files is this, if you have anything else, then something's wrong:

I just downloaded the mod from the link you provided here, and there's also a VesselData.cfg in the PluginData folder. I'm also having the same issue, and I made sure to download the latest version of Solar Cycle Simulator (the other two dependencies are copied over from my other 1.8.1 install).

Oh, also: Stationkeeping drains monopropellant at an incredibly rapid pace; a tank of 20, on a 240kg craft, didn't even last a third of a 46-minute-period orbit (95 km when using JNSQ). Plus, it doesn't seem to do anything when enabled.

(And more on the stutter: if I timewarp, after a few moments, it'll yank me back to about where I started the timewarp, but with my orbit changed. Physics warp seems to work fine; it's non-physics warp that has the issue.)

Edited August 19, 2020 by Starseeker