Whitecat106

Hmm interesting, I am using the same version with the same type of install without issue. I will do some testing into this, definitely caused by Orbital Decay, a solution to this would be to temporarily exclude the certain probe core from the module manager file included in the WhitecatIndustries/Orbital Decay folder. Which probe core(s) in particular are causing the problem?

Cheer @the grue, I've added this to the Github issues list for 2.2.0, must be specific to just one pack as I did not experience this playing through the RSS Full pack. Fix will be included in the next release. In the meantime you could just alt - f12 and complete the contract, you could however delve into the Korabl-Sputnik 3 mission .cfg file. The issue is due to the DestroyVessel parameter being within the VesselParameter group for Korabl-Sputnik -3. Basically, change the contract from this: PARAMETER { name = VesselDestroyed type = VesselDestroyed } } to this: } PARAMETER { name = VesselDestroyed type = VesselDestroyed } At the end of the Korabl-Sputnik-3 .cfg file. Then cancel this contract in the Mission Control center, restart the game and the issue should be fixed! Sorry about this one, Whitecat106

Thanks for your feedback! I have adjusted the following code to this: MeshRenderer OrbitBezierRenderer; MeshFilter OrbitBezierFilter; GameObject OrbitBezier = new GameObject("OrbitBezierLine"); if (OrbitBezier.GetComponent<MeshRenderer>() == null) { OrbitBezierRenderer = OrbitBezier.AddComponent<MeshRenderer>(); } if (OrbitBezier.GetComponent<MeshFilter>() == null) { OrbitBezierFilter = OrbitBezier.AddComponent<MeshFilter>(); } OrbitBezierFilter = OrbitBezier.GetComponent<MeshFilter>(); OrbitBezierRenderer = OrbitBezier.GetComponent<MeshRenderer>(); However this time, although no errors appear, no line is rendered either, anywhere in the tracking station. Any suggestions? The full code is available here if anything else is necessary. I'm very much a novice with this and sadly so little information on the subject seems available, with different plugins using widely different methods, for example, Remote Tech appears to use the more simple method of visible line drawing than say KSP Trajectories, even though the trajectories mod is more akin to what I require. Whitecat106

Hello everyone, Whitecat here with a question about drawing and rendering lines in the tracking station. Basically for my Orbital Decay modification I am beginning to implement n-body simulation, the actual simulation and orbit movements are fine, however such movements are 'forbidden' by the tracking station conics system. e.g, An orbit must ellipsoidal under all circumstances forever... Similarly during timewarp the whole affair gets horrifically messy and would make any sort of space rendezvous beyond 1/2 Hill Sphere radii impossible. However I have a found a solution to this by removing the stock conic rendering for a certain vessel and creating a stepped prediction for the orbit shape and size at various points using position vectors across a period of time. Creating a 'line of best fit path between them. Alas during implementation of this an exception is thrown, Personally I have no experience of any line rendering past creating a GUI, so I have been following the code of Remote Tech's line drawing as a guide. If anyone could shed light on any issues with the code below I would be very grateful! foreach (Orbit orbit in FutureRenderOrbits) { Vector3 PositionAtStart = orbit.getTruePositionAtUT(time + (TimeSnapshots * FutureRenderOrbits.IndexOf(orbit))); Vector3 PositionAt1stDegree = orbit.getTruePositionAtUT(time + (TimeSnapshots * (FutureRenderOrbits.IndexOf(orbit) + (1.0 / 6.0)))); Vector3 PositionAt2ndDegree = orbit.getTruePositionAtUT(time + (TimeSnapshots * (FutureRenderOrbits.IndexOf(orbit) + (2.0 / 6.0)))); Vector3 PositionAt3rdDegree = orbit.getTruePositionAtUT(time + (TimeSnapshots * (FutureRenderOrbits.IndexOf(orbit) + (3.0 / 6.0)))); Vector3 PositionAt4thDegree = orbit.getTruePositionAtUT(time + (TimeSnapshots * (FutureRenderOrbits.IndexOf(orbit) + (4.0 / 6.0)))); Vector3 PositionAt5thDegree = orbit.getTruePositionAtUT(time + (TimeSnapshots * (FutureRenderOrbits.IndexOf(orbit) + (5.0 / 6.0)))); Vector3 PositionAtEnd = orbit.getTruePositionAtUT(time + (TimeSnapshots * (FutureRenderOrbits.IndexOf(orbit) + 1))); MeshRenderer OrbitBezierRenderer= new MeshRenderer(); MeshFilter OrbitBezierFilter = new MeshFilter(); GameObject OrbitBezier = new GameObject("OrbitBezierLine"); if (gameObject.GetComponent<MeshRenderer>() == null) { OrbitBezierRenderer = gameObject.AddComponent<MeshRenderer>(); } if (gameObject.GetComponent<MeshFilter>() == null) { OrbitBezierFilter = gameObject.AddComponent<MeshFilter>(); } OrbitBezierFilter.mesh = new Mesh(); OrbitBezierFilter.mesh.name = "OrbitBezierLine"; OrbitBezierFilter.mesh.vertices = new Vector3[5]; OrbitBezierFilter.mesh.uv = new Vector2[5] { new Vector2(0, 1), new Vector2(0,1), new Vector2(0, 0), new Vector2(1, 1), new Vector2(1, 0) }; OrbitBezierFilter.mesh.SetIndices(new int[] { 0, 2, 1, 2, 3, 1 }, MeshTopology.Triangles, 0); OrbitBezierFilter.mesh.colors = Enumerable.Repeat(Color.red, 5).ToArray(); lineMaterial = MapView.fetch.orbitLinesMaterial; OrbitBezierRenderer.material = lineMaterial; Vector3[] Points2D = new Vector3[4]; Vector3[] Points3D = new Vector3[5]; float LineWidth = 1.0f; var camera = PlanetariumCamera.Camera; var start = camera.WorldToScreenPoint(ScaledSpace.LocalToScaledSpace(PositionAtStart)); var end = camera.WorldToScreenPoint(ScaledSpace.LocalToScaledSpace(PositionAtEnd)); var segment = new Vector3(end.y - start.y, start.x - end.x, 0).normalized * (LineWidth / 2); if (!MapView.Draw3DLines) { var dist = Screen.height / 2 + 0.01f; start.z = start.z >= 0.15f ? dist : -dist; end.z = end.z >= 0.15f ? dist : -dist; } OrbitBezier.layer = 31; Points3D[0] = camera.ScreenToWorldPoint(PositionAt1stDegree); Points3D[1] = camera.ScreenToWorldPoint(PositionAt2ndDegree); Points3D[2] = camera.ScreenToWorldPoint(PositionAt3rdDegree); Points3D[3] = camera.ScreenToWorldPoint(PositionAt4thDegree); Points3D[4] = camera.ScreenToWorldPoint(PositionAt5thDegree); OrbitBezierFilter.mesh.vertices = MapView.Draw3DLines ? Points3D : Points2D; OrbitBezierFilter.mesh.RecalculateBounds(); OrbitBezierFilter.mesh.MarkDynamic(); Please note: Only 6 degrees of Position vectors during a time interval are being shown here, in reality during a high (1000x time warp) around 50 position vectors will be necessary to ensure accuracy of the tracing. The intention of the code is to draw a 'dot to dot' between the position vectors at the start and end of an orbit snapshot (since the orbit will be changed regularly due to n-body perturbation), using the PositionAtNthDegree vectors to provide vertex points to 'beziate' the line to the correct (accurate) orbital curvature. Feedback on how to make the above code actually render a line or two, or even a better method of drawing bezier curves in the Planetarium view would be greatly appreciated! Thanks for your time! Whitecat106

Hmm peculiar, okay maybe try toggling the station keeping option in the probe core main menu and see if that fixes the issue? If not it might be due to a small save file corruption, you could also use find an repace in your .sfs file and remove any module of 'ModuleOrbitalDecay'. (Back up your .sfs first!) Upon restarting the game the problem should have disappeared. If not I will have to look into this deeper.

Good to hear! Its due to the 1.5.1 update, it was a quick patch to stop ModuleManager from reloading its cache every time the game is started. It required a rearrangement of the folder structure of the mod, the code required the settings file to be within the WhitecatIndustries/Plugins/PluginData folder, but this will not automatically change on update from 1.5.0 to 1.5.1, so it requires the mod to be deleted first and then reinstalled. Probably causing some trouble to people who use Ckan especially! This may be due to the engines on the craft not actually being activated (ignited), if not you will have to let me know and I will look into this. Try making sure the engine is active and then activate station keeping hopefully this will fix your issue. Wow that's also a pretty large decay rate! I will make the UI a little more friendly for 1.6.0 displaying something like 'Decay rate: Decay imminent' if the decay rate is above 1000Km. Still working on 1.6.0, having some big problems with the planetarium incorrectly de-registering timewarp changes, hopefully I can get a more accurate model working for Timewarp. For now I am working on the conic patches for some nice squiggly (hopefully accurate) lines! Whitecat106

This contract will reappear after a few days, you can try to force the contract to reappear by declining contracts in the Mission Control building as this also sometimes will work. Working on 2.2.0 this week, I will hopefully have a release by this time next week, this fixes some massive bugs with duration requirements and adds some new content along with further re-balancing and historic detail. The 2.2.0 also will have fixes for RP-0. In the meantime the incomplete 2.2.0 can be downloaded from the source at the Github ! this incomplete version currently has fixes for duration requirements and RP-0. Whitecat106

Ahh it looks like an issue from the settings file as a result of the last update, I would do the following to fix this: Copy your VesselData.cfg and save this temporarily outside of your GameData. Then delete your WhitecatIndustries/Orbital Decay folder, download the latest version (1.5.1) from SpaceDock, install this and then copy your saved VesselData into the WhitecatIndustries/Orbital Decay/Plugins/PluginData folder and overwrite the downloaded file. This should rectify the problem. If this persists let me know and download the 1.5.0 version from the SpaceDock and copy your VesselData.cfg into this download! I Hope this helps! Working on the N-Body simulation now, having some issues with the precision of the stored vessel velocity. Got some pretty looking perturbations though, that being said I will need to add in some major changes in order for rendezvous to be possible anymore! Having some equally big problems with the tracking station plotting and timing, it appears that when timewarp is active the tracking station fails to understand when timewarp is decreased causing teleporting vessels - Not promising! I will update the github soon with a new test version and update the issue list if anyone wants to dab in n-body management. Whiteact106

For the moment a dependency on a signal connection for enabling or disabling station keeping, but I might look into some more RT specific station keeping options for 1.7.0. I decided to move this up to 1.6.0, it will be a very big change to the gameplay, but I will make NBody simulation easily toggleable in the settings since it may not be for everyone. My general plan for this is to be a realistic but less intense version of Principia, using some much more basic maths. That said my initial tests are on the github and I have been partially successful in Lagrange positioning. Currently my progress is as follows: - Add NBody simulation based on velocity changes from internal and external forces within a system. 75% complete, having issues with velocity adjustments. - Add Ui information on NBody Simulations, including safe 'hill Sphere data' 25% done - Add new map conics for NBody simulation. This is the big one for me, predictions are known to be heavy on the cpu and I have never manipulated planetarium conics before so any help would be greatly appreciated! So far having a lot of fun trying to make this work so check this post and github for some 1.6.0 pre releases for the n body work in the coming days! Whitecat106

Hello everyone, This week I will be working on the next version, please let me know if anyone has any requests for new features or fixes! My primary goal for 1.6.0 is compatibility with Galactic core planet packs and Remote Tech along with finalizing and fixing the Radiation Pressure, Yarkovsky and Mascon effects. My future plan for 1.7.0 is to add some rudimentary N-Body simulation physics and make all effects toggleable in the Settings menu for compatibility with Principia etc. Whitecat106

Thanks, will be working on fixes this afternoon to the aforementioned issues! I have added a link to the github on the first page of this thread if anyone wishes to contribute! That being said, I would appreciate if any contribution is thoroughly tested before submitting a pull request, since I simply do not have time to bug fix contracts that I have not made myself! Already looking at possibly 1000+ changes! Right now the 2.2.0 pre release on Github contains RP-0 fixes and some new missions. Whitecat106

Hello everyone, Just put out 1.5.1 which adjusts the file structure for Module Manager to prevent the long loading times! Will be working on 1.6.0 soon, focusing on my Historic Missions contract pack for the moment. @dafidge9898, it looks like your vessel although having a low area also has a low mass and as such a high decay rate results, try adding afew hundred kilograms to the satellite and check out the decay rate now. In reality satellite that small would be orbiting at around 2000Km or higher where the atmospheric density is much lower causing much less drag on the satellite. Enjoy, Whitecat106

Wow! Thanks for that, will be an easy change, I will do so tomorrow hopefully, I thought there was just a problem with my install causing the game to take 7 minutes to load! I never considered the file structure with MM. Added as issue 63 in the github, I'll release a 1.5.1 for this along with the same update to the SCS plugin!

Thanks for this, I have noticed issues with Docking time and duration requirements, I will definitely need to go through this for the next update. As for RP-0 and RO this has been fixed and is ready for the 2.2 release, just working on adding some more details to early missions and fixing the duration requirements which seem to effect lots of contracts, for example even as early as vostok 3, the remain in orbit timer will stop as soon as the vessel is switched, this may be causing the issue and as such is the reason for some failures. If this turns out to be a separate issue then I belive that a rewrite of the vessel definitions will be necessary and this might take some time. But rest assured I hope that 2.2 will fully fix the pack for all versions of KSP, RO/RP-0 especially! The github repository will be up tomorrow for anyone willing to contribute to the pack and so you all can see my progress towards the 2.2.0 update (I apologise for the neglect of this pack up until now!) Whitecat106

Good idea! I will be updating this plugin soon to try and fix some issues with RSS Date-Time formatter, I will rearrange the folder structure at the same time! Whitecat106

Helo there, Thanks for this report, I think if you update to the 1.5.0 version most of these issues should go away, I am playing with the same sort of install and have noticed some similar bugs with the older versions of the mod. Just delete your old Orbital Decay folder and install the new 1.5.0 version and the problems should be fixed. As for the last issue, this is really really bizarre, like a spaceship graveyard?... Might need to have a look at your list of installed mods and see if any of these could be causing issues with Orbital Decay... Could you upload a log file somewhere so I can see which mods are installed? Thanks, Whitecat106

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

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

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!

Ahh this one might just be in the 1.4.2 and earlier versions (which I'm hoping this report is for! ), 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!

Hello everyone, Long time no speak! I have been very busy IRL and with Orbital Decay lately so I apologize for the lack of replies and content. I myself have been playing through my own pack using both RSS, RO, RP-0 and KCT, the issues and solutions I have found are below: RP-0 prevents most of the Historic Missions from loading; this is due to the defined names of planets with RP-0/RO being different to those assigned by RSS, (as far as I can tell), RO uses a different version of the planet name from the GameEngine, using the planet type name rather than the planet defined name, for example RSS uses body.getName() and RP-0/RO uses body.name(), thus some parts of contract configurator parse correctly and others do not. My solution was to find and replace all instances of targetBody = Earth to targetBody = @Homeworld within each contract in the RSS version before starting a new game, this isnt ideal really but it works for now. I will make the necessary corrections for the next release. I may create a small plugin to automatically rename targetBody tags based on the plugins installed, this would be compatible with any contract pack and would enable RP-0 compatibility, but this will be afew weeks away! The early missions are dull... Yep you're right, even I skipped Explorer - 10 because of the repetitive nature, (oh and the 210 Soyuz missions are coming up.. ), I will try and spice up the early missions a tad! The deadlines, now these are a mixed opinion I can see, personally I like the idea of having to rush the build by 10% using KCT, reminds me of the haste of the space race itself, this combined with the high reward funds kind of makes the pack balanced in the early years, (Currently at 1965 relatively at the moment). Some contracts are too nit picky, by this I mean for instance Luna-1, as someone who has not actually played a full Realism career before getting to the Moon from an inclined launch site with little delta-v was tough, even tougher was being within 500Km of the surface to complete the contract... maybe some more realistic altitude requirements are necessary here! There is a void of Russian missions between 1961 and 1964; this is due to the pack currently only having missions up to Luna-4 and not all the way to Luna-16, I will add some more for the next update. The declining rewards for example Apollo - 11 400000 and Apollo-17 85000 was intentional to mirror the decline in interest from the world and thus decline in funding. All in all I have found some bugs I couldn't find by just staring at the contract files over the last year and hopefully I can improve the next version with what I have learned! Anymore suggestions for the next update are welcome, and thank you all for the interesting debates over the last few pages! Again I apologize for my lack of activity, hopefully once 1.5.0 of Orbital Decay is released I can get to work on this pack again. Furthermore I will be adding the pack to a GitHub repositiory this week, hopefully this will encourage some community involvement in the making of the pack from now on! P.S since the Witcher 3 dlc is out tomorrow, I may be away from the keyboard for a few days! Whitecat106

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

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. 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

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

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