Whitecat106

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.

Sorry for the late reply on this one! You do not need to station keep in this scenario no. But as a word of warning to users at the moment; the estimated time to reentry really is an estimate, sometimes it can be too early, other times many days too late, trying to get this more precise for the next release, but the decay rate is always accurate, so if you are in a 500km x 500km orbit and the decay rate is 0.5m per day, you should not really have to worry about station keeping unless you want a precisely kept orbit. That said, Stationkeeping at a higher altitude will be more efficient than at a lower altitude. Taking a break from modding at the moment, spending some time actually playing KSP since my last proper game was KSP 1.0.5! Will be back to work in a few days or so, in the mean time, I will be here to fix any issues. Whitecat106

Hello everyone, This release should have fixed various issues from the 1.4.0 release such as: - Rendezvous Jumps - Resource handling issues - EVA Warps - NaN issues - Decay Rates - UI issues Hopefully this will be a little more playable than the last version! For 1.5.0 I will address any more minor issues and add in some new features including fixing the Active Vessel Decay during no time warp. However I will release a 1.4.3 if there are any big bugs that pop up. Enjoy, Whitecat106

As I recall this was included in version 1.6.0, however KerbalStuff evidently had differing rules to SpaceDock; thank you for drawing my attention to this, for 2.2.0 the flag will be replaced with another icon, that said '3rd reich icons' pretty much removes anything vaguely to do with rocketry.. So a politically safe non offensive image of an historical duck will have to suffice.

@Svm420, I am starting to wonder whether the game bug #9619 might even be intentional by squad rather than an actual bug, if so as you can imagine I will be pretty annoyed.. but I believe this is negatively influencing my testing and bug fixing of the plugin. Been working on the Kerbal Eva bug today, fixed the vessel jumps on Eva bug, next I will be working on the rendezvous bugs and other close proximity vessel issues. Update 11th May, Been working on 1.4.2 today, solved some bugs with Eva and proximity's, working on a new big bug with station keeping and resource rates, should be solved soon. Hopefully a release will be out by the end of the week! Update 13th May, Almost fixed everything, will hopefully have the patch release out today! 1.5.0 looks promising too, I will be including Mascon perturbation and possibly the Yarkovsky effect.

Something definitely is, rendezvous is a big problem, as for manned pods and unmanned I am unsure what is going on here, to be safe I am going to remove the download link again until I can get some stability back to everything!

You can delete said flag from the HistoricMissions/Logo folder, the contract will appear but the logo will be blank as a white image and a small exception will appear in the debug/Alt-F12 log. Since this issue has formerly been raised these will be my only suggestion from now on; this is a Historic Pack and as such I do not believe in censorship with similar matters; hence why Apollo-1, the Soyuz Accidents and the Shuttle Disasters have been included how they were originally supposed to be. Thanks for this! I will be looking through the pack for the next update to see if I can adjust this to something a little more user friendly! Hmm, the contracts should appear, and the flags should be force linked to only Historic Missions contracts, are you sure you have installed the pack correctly by copying the ContractPacks folder from within an 'era' subpack into your game data folder?

Hello everyone, Having some pretty major issues right now, trying to fix a newly apparent bug where an active Eva causes one or both vessels to lose all orbital velocity. To be honest the plugin is just becoming more and more buggy so I will try my best this week to get a new release out, if not it will likely be next week where I can rewrite and clean up the code again... Whitecat106

Hello everyone, Been working on fixes today, managed to fix the issues with NaN's in orbits and decay rates, still working on fixing the contract spawned vessel issues and the speed and magnitude of the stock decay rates, at the moment issues #29, #27 and #26 are the only ones holding back a 1.4.2 release to fix everything! Sorry again about this everyone, it seems like for every bug I fix; three more pop up from the fixes! Should have a fix out before Wednesday with any luck! Thanks for all your bug reports and images, I have a temporary solution for 1.4.1 NaNs and 'empty part config file' warnings: Just clear everything in your VesselData.cfg in the WhitecatIndustries/Orbital Decay/PluginData folder and paste the following into it: VESSEL { name = WhitecatsDummyVessel id = 000 persistence = WhitecatsDummySaveFileThatNoOneShouldNameTheirSave } As I said things are coming along, hopefully I can fix this contract issue as soon as possible, furthermore if you are worried about too high decay rates for small vessels you could open the WhitecatIndustries/Orbital Decay/PluginData/ Settings.cfg and set the DecayDifficulty to a lower value, the ingame settings slider only allows you to change the decay rate to 0.1 but you could bring this down in the settings.cfg to 0.01 or lower! I will include a wiki for 1.5.0 along with many new features, I just hope I can resolve these contract spawned vessel issues and balance the stock decay rates first! 1.4.2 will be out soon! Hopefully this information will help you continue playing if you have issues with NaN's and superfast orbit decay! @Svm420, wow interesting I didnt realise KSP would natively simulate decay to a vessels apoapsis; even if it is a bug! Hopefully this wont affect me, apart from possibly some contract issues... recover part 'blah' from LKO or if the stock rescue 'pod' is only one part. Thanks for the heads up though! Whitecat106

Thanks! That makes sense, possibly because some relics in my code from back in August last year ignore asteroids/unknown objects (these spawned vessels) and some include these, so there may even be some Nans being thrown around inside the code leading to the 50km/day decay rate, possibly causing the rendezvous issues too.

Ah yes, hopefully I can fix this one easily, looks like the system didn't properly recognize that the vessel existed so it assumed it had a mass of 1 and an area of 1 (hence the very fast decay rates), as for the rendezvous jumps probably an oversight on my part, that being said would it be possible for you to test a rendezvous between two vessels you have launched yourself and see if the jumping issue occurs again on rendevouz? I will be away from the computer for today and possibly tomorrow so I don't really have time to set up a scenario like this to test out!

Ah that could be a possibility, could you try temporarily removing the real fuels folder and seeing if this happens again? I thought I had fixed real fuel compatibility but then again I have changed the resource system in the latest version!

This is a pretty severe glitch! Not to worry I will look into this asap sounds like a nasty kraken attack possibly due to some Nan issue in the predicted decay time spreading to other areas of the game! Weird... I will look into this as soon as I can, probably some crossover bug when I set up the Stock decay system, can you check the alt f12 menu and see what exceptions are popping up?

Ahh I see the problem here, are you only having issues with contract spawned vessel rendezvous or general vessel rendezvous? The contract vessel may not be being simulated correctly, added to the 1.4.2 list! As for Nan per day, could you tell me the following: Rss or Stock? Moon or Kerbin/earth? And at what altitude was/is your vessel orbiting? Maybe a problem with formatting or a more serious issue involving the actual decay rate. Thanks, hopefully these will both be quick fixes! Whitecat106

Thanks! Just released 1.4.1 as a quick fix to a small resource rate bug that I noticed, the resource slider is now fixed, sorry about missing that one! I will be around to fix more issues and work on 1.5.0 on Sunday! Enjoy, Whitecat106

Whoops duplicate post!

Hello everyone, I have just released 1.4.0 here are a list of changes: - Fixed Stock and RSS Lag - Fixed Stock and RSS Resource Manager - Added Config node clearing - Fixed Radiation Pressure UI issues - Fixed Crash to Desktop on decouple - Added Hide GUI on F2 - Fixed Debris timewarp runaway - Misc Fixes and Changes - Stock decay system updated to a closer realistic approximation And completely rebuilt the resource and decay systems for integration with Mascon's and engine ISP's for 1.5.0, until then. Enjoy Whitecat106

Not to worry about this! I am about to release 1.4.0 which fixes this exact issue and the stock problems, just checking everythings in order at the moment. Expect a release within the hour which corrects this station keeping fuel bug and fixes stock decay! Whitecat106

This is due to these missions having no 'cool down' period, an issue I will fix for 2.2.0, if you were to accelerate time for 10 days or so the Sputnik missions would appear and the chronological order would be restored! Whitecat106

During Station Keeping resource handling is at the moment just a proportion of the decay rate, I had intended on adding in, as you say, consume 50dv of fuel based on the change in orbital velocity experienced but this requires information on the fuel consumption, ISP, engine count etc that I simply haven't got round to programming yet! Maybe for 1.5.0 I will take a look at this, I know that Kerbal Engineer or Mech Jeb have displays that indicate the current fuel to delta v ratio, (such as those seen in the VAB scene). Send me a PM if you want to know more and Ill see what I can do to help when I have a little more time!

This mod is designed for compatibility with both the Stock game and the Real Solar System mod by @NathanKell , at the moment alot of work has been done to make this mod compatible with RSS and as such the stock side of the mod has been neglected, for the next update I will be looking at and fixing the stock version of this mod. I have had to make a separate decay formula for the Stock game since the planets are so small in stock (in comparison to RSS and real life) the equations simply break, so this is why the mod functions differently with stock than RSS. As for the teleporting issue this has been fixed for the next version! Thanks though! Once I have fixed the stock side of the plugin I will release 1.4.0. (probably by this evening or tomorrow!) Whitecat106

Hello there, I notice that you are using a mostly stock install, thus the mod is using the stock decay system. This works in two ways; background (Non active vessels) and foreground (active vessels). With this system the size and mass of the vessel directly influences the decay rate (in a mostly opposite way to that of real life). For example, a large but light satellite will have the same rate of decay as a small but heavy satellite, if you have a small and light satellite in orbit the decay rate could be very low. This might explain why the satellites decay rate is so low in the background, but even then 10 meters in 6 years is incredibly slow... The active decay system kicks in when the vessel is the active vessel in a flight scene, the decay rates here are the same as in the background but their implementation leaves much to be desired, I have struggled a great deal trying to find a method of updating the active vessels velocity with a calculated velocity reliably - without crazy rates or eccentricity changes, I suppose this is a worst case scenario of the differences between the two systems I will see what I can do for 1.4.0, I have been focusing on RSS alot lately and the stock system needs some love so these issues are on my to do list next! Thanks for the report though, I will see what I can do for the next release! In the mean time try checking out the decay rates on a larger heavier satellite and seeing how much greater the decay rate is. Whitecat106

It will not have an effect on the decay rates no; the stock decay rate is more hard coded, but I made the SCS compatible with both - producing a different length cycle based on the days in the Kerbin / Earth years, this is so that if anyone wants to use my SCS plugin for developing a realistic solar radiation / solar flare / solar magnetism mod they can make it cross compatible with Stock or RSS!

Hello everyone, Just working on a few more things for the 1.4.0 release, trying to nail down this eccentricity problem again, I am also waiting to see if any more issues pop up that need to be addressed. For 1.5.0 I am hoping to include more realistic perturbations for objects orbiting non atmospheric bodies. This has already been partially implemented in 1.1.0 with Solar Radiation Pressure drag, but this is only a small component of real lunar (and beyond) perturbation. As an example, Apollo-17 prior to leaving Lunar orbit, deployed a small satellite to measure gravitational changes in the lunar surface and subsequent perturbations to orbiting satellite, this mission, intended to last many months, lasted just afew weeks before the orbit of the satellite destabilized and it crashed into the surface of the moon. This prompted research into Gravity Anomalies and Mascons (Mass Concentrations); although gravitational fields are assumed to be regular in KSP, in reality gravity is pretty variable. On Earth, the effect to satellites is negligible since: A) the satellites are forced to orbit much higher (above 140km) and B) gravitational variation is relatively low. On the moon however, gravity can be disturbed by Mascons by up to 0.00045 of a G-Unit. This seemingly small change effects the local gravity of the moon at a position by up to 0.03 m/s^2, this causes massive changes in satellite orbits, in Inclination, Semi Major axis, Eccentricity and Mean Anomaly. Completely changing vessels in unstable/non station keeping orbits. So my intention is to map the current models of Mascons of the Earth and the Moon into the game, this will not be easy and will only be beneficial to RSS, but this is the next logical step for realistic decay modelling, I will also produce estimated maps of every other solar body to complete the system. Whitecat106

Sorry everyone, been abit tied up with Orbital Decay at the moment! Thanks @nightingale for helping @Crocn, I hope everything is fixed now, I did look through everything on my end but as far as I can see the continuity of the pack is not broken around Venera-13 but I will check anyway! Working on 2.2.0 now, this will include many more contracts (hopefully getting to that 700 mark... I'll stop soon I promise...), and some more balancing for the pack and also making sure no RSS contracts have a max orbit level too close to the atmosphere of the planet. Whitecat106