chuckstables

Hi people, I bought KSP like YEARS ago, it must've been 2014 or 2015? I've tried logging on and resetting passwords on the store with all of my email addresses, I haven't gotten rid of any I've ever used and have got NOTHING! Do I have to buy it again then or something? Was there a time limit where you had to migrate over? If so that's kind of frustrating. Nevermind, was able to figure it out. Turns out I do in fact have one email I don't use, fortunately I have forwarding set up for it so all good. Would delete this but cant figure out how sorry

Simple answer; No. You can't do that. Here's why. An Nth order truncated geopotential has terms which go like 1/R^(N+1) in it, where R is the radius from the center of the planet. Therefore, for your kerbin, which has a radius about 3.125 times less than earth's, terms of order N in the geopotential will be 3.125^(N+1) times larger on your kerbin's surface than they'd be on earth's surface. For a 30th order geopotential this is about 7*10^14 times larger for the highest order terms. What you can do is make your own reasonable geopotential for your kerbin. For sun-synchronous orbits the most important term in the geopotential is the second zonal term, though for earth other terms contribute significantly. So you could just make a custom geopotential which only includes the J2 term (second zonal term).

I did the frozen orbit quite a while ago so no; I don't have any pictures. That being said it wasn't perfect; it ended up being unstable over a 12 month period with no correction burns. In GMAT the orbit was stable for around 3 years from what I remember with no correction burns, but the fact that it worked with a periapsis of around 30-40 km from what I remember is remarkable. I did it before the orbit analysis window actually was introduced as well; I just went forward in time. Here's the paper I based it off of; https://lunar.gsfc.nasa.gov/library/LRO_AAS_Paper_07-057.pdf In particular look at pages 10-11. I think it was technically a quasi frozen orbit. Still impressive in any case. The LRO these days is in a different quasi frozen orbit with an orbit of 20km x 165km. I think they wanted the Periselene to be lower so they could get more detailed images over the poles. Super interesting graphic by the way! I love stuff like that. Thanks for sharing. If I can replicate it again I will take some pictures and show you. What sort of frozen orbits have you tried to replicate? Thanks for taking the time to respond; I appreciate it.

Yeah definitely fair. I was more just curious whether it would be possible; I've always assumed that the cost of the N-body calculation for the solar system would be more than for a vessel, but that does make sense. I'm curious; what's your time step for asteroids and "unknown" objects? Is it the 10 second one or the 10 minute one? As an aside; I'm honestly super impressed that this mod actually exists; it's absolutely incredible. What's even more awesome is that it's free. I've gotten hours of fun times playing around trying to get quasi-frozen low lunar orbits. I was impressed to see that your selenopotential model was accurate enough to replicate the original frozen orbit of the Lunar Reconnaissance Orbiter. It's a testament to the hard work you guys put into this mod; so thank you.

It's not really that simple. You need high fidelity symplectic integrators to get stable orbits if you are going to go the numerical route. Otherwise energy is not conserved and orbits will diverge and become horribly unstable. It's far simpler using patched conics because the orbits are known EXACTLY with mathematical functions. Once you're in a sphere of influence you use math to determine the exact shape (a conic section) of your orbit and boom; you're done. Your spacecraft is now on rails; there is no need to determine the gravitational force acting on you. There is no real numerical integration here; everything is predetermined and on rails. If you add n-body physics your orbit is no longer known exactly. There is no closed form solution for a general n-body problem. Therefore you have to use numerical integration to approximate the 'true' orbit using a finite step size (as you can't simulate an infinite number of time-steps). Finite step sizes lead to energy not being conserved over longer time scales with most integration methods. You can get around this by using what's called a symplectic integrator, which conserves an energy-like quantity. You also need one in this situation where you can vary the step size to account for situations where you're travelling very fast near a planet, where the step size needs to be smaller. You also need a method which is computationally efficient enough to be run in high time warp. This is difficult to do, which is why the code is probably so large. The mod dev's also needed to add accurate geopotential models for RSS, which model the real gravitational field of planets/moons using a power series with spherical harmonics. They also need to add code to efficiently evaluate the analytical derivatives of each term in the geopotential (at least I'm assuming they analytically evaluate them). This is also difficult. I could write a symplectic integrator in python in about 100 lines; but to get it to run in KSP let alone to run efficiently would require a lot more than that.

Would you guys consider adding in an Ephemeris model for Real Solar System? That way we wouldn't have to simulate the full N-body dynamics of all the planets and they could just follow high fidelity trajectories that exist in a data file. There's lots of high precision Ephemeris models available for the solar system IRL for trajectory designs for missions. This could speed things up quite a bit. Just curious. Thanks!

Hey. I found a few errors in the configs for SSTU. These are pretty simple to fix; I'm using the latest download of Realism overhaul from github. In RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_SCC_Orion.cfg there's a source for a bug that makes it so that the capsule is stuck with the default resources it's given by SSTU. If you try to change these in game it will revert back to the default resources when you launch or reload the craft file. To fix this you have to add !MODULE[SSTUVolumeContainer]{} before you add the ModuleFuelTanks module and define the resources you want the part to have. So this MODULE { name = ModuleFuelTanks type = ServiceModules needs to become this !MODULE[SSTUVolumeContainer]{} MODULE { name = ModuleFuelTanks type = ServiceModule This needs to be done for the Orion Command Module, the Orion European Service Module, and the Orion orbital Command Module. All can be found in the SSTU-SCC-Orion.cfg file. There's another bug in that file which results from the wrong module being named for the RCS. As a result the RCS thrusters on these parts retain their SSTU definitions. Where it says @MODULE[ModuleRCS], It needs to be changed to @MODULE[ModuleRCSFX], This again needs to be done for all the orion parts. Not sure whether or not this is supposed to be posted here, so sorry mods if I'm not supposed to be posting this here! I spent a good hour trying to figure this out, and thought I'd post it to save you all the trouble of fixing it yourself. I personally fixed these issues on my own installation of Realism Overhaul. If the Dev's want me to send them the CFG files I can send the edited ones on GitHub? Just let me know. Thanks for creating this awesome mod guys! I enjoy it quite a bit.