Whitecat106

[1.1.3] Orbital Decay v1.5.2 (17/07/2016) - Total Overhaul

Recommended Posts

@Whitecat106, just ran into what I think is a bug with OD. I launched a rocket in KRASH sim mode and put it all the way out to its final geosynch orbit. OD said the orbit was stable with >1000 years before decay, but being part of a comsat network, I enabled station keeping anyway so I could see how long it would last with the fuel on board. OD seemed to work correctly, telling me that, using Aerozine50 (I'm using real fuels mod), the orbit would be stable and that the station keeping fuel would last >1000 years.

Satisfied with the results of the sim, I terminated back to the VAB, built the rocket through KCT, and then launched about 40 game days later. Everything seemed fine, but after I got into space and went to circularize my orbit at the correct altitude, I noticed that my final stage dV was significantly less than it should be... completely full, its got 1600+, but it was only showing 435. After a little inspection of the tanks, I noticed that most of my Aerozine50 was missing. I reverted back to launch and tried again, only to get the same results. I tried a third time, this time going into OD's menu and setting the station keeping resource to something that wasn't on the craft at all, and then I had full fuel as I was supposed to. For testing purposes, I reverted again and set the station keeping resource back to Aerozine50 and watched the dV window closely through the launch... Apparently, if the station keeping resource is set prior to launch, as soon as the craft crosses the 70km line, a lot of that particular resource is eaten instantly.

I'm not really sure if this is specifically related to OD, or some combination of my many mods yet. Will have to spend some time tomorrow with a bare bones install to see if I can replicate the issue without 170+ mods installed.

Share this post


Link to post
Share on other sites

same as above, stationkeeping fuel is used on suborbital to orbital transition when ship is under main engine acceleration. OD should be disabled for ships that are under acceleration.

My case:

Launching new crewed vessel

monopropelant is set as station keeping fuel.

on transition from suborbital to low orbit all my Monopropellant is spent with message that my (currently getting into orbit at full throttle) vessel is very low.

got to 75x76km LKO, edited monoprop back in quicksave

vessel is being crashed on quicksave load with orbital decay message that it has decayed.....

Share this post


Link to post
Share on other sites
3 hours ago, SpacedInvader said:

@Whitecat106, just ran into what I think is a bug with OD. I launched a rocket in KRASH sim mode and put it all the way out to its final geosynch orbit. OD said the orbit was stable with >1000 years before decay, but being part of a comsat network, I enabled station keeping anyway so I could see how long it would last with the fuel on board. OD seemed to work correctly, telling me that, using Aerozine50 (I'm using real fuels mod), the orbit would be stable and that the station keeping fuel would last >1000 years.

Satisfied with the results of the sim, I terminated back to the VAB, built the rocket through KCT, and then launched about 40 game days later. Everything seemed fine, but after I got into space and went to circularize my orbit at the correct altitude, I noticed that my final stage dV was significantly less than it should be... completely full, its got 1600+, but it was only showing 435. After a little inspection of the tanks, I noticed that most of my Aerozine50 was missing. I reverted back to launch and tried again, only to get the same results. I tried a third time, this time going into OD's menu and setting the station keeping resource to something that wasn't on the craft at all, and then I had full fuel as I was supposed to. For testing purposes, I reverted again and set the station keeping resource back to Aerozine50 and watched the dV window closely through the launch... Apparently, if the station keeping resource is set prior to launch, as soon as the craft crosses the 70km line, a lot of that particular resource is eaten instantly.

I'm not really sure if this is specifically related to OD, or some combination of my many mods yet. Will have to spend some time tomorrow with a bare bones install to see if I can replicate the issue without 170+ mods installed.

 

22 minutes ago, ZAJC3W said:

same as above, stationkeeping fuel is used on suborbital to orbital transition when ship is under main engine acceleration. OD should be disabled for ships that are under acceleration.

My case:

Launching new crewed vessel

monopropelant is set as station keeping fuel.

on transition from suborbital to low orbit all my Monopropellant is spent with message that my (currently getting into orbit at full throttle) vessel is very low.

got to 75x76km LKO, edited monoprop back in quicksave

vessel is being crashed on quicksave load with orbital decay message that it has decayed.....

Ahh this will be due to two issues, both of which I should be able to fix relatively easily and can provide a quick fix for the moment;

-- The first issue is due to some weird resource bug, that I thought was just to do with quick loading and saving on my end, but it would appear that resources can be accidentally set to zero due to a timing issue (the fuel is occasionally not updated properly on launch, once in orbit the system 'catches up' and the resource deficit is removed, thus all resources are depleted). 

Temporary Solution:

- Change the stationkeeping resource to a non used resource, such as xenon (or gypsum if using the CRP), then attempt to station keep by toggling the UI command, this will force the system to reset the resource amount and a message 'vessel x has no fuel to station keep'. Once in orbit set the stationkeeping resource your desired resource and enable stationkeeping, this will prevent resources being deleted. Or slightly invasive, use Hyperedit to refuel the desired resource and then open the UI of a part of the vessel, this will similarly force the system to reset. Both methods will not effect other stationkeeping vessels and should solve any annoying bugs like this one. I will add this to the list of fixes for 1.5.0. 

 

-- The second issue is a tad more serious, this is due to the game state being reset to an earlier point but the VesselData.cfg is not being correctly updated, therefore the Semi Major Axis updates to an older value - often below the atmosphere -. I will add this to the list for 1.5.0 since this is pretty serious. I have a small solution but it is really a hindrance to gameplay.

Temporary Solution:

- Before loading from a quicksave, change the game scene e.g Flight to Tracking Station or Flight to Space Centre, this should force the system to update the vessels Semi Major Axis correctly; but I cannot be sure, such an issue is not due to the plugin being active when it shouldnt but more due to the lag removing programming that I have used for it, at the moment vessel information is lost but not reverted during a quick load quick save event, but this will be corrected for 1.5.0.

 

 

Share this post


Link to post
Share on other sites

changing scene didn't help, changing station keeping resource isn't ideal either switching to all satelites will take a while...

I'm, looking forward to update, it's one of 'it should be stock' mods for me :wink:

Share this post


Link to post
Share on other sites

Oh mod, where have you been all my life?  Yet another thing I RP for "realism" that I can let a sweet mod take over.  I'm glad I already load monoprop onto all my probes/stations/ships (I normally "retire" vessels after x amount of time to simulate orbital decay based on how much fuel I gave them).  

Thanks Whitecat for this!  I can take some of the clutter out of my career game's WordPad file.  Plus it does it waaaaay better then my own personal "system".

Share this post


Link to post
Share on other sites

 

On 16/05/2016 at 4:47 PM, autumnalequinox said:

Oh mod, where have you been all my life?  Yet another thing I RP for "realism" that I can let a sweet mod take over.  I'm glad I already load monoprop onto all my probes/stations/ships (I normally "retire" vessels after x amount of time to simulate orbital decay based on how much fuel I gave them).  

Thanks Whitecat for this!  I can take some of the clutter out of my career game's WordPad file.  Plus it does it waaaaay better then my own personal "system".

Thanks! I'm glad you're enjoying it! I used to do the same as you until I made the plugin! 

 

Hello everyone,

I have been working on 1.5.0 today; I have fixed the bugs raised above and have partially implemented Mascon orbital perturbations in a 1.5.0 pre release. Please feel free to check out my progress, contribute if you would like, or test out the 1.5.0 pre release (please back up your savefiles!) version on the Github .

Quite busy with University at the moment but I should have a new version out within the next week or so depending on how well these Mascon calculations go; so far I have the system working but some areas of the code are patchy and the Mascon model only covers the Kerbin/Earth system (Jupiter/Jool will be my next priority since I actually have some real life data on Jovian moon mascons). Starting to discover that a G-Unit is incredibly unhelpful when it comes to surface gravity changes and their equations!

Here is the .pdf that I am basing the system from if anyone is interested, this is a paper from the Goddard Space Center from March 1970; probably written as a result of findings from the Apollo-12 moon mission... Some mathematical translation was required to code this into a game 46 years later!

Whitecat106 :)

Edited by Whitecat106

Share this post


Link to post
Share on other sites

Hey, I love the concept of this mod but I can't get it to work with probes that use a regular engine . When I select active vessel, I can get it station keep, but I can't get probes which use poodle, spark or ant engines (basically anything that uses LF/Ox). I get no engines or RCS as soon as the craft is unloaded. The same is true for vessels in LKO.

 

I think the 

if (PPMS.moduleName == "ModuleEngines" || PPMS.moduleName == "ModuleRCS")
 

check is failing, but I can't imagine why. All the ships I tried this have stock engines (radialEngineMini and the  liquidEngineLV-90), and I checked the persistence.sfs file. 

 

EDIT: http://96.126.124.51/~mcasadevall/persistent.sfs - here's the persistance file

Edited by NCommander

Share this post


Link to post
Share on other sites
3 hours ago, NCommander said:

Hey, I love the concept of this mod but I can't get it to work with probes that use a regular engine . When I select active vessel, I can get it station keep, but I can't get probes which use poodle, spark or ant engines (basically anything that uses LF/Ox). I get no engines or RCS as soon as the craft is unloaded. The same is true for vessels in LKO.

 

I think the 

if (PPMS.moduleName == "ModuleEngines" || PPMS.moduleName == "ModuleRCS")
 

check is failing, but I can't imagine why. All the ships I tried this have stock engines (radialEngineMini and the  liquidEngineLV-90), and I checked the persistence.sfs file. 

 

EDIT: http://96.126.124.51/~mcasadevall/persistent.sfs - here's the persistance file

That'd be because in 1.1 (and as you can see in your persistance file) all those engines aren't using ModuleEngines, they're using ModuleEnginesFX. I have a similar problem because I'm using RealFuels, which means all my engines are using ModuleEnginesRF. Either way, they won't be picked up by that check.

@Whitecat106, maybe you could rewrite the first half of that check to pick up any modules whose names start with ModuleEngines? That would cover all of the alternate engine modules from various mods that I'm aware of.

-c

 

Share this post


Link to post
Share on other sites
8 hours ago, Cerebrate said:

That'd be because in 1.1 (and as you can see in your persistance file) all those engines aren't using ModuleEngines, they're using ModuleEnginesFX. I have a similar problem because I'm using RealFuels, which means all my engines are using ModuleEnginesRF. Either way, they won't be picked up by that check.

@Whitecat106, maybe you could rewrite the first half of that check to pick up any modules whose names start with ModuleEngines? That would cover all of the alternate engine modules from various mods that I'm aware of.

-c

 

Oooh, good catch. I took a quick look at the API documentation for KSP. As far as I can tell, the correct solution for this is to build a list of engine classes. To do this, you need to iterate on FindChildParts for ModuleEngineClass (and I guess module RCS too), then find all the children of ModuleEngines, and check against that list.

 

I might be able to code for a PR, though I've never been much of a C# guy.

Share this post


Link to post
Share on other sites

I'm curious.  I can set different fuels to use for station keeping on each individual vessel, correct?  As long as I load the vessel?

Example:  A standard probe with monoprop.  So that's default and alls good.  Then I launch a probe with an ion engine and xenon.  So I set fuel to xenon and load the vessel.  

Would I have to do anything else?  Like make sure to set it back to mono before loading the probe with monoprop?

Share this post


Link to post
Share on other sites

Hello everyone,

Thanks @Cerebrate and @NCommander for that, I have fixed this for 1.5.0.

I have put up a new pre-release in the Github which contains some more 'in progress' features, I will work further on this tomorrow and into next week. At the moment the UI may be a little broken as I have tried to optimize some coding and add some new displayable information. The Mascon work is now complete for the Kerbin/Earth system and included within this pre release! Please do try it out and see if there is anything you would like me to include or fix for the 1.5.0.

Hopefully I should have 1.5.0 out by next week once the list of issues on Github shrinks a tad! I would be especially grateful if anyone could try out the Stock 'rescue kerbal or recover part' from orbit contracts to see if the extreme decay rates for these spawned vessels have disappeared! 

Whitecat106 :)

Share this post


Link to post
Share on other sites

Thank you Whitecat106.

On 20/05/2016 at 2:25 AM, autumnalequinox said:

I'm curious.  I can set different fuels to use for station keeping on each individual vessel, correct?  As long as I load the vessel?

Example:  A standard probe with monoprop.  So that's default and alls good.  Then I launch a probe with an ion engine and xenon.  So I set fuel to xenon and load the vessel.  

Would I have to do anything else?  Like make sure to set it back to mono before loading the probe with monoprop?

It won't work, consumption rates won't be correct: 2.3 days worth of monoprop is 92 days worth of xenongas.

That reminds me feature i wanted to suggest. Have station keeping resource set per vessel, in probe core/pod right click context menu, or in Orbital Decay GUI. I know it would be a lot of work, but IMHO would make more sense than global station keeping resource

 

Bug report:

Scene change is reseting StationKeeping state to OFF and reloads resource to persistent.cfg value.

Actually it looks like resource is never updated in persistent.sfs for inactive vessels and VesselData.cfg is discarded every scene change causing loss of data.

All tests above done with only 1 vessel in flight in full stock KSP

Update:

Launching another vessel is reseting already orbiting vessels, same as quicksaving, and autosaving.

orbits seems to be updated correctly.

 

UPDATE:

 line:

if (VesselData.FetchFuel(FlightGlobals.ActiveVessel) < ResourceManager.GetResources(FlightGlobals.ActiveVessel, Settings.ReadStationKeepingResource()))

in decay manager.cs is always false

for some reason

VesselData.FetchFuel(FlightGlobals.ActiveVessel) 

returns value from persistent sfs instead of value from VesselData.cfg, that was intention of this line, right?

 

Edited by ZAJC3W
Bug discovered ;(

Share this post


Link to post
Share on other sites
On 5/21/2016 at 8:09 AM, ZAJC3W said:

It won't work, consumption rates won't be correct: 2.3 days worth of monoprop is 92 days worth of xenongas.

That reminds me feature i wanted to suggest. Have station keeping resource set per vessel, in probe core/pod right click context menu, or in Orbital Decay GUI. I know it would be a lot of work, but IMHO would make more sense than global station keeping resource

Oh ok.  Yeah I was thinking the same thing if that was the case.  It would be a nice feature.

 

On 5/21/2016 at 8:09 AM, ZAJC3W said:

Bug report:

Scene change is reseting StationKeeping state to OFF and reloads resource to persistent.cfg value.

Actually it looks like resource is never updated in persistent.sfs for inactive vessels and VesselData.cfg is discarded every scene change causing loss of data.

All tests above done with only 1 vessel in flight in full stock KSP

Update:

Launching another vessel is reseting already orbiting vessels, same as quicksaving, and autosaving.

orbits seems to be updated correctly

Same here.  I didn't catch it myself until a sat never seemed to run out of fuel.

Share this post


Link to post
Share on other sites
22 hours ago, ZAJC3W said:

Thank you Whitecat106.

It won't work, consumption rates won't be correct: 2.3 days worth of monoprop is 92 days worth of xenongas.

That reminds me feature i wanted to suggest. Have station keeping resource set per vessel, in probe core/pod right click context menu, or in Orbital Decay GUI. I know it would be a lot of work, but IMHO would make more sense than global station keeping resource

 

Bug report:

Scene change is reseting StationKeeping state to OFF and reloads resource to persistent.cfg value.

Actually it looks like resource is never updated in persistent.sfs for inactive vessels and VesselData.cfg is discarded every scene change causing loss of data.

All tests above done with only 1 vessel in flight in full stock KSP

Update:

Launching another vessel is reseting already orbiting vessels, same as quicksaving, and autosaving.

orbits seems to be updated correctly.

 

UPDATE:

 line:


if (VesselData.FetchFuel(FlightGlobals.ActiveVessel) < ResourceManager.GetResources(FlightGlobals.ActiveVessel, Settings.ReadStationKeepingResource()))

in decay manager.cs is always false

for some reason


VesselData.FetchFuel(FlightGlobals.ActiveVessel) 

returns value from persistent sfs instead of value from VesselData.cfg, that was intention of this line, right?

 

Is this with the latest Github 1.5.0 pre release or the 1.4.2? I have just updated the Github version, this should prevent the issue above, but alas it will reintroduce quickload/quicksave issues, this shouldnt be a problem unless you load from a quicksave from a long time ago (afew hours shouldn't matter but a couple of weeks or months may be a different case - working on it!)

Please let me know if the Github version has the same issue, I am playing through a 1.1.2 RSS career using the Github version and this seems to have been rectified on my end.

That being said I have discovered a mod incompatibility; RSS Extrasolar will not work with this plugin as of right now, Sagittarius A* has been coded using Kopernicus as a planet with a massive radius and atmosphere, as such vessels are destroyed by Orbital Decay as soon as they enter the sphere or influence. This issue may also be present in some 'multiple solar system' or 'binary system' planet packs depending on how the barycentre is coded.

12 hours ago, autumnalequinox said:

Oh ok.  Yeah I was thinking the same thing if that was the case.  It would be a nice feature.

 

Same here.  I didn't catch it myself until a sat never seemed to run out of fuel.

I will look at introducing a part module system (Scrapped with KSP 1.0.5 since I was getting lots of Module exceptions in the VAB so I decided to just remove the system). I think it would be easier for me to introduce a separate UI menu only for an active vessel to set the Station Keeping resource from here for each vessel, then have these stored in the VesselData.cfg (both the virtual configNode (run by the code to prevent lag from reading and writing to a file) and the actual VesselData.cfg file).

Thanks for noticing this one though, I had not even considered that some fuels would never deplete!

Will be working more on 1.5.0 soon, hopefully this will also see the resource changes as mentioned above and hopefully some workaround for Kopernicus issues!

Whitecat106 :)

Share this post


Link to post
Share on other sites

Little update:

2 issues found:

VesselData.cs:

 public static void OnQuickSave()
        {
            if (DecayManager.CheckSceneStateMain(HighLogic.LoadedScene))
            {
                if ((Planetarium.GetUniversalTime() == HighLogic.CurrentGame.UniversalTime) || HighLogic.LoadedScene == GameScenes.FLIGHT)
                {
                    print("WhitecatIndustries - Orbital Decay - Vessel Information saved.");
                    File.ClearNodes();
                    VesselInformation.Save(FilePath);
                    VesselInformation.ClearNodes();
                }
            }
        }

Code above is executed before every ship loading, causing VesselInformation being repopulataed with fuel data from persistent.sfs -> loss of consumed fuel info. Since WhiteCat106 is rewriting(as he says in readme) VesselData.cs I'll leave it to him. But commenting out VesselInformation.ClearNodes(); line solves this problem.

Issue no.2

DecayManager.cs

public static void UpdateActiveVesselData(Vessel vessel)

Is executed before

  public void FixedUpdate()

First method/function(im no programmer by any means) is updating VesselInformation nodes to fuel level from freshly loaded ship, before that fuel level is updated by FixedUpdate.....

P.S i'll make pull request when i figure out a fix for it.

Share this post


Link to post
Share on other sites

Sorry Whitecat106 somehow i managed to miss your reply.

I'm testing 1.5.0 prerealease, have now VS linked to github so no more typos like in my last Pull request.

Issue is caused by onQuickSaveorloadUpdate being called before resourcecatchup on loading of a vessel.

I have found yet another way of rectyfing fuel update issue, propper one this time. quicksave, autosave and revert safe.

using this in every resources update for unloaded vessels

 protopartresourcesnapshot.resourceValues.SetValue("amount", PartFuel.ToString(), 0);

Storing Fuel level in seperate file becomes obsolete, as it's updated every second(as for now) and stored in .sfs file.

Station keeping state, and individual ship resurce type should be stored same way, as i can't see any other way of restoring them reliably after quickload from 2-3 days before. Using partmodule would be the way forward, me (modding noob) thinks :wink:

Same modding noob thinks that storing anything  that should be restored on quickload in VesselData.cfg isn't gonna work.

 

 

Edited by ZAJC3W

Share this post


Link to post
Share on other sites

Hello everyone,

Have been working on the mod today and thanks to @ZAJC3W 's work on overhauling the station keeping and resource system 1.5.0 will be released soon, the list of issues on Github is down to about 7, been working on adding the Yarkovsky effect for this release as well as Mascons. Should have a release within the next few days, this one has had some pretty comprehensive fixes and additions along with a great deal of testing! 

Whitecat106 :)

Share this post


Link to post
Share on other sites

Don't be surprised to see invalid format exception alot - found cause and solution, but needs more testing...

few hours later....

After some testing on fully blown install with 60 mods 2 bugs squashed, one feature posibility spotted SAVE NOT BROKEN!!!! :)

 

Edited by ZAJC3W

Share this post


Link to post
Share on other sites

@Whitecat106 I've found a bug. When my ships come close to each other to dock, the one that's not active, vanishes, and reappears a hundred or so meters away.

Share this post


Link to post
Share on other sites
13 hours ago, The-Doctor said:

@Whitecat106 I've found a bug. When my ships come close to each other to dock, the one that's not active, vanishes, and reappears a hundred or so meters away.

Ahh this one might just be in the 1.4.2 and earlier versions (which I'm hoping this report is for! :D), hopefully this is squashed for the 1.5.0, in the upcoming 1.5.0 version the distance between vessels is checked and the decay simulator is frozen for both objects if a vessel is within 100km of another vessel. This however means that some maneuver-node adjustment is required for 1.6.0, for example a probe in a LEO/LKO transfer orbit could have a reduced SMA and as such a maneuver node would need to be altered based on the new world position... Pretty complicated so ill leave this for the 1.6.0.

Will be working on 1.5.0 again this evening!

 

Share this post


Link to post
Share on other sites
2 hours ago, Whitecat106 said:

Ahh this one might just be in the 1.4.2 and earlier versions (which I'm hoping this report is for! :D), hopefully this is squashed for the 1.5.0, in the upcoming 1.5.0 version the distance between vessels is checked and the decay simulator is frozen for both objects if a vessel is within 100km of another vessel. This however means that some maneuver-node adjustment is required for 1.6.0, for example a probe in a LEO/LKO transfer orbit could have a reduced SMA and as such a maneuver node would need to be altered based on the new world position... Pretty complicated so ill leave this for the 1.6.0.

Will be working on 1.5.0 again this evening!

 

The bug actually is for the latest version of orbital decay (I'm unsure which version but I installed through CKAN)

Share this post


Link to post
Share on other sites
Just now, The-Doctor said:

The bug actually is for the latest version of orbital decay (I'm unsure which version but I installed through CKAN)

Yeah this will be the 1.4.2, sorry about this one, its incredibly annoying I know, this should only happen once though, and the change should only be afew kilometers, unless the orbit is very close to the atmosphere. This will be fixed soon, I hope to have the new version out before the end of the week!

Thanks for the report though! :)

Share this post


Link to post
Share on other sites

Hello everyone,

I'm ready to release the 1.5.0 but first I have put up a .dll on Github, if anyone could test it out incase there is anything I have missed it would be greatly appreciated!

Hopefully I will release the next update this evening! :)

Whitecat106

Share this post


Link to post
Share on other sites

Hello everyone,

Updated to 1.5.0, here is a concise list of the changes:

- Overhauled Resource & Station Keeping System - Thanks zajc3w!
- Added decay rate breakdown UI
- Added Mascon perturbation
- Added Yarkovsky effect perturbation
- Added engine ignited requirements for Station Keeping
- Removed global resource
- Adjusted atmosphere warnings
- Fixed EVA warping and rendezvous issues
- Fixed a multitude of NaNs and exceptions
- Added QuickLoad / QuickSave handling
- Began Wiki creation
- Fixed multiple bugs and added other minor requests

Please let me know if there are any pressing bugs, I can bugfix for the next two days!

Enjoy!

Whitecat106:)

Share this post


Link to post
Share on other sites

Hey. I've been playing rp0 carreer with the 1.4.2 version for a few weeks now. One Issue ive been having:

Vessels that have decayed are listed in the tracking station as "on sub-orbital trajectory" and they wont get removed/destroyed. Orbital parameters are all NaN. When I try to switch to one of these, the kraken stikes and the scene goes sort of black, I cant switch back  and have to kill KSP.

<Edit> Ok heres another scenario - I can switch back to space center but that just gives me a beautiful view of the skybox, nothing else (KSC building buttons present, upon clicking the game crashes) </Edit>

Lately I noticed that when zooming around the solar system in map view, my supposed-to-be deorbited crafts show up far in the distance with ridiculously high solar orbits. some gazilions kilometers altitude. Exept one, which is in a super tight orbit like 1/3 of mercury.

I should mention that I have some 90 mods installed. So if it's not a known bug it might just be anything on my end.

Edited by Gannaf

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.