• Content Count

  • Joined

  • Last visited

Community Reputation

176 Excellent


About Eriksonn

  • Rank
    Ion thruster repair man

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Despite what it seems like, i have never actually done any manned moho mission ever, not even landed on moho in any way whatsoever, so good job getting there and back so early into the game. About overengineering stuff, i tend to do that in kindof the opposite way to most people, as i dont feel like "more boosters" really fit with my personality very much. Instead i tend to focus on effective upperstages and multi layered gravity assists. (I really like the near future mod that adds more ion engines and stuff) I also overengineer on my gravity assists and flight plans, i also use the principia mod for n-body gravity as that makes orbits so much more interesting in my opinion. So one can say that i overengineer my orbits instead of overengineering my rockets.
  2. the new principia version doesnt work for me... The Principia DLL failed to load. Dependencies, namely the Microsoft Visual C++ 2015-2019 Redistributable (x64) - 14.22.27821, were not found. what should i do about this?
  3. I kindof gave up on all of the advanced math for getting the geoids of arbitrary planets, and decided instead to semi brute-force it. To the left is Minmus and to the right is the geoid of Minmus scaled up by a factor of 3. I have not yet implemented this in my little mod, as i want to see if i can optimize it somehow first, as it takes a few seconds to compute everything. And that will be even worse when i need to do it over all of the bodies instead of just minmus. Luckely i have recently learned to use multithreading, so that will definitly help to speed things up.
  4. That was exactly what i ment, that the ship would need 10^3800 tanks, and the same amount of stages, as i assumed that each tank was staged off as it get empty. That is indeed almost exactly the average deltav per stage Not sure what you ment by expoentiall larger stages, as each stage is just a single tank, if it was becauce of the sun example, that was just a demostration of the amount of tanks required
  5. in my first post on this topic, my math showed that you need 10^3800 stages, that is a 1 followed by 3800 zeroes, to put that in perspective, that would be like taking all the atoms in the entire sun, and making each one of those atoms into a whole sun, and then replacing all the atoms in each of those suns with xenon tanks, only then would you get somewhat close to the amount of tanks/stages that you will need
  6. I kindof guesses that infinite fuel was allowed, but i enjoyed doing the math regardless, just to give a perspective as to how hard it would be without infinite fuel
  7. Firstly i am abit confused by the sentance: as i dont really know if those things are allowed or disallowed, but assuming that those are not allowed there is a massive problem here: I think that you are underestimating the speed of light, as 300 million m/s is vastly faster than any normal speed that people are used to(and that includes all of the high speed crashes into the mun that would be considered very fast by non-ksp players) Just becauce i am that type of person i am going to do the math on how much is needed to get to that speed in the stock game. As much as i like them, i am going to ignore gravity assists, as whatever can be gained from them is completely negligable compared to lightspeed. I was at first going to write how i got to the final awnser, but that got longer than i expected, and was hard to read as i cant get fancy math notation here... Therfore i will just tell you about my final results instead. So if we assume a ship made entirely out of one ion engine and a bunch of the large xenon tanks, and we stage off each individual tank when empty, then the deltav for a ship with N tanks is approximatly 32961*log(N) m/s. I know that that equation seems kindof small, and it is, but the process to get it was not simple, and i did kindof give up slightly at the end, as the problem actually didnt have a nice mathematical solution, so i approximated abunch and got this, although this is a damn good approximation despite the amounf of guessing and trial and error that went into making it. Anyhow, lets get to the results... so if we want a ship with 300 000 000 m/s in deltav, we need e^(300000000/ 33785) tanks. This number has 3856 zeroes if written out in decimal form, and this is for the most effective spacecraft physically possible in the stock game. To put that number in context for a bit, filling the entire observable universe with xenon tanks will not even be close to the amount that we need, 10^80 compared to 10^3856. That means that we still have 10^3776 times too few xenon tanks. Oh and btw, the amount of tanks needed is very sensitive to the weight of the engine and the rest of the spacecraft, as adding an extra 300 kg of stuff to this Engine+tanks spacecraft(like for example a probecore, a few batteries and a few solar panels), increases the tank count by about 10^300
  8. @eggrobin I have read through that link that you sent, but i have reached a dead end, as that whole paper seems to assume that i have the disturbing potential as well as the topography, and i only have the topography. But it should be possible to get the geoid with only the topography, atleast if constant density is assumed. I tried to do a brute force approach, but that was very slow, and i am not confident in its accuracy. Most of the papers i find on this seems to either use ground measurements of the gravity or computing other values that i dont care about, by using the geoid as a given. So i am abit stuck right now...
  9. @eggrobin Ah, that makes sense. I made this little diagram for myself, and now it makes perfect sense why having the geopotential be equal to the terrain is a bad idea. Now i need to throw myself back into the sea of strange math(ie, the link you gave me) to find a way to get the correct smooth version of the geopotential
  10. @eggrobin Hmm, so you are saying that having the geoid be equal to the terrain height is a bad approximation for a constant-density body? I will take a look at that link you gave and see if i can find something interesting. About the coefficients, I already guessed that the degree 1 coefficients were not useful as they would make the body have a center of mass that is not aligned to its rotation axis, and that makes no sense. So I have already removed degree 1 from my config output.(the one about Minmus that you referenced is abit outdated) That degree 2, order 1, I did not know was problematic, but i guess that i can remove that one too, if principia dont care about it either. (Although it would be interesting to know why it is problematic/doesnt matter) I am just using the Body.TerrainAltitude() function to get my terrain height, and i would strongly guess that for most bodies their center of mass is not necceraily aligned with their "origin" as the game sees it. As I have already removed the degree 1 component, I am not sure how much of a problem that is.
  11. It actually has nothing to do with saves, it generates one single config file that then works on any save. I have put a small boolean variable in the settings file if one wants to re-run it as it needs to be re-run if the solar system changes(Becauce of planet packs and the like) I sortof fixed that by simply increasing the density of my sample points, so now that problem is negligable compared to the "usual" values that occur simply by the lumpyness of the planet/moon itself. (the "problem" is now about 10 times smaller than what the other values usually are)
  12. I already fixed the config files, otherwise i wouldnt be able to make take those screenshots. But i apparently forgot to edit that question. I simply(the math wasnt simple...) get the terrain height for each latitude and longitude, and then use the "discrete inverse spherical harmonic equation" on the whole body to get the coefficents. This is the main code for this: for (int i = 0; i < ResolutionWidth; i++) { for (int j = 0; j < ResolutionWidth / 2; j++) { //get the longitude and latitude of the current point on the surface double Longitude = Math.PI * 2 * (i / (double)ResolutionWidth); double Latitude = Math.PI * 2 * (j / (double)ResolutionWidth); //get the terrainheight from the center of the body, scaled by radius double CurrentRadius = 1+Body.TerrainAltitude((j*360.0 /ResolutionWidth) - 90, i * 360.0 / ResolutionWidth) / Body.Radius; //a scaling factor that accounts for increased density of sample points close to the poles, and also for the total surface area of the body double AreaScale = (Math.Sin(Latitude)) / (ResolutionWidth * ResolutionWidth * Math.PI); for (int n = 0; n <= MaximumDegree; n++) { for (int m = 0; m <= n; m++) { //save the total scaling factor so that i dont have to use it twice //(TODO)as both the P and Normalization functions contain factorial terms that gets messed up if MaximumDegree>10, //i should "bake in" these functions into the for loops themselves, so that i can support higher degrees than 10 double Q = AreaScale * CurrentRadius * P(n, m, Latitude) * Normalization(n, m); //I am using a precomputed lookup table for the cos() and sin() functions to be more performace friendly. //A little optimazaiton never hurts ;) CosArray[n][m] += Q * CosTable[i, m]; SinArray[n][m] += Q * SinTable[i, m]; } } } } That is a good idea, as currently everything has the same degree. Once my mod can handle it, I will have to look at some higher degrees to see what the trend is. I am already ignoring Stars and planets like Jool as they have no surface and is perfectly round(interestingly though, my program did generate some low but noticable factors even for Jool, especially the n=2,m=0 cos factor was alot higher than any other factor for Jool, but still lower than any other body. It seems like the algorithms is biased to the poles for some reason, but the error went down significantly by adding more sample Points(default is now 200x100, but can be changed in the Settings.cfg)) That sounds good, that (probably) means that I wont need to worry about giving geopotentials to too many things at once.
  13. Firstly, the main mod for this is the principia mod that I didnt make. My mod only adds some config files That principia uses. I am not fully done with my little mod either. I can still awnser your questions tho. a) It will (as any other orbit), keep orbiting when you are not looking. And can destabelize when you are not looking, so keep an eye out on sattelites in lower orbits- b) Yes, and it also depends on the "lumpyness" of the body you are orbiting. Minmus is quite lumpy and Gilly is even worse. The Mun and Ike are less lumpy, so they wont be as suceptible to this. I did some tests and it appears that a 30km orbit around mun is just barely stable enough to not collide, but a 50 km orbit is fine. Both of those options gets quite a high inclination after a while(maybe 5 degrees or thereabout). A 25 km orbit of Minmus seems fine aswell. Compared to the radius of each moon, the stable minmus orbit was further out due to the higher lumpyness of minmus.
  14. I think that you could add it to an existing one(it wont crash or anything), but then you have to be real quick to save some of your stuff depending on where they are. On minmus for example, yes it gets messed up at 15km, but once you extend the orbit to 30km or so, it quickly gets stable again. So only very low orbits around very lumpy things will be at risk. So a low orbiting minmus sat might need fixing, but a space station around duna is probably safe. Even the mun is quite safe, becauce it isnt as lumpy as minmus, so a mun station is also probably good.
  15. @eggrobinSo i think that i have finished my little mod for adding geopotentials to the stock system(or rather any system except RSS). It generates a single config file that links to the principia_gravity_model config that is used by principia for the RSS geopotentials. It generates up to degree 10, wich i think should be good enough, and as i am doing it for every body(everything is the default, although a whitelist is also an option) i dont want to have too high degree as i am not sure how performace intensive this operation is(i havent gotten any more lag than usual on max warp using this, so i think it is fine). In this image i am orbiting in a circular 15km orbit around minmus, but due to the hills and flats, the orbit gets destabelized, and eventually crashes into minmus. Here is the same orbit from the side, to show that it also affects inclination. It even works with modded planets/moons. This one has a very oblate shape, leading to a very high precession rate of about 40 degrees per orbit. Now i think that i will make my own thread for this little mod when i am feeling done with it(should be soon i hope), and then i can make a link to it from here. I hope that it is ok for me to do this and if you want you can maybe mention my mod in a more direct way, so that others can see it. Becauce i think that having stock geopotentials is a very neat and exciting thing to be able to have. I hope that this sounds like an interesting concept. Tell me if you have any questions about anything.