• Content Count

  • Joined

  • Last visited

Community Reputation

166 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. @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...
  2. @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
  3. @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.
  4. 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)
  5. 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.
  6. 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.
  7. 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.
  8. @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.
  9. That is neither going to work, nor is it required, as the only thing my mod does is to generate a single config file for a much larger mod, so i cant test it on its own. And I also only wanted to see if it lagged noticible more with every body in the system having this feature. I have also already done it so that it does it to all of them, and i didnt notice any lag issues at all.
  10. I actually succeded in getting my mini mod to work. I am so happy that i actually managed to do it. My sattelite is in a perfectly circular 15km orbit over minmus, and the flightplan says that i will crash in a few orbits, as the hills and flats of minmus messes with my orbit. Now it is time to stress test this feature to see how many bodies i can give this to without lagging too much.
  11. I am not 100% sure that this counts as it is has nothing to do with cool looking space stations or anything like that(even tho that is cool too). But the thing that i am currently trying to do is to make a mini mod as an extension for the Principia mod(that mod that adds n-body gravity and such). Principia has a thing with RSS where it gives the Earth and the Moon what i call the "lumpy gravity condition", and for the Earth that means that it is slightly flattend due to its rotation as it is in real life. That means that if you have a sattelite in a high inclination orbit, the ascending and decending nodes will slowly rotate around the equator. And for the Moon it leads to low orbiting bodies being destabelized over many years, and will eventually crash into the surface. Principia will model all of these effects in RSS, but what i am aiming to do is to replicate this behaviour in the stock system as well. As for example, Minmus is very lumpy, so if i can give it equally lumpy gravity, the orbits around it should get very interesting. The main problem with all of this is that Principia wants a very special encoding for this lumpyness, and i think that i have finally managed to solve it. For this image, i have an image of minmus on the left, but on the right is my own small program to decode the special encoding that my mod spits out. And if You look closely, That ball on the right sortof looks like minmus, where the redder areas corresponds to the flats, and the greener areas corresponds to the highlands. What is so cool about all of this is that the special encoding enabled me to generate that right sphere using only about 40 numbers, instead of the 10000 i would need to get each height individially. And if you ask me, i think that giving lumpy gravity to minmus is quite cool.
  12. @eggrobin Over the past few days i have been making a mini mod thing for automatically generating the spherical harmonics needed to allow some of the stock bodies to have geopotentials.(My current "test subject" is Minmus) At this point in time i have managed to generate a suitible(i think) config file with the same format as the one in Principia/real_solar_system/gravity_model. principia_gravity_model { Body { Name = Minmus geopotential_row { degree = 1 geopotential_column { order = 0 cos = 2.01267793181124960E-004 sin = 0.00000000000000000E+000 } geopotential_column { order = 1 cos = -1.67248927462036320E-003 sin = 2.96599647369928530E-003 } } geopotential_row { degree = 2 geopotential_column { order = 0 cos = 8.05394019210287260E-003 sin = 0.00000000000000000E+000 } geopotential_column { order = 1 cos = -2.80339441217786760E-003 sin = 1.38156354030291020E-003 } geopotential_column { order = 2 cos = -5.70133104974222470E-003 sin = 3.12729158537247910E-003 } } ...up to degree 10... However, i am now having 2 problems. One is that i dont know where to put this new file(i am calling it gravity_model_extension). Can i still have it in my own mod folder and somehow link it to the principia folder, i have tried adding an @ to the of start principia_gravity_model, but that didnt work either. Two is does my file contain enough information as is or do i need more? (as i saw that the gravity_model file contained lots of other information like gravitational_parameter and reference_radius. Do i need that too, or am i good with what i have?)
  13. Although i didnt actually *make* Rega and its rings, i just moved it. Ant that also means that i cant use it without the kerbol origins mod, although maybe i can copy it but still... I didnt actually make it
  14. The mods i used was most of the near future technologies mods atleast i think that those were most of the important ones, might still be a few "trace parts" from other mods too but the NFT mods is by far the majority
  15. Recently i posted in this thread: Where my entry was the Kerberos ship i sent to Dres as a submission for this thread a while ago. Now i got abit inspired by this and(after getting some new shiny mods for station parts and radiators) decided to make an even larger version to send to explore the new solar system setup i have. This means that i hope that i will atleast swingby every body in the solar system(and plop down a manned lander on an many as i can, and that includes Moho and Eeloo). But as i had planned(and as the transfer window was nicely lined up as a bonus) I will go to Dres and its new friend Rega for the first stop. With 1600 tons on the pad and 260 tons in orbit, Kerberos 2.0 is even bigger than its predecessor with the one to two sizes wider(3.75 and 5 meters compared to 2.5 for the old one) core section. It has less "companions" in terms of relays and rovers and such. But it still carries a manned lander, a somewhat large miner, and 2 small survey sattelites. Actually took a picture of the launch this time. Sucessful deployment into orbit. Transfer to Dres went well(split the burn in 2 parts for this), forgot to take a picture of the hud becauce i was so busy getting everything to work, but it was basically the same as the previous mission so you can go look at that if you want Almost twice as many engines this time(and all of them worked due to proper radiators as opposed to Kerberos 1) Transfer burn completed to Dres, and here you can see the resources hud for the first time(i am horrible at documenting that aren't I...) To be continued once I arrive at Dres...