Whitecat106

Hello everyone, I apologise for my absence, this is all explained in my recent post in my Orbital Decay thread so please have a read. In short I am leaving the modding scene, moving on to producing my own unity game, as such I give permission to @Fengist and @linuxgurugamer to carry on, change, redistribute and do anything with this mod that they desire - just name a boat after me or something yeah? Thank you all for your help over the past few years and I hope you enjoy your KSP adventures! Farewell all! Kindest regards, Whitecat106

Hello everyone, I apologise for my lack of activity, this has been due to a number of factors of which I shall explain. - First of all, university; I simply do not have much time, especially due to my next reason. - Updating the mod for new versions of KSP; I am sick and tired of having to rebuild an element of the mod every time KSP updates, with no useful update log from the developers; which pretty much caused the death of my boat navigation mod with 1.0.3. Having begun modding with no experience of C# nor Unity, finding solutions to an undocumented change takes a long, and frequently, unnecessary amount of time for a trivial change to an already messily coded game. - Thirdly, my own interest in KSP has vanished, having played through my own historic missions to the early space shuttle age using every realistic detail, including this mod (in its last stable version), only to have the game slowly crawl through at a few fps,where a simple quick save takes almost a minute due to the ridiculously slow config file parsing built into the game even though the save file is smaller than the texture file for the orbital decay toolbar icon. With no sign of modernisation, (a touch of "we don't care now it's out of Alpha/Beta"), KSP for me has stopped being the game I started playing almost five years ago. This game is barely built for saving and loading, how can it possibly handle N-Body perturbation and still run any other mod? Hence I decided no more, for the past many months I decided I would make my own unity game, built for 2017/18 and not for 2011 as KSP is. Therefore I will be taking requests for someone to take over this mod, please send me a message and I can arrange this. This would also apply to my Historic Missions had I not discovered that the developers have already bulldozed over the work I put into the pack without a single comment, just a making history expansion with no mention of the community engagement in space history my mod produced - the reason the devs have made the expansion in the first place. I would have thought that over 50000 downloads of historic missions would have deserved a footnote in squads expansion - but as I along with many modders have known : the developers do not care about the modding community, the one thing that's stopped this incredibly limited stock game from being forgotten long ago. Thank you all for your support and help over the last three years, I hope you can appreciate my reasoning and understand my frustration. Kindest regards to all, Whitecat106

Hello there, Those are some really interesting points that you raise, I will open up an issue in github and have a look at KSPTOT and see what I think. I could possibly make a branch release with a reduced version of orbital decay that would act as an extension to KSPTOT, simply altering some numerical values before KSP sets these into vessel orbits. Working backwards at the moment seems to be a good idea, especially since I want to rebuild the code for the next version of orbital decay anyway; I'm sure I could look into this! Up to this point I had not realized this incompatibility! @sidfu, thanks for this! Since 1.2 new vessel types have been added so I will have to add a check for these in the UI. Added to the Github as #87. As for a note on progress, I have been thinking a lot and a rebuild of the code is in order for 1.6.0: - starting by trying to remove as many clunky 'foreach' loops as I can, generally try and reduce system strain, especially with large games. - I shall then work checking Mascon functions are working and accurate - this will include making Mascon maps for each planet in the stock and RSS systems - Maybe a scansat add on displaying such maps would be cool? Any ideas? - I will then fix and finalize some of the features I had planned for 1.6.0, including fixing the SCS plugin issues (resetting solar cycles randomly), fixing the in development VAB/SPH menu, better vessel sorting (by name, active, search). - If possible I will try and produce some compatibility with persistent rotation, (basically background Yarkovsky effect) - It would be nice to have to make sure you rotated in an axis perpendicular to a heat source to minimize decay! In the mean time, for 1.5.3 I would like to address any issues with the dropbox version I uploaded on Saturday, so please do let me know if everything is going good/bad and what I need to tweak! Of course time is still an issue, so any code submissions/pull requests would be greatly appreciated especially in the VAB/SPH editor utilities menu area. Whitecat106

Hello everyone, So I have compiled a build for KSP 1.2.X, this should be working just as well as previous versions of the game. An editor interface is now available to be opened which gives some information of vessel dimensions but I have run out of time today to get any more new features working. So give it a try from this dropbox link! Now as for where I want to go with the mod: -Once I get more time I really do want to have an N-Body model perturbing every orbit, including the planets, this however will probably only be possible in May/June time. As always any suggestions or code snippets would be appreciated and would be best sent as an issue or pull request on the github repository. Sadly the lack of time really is the deciding factor with what I get done here, if anyone would like to collaborate in further updates I would be very willing to share the work load. I am still motivated to produce a more 'accessible' n-body mod, that being said now that Principia has been released as a binary, I would request anyone desperate for N-Body orbits to check that out and see if Orbital Decay is compatible! As for mac users, @Simon91 I will certainly carry on development, probably with a completely new version of Orbital Decay (1.6.0) for a neater and less cpu intensive release, but as I said, it may take a little while! Enjoy and please do let me know of any problems, suggestions or anything else, preferably by raising an issue in the github repo as I tend to get notifications from github more directly than though the KSP forum! Whitecat106

Hello everyone, Sorry for the delay with everything! I have decided, after reading through the recent posts and the big issues with the N-body decay side that I will, for the mean time, remove the N-Body code from the mod and instead focus again on the original decay functions. The reason a KSP 1.2 version has not been released yet is due to a resource handling issue for station keeping; The original code for station keeping was written by zajc3w, however as of KSP 1.2.x the code seems to fail due to some of KSP's part module functions having been culled, I will release a tester version compiled for 1.2 later this afternoon but I need to specifically find out if the station keeping resources are being drained in the background as they used to be, this should work for RSS and Stock. This version will only be intermediary as I really do want to add in some better UI elements, fix some Mascon issues, and generally polish things up better, sadly I just don't have much time as of late. So the plan is this: - I will release a test version this afternoon for KSP 1.2 , probably via dropbox for anyone to test out and see if they can find any issues, this feature will include a new VAB menu and (hopefully) a work around for resource consumption, so I will post back on the forum with a link to this version once I have compiled it and removed some glaring issues today. - I will then fix anymore bugs and release 1.5.3 on Spacedock as a release version with just not many new changes. - Once I have more time I will work towards a 1.6.0 with some big code changes to Yarkvosky, Mascon and Radiation pressure, and bigger fixes as necessary. Thanks for your patience everyone! Whitecat

Hello everyone, Thank you all for your patience with this! I know everyone is eager to get a version that works with KSP 1.2! I still have a lot of work to do IRL but since Christmas is coming up I do have some more free time! So a note on progress! 1.6.0 is still on the way, still have to get round to totally rebuilding N-Body... and a tonne of other things... so in the mean time I have decided to work on a 1.5.3 patch just to make everything compatible with the new KSP. That being said I do not know when I will have this finished, or if there will be any new shiny features but I will try and keep you all updated! One big issue is the changes to the Orbit Driver method in the new version, this 'cleanup' has made a great deal of errors, this has hampered pretty much everything to do with the Mascon code and my future N-Body code, so I will have to write a new function for this, derived from the other orbital elements... possibly causing slightly more lag for the next version... especially since as far as I remember the mean anomaly function in question requires use of the Newton Raphson method over many iterations just to get an accurate value! Other than this I should be able to release a test version asap! If anyone wants to take a crack at the code before I can get a chance please do check out the Github, raise an issue and it will speed things up! Kindest Regards! Whitecat106

Hello everyone, For any that require, the following link is a dropbox link to the Maritime Pack source code, note this was last build on 1.0.4 so any use of the UI will be completely broken, references to Universal time etc will have to be changed and pretty much every .dll in KSPData will need to be a reference. I had planned when first releasing the pack to do a rover spin off but that never really became a thing due to Squads 1.0.5 buoyancy changes which ironically culled all of the water based mods and ground my work into the ground...or the sea.... I'm not bitter I swear But anyway please do extract whatever you can from my code, one day I may comeback to the maritime pack (had some great fun making everything) but for now I am focusing on Orbital Decay, that being said right now with University its hard to find time between the Astrophysics degree and drinking... Maritime Source Code (With 1.0.4 compiled release) Good luck with the mod @RealGecko and nice to hear from you @colmo, until next time, Whitecat106

I have encountered a few issues with Kopernicus on my end, but only with packs that alter the Sun (Kerbol), Kopernicus seems to want to add an atmosphere to re parented stars which can cause alot of problems with vessels being thrown off into escape trajectories. At the moment, I would air on the side of caution with Kopernicus planet packs, especially ones that alter the sun. However new horizons should not be a real issue, the problem might be to do with 6.4x, I will do some digging and get back to you! Hello everyone and sorry for my lack of replies lately, University has just begun and as such I have been far too horrendously drunk to solve the nbody problem! But not to worry, more is in the pipeline and hopefully I will have a 1.2 release version soon - a few more weeks for things to settle down and I will be doing some serious mod grinding to get 1.6.0 out to you all! Please for the moment ignore any error messages that pop up, the issue has been resolved with Mascons (hopefully!). If anyone could let me know if there are any problems with KSP 1.2 and the mod that would be great so I do not need to spend too much time catching up when I finally get a sober 10 minutes! Whitecat106

Hello there, There is a partially complete Github guide here. Currently the NBody breakdown function is only for display, eventually this will show something useful! The decay rate breakdown shows how the vessel orbit is being changed by various types of decay, giving some useful numbers. Check out the guide and let me know if you have any problems and I will be happy to help! If you would prefer, I can translate the guide into your native language and send it to you if it helps! Are you observing the vessel through the tracking station or by controlling the vessel (active)? As of 1.5.1 decay for active vessels has been temporarily turned off (since this would interfere with some aspects of 1.6.0), this will be turned back on for the next update but orbits should currently be decaying if observed in the tracking station or from another vessel just not an active vessel. Sorry about this! Let me know if this still persists as it may be a mod incompatibility! I am also running with an RSS install but everything seems to be working fine on my end. As for the Mascon Issue, please ignore this for the moment, seems to be a persistent bug with something dividing by zero - (I just havent tracked it down yet!), shouldn't effect gameplay too much! Whitecat106

Hello everyone, Thanks for reminding me about the Orbital Drift Compensation setting, completely forgot about it when I put out 1.5.2! I knew there was something else I had to include for the update! Anyway for now I shall leave the solution next to the download button on the first page, everything abit too messy at the moment for a 1.5.3, but 1.6.0 is coming. So far 1.6.0 features include: - NBody Simulation: will be completed for the next merge on Github, this may result in some lag at high timewarp but hopefully I have found a solution to cut down lag by reducing orbit simulation samples (at the cost of some accuracy) during exceptionally high timewarp (so the biggest issue will be full timewarp in an RSS-RO game). This NBody perturbation will only effect vessels that are a sufficient distance away from a planet,- purely for the sake of performance at the moment, e.g a small wiggle in a closely orbiting space station isnt really worth 1/2 a FPS, whereas a vessel with an eccentric orbit beyond the hill sphere of a moon of the Jupiter system is much more interesting and worth while; that being said the true performance impact will become apparent when I release a 1.6.0 testing version for everyone to try out and give some feedback! Station keeping will prevent n body perturbations, but will require a lot more fuel - pretty essential for rendezvous. - NBody conics, the code is pretty much there in the most recent Github update, the maths and the logic works... but for some reason the lines are a squiggly mess in the corner of the tracking station... this should surely be the easy bit... not to worry! This is my main goal at the moment, since the code for predicting the vessel positions used to generate the orbital path lines is pretty much identical to the actual vessel perturbation code. - When one works the other should too and with a visible path I can better check that everything is predicting correctly. The biggest issue at the moment is just putting things in the right type of coordinates (WorldSpace, ScaledSpace, RelativePositions and World Positions etc). - VAB-SPH UI: Contains information on your vessel, how long it would take to decay and how much station keeping fuel would be required for a duration etc etc - Plan your missions easier! - 50% complete, just need to add station keeping info etc. - Quick Load fixes: Stops that annoying bug I mentioned a few posts back! - User alerts: More visible, better timed alerts about when a vessel is running out of fuel, about to decay and has decayed. Maybe an alert for 50% station keeping fuel remaining? - Automatic force disabling of the Orbital Drift Compensation setting. - Map overlays for Hill Spheres and SOI's, (nice togglable circular lines around bodies so you can visually see intersections (needs the NBody conics to draw lines correctly first!). You can check out progress at the github, any assistance would be appreciated, especially with the conics drawing in the MapView. Its been a while working all of this out but I think everything is finally coming together abit more. I will not put up a .dll yet since the NBody perturbation equations need yet another rebuild (See Github issue #77 comments), so at the moment timewarp can cause the orbit to break entirely. Once conics are fixed I will rebuild the NBody code (pretty quick fix actually) and release a test .dll for everyone to try out the new features. Again, NBody will be completely optional because I know how much more complicated it can make interplanetary transfers etc... Any more issues that anyone can find, please let me know and I will add them to the 1.6.0 list. Whitecat106

Hello everyone, Orbital Decay should work fine, I have been using it in my own playthough with RSS and RO for quite some time, with the latest version and the latest RO install in KSP 1.1.3. If there are any obvious issues like orbits not decaying please do let me know in the Orbital Decay thread and/or the Github issue tracker here . That being said the latest version will need some tweaking for an RO and RSS play through, within the WhitecatIndustries/Orbital Decay folder lies a folder for PluginData, within this there should be a settings.cfg file, within this the line DecayDifficulty = 10 needs to be set to DecayDifficulty = 1, otherwise orbits will decay 10x as fast as real life. The mod itself has been made to follow realistic formulas as much as possible and so should be well suited to a RSS-RO career, if anyone has any issues with non decaying orbits please do let me know as soon as possible so I can fix this and ensure compatibility with RSS-RO Whitecat106

Good idea! I have noticed this myself actually, added to the 1.5.3 list

Might be worth checking also if you have any duplicates of .cfg files in the HistoricMissions/Missions folder, a reinstall would fix this Please let me know if you get everything running smoothly again!

Hello there, Im sorry to hear you are having trouble with the pack, I have also noticed this on my own RSS career save, pretty much had to reaccept and auto complete every contract up until my most recent one. This, I believe, is due to either the adjustments to the contract grouping system or some unforseen issue with the new Contract Configurator update, however Nightingale has just released a new version of CC which may fix some issues if you re download it. Apart from that I would try downgrading to an early version of CC and the 2.2.0 version of this pack, along with reloading from an earlier (hopefully backed up save). This issue does not seem to be just with my pack and seems to be effecting many others :S I would definitely stay tuned with the Contract Configurator thread and check there for updates, sadly there doesnt seem to be much I can do on my end Whitecat106

Hello there @M4ssler, I believe everything should work fine with Outer Planets, decay might be quite high around Sarnus for example, but everything should work.

@ebigunso sorry about this. Looks like a setting I changed accidentally then redistributed for both stock and Rss; I would recommend setting this to 1 instead of 10 - otherwise orbits will decay 10x faster! @Sol Invictus This setting is depreciated and should have no effect to gameplay, it was added pre 1.2.0 as an option to allow realistic decay instead of the former stock model (which no longer is implemented and only applied to atmospheric drag), the only decay formula used now is one based on actual decay equations as of 1.3.0 +! As for some other 1.5.2 things, the NBody simulation breakdown tab currently has no practical use as NBody simulation is not yet added, this simply shows a (possibly incorrect) display of velocity perturbations acting on the vessel per second (UT). Also the icons seem slightly misfitted, - the closest I could find from the Stock folder! I will find some more fitting for 1.5.3! Another plaguing issue is the quickload vessel orbit update issue, e.g quicksaving before a moon landing, crashing accidentally and reloading causing the vessel to reload at a position closer to the moon not equal to the quicksave position can be a pest, but can be remedied by deleting the cfg entry for the vessel in the VesselData.cfg file prior to quickloading. This will reload the vessel at the correct position at the time of the quicksave! This will be fixed in 1.5.3! As for 1.6.0; NBody is a real pain, in theory the process should be simple but I think afew days off and a complete NBody rewrite is in order to sort things out! In the meantime I will reduce the Github issue list and bring out a 1.5.3 with fixes for the issues above, some more mascon and yarkovsky fixes and a lifting of the atmosphere decay height limit (currently at 1000Km) so expect your small light geostationary satellites to decay in about 700 years! I will also be taking some time off to further develop the SCS plugin and work on a new mod I have had in the pipeline for afew months, and hopefully a revamp of my maritime missions contract pack since @Fengist has returned! Whitecat106

Hello everyone, 2.3.0 is out, this release includes a major update for Contract Configurator 1.15.3, some additions to the Mars/Duna missions and some general bug fixing and reworking. * Adjusted contract structure * Reduced resdistribute size * KSP 1.1.3 release version * Fixed multiple bugs * Added Phobos Program * Overhauled Mars Program; added Mars 3-7 * Added Viking 1 & Viking 2 For the moment the pack is not being released in subpacks (simply too much work to make sure every contract across four subpacks for both RSS and Stock are the same, to counter this I am working on a settings contract for the pack, this will enable the options to: - Play the full pack - Play an era, Early (1945-1975), Mid(1976-1996) and Late(1996 - 2026) - Play either Soviet or American missions only This however is not ready for the 2.3.0 release sadly, but I will be releasing a 2.3.1 as soon as possible to re-enable this feature, but now with the CC 1.15.1 update all contracts are visible and more suitably grouped with their requirements, as a result one should be able to auto complete any missions they do not want to play etc etc. I would recommend backing up your persistence file before updating as this version may be incompatible with former save games - sorry! Enjoy, Whitecat106

Hello everyone, Just put out a 1.5.2 which is a recompile for KSP 1.1.3, contains some small bug fixes and a UI filtering option, this is pretty much a mash up of some features of 1.6.0 but released early! As for the new main version release, hopefully I will be able to release N-Body decay by the end of the month... progress still slow I also have to shift some attention to Historic Missions for the new Contract Configurator update, but I will be working on the mod for a few hours this evening to see what I can do! At the moment the main issue is with Timewarp, for stock this is not much of a problem due to the timewarp limits, however in RSS the timewarp rate is much greater, so the sample time for NBody predictions has to be either increased...or more accurate, whilst keeping FPS above 50; not an easy task, but things are starting to fall together so fingers crossed everything will work out! Whitecat106

Hello there! Honestly I have not tried the two, but since KSP has a limited number of orbit changing functions I would assume this would be compatible for now. However in the 1.6.0 release of Orbital Decay, the two will not be compatible; with Principia effectively doing very similar things but in a somewhat more complex way! As for 1.6.0 progress, Although slow, I have been working on the NBody version, having some big problems so far but the framework is in place, hopefully once I can manage to accurately build the eccentricity, longitude of ascending node, argument of periapsis and mean anomaly from state vectors I will have working version. Of course I am having to do a great deal of simplification to bust lag (especially during timewarp), in the meantime however, if progress is still show by this time next week, I shall release 1.5.2 for KSP 1.1.3, this will include some FPS improvements for the UI, some UI filtering and afew more additions I was saving for the 1.6.0. If anyone has any experience in State vector orbital representation or more important the conversion factors for the different position/ coordinate systems in KSP please get in touch! At the moment the two body problem is pretty much solved, but the 3 body and thus n body problem still requires alot of work. As for new conics.... well that should fall into place once I can generate the orbit predictions accurately.. - Matlab would be pretty useful right now! I am leaving the body perturbations until last (so as to not further complicate the nbody simulator!) So in short, 1.5.2 for KSP 1.1.3 next week if I get really bogged down with this! If not hopefully some breakthroughs will speed things up! Whitecat106

Thanks for that! It would appear that this is an issue with 1.5.1, I accidentally forgot to update a small line of code, this is fixed for 1.6.0 but I would recommend downloading the 1.5.0 version from the SpaceDock to prevent this happening again until the next release,this may mean longer loading times for Module Manager but has the same features of the 1.5.1! Sorry for the trouble here! Cheers for the RVE instructions too by the way and the Lat/Longitude, I have noted this and this will be useful in my debugging of this issue!

Hello everyone, I have just updated the pack to 2.2.0 for the latest version of KSP. This version includes a multitude of fixes and changes: * Added Bion Program (12 Contracts) * Added Soyuz TMA-15M to Soyuz TMA-20M (5 Contracts) * Added Lunar Orbiter Program (5 Contracts) * Renamed TargetBody = Earth to TargetBody = HomeWorld() for RO - RP-0 support * Fixed Duration parameters across all contracts * Added Luna 6-9 (4 Contracts) * Replaced offensive logo * Multiple minor fixes * Total contract count = c.672 For 2.3.0 I will include the AVC for update notifications, more contracts (lets get to 700!), completion text for every contract and more detail to the existing pack, along with some fixes to Shuttle missions (post STS-45). For now, enjoy! Whitecat106

No problem! Wow that's a pretty gorgeous shot! Out of curiosity how did you manage to get RVE working with RSS? My install still has the standard EVE install and I just cant figure out how to make RVE work properly! I have added both points made about area calculations and drag coefficients to issues #71 and #72 respectively in the Github Work on the 1.6.0 version is coming along, having a magnitude of issues with the NBody simulation, starting to think I should change to an Astrophysics degree after all this! Basically everything works pretty well, maybe a little aggressively at the moment... probably some orbit.GetPosAtUT() accidentally somewhere rather than GetRelativePosAtUT(). The biggest issue is managing the system during timewarp, especially with RSS. Basically the NBody simulator works by: 1. Find the vessel location at a certain time (t) and the location of all influencing bodies nearby. 2. Calculate the resultant acceleration from each force at time (t) 3. Update the orbit based on the change in velocity as a vector. Now this works perfectly fine in regular 1x game time. However in timewarp this is a different matter all together since in an N-Body scenario a position point in the future can really only be determined by the result of forces acting on a satellite across the entire duration, of course this can be simplified but is still processor intensive. My current system to manage this works as follows: 1. Determine the UT at which timewarp began. Determine time since this began or since the last update to the system. 2. Define a time interval to sample the vessel across the time since timewarp began. (Since the Orbital Decay mod does everything based on steps of 1 second (for simplicity) this means a time interval at RSS full timewarp could be more than 100000 seconds in the future!) 3. Find the velocity vector from the acceleration vector imposed by n number of bodies in the system. 4. Calculate a new orbit prediction from State Vectors of the velocity and position at the current time. 5. Save this orbit to a list and update the time of last update. 6. Update the actual orbit of the vessel to this value when timewarp has ceased. The main problem is with point 4. KSP has a function that does just this, called .UpdateFromStateVectors(pos, vel, body, UT). However this automatically updates the actual orbit (thus updating before timewarp has ceased preventing 5. .and 6. from correctly working. What I am working on now is an extension to the orbitdriver.orbit method that will return a new orbit based on the state vectors but not actually set the orbit into 'reality'. Which is a real pain!!! The conics management has been put on hold until I can get the actual orbit predictions working properly, at which point I will delve into generating orbit lines for 'predicted paths', a rendezvous management system (Disable nbody movement if within 500Km of a vessel maybe), and possibly varying frames of reference - yay pretty pictures! In the meantime I would be grateful if anyone could help out at the Github page, looking over some code offering suggestions, pull requests are all welcome! Whitecat106

Hello! Yes I can see the issue you're experiencing, I noticed this myself for the Vanguard - 2 (decaying in the equivalent of 1961 for me), however as of now (1966 with a RSS RP-0 playthrough) Vanguard 1 from American Probe pack remains in orbit. I believe the issue stems from the area calculations of a vessel and the inclination of the vessel orbit with Mascons in consideration. The problem is that with off rails vessels, the area of the vessel does not really exist, thus stock calculations to manage the area fail to work. Instead I use a formula which creates an average area 'bubble' around the vessel. For proportionately shaped objects like spheres the area is close to the actual value but not quite. In this case the vanguard 1 probe area could possibly include the deploy-able antennas (so the area bubble is now more than double the actual area; thus causing a higher drag). The only solution to this would be to use part meshes to work out the exact (prograde) facing area, something I probably will not touch upon until 1.7.0. The coefficient of drag is another variable which I must look at, at the moment this has been hard coded to the fabled 2.2, however obviously this is variable; if I can calculate a more accurate coefficient I shall endeavor to for the next update! I am still working on 1.6.0 which will be the KSP 1.1.3 release version too, so bear with me on this. If anyone can find any issues with the current 1.5.1 version in the new KSP version please let me know since I have not yet downloaded KSP 1.1.3 and this will speed up the next release!

Thanks! I will hopefully add in a check to force this option off when playing with the Orbital Decay mod since this is a pretty big incompatibility, considering the decay rate is wholly inaccurate with imaginary numbers for the physics.cfg... thanks again squad... In my opinion; do it properly or leave it to the modders! @CoriW I am glad the vab issue has stopped, I have also encountered this but I cannot quite work out what is causing it As for the decay bug, it would appear its a feature squad added in with 1.1.0 without noting this in a change log, which to me is incredibly infuriating as I spent a lot of time trying to fix this issue by adapting my own plugin! Yet again. @NemesisBosseret I will need to see an instance of the error from your ksp output log to know whats going on, please post a small snippet of this showing the exception in this thread Still working on NBody perturbations, getting some mixed results, the biggest issue will be drawing conics (there is so little information on the web about this) and managing rendezvous (possibly a make or break with N-Body simulation). Whitecat106

Bizarre, maybe because FASA part modules are still outdated by a few updates? I am not sure, I have the Soviet probes packs installed and have not yet encountered this problem but I will certainly look into it. If you experience this with any other parts please let me know which parts these are so I can write some MM patches to fix this.